Távos tömörítések a RocksDB-Cloud-ban

(Hieu Pham) (június 10.) , 2020)

Bevezetés

A RocksDB egy olyan LSM tárolómotor, amelynek növekedése hatalmas mértékben elszaporodott az elmúlt években . A RocksDB-Cloud nyílt forráskódú, és teljes mértékben kompatibilis a RocksDB-vel, azzal a kiegészítő funkcióval, hogy minden adat tartóssá válik, ha automatikusan tárolja azokat a felhő tárhelyén (pl. Amazon S3).

A Rocksetnél használjuk A RocksDB-Cloud a Rockset elosztott konvergált indexének egyik építőköve. A Rockset felhőalapú elvekkel készült, és a felhőalapú adatbázis egyik elsődleges tervezési elve az, hogy el kell különíteni a számítást a tárolótól. Megbeszéljük, hogyan bővítettük a RocksDB-Cloud alkalmazást a tárolási igények és a számítási igények tiszta elkülönítése érdekében.

Tömörítőgép, amelyet az amerikai haditengerészet Seabees üzemeltet és a talajtömörítést végzi

A RocksDB LSM motorja

RocksDB-Cloud adatokat tárol egy helyileg csatolt SSD-ben vagy forgó lemezeken. Az SSD vagy a forgó lemez biztosítja a tárolt adatokat az általa kiszolgált adatok tárolásához. Az új írások a RocksDB-Cloud-ba egy memóriában lévő memtable-be íródnak, majd ha a memtable megtelt, akkor egy új SST fájlba kerül a tárolóban.

LSM tároló motorként, készletként A háttérszálak tömörítésére szolgálnak, és a tömörítés egy olyan folyamat, amely egyesíti az SST fájlkészletet, és új SST fájlokat állít elő felülírott kulcsokkal és a kimeneti fájlokból törölt törölt kulcsokkal. A tömörítéshez sok számítási erőforrásra van szükség. Minél nagyobb az írási sebesség az adatbázisba, annál több számítási erőforrásra van szükség a tömörítéshez, mert a rendszer csak akkor stabil, ha a tömörítés képes lépést tartani az adatbázis új írásaival.

A probléma, amikor a számítást és a tárolást nem bontják szét

Tipikus esetben A RocksDB alapú rendszer, a tömörítés olyan CPU-kon történik, amelyek lokálisak a tárolót is kiszolgáló kiszolgálón. Ebben az esetben a számítást és a tárolást nem bontják szét. Ez azt jelenti, hogy ha az írási sebesség növekszik, de az adatbázis teljes mérete változatlan marad, akkor dinamikusan kell további kiszolgálókat létrehoznia, az összes szerverre el kell terjesztenie az adatait, majd kihasználnia kell a kiszolgálók további számítását, hogy lépést tartson a tömörítés.

Ennek két problémája van:

  • Az adatok terjesztése több kiszolgálóra nem pillanatnyi, mert ehhez sok adatot kell másolnia. Ez azt jelenti, hogy nem tud gyorsan reagálni a gyorsan változó munkaterhelésre.
  • Az egyes kiszolgálókon a tárolókapacitás-kihasználtság nagyon alacsony lesz, mert az adatokat több szerverre terjeszti. A szerverein lévő összes fel nem használt tárhely miatt elveszíti az ár-teljesítmény arányt.

Megoldásunk

Az elsődleges ok, amiért a RocksDB-Cloud alkalmas a tömörítési számítás és a tárolás elkülönítésére azért van szükség, mert ez egy LSM tároló motor. A B-Tree adatbázissal ellentétben a RocksDB-Cloud soha nem frissíti az SST fájlt, miután létrehozta. Ez azt jelenti, hogy a teljes rendszer összes SST fájlja csak olvasható, kivéve az aktív memóriában lévő adatok miniszekuláris részét. A RocksDB-Cloud megőrzi az összes SST fájlt egy felhő tárolóobjektum-tárolóban, mint például az S3, és ezek a felhőobjektumok biztonságosan elérhetők minden szerveréről, mert csak olvashatók.

Tehát az az elképzelésünk, hogy ha egy RocksDB -A felhő-kiszolgáló egy tömörítési feladatot beilleszthet felhőobjektum-készleteibe, majd elküldheti a kérést egy távoli, állam nélküli szervernek B – és ez a B szerver lekérheti a releváns objektumokat a felhőboltból, elvégezheti a tömörítést, előállíthat egy sor kimenetet Azokat az SST fájlokat, amelyeket visszaírnak a felhőobjektum-tárolóba, majd ezt az információt visszaküldik az A szervernek – lényegében elkülönítettük a tárolót (amely az A szerveren található) a tömörítési számítástól (amely a B szerveren található). Az A szervernek van tárhelye, míg a B szervernek nincs állandó tárhelye, csak a tömörítéshez szükséges számítás van. Voila!

RocksDB bedugható tömörítési API

Az alap RocksDB API-t két új módszerrel bővítettük, amelyek a RocksDB-ben lévő tömörítő motort külsőleg bedughatóvá teszik. A db.h részben új API-t vezetünk be egy tömörítési szolgáltatás regisztrálásához.

Status RegisterPluggableCompactionService(std::unique_ptr);

