Zum Inhalt springen

Staubsaugen der Datenbank

Eine neue Ära der Massenspeichergeräte

Einer der Hauptgründe für das Staubsaugen von Datenbanken ist die Speicherung, nicht nur wegen der Kapazität, sondern auch um die Lebensdauer der Geräte zu verlängern. Protip: Wenn Sie den Unterschied zwischen Festplatten und Datenbanktechnologien bereits kennen, fahren Sie mit dem letzten Teil fort, um zu sehen, wie wir mit unserer Staubsaugertechnologie erfolgreich waren.

Festplatten (HDDs) beherrschen seit vielen Jahren den Markt. Kürzlich wurde eine neue Technologie mit Solid-State-Laufwerken (SSDs) entwickelt. Beide Technologien haben eine enorme Entwicklung mit Verbesserungen in Bezug auf Geschwindigkeit, Zuverlässigkeit, Kapazität und Preis erfahren. Da SSDs billiger werden, ersetzen sie in vielen Anwendungen Festplatten.

Wie HDDs auf konzeptioneller Ebene funktionieren, ist den meisten Entwicklern gut bekannt, aber bei SSDs gibt es viele Missverständnisse. Wir werden daher eine kurze Einführung in beide Technologien geben, um die Szene für die folgende Diskussion vorzubereiten.

Erweiterte Lebensdauer der Hardware

Festplatten (HDDs)

Festplatten speichern Daten auf rotierenden Magnetplatten mithilfe von Lese- / Schreibköpfen, die an Roboterarmen angebracht sind. Aufgrund der Verwendung beweglicher Teile ergeben Lese- und Schreibvorgänge auf Festplatten im Vergleich zu integrierten Schaltkreisen (ICs) eine hohe Latenz. Abhängig vom tatsächlichen Festplattenmodell werden die Daten möglicherweise nicht sofort geschrieben, sondern in der Steuerung gespeichert, um später geschrieben zu werden. Dieser Ansatz verbessert die Schreibleistung auf Kosten der Haltbarkeit. Um die Auswirkungen auf die Haltbarkeit zu minimieren, sind Festplatten häufig mit einem großen Kondensator oder einer Batterieunterstützung ausgestattet, die es ermöglicht, die Daten zu schreiben oder im Falle eines Stromausfalls in einem flüchtigen Speicher zu speichern

Aufgrund der Funktionsweise von Festplatten werden Daten immer in Seiteneinheiten gelesen und geschrieben. Moderne Festplatten haben eine Seitengröße von 4.096 Byte (oder 4 KB) und das tatsächliche Layout der Daten auf dem Plattenteller ist für den Host nicht direkt sichtbar.

Solid-State-Laufwerke (SSDs)

SSDs speichern Daten auf speziellen ICs ohne bewegliche Teile und bieten eine geringe Latenz bei ihren Lese- und Schreibvorgängen. im Vergleich zu Festplatten. Diese ICs werden auf besondere Weise zusammengebaut, damit SSDs kostengünstig sind. Diese ICs werden von nun an als Flash-Speicher bezeichnet. Die Beschreibung hier ist vereinfacht und nicht ganz korrekt, da die Details auch vom tatsächlichen Hersteller und Modell der SSD abhängen.

SSDs verwenden dieselbe Seitengröße wie moderne Festplatten, obwohl der Aufwand für den Zugriff auf eine Seite im Vergleich zu einer Festplatte nahezu vernachlässigbar ist. Das Lesen einer kleinen Anzahl von Bytes von einer SSD ist viel effizienter als von einer Festplatte. In der Diskussion hier wird davon ausgegangen, dass die dem Host präsentierte Seitengröße mit der Seitengröße des Flash-Speichers übereinstimmt. Wie bei der Festplatte ist das tatsächliche Layout der Daten im Flash-Speicher für den Host nicht direkt sichtbar.

Der Flash-Speicher ist in mehrere Sektoren unterteilt und jeder Sektor hat mehrere Seiten. Jede Seite kann eine begrenzte Anzahl von Malen geschrieben werden, und bevor die Seite aktualisiert werden kann, muss der gesamte Sektor, in dem sich die Seite befindet, gelöscht werden. Dieses Schema hat einige Konsequenzen.

Wenn Daten aktualisiert werden, schreiben SSDs sie auf eine „frische“ Seite (Copy-on-Write) oder auf eine Seite, auf die seit dem letzten Löschen des Sektors noch nicht geschrieben wurde. Durch dieses Schreiben wird die Seite "verwendet". Die Seite mit den alten Daten wird als "veraltet" bezeichnet.

Zusätzlich zu normalen Schreibvorgängen werden verwendete Seiten regelmäßig von Sektoren mit vielen veralteten Seiten in Sektoren mit neuen Seiten kopiert. Ein Sektor, dessen Seiten als veraltet markiert sind, wird gelöscht, wodurch alle Seiten dieses Sektors frisch werden. Dies hat den Nettoeffekt, dass mehr frische Seiten für normale Schreibvorgänge verfügbar sind. Das Löschen eines Sektors kann eine teure Operation sein und ist häufig der Engpass für die Schreibleistung. Dieser Vorgang wird als Speicherbereinigung bezeichnet.

Eine effizientere Speicherbereinigung ist mit mehr Sektoren mit vielen veralteten Seiten möglich. Grundsätzlich gibt es drei Arten von Datenänderungen. Datenerstellung, Datenaktualisierung und Datenlöschung. Herkömmliche Festplatten befassen sich nicht mit dem Löschen von Daten, da Seiten stattdessen vom Dateisystem ignoriert werden. Bei einem Solid-State-Laufwerk kann die Speicherbereinigung effizienter durchgeführt werden, wenn diese ignorierten Seiten bekannt sind. Dies wird durch den ATA-Befehl TRIM oder den SCSI-Befehl UNMAP implementiert.

Es gibt viele andere Aspekte von SSDs, die hier für die folgende Diskussion nicht erwähnt werden müssen. Weitere Informationen finden Sie in Wikipedia.

Datenbanktechnologien

Herkömmliche Datenbanken verwenden Datenstrukturen, die die Anzahl der gelesenen Seiten minimieren. Dieser Ansatz ist entscheidend, wenn herkömmliche Festplatten verwendet werden, da die Zeit zum Abrufen der Daten proportional zur Anzahl der gelesenen Seiten ist. Dies gilt zum Teil auch für SSDs, da die E / A-Kanäle für HDDs optimiert sind. Die Daten können jedoch um eine Größenordnung schneller von einer SSD als von einer HDD abgerufen werden.

Datenbanken implementieren normalerweise die Haltbarkeit (eine der Eigenschaften von ACID) Verwenden eines Transaktionsprotokolls, das die tatsächlichen Benutzerdaten enthalten kann oder nicht. Die für das Transaktionsprotokoll geschriebenen Seiten und die für das aktualisierte Datenbankabbild geschriebenen Seiten landen wahrscheinlich auf demselben Sektor, da sie ungefähr zur gleichen Zeit geschrieben werden. Dies gilt insbesondere für kleine Transaktionen. Die Seiten für das Transaktionsprotokoll werden normalerweise vor den kürzlich geschriebenen Seiten des Datenbankabbilds veraltet. Dies bedeutet, dass diese Sektoren möglicherweise bald veraltete Seiten haben, die Speicherplatz beanspruchen, oder dass die Sektoren bald den Schwellenwert für die Speicherbereinigung erreichen. Die Leistung kann in beiden Fällen abnehmen.

Staubsaugen der Datenbank

RDM 15.0

Mit RDM 15.0 haben wir einen anderen Ansatz gewählt. Auf Dateisystemebene besteht die Datenbank aus einer Reihe von Paketdateien, die Benutzerdaten, Indizes und Metadaten enthalten, die für die Wiederherstellung und das Staubsaugen erforderlich sind. Diese Packdateien werden zusammenfassend als "Pack" bezeichnet.

Die Dateisystemperspektive des Pakets

In diesem Abschnitt werden einige vom Dateisystem beobachtete Merkmale des Pakets beschrieben und wie sie sich auf die E / A-Leistung der SSD auswirken.

Ein Pack besteht aus mehreren Pack-Dateien mit einer maximalen Größe von 2 GiB. Pack-Dateien werden nacheinander durch Anhängen an das Ende geschrieben. Die Gesamtgröße der Packdateien wird unter einem Schwellenwert gehalten. Wenn Packdateien gelöscht werden, werden sie immer in der Reihenfolge gelöscht, in der sie erstellt wurden.

Da Packdateien nacheinander geschrieben werden, wird wahrscheinlich eine Folge von Seiten für ein bestimmtes Pack im Vergleich zu anderen E / A-Ladevorgängen zusammengeballt, insbesondere bei einer großen Transaktionslast. Wenn ein solches Clustering angenommen wird, werden diese Sektoren wahrscheinlich erst dann einer Speicherbereinigung unterzogen, wenn die Packdatei gelöscht wird.

Wenn die obige Annahme nicht der Fall ist, muss die Datenbanklast möglicherweise auf einer separaten Partition oder einer separaten SSD gespeichert werden, um die erforderliche Leistung zu erzielen. Diese Details liegen außerhalb unserer Kontrolle. Aus Sicht des Datenbankdesigns ist dies jedoch das Beste, was wir tun können, um eine E / A-Leistung auf einer SSD zu erzielen.

