Compacții la distanță în RocksDB-Cloud

(Hieu Pham) (10 iunie) , 2020)

Introducere

RocksDB este un motor de stocare LSM a cărui creștere a proliferat enorm în ultimii ani . RocksDB-Cloud este open-source și este pe deplin compatibil cu RocksDB, cu caracteristica suplimentară că toate datele sunt făcute durabile prin stocarea automată în stocarea în cloud (de exemplu, Amazon S3).

Noi, la Rockset, folosim RocksDB-Cloud ca unul dintre elementele de bază ale indexului convergent distribuit al Rockset . Rockset este proiectat cu principii native pentru cloud și unul dintre principiile principale de proiectare ale unei baze de date native pentru cloud este separarea calculului de stocare. Vom discuta despre modul în care am extins RocksDB-Cloud pentru a avea o separare curată a nevoilor sale de stocare și a nevoilor sale de calcul.

Un compactor, operat de US Navy Seabees, care compactează solul

Motorul LSM RocksDB

RocksDB-Cloud stochează date în SSD atașate local sau pe discuri rotative. SSD-ul sau discul rotativ oferă spațiul de stocare necesar pentru stocarea datelor pe care le servește. Scrierile noi pe RocksDB-Cloud sunt scrise într-un memtable în memorie, iar atunci când memtable este plin, acesta este transferat într-un nou fișier SST din spațiul de stocare.

Fiind un motor de stocare LSM, un set a firelor de fundal sunt utilizate pentru compactare, iar compactarea este un proces de combinare a unui set de fișiere SST și generarea de noi fișiere SST cu chei suprascrise și chei șterse curățate de fișierele de ieșire. Compactarea are nevoie de o mulțime de resurse de calcul. Cu cât rata de scriere este mai mare în baza de date, cu atât sunt necesare mai multe resurse de calcul pentru compactare, deoarece sistemul este stabil numai dacă compactarea este capabilă să țină pasul cu noile scrieri în baza de date.

Problema atunci când calculul și stocarea nu sunt dezagregate

Într-un tipic Sistem bazat pe RocksDB, compactarea are loc pe procesoarele care sunt locale pe serverul care găzduiește și stocarea. În acest caz, calculul și stocarea nu sunt dezagregate. Și asta înseamnă că, în cazul în care rata de scriere crește, dar dimensiunea totală a bazei de date rămâne aceeași, va trebui să aprovizionați dinamic mai multe servere, să vă răspândiți datele în toate acele servere și apoi să utilizați calculul suplimentar de pe aceste servere pentru a ține pasul cu încărcare de compactare.

Acest lucru are două probleme:

  • Răspândirea datelor dvs. pe mai multe servere nu este instantanee, deoarece trebuie să copiați multe date pentru a face acest lucru. Acest lucru înseamnă că nu puteți reacționa rapid la o sarcină de lucru care se schimbă rapid.
  • Utilizarea capacității de stocare pe fiecare dintre serverele dvs. devine foarte redusă, deoarece vă răspândiți datele pe mai multe servere. Pierdeți raportul preț-performanță din cauza întregului spațiu de stocare neutilizat pe serverele dvs.

Soluția noastră

Motivul principal pentru care RocksDB-Cloud este potrivit pentru separarea calculării și stocării compactării se datorează faptului că este un motor de stocare LSM. Spre deosebire de o bază de date B-Tree, RocksDB-Cloud nu actualizează niciodată un fișier SST odată ce a fost creat. Aceasta înseamnă că toate fișierele SST din întregul sistem sunt doar în citire, cu excepția porțiunii minuscule de date din memoria activă. RocksDB-Cloud persistă toate fișierele SST dintr-un depozit de obiecte de stocare în cloud, cum ar fi S3, iar aceste obiecte cloud sunt accesibile în siguranță de pe toate serverele dvs., deoarece sunt doar în citire.

Deci, ideea noastră este că, dacă un RocksDB -Servorul cloud A poate încapsula o lucrare de compactare cu setul său de obiecte cloud și apoi poate trimite cererea către un server B fără stat la distanță și serverul B poate prelua obiectele relevante din magazinul cloud, poate compacta, produce un set de ieșiri Fișierele SST care sunt scrise înapoi în depozitul de obiecte cloud și apoi comunică aceste informații înapoi serverului A-am separat în esență stocarea (care se află în serverul A) de calculul de compactare (care se află în serverul B). Serverul A are stocarea și în timp ce serverul B nu are stocare permanentă, ci doar calculul necesar pentru compactare. Voila!

API de compactare RocksDB pluggable

Am extins API-ul RocksDB de bază cu două noi metode care fac ca motorul de compactare din RocksDB să fie conectat extern. În db.h , introducem un nou API pentru a înregistra un serviciu de compactare.

Status RegisterPluggableCompactionService(std::unique_ptr);

Acest API înregistrează pluginul care este utilizat pentru a executa operația de compactare de către RocksDB. Compactarea la distanță are loc în doi pași: Run și InstallFiles. Prin urmare, pluginul, PluggableCompactionService , ar avea 2 API-uri:

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 este locul unde se întâmplă executarea compactării.În arhitectura noastră de compactare la distanță, Run ar trimite un RPC la un nivel de compactare la distanță și ar primi un rezultat de compactare care are, printre altele, lista fișierelor SST recent compactate.

