Új adatbázis-motorral jelentkezett a Google

Új adatbázis-technológiával jelentkezik a Google, az immár hivatalosan is elérhető Cloud Spanner igazi áttörés lehet az elosztott globális adatbázisok piacán, amelyet ráadásul üzleti kritikus rendszerek alá is mer ajánlani a cég. Lássuk, mitől akkora szám a Spanner!

Transzkontinentális konzisztencia

A nagy ígéret, hogy a Spanner képes a relációs és nem-relációs adatbázisok előnyeit ötvözni. Így rendelkezik sémával, SQL-lel kérdezhető le és erős konzisztenciát nyújt. Miközben magas rendelkezésreállást, horizontális skálázódást és automatikus replikációt is kínál, a Google-től pedig felhős szolgáltatásként vehető igénybe.

A szakemberek már az előző bekezdésnél felkaphatták a fejüket: az ACID-elveket betartó, SQL-szemantikával kompatibilis, de globálisan elosztott adatbázis-platform, amely ráadásul nagyon magas rendelkezésre állást is kínál, nem nagyon van a piacon. A hagyományos relációs adatbázisok ugyan már évtizedek óta bizonyítanak rendelkezésre állás területén és természetesen az ACID és az SQL sem okoz nekik semmilyen kihívást, a horizontális skálázódás és különösen a globális adatközpontok közötti elosztás már komoly akadályt jelent. A másik végletet a NoSQL adatbázisok jelentik, amelyeket kimondottan a skálázódás igénye hívott életre, ez a területen pedig ragyogóan be is váltak. A tranzakciós konzisztenciánál már nem teljesítenek ennyire jól és a rendelkezésre állás sem elegendő az üzleti kritikus szerepekre.

De mi lesz a CAP-elmélettel?

A Brewer-elmélet (vagy CAP-elmélet) kimondja, hogy nem lehet olyan elosztott számítógépes rendszert építeni, amely egyszerre konzisztens, nyújt tökéletes rendelkezésre állást és particionálás-tűrést (consistency, availability, partition-tolerance - CAP), a három jellemzőből maximum kettő érhető egyszerre el (ezt egyébként 2002-ben a formális matematika eszközeivel sikerült is igazolni). A gyakorlatban ez azt jelentette, hogy ha skálázódó rendszert akarunk építeni, akkor a P kötelező, a C és az A közül, vagyis a konzisztencia és a rendelkezésre állás közül kell választani.

A csavar a dologban, hogy a CAP-elmélet csak az abszolút értelemben érvényes, tehát tökéletes, 100%-os rendelkezésre állás esetén. Vagyis a matematika (szerencsére) megengedi, hogy a konzisztencia és a particionálás mellett valamilyen szintű rendelkezésreállás is elérhető maradjon - ennek emeléséről szól igazából a Spanner fejlesztése. Az eredmény a Google szerint egy olyan CP-rendszer, amelyet a vásárlók nyugodtan tekinthetnek CA-nak - vagyis garantálja a konzisztenciát és a magas rendelkezésreállást is.

Ezt pedig saját példáján keresztül igazolni is tudja - egyes Google-szolgáltatások alatt ugyanis évek óta a Spanner verziói futnak, így a cég viszonylag pontosan látja már a rendszer limitációit. Az adatok szerint pedig a Spanner el tudja érni az öt-kilences rendelkezésre állást, ugyanúgy, mint egy korábbi kisérleti projekt, a kimondottan CA-elv mentén épült Chubby. Ezt egyébként amiatt van, mivel a P-ből, vagyis a particionálásból (jellemzően a partíciókat összekötő hálózat hibáiból) származó hibák mindössze szolgáltatáskiesések 8 százalékáért felelősek, ez a gyakorlatban annyira alacsony szám, hogy valós felhasználás mellett el lehet tőle tekinteni - erre mondja a Google, hogy a CP gyakorlatilag CA-szintű.

A kísérleti adatokat és a Spannert bemutató publikáció ki is mondja, hogy nem komplex adatbázis-szintű megoldásokkal sikerült ezt elérni - egész egyszerűen olyan minőségű hálózattal kell összekötni a globálisan szétszórt adatbázis-partíciókat, amelyik nem áll le. A Spanner partíciók összekötését ugyanis a Google nem a publikus interneten keresztül végzi, épp ellenkezőleg. A Google-adatközpontok között száz százalékban Google-által kontrollált hálózati eszközök dolgoznak, az adatbázisok között áramló hálózati csomagok nem érintenek idegen eszközöket. Persze redundancia is van a rendszerben, minden adatközpont három különböző optikán keresztül kapcsolódik a cég privát globális hálózatához, a redundancia pedig adatközponton belül és az eszközök szintén is megtalálható.

A fizikai redundancia persze csak a megbízhatóság egy része, korábban sok-sok példa mutatja, hogy téves üzemeltetési folyamatokkal egy redundáns rendszer is kártyavárként omlik össze - például hibásan konfigurált hálózati eszközökkel. A Google ezzel pontosan tisztában van, mára olyan üzemeltetési stratégiákat sikerült gyakorlatba ültetni, amelyek a gyakorlatban is limitálni tudják a változtatások hatását, így a rendkívül veszélyes dominó-effektus elkerülhető.

Google-technológiát, szolgáltatásként

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

A Spanner nem friss fejlesztés évek óta dolgozik különböző Google szolgáltatások alatt, a Gmail, az AdWords és számos más rendszer is erre az adatbázis-motorra támaszkodik. Az újdonság abban rejlik, hogy a rendszert a Google végre külső partnerek számára is megnyitotta, a Google Cloud Platform részeként immár előfizetéses szolgáltatásként bárki igénybe tudja venni, kiegészítve a cég adatbázis-szolgáltatási portfólióját a Cloud SQL, a Cloud Datastore és a Cloud Bigtable mellett.

A cég a Cloud Spannert kimondottan olyan feladatok alá ajánlja, ahol a tranzakcionális konzisztencia és a magas rendelkezésre állás fontos (raktárkészletek, pénzügyi tranzakciók, stb.). Az árazási modell viszonylag egyszerű, felhasznált node-onként 90 cent óránként - ami havonta mintegy 650 dollárnak felel meg. Ezen felül fizetni kell a tárolásért is, ez 30 cent per gigabájt per hónap. Szintén díjköteles az interkontinentális kimenő hálózati forgalom, amelyet célpont és forgalom szerint 8-23 centért mér gigabájtonként a cég. A szolgáltatás egyelőre béta címkével érhető el, de néhány hónap múlva az általános rajt is esedékes lehet.