Fernverbindungen in RocksDB-Cloud

(Hieu Pham) (10. Juni , 2020)

Einführung

RocksDB ist eine LSM-Speicher-Engine, deren Wachstum in den letzten Jahren enorm zugenommen hat . RocksDB-Cloud ist Open Source und vollständig kompatibel mit RocksDB, mit der zusätzlichen Funktion, dass alle Daten dauerhaft gespeichert werden, indem sie automatisch im Cloud-Speicher (z. B. Amazon S3) gespeichert werden.

Wir bei Rockset verwenden RocksDB-Cloud als einer der Bausteine ​​des verteilten Converged Index von Rockset. Rockset basiert auf Cloud-nativen Prinzipien. Eines der wichtigsten Designprinzipien einer Cloud-nativen Datenbank ist die Trennung von Computer und Speicher. Wir werden diskutieren, wie wir RocksDB-Cloud erweitert haben, um eine saubere Trennung zwischen Speicher- und Rechenanforderungen zu erreichen.

Ein von US Navy Seabees betriebener Verdichter, der eine Bodenverdichtung durchführt.

RocksDBs LSM-Motor

RocksDB-Cloud speichert Daten auf lokal angeschlossenen SSDs oder sich drehenden Festplatten. Die SSD oder die sich drehende Festplatte stellt den Speicher bereit, der zum Speichern der von ihr bereitgestellten Daten erforderlich ist. Neue Schreibvorgänge in RocksDB-Cloud werden in eine speicherinterne Memtable geschrieben. Wenn die Memtable voll ist, wird sie in eine neue SST-Datei im Speicher geleert.

Als LSM-Speicher-Engine eine Menge Für die Komprimierung werden Hintergrundthreads verwendet. Bei der Komprimierung werden mehrere SST-Dateien kombiniert und neue SST-Dateien mit überschriebenen Schlüsseln und gelöschten Schlüsseln generiert, die aus den Ausgabedateien gelöscht wurden. Die Komprimierung erfordert viele Rechenressourcen. Je höher die Schreibrate in die Datenbank ist, desto mehr Rechenressourcen werden für die Komprimierung benötigt, da das System nur dann stabil ist, wenn die Komprimierung mit neuen Schreibvorgängen in Ihre Datenbank Schritt halten kann.

Das Problem, wenn Berechnung und Speicher nicht disaggregiert sind

In einem typischen Fall RocksDB-basiertes System, Komprimierung erfolgt auf CPUs, die lokal auf dem Server sind, auf dem sich auch der Speicher befindet. In diesem Fall werden Berechnung und Speicherung nicht disaggregiert. Dies bedeutet, dass Sie bei steigender Schreibrate bei gleichbleibender Gesamtgröße Ihrer Datenbank dynamisch mehr Server bereitstellen, Ihre Daten auf alle diese Server verteilen und dann die zusätzliche Rechenleistung auf diesen Servern nutzen müssen, um mit der Leistung Schritt zu halten Komprimierungslast.

Dies hat zwei Probleme:

  • Die Verteilung Ihrer Daten auf mehrere Server erfolgt nicht sofort, da Sie dazu viele Daten kopieren müssen. Dies bedeutet, dass Sie nicht schnell auf eine sich schnell ändernde Arbeitslast reagieren können.
  • Die Speicherkapazitätsauslastung auf jedem Ihrer Server wird sehr gering, da Sie Ihre Daten auf mehrere Server verteilen. Sie verlieren das Preis-Leistungs-Verhältnis aufgrund des nicht genutzten Speichers auf Ihren Servern.

Unsere Lösung

Der Hauptgrund, warum RocksDB-Cloud geeignet ist Zum Trennen von Verdichtungsberechnung und Speicherung handelt es sich um eine LSM-Speicher-Engine. Im Gegensatz zu einer B-Tree-Datenbank aktualisiert RocksDB-Cloud eine SST-Datei niemals, sobald sie erstellt wurde. Dies bedeutet, dass alle SST-Dateien im gesamten System schreibgeschützt sind, mit Ausnahme des winzigen Teils der Daten in Ihrer aktiven Memtable. RocksDB-Cloud speichert alle SST-Dateien in einem Cloud-Speicherobjektspeicher wie S3, und auf diese Cloud-Objekte kann von allen Servern aus sicher zugegriffen werden, da sie schreibgeschützt sind.