Ez az API regisztrálja azt a plugint, amelyet a tömörítési feladat végrehajtására használ a RocksDB. A távoli tömörítés két lépésben történik: Run és InstallFiles. Ezért a plugin, PluggableCompactionService , két API-val rendelkezik:

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 itt történik a tömörítés végrehajtása.Távoli tömörítési architektúránkban a Run RPC-t küld egy távoli tömörítési rétegnek, és egy tömörítési eredményt kap, amely többek között az újonnan tömörített SST fájlok listáját tartalmazza.

InstallFiles ahol a RocksDB telepíti az újonnan tömörített SST fájlokat a felhőből (remote_paths) a helyi adatbázisába (local_paths).

A Rockset tömörítési szintje

Most megmutatjuk, hogyan használtuk a fent leírt bedugható tömörítési szolgáltatást a Rockset tömörítési szolgáltatásában. Mint fent említettük, az első lépés, Run, RPC-t küld egy távoli tömörítési rétegnek tömörítési információkkal, például bemeneti SST fájlnevekkel és tömörítési információkkal. Ezt a tömörítési feladatot végrehajtó gazdagépet tömörítőnek hívjuk compactor.

A tömörítő a tömörítési kérelem kézhezvétele után RocksDB-Cloud példányt nyit meg szellem mód. Ez azt jelenti, hogy a RocksDB-Cloud csak a szükséges metaadatokkal nyitja meg a helyi adatbázist anélkül, hogy az összes SST fájlt lekérné a felhő tárhelyéről. Miután megnyitja a RocksDB példányt ghost módban, végrehajtja a tömörítési feladatot, beleértve a szükséges SST fájlok beolvasását, tömörítését és az újonnan tömörített SST fájlok ideiglenes tárolását a felhőben.

Itt találhatók a RocksDB-Cloud megnyitásának lehetőségei a tömörítőben:

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;

Több kihívás is van a tömörítési szint és a megoldásaink során szembesültünk:

Javítsa a RocksDB-Cloud megnyitásának sebességét a ghost ban mode

A RocksDB példányok megnyitása során, az összes SST fájl felhőből történő lekérése mellett (amelyet a ghost mode), számos más művelet lelassíthatja a nyitási folyamatot, nevezetesen az SST fájlok listájának megszerzése és az egyes SST fájlok méretének megadása. Általában, ha az összes SST fájl helyi tárhelyen található, akkor ezeknek a get-file méretű műveleteknek a késleltetése kicsi lenne. Amikor azonban a tömörítő megnyitja a RocksDB-Cloud szolgáltatást, ezek a műveletek mindegyike távoli kérelmet eredményez a felhőtárolóhoz, és a teljes kombinált késleltetés túlzottan drágává válik. Tapasztalataink szerint egy RocksDB-Cloud példány, SST fájlok ezreivel, megnyitása akár egy percet is igénybe vehet az S3-hoz tartozó get-file méretű kérések ezrei miatt. Ennek a korlátozásnak a kiküszöbölése érdekében különféle lehetőségeket vezettünk be a RocksDB-Cloud beállításaiban, hogy letiltsuk ezeket az RPC-ket a nyitás során. Ennek eredményeként az átlagos nyitási idő 7 másodpercről 700 milliszekundumra változik.

L0 letiltása -> L0 tömörítés

A távoli tömörítés kompromisszum az egyetlen tömörítés sebessége és a több tömörítési feladat párhuzamos futtatásának lehetősége között. Ennek oka, hogy természetesen minden távoli tömörítési feladat lassabb lenne, mint ugyanaz a helyileg végrehajtott tömörítés, a felhőben történő adatátvitel költségei miatt. Ezért a lehető legkisebbre szeretnénk minimalizálni a tömörítési folyamat szűk keresztmetszetét, ahol a RocksDB-Cloud nem tud párhuzamosítani.

Az LSM architektúrában az L0-> L1 tömörítés általában nem párhuzamosítható, mert Az L0 fájlok átfedő tartományokkal rendelkeznek. Ennélfogva, amikor L0-> L1 tömörítés történik, a RocksDB-Cloud képes végrehajtani az L0-> L0 tömörítést is, azzal a céllal, hogy csökkentse az L0 fájlok számát és megakadályozza az írás elakadást, mivel a RocksDB-Cloud eléri az L0 fájlt határ. A kompromisszum azonban az, hogy minden L0 fájl mérete nagyobb lesz minden L0-> L0 tömörítés után.

Tapasztalataink szerint ez az opció több problémát okoz, mint az általa nyújtott előnyök, mert nagyobb L0 fájlok birtoklása sokkal hosszabb L0-> L1 tömörítést eredményez, ami rontja a RocksDB-Cloud szűk keresztmetszetét. Ezért letiltjuk az L0-> L0 tömörítést, és helyette élünk az írási elakadás ritka problémájával. Kísérletünkből a RocksDB-Cloud tömörítés sokkal jobban felzárkózik a beérkező írásokkal.

Most már használhatja

A RocksDB-Cloud egy nyílt forráskódú projekt, így munkánk képes bármely más RocksDB fejlesztő által kihasználható, aki előnyöket akar elérni azzal, hogy elválasztja a tömörítési számítását a tárolási igényektől. A távoli tömörítési szolgáltatást a gyártásban futtatjuk. A RocksDB-Cloud 6.7.3 kiadásával érhető el. A RocksDB-Cloud szolgáltatással kapcsolatban mindent a nyilvános Slack csatornán tárgyalunk a http://bit.ly/rockset-community-channel címen.

Szerzők:

Hieu Pham – szoftvermérnök, Rockset
Dhruba Borthakur – CTO, Rockset

Eredetileg a https: // rockset.com 2020. június 4-én.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük