it-swarm.com.de

Warum erstellen Datenbanken nicht automatisch ihre eigenen Indizes?

Ich hätte gedacht, dass Datenbanken genug über das wissen, was ihnen häufig begegnet, und in der Lage sein würden, auf die Anforderungen zu reagieren, unter denen sie stehen, um Indizes zu stark angeforderten Daten hinzuzufügen.

32
Jharwood

Update

Dies ist jetzt in SQL Server Azure implementiert. Es generiert Empfehlungen

(enter image description here

und Indexverwaltung kann automatisch konfiguriert werden .

Automatische Indexverwaltung aktivieren

Sie können den SQL Database Advisor so einstellen, dass Empfehlungen automatisch implementiert werden. Sobald Empfehlungen verfügbar sind, werden sie automatisch angewendet. Wie bei allen vom Service verwalteten Indexoperationen wird die Empfehlung zurückgenommen, wenn die Auswirkungen auf die Leistung negativ sind.

Ursprüngliche Antwort

Einige Datenbanken erstellen bereits automatisch Indizes.

In SQL Server kann der Ausführungsplan manchmal einen Operator Index Spool enthalten, mit dem das RDBMS dynamisch eine indizierte Kopie der Daten erstellt. Dieser Spool ist jedoch kein dauerhafter Teil der Datenbank, der mit den Quelldaten synchronisiert ist, und kann nicht von Abfrageausführungen gemeinsam genutzt werden. Dies bedeutet, dass die Ausführung solcher Pläne möglicherweise wiederholt temporäre Indizes für dieselben Daten erstellt und löscht.

Möglicherweise können RDBMS in Zukunft dynamisch gelöscht und persistente Indizes entsprechend der Arbeitslast erstellt werden.

Der Prozess der Indexoptimierung ist letztendlich nur eine Kosten-Nutzen-Analyse. Zwar haben Menschen im Prinzip möglicherweise mehr Informationen über die relative Bedeutung von Abfragen in einer Arbeitslast, aber es gibt keinen Grund, warum diese Informationen dem Optimierer nicht zur Verfügung gestellt werden könnten. SQL Server verfügt bereits über einen Ressourcen-Governor, mit dem Sitzungen je nach Priorität in verschiedene Workload-Gruppen mit unterschiedlichen Ressourcenzuordnungen klassifiziert werden können.

Die von Kenneth erwähnten fehlenden Index-DMVs sollen nicht blind implementiert werden, da sie nur die Vorteile einer bestimmten Abfrage berücksichtigen und nicht versuchen, die Kosten des potenziellen Index für andere Abfragen zu berücksichtigen. Es konsolidiert auch keine ähnlichen fehlenden Indizes. z.B. Die Ausgabe dieser DMV meldet möglicherweise fehlende Indizes für A,B,C und A,B INCLUDE(C)

Einige aktuelle Probleme mit der Idee sind

  • Die Qualität einer automatisierten Analyse, bei der der Index nicht erstellt wird, hängt stark von der Genauigkeit des Kalkulationsmodells ab.
  • Selbst im Bereich der automatisierten Analyse kann eine Offline-Lösung gründlicher sein als eine Online-Lösung, da eine Online-Lösung dem Live-Server keinen großen Aufwand für die Buchhaltung hinzufügen und den Hauptzweck der Ausführung von Abfragen beeinträchtigen muss.
  • Die Indizes, die automatisch als Antwort auf die Arbeitslast erstellt werden, werden notwendigerweise als Antwort auf Abfragen erstellt, die sie als nützlich erachtet hätten, sodass sie hinter Lösungen zurückbleiben, die die Indizes im Voraus erstellen.

Es ist wahrscheinlich vernünftig zu erwarten, dass sich die Genauigkeit von Kalkulationsmodellen im Laufe der Zeit verbessert, aber Punkt 2 ist schwieriger zu lösen und Punkt 3 ist von Natur aus unlösbar.

Dennoch befindet sich wahrscheinlich die überwiegende Mehrheit der Installationen nicht in dieser idealisierten Situation mit qualifiziertem Personal, das Änderungen der Arbeitslast kontinuierlich überwacht, diagnostiziert und antizipiert (oder zumindest darauf reagiert).

Das AutoAdmin-Projekt bei Microsoft Research läuft seit 1996

Ziel dieses Projekts ist es, die Datenbanken selbst zu optimieren und zu verwalten, indem das Wissen über die Arbeitslast genutzt wird

Auf der Projekthomepage werden mehrere interessante Projekte aufgelistet. Eine ist hier besonders relevant für die Frage

Ein weiteres interessantes Problem tritt auf, wenn kein DBA verfügbar ist (z. B. eine eingebettete Datenbank oder ein kleines Unternehmen). In solchen Szenarien kann ein kontinuierlicher Indexoptimierungsansatz mit geringer Berührung wichtig werden. Wir haben Lösungen untersucht ... [in] " Ein Online-Ansatz zur Optimierung des physischen Designs " in ICDE 2007.

Die Autoren geben an

Mit zunehmend verbreiteten DBMS-Funktionen wie Online-Indizes ist es attraktiv, automatischere Lösungen für das Problem des physischen Designs zu finden, die den Stand der Technik voranbringen.

Das Papier stellt einen Algorithmus vor

Seine Hauptmerkmale sind:

  • Bei der Optimierung von Abfragen identifizieren wir einen relevanten Satz von Kandidatenindizes, die die Leistung verbessern würden. Mit dieser Funktion kann die Abfrageverarbeitung parallel zu den im Hintergrund erstellten Indizes fortgesetzt werden.
  • Zur Ausführungszeit verfolgen wir die potenziellen Vorteile, die wir verlieren, wenn wir keine solchen Kandidatenindizes haben, sowie den Nutzen vorhandener Indizes bei Abfragen, Aktualisierungen und Speicherplatzbeschränkungen.
  • Nachdem wir genügend „Beweise“ dafür gesammelt haben, dass eine physische Designänderung von Vorteil ist, lösen wir automatisch Indexerstellungen oder -löschungen aus.
  • Der Online-Charakter unseres Problems impliziert, dass wir im Allgemeinen hinter optimalen Lösungen zurückbleiben, die die Zukunft kennen. Durch sorgfältige Messung der Beweise stellen wir jedoch sicher, dass wir nicht wesentlich unter „verspäteten“ Entscheidungen leiden, wodurch die Höhe des entstandenen Verlusts begrenzt wird

Die Implementierung des Algorithmus ermöglicht eine Drosselung als Reaktion auf Änderungen der Serverlast und kann auch die Indexerstellung abbrechen, wenn sich die Workload während der Erstellung ändert und der erwartete Nutzen unter den Punkt fällt, den es als sinnvoll erachtet.

Das Fazit der Autoren zum Thema Online versus traditionelles physikalisches Tuning.

Die Online-Algorithmen in dieser Arbeit sind nützlich, wenn DBAs über das zukünftige Verhalten der Arbeitslast unsicher sind oder keine Möglichkeit haben, eine umfassende Analyse oder Modellierung durchzuführen. Wenn ein DBA vollständige Informationen über die Workload-Eigenschaften hat, wäre eine statische Analyse und Bereitstellung durch vorhandene Tools (z. B. [2, 3]) eine bessere Alternative.

Die Schlussfolgerungen hier ähneln denen in einem anderen Artikel Autonomous Query Driven Index Tuning

Unser Ansatz kann den Indexberater nicht schlagen, wenn die gesamte Arbeitslast im Voraus bekannt ist. In dynamischen Umgebungen mit sich entwickelnden und ändernden Workloads führt der abfragegesteuerte Ansatz jedoch zu besseren Ergebnissen.

25
Martin Smith

Das von Ihnen eingerichtete Indexdesign ist eher eine Kunst als eine Wissenschaft. Das RDBMS ist nicht intelligent genug, um allgemeine Workloads zu übernehmen und eine intelligente Indizierungsstrategie zu entwerfen. Es liegt an der menschlichen Intervention (sprich: DBA), die Arbeitsbelastung zu analysieren und den besten Ansatz zu ermitteln.

Wenn es keine Strafe für Indizes gäbe, wäre es ein Shotgun-Ansatz, nur eine unendliche Anzahl von Indizes hinzuzufügen. Da sich Datenänderungen (INSERTS, UPDATES und DELETES) jedoch auf die aktivierten Indizes einer Tabelle auswirken, wird dieser variable Overhead dieser Indizes auftreten.

Es erfordert menschliches Design und Strategie, um intelligent Indizes zu erstellen, die die Leseleistung maximieren und gleichzeitig den geringsten Aufwand für Datenänderungen verursachen.

20
Thomas Stringer

In der Tat gibt es einige Datenbanken, die dies tun. Beispiel: Googles BigTable und Amazon SimpleDB erstellen automatisch Indizes (obwohl auch keine RDBMS) . Es gibt auch mindestens eine MySQL RDBMS-Engine , die dies tut. SQL Server auch verfolgt die Indizes, die Sie erstellen sollten , obwohl es nicht so weit geht, sie tatsächlich zu erstellen.

Das Problem ist überraschend schwer zu beheben, daher ist es kein Wunder, dass die meisten Datenbanken sie nicht automatisch erstellen (BigTable/SimpleDB kommen damit durch, weil sie keine willkürlichen Verknüpfungen zulassen, was dazu führt Dinge deutlich einfacher) . Das Erstellen von Indizes im laufenden Betrieb ist außerdem ein zeitaufwändiger Prozess, der den exklusiven Zugriff auf die gesamte Tabelle erfordert - definitiv nicht, wenn die Tabelle online ist.

Angesichts der Anzahl der LAMP-Webanwendungen, die von Amateuren geschrieben wurden, die nicht einmal wissen, was ein Index ist , denke ich immer noch an diese Funktion wäre für manche Menschen von Vorteil.

Obwohl es bereits einige ausführliche Antworten gibt, scheinen sie die eigentliche Antwort zu umgehen: Indizes sind nicht immer wünschenswert.

Mit der in den Kommentaren erwähnten Autoanalogie sollten Sie besser sagen, warum nicht alle Autos mit Extremsportpaketen ausgestattet sind. Teilweise sind es Kosten, aber es liegt auch an der Tatsache, dass viele Menschen keine Niederquerschnittsreifen und steinharte Federung benötigen oder wollen. es ist unnötig unangenehm.

Vielleicht haben Sie 1.000 Lesevorgänge für jede Einfügung. Warum nicht einen automatisch erstellten Index? Wenn die Tabelle breit ist und die Abfragen unterschiedlich sind, warum nicht mehrere? Möglicherweise ist das Festschreiben zeitkritisch und die Lesevorgänge nicht. Unter diesen Umständen kann es nicht akzeptabel sein, den Einsatz zu verlangsamen. Möglicherweise arbeiten Sie mit begrenztem Speicherplatz und können es sich nicht leisten, zusätzliche Indizes in den verfügbaren Speicherplatz zu integrieren.

Der Punkt ist, dass Indizes nicht automatisch erstellt werden, weil sie nicht die Antwort auf alles sind. Beim Entwerfen von Indizes geht es nicht nur darum, "Hey, das beschleunigt meine Lesevorgänge" zu sagen, sondern es gibt noch andere Faktoren, die berücksichtigt werden müssen.

10
Matt

Sie können frühere Abfragen analysieren und Indizes vorschlagen/erstellen. Dies funktioniert jedoch nicht optimal, da Indizes ein Gleichgewicht finden, um das zu beschleunigen, was Sie optimieren möchten zu einem Preis und der Server Ihre Absichten nicht kennen kann.

6
JamesRyan