Unsere Idee ist also, dass es sich um eine RocksDB handelt – Cloud-Server A kann einen Komprimierungsjob mit seinen Cloud-Objekten kapseln und die Anforderung dann an einen entfernten zustandslosen Server B senden. Server B kann die relevanten Objekte aus dem Cloud-Speicher abrufen, die Komprimierung durchführen und eine Ausgabe erstellen SST-Dateien, die in den Cloud-Objektspeicher zurückgeschrieben werden und diese Informationen dann an Server A zurücksenden – wir haben den Speicher (der sich auf Server A befindet) im Wesentlichen von der Verdichtungsberechnung (die sich auf Server B befindet) getrennt. Server A verfügt über den Speicher und Server B über keinen permanenten Speicher, sondern nur über die für die Komprimierung erforderliche Berechnung. Voila!

RocksDB steckbare Verdichtungs-API

Wir haben die Basis-RocksDB-API um zwei neue Methoden erweitert, mit denen die Komprimierungs-Engine in RocksDB extern steckbar ist. In db.h führen wir eine neue API zum Registrieren eines Komprimierungsdienstes ein.

Status RegisterPluggableCompactionService(std::unique_ptr);

Diese API registriert das Plugin, mit dem der Komprimierungsjob von RocksDB ausgeführt wird. Die Remote-Komprimierung erfolgt in zwei Schritten: Run und InstallFiles. Daher hätte das Plugin PluggableCompactionService zwei APIs:

Status Run(const PluggableCompactionParam& job, PluggableCompactionResult* result) std::vector InstallFiles(
const std::vector& remote_paths,
const std::vector& local_paths,
const EnvOptions& env_options, Env* local_env)

Run ist der Ort, an dem die Komprimierungsausführung stattfindet.In unserer Remote-Komprimierungsarchitektur würde Run einen RPC an eine Remote-Komprimierungsschicht senden und ein Komprimierungsergebnis empfangen, das unter anderem die Liste der neu komprimierten SST-Dateien enthält.

InstallFiles Hier installiert RocksDB die neu komprimierten SST-Dateien aus der Cloud (remote_paths) in seine lokale Datenbank (local_paths).

Rockset-Komprimierungsstufe

Nun zeigen wir, wie wir den oben im Rockset-Komprimierungsdienst beschriebenen steckbaren Komprimierungsdienst verwendet haben. Wie oben erwähnt, sendet der erste Schritt, Run, einen RPC mit Verdichtungsinformationen wie eingegebenen SST-Dateinamen und Komprimierungsinformationen an eine entfernte Komprimierungsschicht. Wir nennen den Host, der diesen Komprimierungsjob ausführt, einen compactor.

Der compactor würde beim Empfang der Komprimierungsanforderung eine RocksDB-Cloud-Instanz in öffnen Ghost -Modus. Dies bedeutet, dass RocksDB-Cloud die lokale Datenbank nur mit den erforderlichen Metadaten öffnet, ohne alle SST-Dateien aus dem Cloud-Speicher abzurufen. Sobald die RocksDB-Instanz im Ghost -Modus geöffnet wird, wird der Komprimierungsjob ausgeführt, einschließlich des Abrufs der erforderlichen SST-Dateien, der Komprimierung und des Hochladens der neu komprimierten SST-Dateien in einen temporären Speicher in der Cloud.

Hier sind die Optionen zum Öffnen von RocksDB-Cloud im compactor :

rocksdb::CloudOptions cloud_options; cloud_options.ephemeral_resync_on_open = false; cloud_options.constant_sst_file_size_in_sst_file_manager = 1024; cloud_options.skip_cloud_files_in_getchildren = true;rocksdb::Options rocksdb_options;
rocksdb_options.max_open_files = 0; rocksdb_options.disable_auto_compactions = true; rocksdb_options.skip_stats_update_on_db_open = true; rocksdb_options.paranoid_checks = false; rocksdb_options.compaction_readahead_size = 10 * 1024 * 1024;

