Zum Inhalt springen

Log-Structured Merge-Tree

aus Wikipedia, der freien Enzyklopädie

Ein Log-Structured Merge-Tree, kurz LSM-Tree, ist eine für schreibintensive Datenbestände optimierte Datenstruktur zur persistenten Speicherung sortierter Schlüssel-Wert-Paare. Änderungen werden zunächst im Arbeitsspeicher gesammelt und später in zusammenhängenden, sortierten Dateien auf einen Massenspeicher geschrieben. Hintergrundprozesse führen diese Dateien schrittweise zusammen. Dadurch werden viele kleine zufällige Schreibzugriffe durch größere sequenzielle Schreibvorgänge ersetzt.[1]

Eine moderne LSM-Tree-Speicherengine besitzt üblicherweise folgende Bestandteile:

  1. Ein Write-Ahead Log hält Änderungen für die Wiederherstellung nach einem Absturz fest.
  2. Eine sortierte Datenstruktur im Arbeitsspeicher, häufig Memtable genannt, nimmt neue und geänderte Schlüssel auf.
  3. Sobald die Memtable eine Größenbegrenzung erreicht, wird sie eingefroren und als unveränderliche sortierte Datei auf den Massenspeicher geschrieben. Solche Dateien werden häufig Sorted String Tables, kurz SSTables, genannt.
  4. Eine Hintergrundverdichtung, die Compaction, führt mehrere SSTables zusammen, entfernt überschriebene Werte und verarbeitet Löschmarkierungen.[2]

Das ursprüngliche Modell von 1996 beschrieb eine kleine speicherresidente Komponente und eine größere plattenbasierte Komponente . Heutige Systeme verwenden meist mehrere aufeinanderfolgende Ebenen mit wachsender Kapazität.[1][3]

Schreib- und Lesevorgänge

[Bearbeiten | Quelltext bearbeiten]

Ein Schreibvorgang wird zunächst sequenziell im Write-Ahead Log protokolliert und anschließend in die Memtable übernommen. Das Schreiben der sortierten Dateien erfolgt gebündelt. Dieses Verfahren ermöglicht einen hohen Schreibdurchsatz, da die Speicherengine nicht bei jeder Änderung eine bestehende Datei an einer zufälligen Position umorganisieren muss.[2]

Bei einer Leseanfrage werden zunächst die Memtable und danach die relevanten SSTables durchsucht. Da ein Schlüssel in mehreren Dateien vorkommen kann, muss das System die neueste Version bestimmen. Bloomfilter und zusätzliche Indizes helfen dabei, Dateien auszuschließen, die den gesuchten Schlüssel sicher nicht enthalten.[4]

Bei der Leveled Compaction enthält eine Ebene normalerweise nur nicht überlappende Schlüsselbereiche. Dateien werden regelmäßig mit überlappenden Dateien der nächsten Ebene zusammengeführt. Dies begrenzt die Zahl der Dateien, die eine Leseanfrage prüfen muss, kann Daten während ihrer Lebensdauer jedoch mehrfach neu schreiben.[2]

Bei der Tiered Compaction dürfen mehrere sortierte Läufe ähnlicher Größe nebeneinander bestehen. Sie werden seltener zusammengeführt. Das reduziert die Schreibverstärkung, erhöht aber typischerweise den Aufwand für Lesevorgänge und den vorübergehend benötigten Speicherplatz. Die Wahl der Strategie ist daher ein Kompromiss zwischen Schreibverstärkung, Leseverstärkung und Platzverstärkung.[3]

Einsatz und Eigenschaften

[Bearbeiten | Quelltext bearbeiten]

LSM-Trees sind besonders für Arbeitslasten mit vielen Einfügungen und Aktualisierungen geeignet. Der hohe Schreibdurchsatz wird mit zusätzlicher Hintergrundarbeit erkauft. Compaction benötigt Ein- und Ausgabe-Bandbreite, kann dieselben Daten mehrfach schreiben und kann bei unzureichender Kapazität Schreibvorgänge verzögern.[3]

Die Schlüssel-Wert-Datenbank RocksDB und das verteilte Datenbankmanagementsystem Apache Cassandra verwenden LSM-basierte Speicherarchitekturen.[2][4]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. 1 2 Patrick O'Neil, Edward Cheng, Dieter Gawlick, Elizabeth O'Neil: The log-structured merge-tree (LSM-tree). In: Acta Informatica. Band 33, Nr. 4, 1996, S. 351–385, doi:10.1007/s002360050048 (englisch).
  2. 1 2 3 4 RocksDB Overview. In: RocksDB Wiki. 18. Juli 2023, abgerufen am 26. August 2026 (englisch).
  3. 1 2 3 Chen Luo, Michael J. Carey: LSM-based storage techniques: a survey. In: The VLDB Journal. Band 29, Nr. 1, 2020, S. 393–418, doi:10.1007/s00778-019-00555-y, arxiv:1812.07527 (englisch).
  4. 1 2 Storage Engine. In: Apache Cassandra Documentation. Abgerufen am 26. August 2026 (englisch).