Grundsätzlich - kann DB mehrere Indizes kombinieren?

[jobo]

Zitat von mm1256:

..
Bitte korrigiere mich, wenn ich da etwas falsch sehe:

Systemumgebung: Auch wenn die DB auf deinem eigenen Test-Server mit anderer Hardware läuft, sollten zuverlässige Ergebnisse möglich sein. Dass die Ergebnisse/Zeiten natürlich von der realen Umgebung beim Kunden abweichen, ist mir schon klar. Die Relation der Unterschiede untereinander dürfte jedoch eindeutig zu erkennen sein. Und darum geht es doch letzendlich. ..

Ja, darum geht es primär und das kann man testen, auch in Relation.

Ich würde aber ergänzen:
Der springende Punkt bei solchen Systemen ist, dass sie idR einer Fülle von anderen Anforderungen- von OLTP bis ggF. Reporting- ausgesetzt sind, dass sie über Monate bis Jahre getuned und optimiert wurden und zwar bis in die Formulierung einzelner Abfragen hinein. Und das sehr wahrscheinlich zu einem guten Teil mit einem empirischen Vorgehen, sprich "nicht nachvollziehbar". Status Quo im Produktivsystem ist dann einfach, dass es eben läuft. Und das lässt man nicht gern fahren für einen blöden Index von einem Externen für einen Report, den kein einziger Manager braucht.
Das Risiko ist einfach, dass das System bei irgendwelchen zuvor harmlosen Abfragen kippt und steht.

Das bedeutet am Ende, die Änderung mag für sich Sinn machen und funktionieren und fürchterlich viel Speed bringen für die Abfrage. Wie aber reagiert der Rest des Systems? Das kann ich nur in einem Echtsystem feststellen in dem ein Arbeitstag, eine Arbeitswoche, ein Abschluss, etc pp durchgeorgelt wird.

[Blup]

Variante 1: Ein Index, der die selben Spalten in der gleichen Reihenfolge und Ausrichtung (desc) enthält, wie diese in der Abfragebedingung auftreten.
- optimale Geschwindigkeit bei der Abfrage
- wenn sehr viele Indexe, Zeitaufwand beim Insert/Update
- hohe Entwicklungskosten und Pflegeaufwand

Variante 2: Für jede Spalte die in der Abfragebedingung auftaucht einen eigenen Index.
- Zeitaufwand bei der Abfrage

Meine Erfahrungen decken sich mit dem Zitat von Uwe Raabe:

Bei Interbase ist Variante 1 fast schon zwingend.
Variante 2, erfordert die Abfrage auf dem Server sehr viel Speicher und ist um Größenordnungen langsamer.

Unter Firebird sind Variante 1 und 2 dagegen fast genauso schnell bei der Abfrage.
Deshalb würde ich in der Regel dort Variante 2 einsetzen.

[IBExpert]

kleiner Hinweis in dem Zusammenhang übrigens in Bezug auf Performanceunterschiede bei viel/wenig Indizes
Folgende Werte habe ich vor kurzem mal in einer Kundenschulung ermittelt:

Tabelle

Code:

create table test
(id bigint not null primary key,
txt varchar(80))

Variante 1: auf der Spalte TXT wurde genau 1 Index angelegt
Variante 2: auf der Spalte TXT wurden 100 Indizes angelegt

Test Insert von 10000 Datensätzen

Laufzeit Variante 1 mit einem Index auf TXT: 0,35 Sekunden
Laufzeit Variante 2 mit 100 Indizes auf TXT: 12,31 Sekunden

Zu viele Indizes anlegen, die man eigentlich nicht braucht, ist also ein erheblicher Zeitfaktor beim Schreiben.
Vorteile ergeben sich daher bei Firebird für die Variante single column indizes, weil der Optimierer diese
nach Bedarf kombiniert benutzen kann. Für andere Datenbanken gilt diese Regel aber eben nicht, weil die meisten
eben keine Indizes kombiniert benutzen können.

Ich sehe auch immer wieder Datenbanken beim Kunden, wo gleichartige Indzes mehrfach existieren. Das lässt sich
mit einem SQL in Firebird über RDB$INDICES und RDB$INDEXSEGMENTS relativ einfach finden. Auch non unique Indizes
auf Feldern, wo eh schon unique indizes existieren, ergeben selten Sinn.

Es ist auch hier wie fast immer: Es kommt drauf an, was man braucht und wie die eigene Umgebung damit umgeht.

Ach ja, und ergänzend: Bei Tabellen mit 200 Mio Datensätzen oder noch mehr würde ich auch versuchen, kombinierte
Indizes gemäß der SQL Anforderungen bereitzustellen, weil bei wirklich großen Datenmengen (meiner Meinung nach
ab 10 mio Datensätze) die Kombination von Single Column Indizes nicht unbedingt den gleichen Speed ergibt.
Wenn die Kombinierten Indizes aber nicht passen oder halt was fehlt, wie hier bei der ursprünglichen Kundentabelle,
dann sollte man eben ggf. die verschlechterte Schreibleistung in Kauf nehmen, weil am Ende der Server weniger
Last durch unsinnige Lesevorgänge hat und über alles betrachtet fast immer trotzdem bessere Performance haben wird.


Testgrundlage war hier wieder Firebird 2.5.4

[Dejan Vu]

Es ist grundsätzlich keine gute Idee, in einer zeitkritischen Umgebung irgendwelche Abfragen. Ich würde in solcher einer Umgebung alles auf die Produktivperformance legen und dann über einen Synchronisationsmechanismus (Replikation, Shadow o.ä.) eine 'Reporting-DB' pflegen, die dann eher abfrageoptimiert ist.

[BlackbirdBerlin]

Hi zusammen.
Nochmal der Hinweis, dass es sich hierbei um SAP handelt und da hängt i.d.R. eine Oracle oder DB2 drunter und für Reporting gibt's oft ein extra BI-System. Diese Daten, um die es hier geht, werden aber aus dem ERP gezogen, da nicht bei jeder Gesellschaft die gleichen Voraussetzungen (z.B. BI vorhanden) herrschen. Der gemeinsame Nenner ist das ERP und das Vorhandensein der größtenteils identischen Datenbasis darin.
Viele Grüße
Tim

[Dejan Vu]

Alles klar. Danke für den Hinweis. Hast Du meine Links gelesen?

[BlackbirdBerlin]

Ja, danke. Die hatte ich gesehen und "schnell-gelesen"
Ich habe Bitmapped-Indexes (das sollte ja die technische Basis zur Kombination von Indizes mit einem Feld jeweils) so verstanden, dass diese bei sehr großen Datenmengen und bei hoher Kardinalität wenig sinnvoll sind.
Daher scheint es mir unumgänglich, einen kombinierten Index über alle Felder, die in meiner Abfrage verwendet werden, zu definieren.

Hoffe, ich hab jetzt nix durcheinander gewürfelt...

Viele Grüße
Tim

[jobo]

Zitat von BlackbirdBerlin:

..Hinweis, dass es sich hierbei um SAP handelt und da hängt i.d.R. eine Oracle oder DB2 drunter..

Rein aus Interesse: Mit welchen Versionsständen wird da gearbeitet?

[BlackbirdBerlin]

Hi Jobo,
welche Versionsstände meinst Du?
SAP (welche Komponente), DB, ...?
Viele Grüße
Tim

[jobo]

Zitat von BlackbirdBerlin:

welche Versionsstände meinst Du?

Vor allem DB, SAP kenne ich kaum, vlt die Komponenten um die es hier bzw. beim DB Zugriff geht.