InstallFiles este locul unde RocksDB instalează fișierele SST recent compactate din cloud (remote_paths) în baza sa de date locală (local_paths).

Nivelul de compactare Rockset

Acum vom arăta cum am folosit serviciul de compactare conectabil descris mai sus în serviciul de compactare Rockset. După cum s-a menționat mai sus, primul pas, Run, trimite un RPC către un nivel de compactare la distanță cu informații de compactare, cum ar fi numele fișierelor SST de intrare și informații de compresie. Numim gazda care execută această activitate de compactare compactor.

compactorul , la primirea cererii de compactare, ar deschide o instanță RocksDB-Cloud în modul fantomă . Ceea ce înseamnă acest lucru este că RocksDB-Cloud deschide baza de date locală numai cu metadatele necesare fără a prelua toate fișierele SST din stocarea în cloud. Odată ce deschide instanța RocksDB în modul fantomă , va executa apoi operația de compactare, incluzând preluarea fișierelor SST necesare, compactarea lor și încărcarea fișierelor SST recent compactate într-un spațiu de stocare temporar în cloud.

Iată opțiunile pentru a deschide RocksDB-Cloud în compactorul :

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;

Există mai multe provocări ne-am confruntat în timpul dezvoltării nivelului de compactare și a soluțiilor noastre:

Îmbunătățim viteza de deschidere a RocksDB-Cloud în fantomă mode

În timpul deschiderii instanțelor RocksDB, pe lângă preluarea tuturor fișierelor SST din cloud (pe care le-am dezactivat cu ghost mode), există mai multe alte operații care ar putea încetini procesul de deschidere, în special obținând lista fișierelor SST și obținând dimensiunea fiecărui fișier SST. În mod obișnuit, dacă toate fișierele SST se află în spațiul de stocare local, latența acestor operații de obținere a dimensiunii fișierului ar fi mică. Cu toate acestea, atunci când compactorul deschide RocksDB-Cloud, fiecare dintre aceste operații ar avea ca rezultat o cerere de la distanță pentru stocarea în cloud, iar latența totală combinată devine prohibitiv costisitoare. Din experiența noastră, pentru o instanță RocksDB-Cloud cu mii de fișiere SST, deschiderea acesteia ar dura până la un minut din cauza mii de solicitări de dimensiune a fișierului get către S3. Pentru a evita această limitare, am introdus diverse opțiuni în opțiunile RocksDB-Cloud pentru a dezactiva aceste RPC-uri în timpul deschiderii. Ca urmare, timpul mediu de deschidere merge de la 7 secunde la 700 de milisecunde.

Dezactivează L0 -> Compactarea L0

Compactarea la distanță este un compromis între viteza unei singure compactări și capacitatea de a rula mai multe lucrări de compactare în paralel. Acest lucru se datorează faptului că, în mod firesc, fiecare activitate de compactare la distanță ar fi mai lentă decât aceeași compactare executată local datorită costului transferului de date în cloud. Prin urmare, am dori să minimalizăm blocajul procesului de compactare, unde RocksDB-Cloud nu poate paralela, pe cât posibil.

În arhitectura LSM, compactarea L0-> L1 nu este de obicei paralelizabilă deoarece Fișierele L0 au intervale suprapuse. Prin urmare, atunci când apare o compactare L0-> L1, RocksDB-Cloud are capacitatea de a executa și compactarea L0-> L0, cu scopul de a reduce numărul de fișiere L0 și de a preveni blocajele de scriere datorită RocksDB-Cloud care lovește fișierul L0 limită. Cu toate acestea, compromisul este că fiecare fișier L0 ar crește în dimensiune după fiecare L0-> L0 compactări.

Din experiența noastră, această opțiune provoacă mai multe probleme decât beneficiile pe care le aduce, deoarece având fișiere L0 mai mari are ca rezultat o compactare mult mai lungă L0-> L1, agravând blocajul RocksDB-Cloud. Prin urmare, dezactivăm compactarea L0-> L0 și, în schimb, trăim cu rara problemă a blocajului de scriere. Din experimentul nostru, compactarea RocksDB-Cloud recuperează scrierile primite mult mai bine.

Îl puteți folosi acum

RocksDB-Cloud este un proiect open-source, astfel încât munca noastră poate să fie valorificat de orice alt dezvoltator RocksDB care dorește să obțină beneficii prin separarea calculului de compactare de nevoile lor de stocare. Acum rulăm serviciul de compactare la distanță în producție acum. Este disponibil cu versiunea 6.7.3 a RocksDB-Cloud. Discutăm toate lucrurile despre RocksDB-Cloud în canalul public Slack la http://bit.ly/rockset-community-channel .

Autori:

Hieu Pham – Inginer software, Rockset
Dhruba Borthakur – CTO, Rockset

Publicat inițial la https: // rockset.com pe 4 iunie 2020.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *