MyRocks als InnoDB-Alternative: wann sich der LSM-Tree-Ansatz lohnt

1. Warum InnoDBs B-Tree-Architektur bei Schreiblast an Grenzen stößt

InnoDB speichert jeden Index, einschließlich des Primärschlüssels, als B+Tree. Jede Änderung an einer Zeile wird direkt in der passenden Seite des Baums vorgenommen, was bei sequentiellen Zugriffen sehr effizient ist. Bei zufälligen Schreibzugriffen auf große Tabellen führt dieses In-Place-Update-Modell jedoch regelmäßig zu Seiten-Splits, weil eine Seite voll wird und aufgeteilt werden muss, was zusätzliche I/O-Operationen und Fragmentierung erzeugt.

Kombiniert mit dem Redo Log und dem Doublewrite Buffer, die beide für Crash-Sicherheit sorgen, entsteht eine spürbare Write Amplification: Eine einzelne logische Zeilenänderung führt zu mehreren physischen Schreibvorgängen auf der Platte. Bei Workloads mit sehr hoher Einfügerate, etwa Ereignisprotokollen, Audit-Logs oder Zeitreihendaten mit Millionen Zeilen pro Tag, summiert sich dieser Overhead zu einem echten Engpass, selbst wenn die einzelnen Abfragen für sich genommen unproblematisch wären.

2. Das Grundprinzip des Log-Structured-Merge-Tree im Vergleich zum B-Tree

Ein LSM-Tree kehrt das Speicherprinzip um: Statt eine Zeile sofort an ihrer endgültigen Position zu aktualisieren, werden neue Schreibvorgänge zunächst in eine sortierte In-Memory-Struktur, die Memtable, angehängt. Erreicht diese Memtable eine bestimmte Größe, wird sie unverändert als sortierte, unveränderliche Datei, eine sogenannte SST-Datei, auf die Platte geschrieben. Änderungen an bereits geschriebenen Zeilen erzeugen also keine In-Place-Updates, sondern zusätzliche Einträge, die spätere Versionen überschreiben.

Im Hintergrund läuft ein Compaction-Prozess, der mehrere SST-Dateien zu größeren, wieder sortierten Dateien verschmilzt und dabei veraltete Versionen sowie gelöschte Zeilen entfernt. Sowohl das Schreiben der Memtable als auch die Compaction erfolgen sequentiell, was zufällige Schreibmuster der Anwendung in überwiegend sequentielle Plattenzugriffe umwandelt, während ein B-Tree bei denselben zufälligen Schreibzugriffen weiterhin zufällige Seitenzugriffe benötigt.

3. Wie MyRocks als Storage Engine in MySQL integriert ist

MyRocks entstand bei Facebook, dem heutigen Meta-Konzern, als Storage-Engine-Schicht über RocksDB, einer eingebetteten Key-Value-Bibliothek, die selbst wiederum von Googles LevelDB abstammt. RocksDB übernimmt dabei Memtable, SST-Dateien und Compaction, während MyRocks als Bindeglied das MySQL-Storage-Engine-API implementiert und relationale Tabellen samt Sekundärindizes auf das Key-Value-Modell von RocksDB abbildet.

Verfügbar ist MyRocks als ENGINE=ROCKSDB in Percona Server for MySQL standardmäßig als Plugin, in MariaDB als optionales, ladbares Plugin und lässt sich aus dem Quellcode auch für MySQL Community Server selbst bauen. Für Transaktionssicherheit über Binlog und RocksDB-eigenes Write-Ahead-Log hinweg nutzt MyRocks ein Zwei-Phasen-Commit-Verfahren, und Betriebsdaten stehen über die INFORMATION_SCHEMA.ROCKSDB_*-Tabellen zur Verfügung.

4. Schreiblast-Vorteile: geringere Write Amplification und sequentielle I/O

Weil Schreibvorgänge zunächst nur an die Memtable angehängt und erst später im Hintergrund kompaktiert werden, fällt die Write Amplification bei MyRocks im Vergleich zu InnoDB deutlich geringer aus, insbesondere bei Workloads mit sehr vielen kleinen, zufällig verteilten Inserts oder Updates. Benchmarks von Facebook und Percona zeigen bei schreiblastigen Workloads regelmäßig einen spürbar geringeren I/O-Durchsatz auf der Platte bei vergleichbarem Durchsatz auf Anwendungsebene.

Für Magento-Kontexte betrifft das vor allem Tabellen mit sehr hohem Insert-Volumen und seltenen punktuellen Lesezugriffen, etwa Changelog-Tabellen der Indexer, Admin-Aktionsprotokolle oder Kundenaktivitätslogs, bei denen Zeilen überwiegend geschrieben und selten einzeln wieder gezielt gelesen werden.

-- Tabelle für ein Änderungsprotokoll auf MyRocks anlegen
CREATE TABLE catalog_index_changelog_rocks (
    version_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    entity_id  INT UNSIGNED NOT NULL,
    changed_at DATETIME NOT NULL,
    KEY idx_entity (entity_id),
    KEY idx_changed (changed_at)
) ENGINE=ROCKSDB DEFAULT CHARSET=utf8mb4;

-- Aktuelle Kompressionsraten je Storage-Engine vergleichen
SELECT engine, SUM(data_length) AS data_bytes, SUM(index_length) AS index_bytes
FROM information_schema.tables
WHERE table_schema = DATABASE()
GROUP BY engine;

5. Speicherplatzkompression: warum MyRocks-Tabellen oft deutlich kleiner sind

RocksDB komprimiert Datenblöcke pro Level einzeln, üblicherweise mit LZ4 für untere, häufig gelesene Levels und mit dem stärker, aber langsamer komprimierenden Zstandard für höhere Levels mit selten gelesenen, älteren Daten. Weil Compaction ohnehin regelmäßig Daten neu schreibt, lässt sich diese Kompression nahezu ohne zusätzlichen Aufwand in den bestehenden Hintergrundprozess integrieren, anders als bei InnoDB, wo Kompression zusätzliche Seiten-Reorganisationen erzwingt.

In der Praxis berichten Betreiber häufig von zwei- bis vierfach kleineren Tabellen gegenüber unkomprimiertem InnoDB, abhängig von Datentyp und Redundanz der Werte. Für Magento-Installationen mit begrenztem Speicherplatz auf dem Datenbankserver, etwa bei sehr umfangreichen historischen Bestell- oder Protokolldaten, kann das den Unterschied zwischen einem knappen und einem komfortablen Storage-Budget ausmachen.

-- Kompressionsalgorithmus je RocksDB-Level konfigurieren (my.cnf)
-- rocksdb_default_cf_options=compression=kLZ4Compression;
--     bottommost_compression=kZSTD

-- Aktuelle RocksDB-Kompressionsstatistik je Column Family pruefen
SELECT * FROM information_schema.rocksdb_compaction_stats
WHERE cf_name = 'default';

6. Die Kehrseite: Read-Amplifikation und wann sie spürbar wird

Der Preis für günstige Schreibvorgänge ist eine höhere Read-Amplifikation: Ein einzelner Punktzugriff muss im schlimmsten Fall die Memtable und mehrere SST-Levels durchsuchen, bis der aktuelle Wert einer Zeile gefunden ist, während ein B-Tree-Zugriff bei InnoDB direkt über den Index in nahezu konstanter Tiefe zum Ziel führt. Bloom-Filter mindern dieses Problem erheblich, indem sie pro SST-Datei mit hoher Wahrscheinlichkeit ausschließen, dass ein gesuchter Schlüssel überhaupt darin enthalten ist, sodass viele Levels gar nicht erst gelesen werden müssen.

Trotzdem bleibt die Lesecharakteristik unter Last weniger vorhersagbar als bei InnoDB, besonders bei Workloads mit vielen zufälligen Punktlesevorgängen auf kalten, noch nicht im Block-Cache befindlichen Daten. Für Tabellen mit einem hohen Anteil an Random Reads, etwa Produktkataloge mit sehr vielen individuellen Lookups pro Sekunde, kann das die Latenz gegenüber InnoDB spürbar erhöhen, selbst wenn der Gesamtdurchsatz im Batch-Betrieb höher liegt.

