Hat das Aufkommen der SSD Auswirkungen auf die Datenbankoptimierung?

Heute habe ich ein Buch über die SQL Server-Optimierung durchgesehen und es schien, dass ein gewisser Teil der Ideen auf einem linearen Speichermodell beruhte. Verändern SSDs, die ein völlig anderes Speichermodell haben, in irgendeiner Weise das Spiel in Bezug darauf, wie man über Datenbankoptimierung oder -optimierung denkt?

Ja, sie verändern das Spiel. Optimierungen, die auf den Eigenschaften sich drehender Magnetplatten basieren (wie Suchzeit und Rotationsverzögerung ), sind bei SSD-Laufwerken möglicherweise nicht relevant. In einem kürzlich in FITME 2010 veröffentlichten Artikel ^{* wird} ein neuer Algorithmus zur Abfrageoptimierung vorgestellt, der auf den Eigenschaften von SSDs basiert.

Bei diesen Änderungen handelt es sich jedoch wahrscheinlich um Änderungen auf niedriger Ebene (z. B. bei Speicher- und Abrufalgorithmen), die von Datenbankentwicklern effektiv implementiert werden können. Sie wirken sich wahrscheinlich nicht auf Datenbankbenutzer aus.

^* IEEE Xplore - Eine spaltenorientierte Speicherabfrageoptimierung für Flash-basierte Datenbanken

Performance

SSDs sind leistungsfähig: Sie müssen nicht suchen, und der Durchsatz ist enorm. Die meisten Software-Programme, die sich mit Festplatten befassen, sind, soweit sie optimiert sind, so optimiert, dass die Anzahl der synchronen Suchvorgänge verringert wird. Dabei führen sie eine Vielzahl von Komplexitäten ein. Mit dem Aufkommen schneller, suchloser Schreibvorgänge für dauerhaften Speicher erfordern neue Datenspeichersysteme keine derartigen Komplexitäten mehr.

Haltbarkeit

SSDs weisen derzeit hohe Ausfallraten auf. Ihre SSD wird ausfallen. Ihre SSDs fallen mit einer viel höheren Rate aus als Magnetplatten. Sie müssen dies mit Replikation, Backups usw. umgehen. Dies führt zu einer Reihe von Komplexitäten.

Die allgemeine Reduzierung des Speicherpreises hat weitaus tiefgreifendere Auswirkungen.

Bevor wir SQL hatten, hatten wir superoptimierte Hierarchie- und Netzwerkdatenbanken, in denen Datenbankadministratoren die Platzierung von Daten nachverfolgen und zylinderförmig planen mussten.

SQL-Datenbanken sind viel weniger effizient. Aber jetzt, da die Festplatten billig, riesig und schnell sind, ist es uns egal.

NoSQL-Datenbanken ("Document") können etwas weniger effizient sein als SQL, da das logische SQL-Schema und das zugrunde liegende physische Schema von Dateien oder Tabellenbereichen oder was auch immer nicht die gleichen Funktionen für die Zuordnung von logisch zu physisch aufweisen. Und es interessiert uns kaum.

Die SSD-Leistungsverbesserungen gehen wahrscheinlich durch die Änderungen verloren, die durch die Verwendung von NoSQL-Datenbanken an der Art und Weise verursacht werden, wie wir Systeme insgesamt entwerfen.

Das Hauptproblem bei der Optimierung von SSDs hat mit dem Schreiben von Daten zu tun. Eine herkömmliche Festplatte speichert normalerweise Daten in kleinen Sektoren von etwa 512 Bytes und kann Sektoren direkt auf oder sogar unterhalb dieser Ebene bearbeiten.

SSDs haben einige Nachteile in Bezug auf Schreibvorgänge:

• Eine minimale Blockschreibgröße von ca. 4-8 KB.
• Schreibvorgänge können nur auf einer vollständigen Seitenbasis von normalerweise 256 KB ausgeführt werden.
• Es können nur leere Blöcke beschrieben werden.

Ein typisches Alptraumszenario, das als Write Amplification bezeichnet wird , besteht darin, dass Sie ein einzelnes Byte an eine Stelle auf der Festplatte schreiben möchten, an der bereits einige Blöcke verwendet werden. Um dort zu schreiben, müssen Sie zuerst die gesamte 256-KB-Seite in den Speicher kopieren, den gesamten Block löschen, das einzelne Byte auf der Seite ändern und dann die gesamte modifizierte 256-KB-Seite zurückschreiben. Um ein einzelnes Byte zu schreiben, wurde ungefähr ein halbes Megabyte "Verkehr" erzeugt!

Es gibt viele Optimierungen für dieses Problem, die auf SSD-, Controller- und sogar Betriebssystemebene implementiert sind. DBMSs können jedoch zweifellos davon profitieren, wenn sie diese Optimierungen an ihre spezifischen Funktionen anpassen.

Dies ist jedoch nichts, worüber Datenbankbenutzer nachdenken müssen (wie bei der Verwendung einer Datenbank in ihrer Anwendung), da dies in hohem Maße von Entwurfs- / Implementierungsentscheidungen auf DBMS-Ebene abhängt.

Nach dem , was ich aus dem ServerFault- Blog erfahre , müssen Datenbankserver über umfangreiche Hardware verfügen. Auf dem Datenbankserver der Stack-Exchange-Sites werden SSDs ausgeführt (siehe http://blog.serverfault.com/post/our-storage-decision/ ), und ich würde mir vorstellen, dass die Abfrageoptimierung immer noch sehr wichtig ist. CPU und Speicher sind sowohl von Datenbankabfragen als auch von E / A betroffen.

Die Datenbankleistung hängt jedoch in hohem Maße von E / A ab, sodass SSDs sicherlich Abhilfe schaffen.

Ja, aus den Gründen, die jeder angegeben hat.

Ich habe mir einen Podcast angehört, in dem gesagt wurde, dass große Teile von RDBMSs wie Oracle, SQL Server usw. als "optional" eingestuft werden, wenn sie die Trennung ordnungsgemäß durchführen können. Ermitteln Sie, ob es sich um ein SSD-Laufwerk handelt, und optimieren Sie es entsprechend.

Es ist eine Menge zusätzlicher Code in das Caching und Schreiben von Daten eingebaut, der einfach nicht mehr benötigt wird.

Noch interessanter ist der RAMSAN und seine Varianten. Grundsätzlich handelt es sich um ein Festplattenlaufwerk aus RAM-Chips mit einer eingebauten X-Hour-USV und der Möglichkeit, im Hintergrund auf einen längerfristigen Festplattenspeicher zu schreiben.