Staubsaugen im Raima Database Manager (RDM)

Die Pack-Implementierung wird in diesem Abschnitt erläutert. Wir werden mit Beobachtungen früherer Versionen von RDM beginnen und das RDM 15.0-Design vorstellen. Wenn Sie in die technischen Details eintauchen möchten, erfahren Sie mehr in unsere Dokumentation.

Frühere Versionen von RDM

RDMe 12.0 und älter (”RDMe”) verwendete ein Transaktionsprotokoll. Dies bedeutete, dass Daten normalerweise zweimal geschrieben wurden - zuerst in das Transaktionsprotokoll und dann in die eigentlichen Datenbankdateien. RDMe speicherte auch Elemente mit fester Länge, und in einigen Fällen mussten zusätzliche Inhalte an anderer Stelle separat gespeichert werden. Dieses Design führte zu Platzverschwendung und zusätzlichem Overhead, wenn der Inhalt aufgeteilt werden musste. Es war auch nicht möglich, die Daten zu komprimieren.

RDM 14.0 ist die erste Version von RDM, die im Gegensatz zum herkömmlichen Transaktionsprotokoll und Datensteckplätzen mit fester Länge einen speicherinternen Schlüsselwertspeicher (ID-Index) und ein Paketformat für die Datenverwaltung verwendet. Es wurde jedoch Speicherplatz in den Packdateien wiederverwendet. Ein Update des Pakets wurde immer mit einer Kopie beim Schreiben von der Originalseite auf die Seite durchgeführt, auf der Speicherplatz verfügbar war. Der ID-Index verfolgte diesen nicht genutzten Speicherplatz. Diese Nachverfolgung und die Datenstrukturen, die zur effizienten Nutzung des nicht genutzten Speicherplatzes erforderlich sind, erwiesen sich als recht teuer. Es verhinderte auch die Wiederverwendung von Speicherplatz in Kombination mit Massenschreiben. Die E / A-Leistung war ebenfalls alles andere als optimal, da Daten in Seiten geschrieben wurden, wenn nur ein Bruchteil der Seite aktualisiert wurde.

RDM 14.1 und RDM 14.2 verfolgten einen etwas anderen Ansatz. In den folgenden Abschnitten werden wir hauptsächlich das 15.0-Design diskutieren, das dem 14.2-Design ähnlich ist. Das 15.0-Design hat auch einige Merkmale mit dem 14.1-Design gemeinsam.

RDM 15.0

RDM 15.0 behebt alle oben genannten Probleme mit einem völlig anderen Ansatz. Beim Schreiben wird weiterhin kopiert, der nicht verwendete Speicherplatz in den Pack-Dateien wird jedoch nie wiederverwendet. Stattdessen wird immer mit Datenstrukturen, die keinen ID-Index verwenden, an das Ende der letzten Packdatei geschrieben. Dies bedeutet, dass Sie vermeiden können, auf Seiten zu schreiben, auf denen nur teilweise Speicherplatz verfügbar ist.

Nicht genutzter Speicherplatz in Pack-Dateien wird mit einem Prozess namens "Staubsaugen" gelöscht. Das Staubsaugen ähnelt der zuvor beschriebenen Speicherbereinigung, mit der Ausnahme, dass das Staubsaugen auf Packdateien anstatt auf Sektoren auf einer SSD ausgeführt wird. Wenn es richtig gemacht wird, verbessert das Staubsaugen die Müllabfuhr erheblich.

Speicherplatz vs Verwendete Seiten

Beim Staubsaugen werden zwei Hauptziele gegeneinander abgewogen: Verringern des gesamten Speicherplatzes für eine Datenbank und Verringern der Anzahl der Seiten, auf denen sich die Datenbank tatsächlich befindet. Die Optimierung für das eine könnte gegen das andere wirken. RDM 15.0 staubsaugt immer die älteste Packdatei “, was das erste Ziel begünstigt. Wenn die älteste Packdatei nicht referenziert wird und ansonsten nicht benötigt wirdwird es gelöscht und erst dann löschen wir tatsächlich die Packdatei. RDM 14.1 favorisierte das zweite Ziel, indem es die Packdatei mit dem niedrigsten relativen „In-Use“ saugte. RDM 15.0 kann mit weniger Metadaten im Paket davonkommen, da nur die ältesten Paketdateien gesaugt werden. Dieser Ansatz hat auch den Vorteil, dass die Metadaten für gelöschte Daten im Rahmen des Staubsaugens nicht kopiert werden müssen, wodurch die Kosten für das Staubsaugen weiter gesenkt werden. Und schließlich verbessert die Optimierung des Speicherplatzes auch die SSD-Leistung.

Lesen vs Schreiben