7. Praktische Grenzen: Reifegrad, fehlende Foreign Keys, Locking-Unterschiede

MyRocks unterstützt keine referenzielle Integrität über Foreign Keys, was für Tabellen mit expliziten Fremdschlüssel-Constraints, wie sie in klassischen Magento-Kernschemata häufig vorkommen, ein direktes Ausschlusskriterium ist, sofern die Constraints nicht ohnehin in der Anwendungslogik geprüft werden. Auch das Sperrverhalten unterscheidet sich: MyRocks kennt kein Next-Key-Locking wie InnoDB, was das Verhalten bei Phantom-Reads unter bestimmten Isolationsstufen anders ausfallen lässt als gewohnt.

Insgesamt ist MyRocks deutlich jünger im produktiven Breiteneinsatz als InnoDB, das Operations-Tooling für Backup, Monitoring und Fehlerdiagnose ist schmaler, und viele Drittanbieter-Tools sowie Community-Erfahrung sind primär auf InnoDB ausgelegt. Wer MyRocks einsetzt, sollte deshalb bewusst mit weniger etabliertem Betriebswissen kalkulieren und Testphasen entsprechend großzügig planen.

8. Wann sich MyRocks lohnt und wann InnoDB die bessere Wahl bleibt

MyRocks eignet sich besonders für Tabellen mit sehr hoher, überwiegend sequentieller oder append-artiger Schreiblast und seltenen, eher batchartigen Lesezugriffen: Logging, Audit-Trails, Zeitreihendaten, Änderungsprotokolle von Indexern oder Archivtabellen, die primär für spätere Analysen und selten für einzelne Lookups genutzt werden. Auch wenn Speicherplatz auf dem Datenbankserver ein knapper und teurer Faktor ist, spricht die Kompression klar für MyRocks.

Für klassische OLTP-Kerntabellen eines Magento-Shops, etwa Warenkorb, Bestellungen und Produktkatalog mit hohem Anteil an zufälligen Punktlesevorgängen, gemischten Lese- und Schreiblasten sowie Fremdschlüssel-Anforderungen, bleibt InnoDB die robustere und besser erprobte Wahl. Ein pauschaler Wechsel der gesamten Datenbank auf MyRocks ist deshalb in den seltensten Fällen sinnvoll.

9. Migration und Koexistenz: einzelne Tabellen gezielt umstellen

MyRocks lässt sich pro Tabelle einsetzen, während der Rest der Datenbank weiterhin auf InnoDB läuft. Das erlaubt einen risikoarmen, schrittweisen Einstieg: Man identifiziert zunächst konkrete Kandidaten mit hohem Schreibvolumen und geringem Punktleseaufkommen, wandelt sie testweise auf Staging-Umgebungen um und misst Speicherplatzersparnis sowie Antwortzeiten unter realistischer Last, bevor produktiv umgestellt wird.

Für die eigentliche Umstellung genügt ein ALTER TABLE ... ENGINE=ROCKSDB, wobei bei sehr großen Tabellen der Online-DDL-Prozess entsprechend Zeit und I/O-Kapazität benötigt und idealerweise außerhalb der Hauptlastzeiten ausgeführt wird. Monitoring über information_schema.rocksdb_compaction_stats und die RocksDB-eigenen Logdateien hilft danach, Compaction-Verhalten und tatsächliche Kompressionsraten im laufenden Betrieb zu überwachen.

-- Eine bestehende InnoDB-Logtabelle testweise auf MyRocks umstellen
ALTER TABLE admin_action_log ENGINE=ROCKSDB;

-- Größe vorher/nachher vergleichen
SELECT table_name, engine,
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE() AND table_name = 'admin_action_log';

10. Zusammenfassung

11. FAQ: MyRocks in MySQL: Das Wichtigste auf einen Blick