Es gibt mehrere Herausforderungen Wir waren während der Entwicklung der Verdichtungsebene und unserer Lösungen konfrontiert:

Verbessern Sie die Geschwindigkeit beim Öffnen von RocksDB-Cloud in ghost mode

Beim Öffnen einer RocksDB-Instanz werden zusätzlich alle SST-Dateien aus der Cloud abgerufen (die wir mit ghost mode) gibt es mehrere andere Vorgänge, die den Öffnungsprozess verlangsamen können, insbesondere das Abrufen der Liste der SST-Dateien und das Abrufen der Größe jeder SST-Datei. Wenn sich alle SST-Dateien im lokalen Speicher befinden, ist die Latenz dieser Operationen zum Abrufen der Dateigröße normalerweise gering. Wenn der compactor jedoch RocksDB-Cloud öffnet, würde jeder dieser Vorgänge zu einer Remote-Anforderung an den Cloud-Speicher führen, und die gesamte kombinierte Latenz wird unerschwinglich teuer. Nach unserer Erfahrung würde das Öffnen einer RocksDB-Cloud-Instanz mit Tausenden von SST-Dateien aufgrund von Tausenden von Anforderungen an die Dateigröße an S3 bis zu einer Minute dauern. Um diese Einschränkung zu umgehen, haben wir in den RocksDB-Cloud-Optionen verschiedene Optionen eingeführt, um diese RPCs beim Öffnen zu deaktivieren. Infolgedessen beträgt die durchschnittliche Öffnungszeit 7 Sekunden bis 700 Millisekunden.

Deaktivieren Sie die L0 -> L0-Komprimierung

Remote-Komprimierung ist ein Kompromiss zwischen der Geschwindigkeit einer einzelnen Komprimierung und der Fähigkeit, mehr Komprimierungsjobs parallel auszuführen. Dies liegt daran, dass natürlich jeder Remote-Komprimierungsjob aufgrund der Kosten für die Datenübertragung in der Cloud langsamer ist als dieselbe lokal ausgeführte Komprimierung. Daher möchten wir den Engpass des Verdichtungsprozesses minimieren, bei dem RocksDB-Cloud nicht so weit wie möglich parallelisieren kann.

In der LSM-Architektur ist die L0-> L1-Verdichtung normalerweise nicht parallelisierbar, da L0-Dateien haben überlappende Bereiche. Wenn eine L0-> L1-Komprimierung auftritt, kann RocksDB-Cloud daher auch eine L0-> L0-Komprimierung ausführen, mit dem Ziel, die Anzahl der L0-Dateien zu verringern und Schreibstillstände zu verhindern, wenn RocksDB-Cloud auf die L0-Datei trifft Grenze. Der Nachteil ist jedoch, dass jede L0-Datei nach jeder L0-> L0-Komprimierung größer wird.

Nach unserer Erfahrung verursacht diese Option mehr Probleme als die damit verbundenen Vorteile, da größere L0-Dateien vorhanden sind führt zu einer viel längeren L0-> L1-Verdichtung, was den Engpass von RocksDB-Cloud verschlimmert. Daher deaktivieren wir die L0-> L0-Komprimierung und leben stattdessen mit dem seltenen Problem des Schreibstillstands. Aus unserem Experiment geht hervor, dass die RocksDB-Cloud-Komprimierung die eingehenden Schreibvorgänge viel besser einholt.

Sie können sie jetzt verwenden.

RocksDB-Cloud ist ein Open-Source-Projekt, sodass unsere Arbeit dies kann von jedem anderen RocksDB-Entwickler genutzt werden, der Vorteile erzielen möchte, indem er seine Verdichtungsberechnung von seinen Speicheranforderungen trennt. Wir führen den Remote-Verdichtungsdienst jetzt in der Produktion aus. Es ist mit der Version 6.7.3 von RocksDB-Cloud verfügbar. Wir diskutieren alles über RocksDB-Cloud im öffentlichen Slack-Kanal unter http://bit.ly/rockset-community-channel .

Autoren:

Hieu Pham – Software-Ingenieur, Rockset
Dhruba Borthakur – CTO, Rockset

Ursprünglich veröffentlicht unter https: // rockset.com am 4. Juni 2020.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.