Ein Aspekt, der nicht übersehen werden sollte, ist Lesen versus Schreiben. Wie oben erwähnt, wird durch aggressives Staubsaugen die Gesamtgröße der Datenbank begrenzt. Oft noch wichtiger ist, dass aggressives Staubsaugen Daten, die verwendet werden, zusammen mit weniger verschwendetem Speicherplatz dazwischen gruppiert. Dies ist wichtig, wenn es darum geht, was sich tatsächlich auf jeder Seite befindet. Das Beibehalten von Datenclustern kann dazu führen, dass mehr verwendete Daten möglicherweise auf weniger Seiten passen und somit im Arbeitssatz des Dateisystem-Cache verbleiben, wodurch möglicherweise die kostspieligen E / A für das zugrunde liegende Blockgerät reduziert oder beseitigt werden. 

Kompromiss zwischen Schreibvorgängen und Gesamtgröße Es gibt auch einen Kompromiss zwischen der Menge der geschriebenen Daten und der Gesamtgröße des Pakets. Je nachdem, wie die Anwendung gestaltet werden soll oder wie der Administrator oder der Benutzer das System konfigurieren muss, kann es schwierig sein, genau zu wissen, wie das richtige Gleichgewicht zwischen beiden hergestellt werden kann. Das ist wahrscheinlich die größte Herausforderung bei diesem Ansatz. Beachten Sie jedoch, dass die Alternativen zu diesem Ansatz nicht sehr effizient sind. Wir haben gesehen, wie ineffizient es sein kann, Speicherplatz in Packdateien wiederzuverwenden oder ein Transaktionsprotokoll zu verwenden.

Das Nettoergebnis dieses Ansatzes ist, dass Daten wie RDM 12.0 und älter möglicherweise mehrmals geschrieben werden. Der Unterschied besteht jedoch darin, dass Schreibvorgänge für RDM 15.0 geclustert werden und mit einem geeigneten Schwellenwert für das Staubsaugen eine hervorragende E / A-Leistung und Leistung erzielen Speicherbereinigung in der SSD sehr effizient, wie zuvor erläutert.

Dateiformat packen

Das Pack-Dateiformat ist wichtig für ein effizientes Staubsaugen. Zunächst einige Beobachtungen. Grundsätzlich kann das Staubsaugen auf verschiedene Arten erfolgen. RDM 14.1 war in der Lage, Clustering anhand der Slot-ID im ID-Index oder Clustering anhand der alten Position in der Pack-Datei durchzuführen. Beide stützten sich auf einen ID-Index und bestimmte Metadaten in den Packdateien.

Der Ansatz von RDM 15.0 besteht darin, die Datenstrukturen zu durchlaufen und alles, was sich derzeit in Pack-Dateien befindet, die einem Staubsaugen unterliegen, zu verschieben, indem es an die letzte Pack-Datei angehängt wird. Datenstrukturen, die Verweise auf kopierte Daten enthalten, müssen ebenfalls verschoben werden. Die Datenstrukturen in RDM 15.0 enthalten daher Informationen zur ältesten Packdatei, die direkt oder indirekt erreicht werden können. Dies ermöglicht es, Inhalte effizient abzusaugen, ohne mehr Daten als nötig durchlaufen zu müssen. Dieser Ansatz hat auch den Vorteil, dass Inhalte basierend auf ihren Schlüsseln geclustert werden, wodurch nachfolgende Suchvorgänge effizienter werden.

Notwendigkeit für Schlösser

Darüber hinaus kann das Staubsaugen ohne Erwerb von Schreibsperren durchgeführt werden. Dies bedeutet, dass die Leser vom Staubsaugen nicht besonders betroffen sind. Aktualisierungen sind betroffen, da das Staubsaugen für eine bestimmte Tabelle nicht parallel durchgeführt werden kann, während für diese Tabelle eine Aktualisierung ausgeführt wird. Es wird jedoch erwartet, dass die zu saugende Datenmenge um eine Größenordnung geringer sein kann als die für eine Aktualisierung geschriebene Datenmenge, obwohl sie häufig nur einen Faktor von zwei oder drei beträgt, je nachdem, wie aggressiv wir staubsaugen.

Fazit

Wir haben gesehen, dass das Dateiformat für RDM 15.0 besonders gut zur Minimierung von Festplatten-E / A geeignet ist und Eigenschaften aufweist, die für dauerhaften Speicher, einschließlich SSD und Flash-Speicher, sehr gut geeignet sind. Durch die Minimierung der Festplatten-E / A haben die Geräte eine längere Lebensdauer. Viele Details wurden weggelassen, um die Diskussion zu vereinfachen. Wir hoffen es hat euch gefallen.

 

von Sverre Hvammen Johansen und Daigoro Toyama