Üdvözlet Habrovszk lakosai. Szokás szerint továbbra is érdekes anyagokat osztunk meg az új tanfolyamok kezdete előtt. Ma kifejezetten az Ön számára tettünk közzé egy cikket a Google Cloud Spannerről, hogy egybeessen a kurzus elindításával .
Eredetileg megjelent .
A Lightspeed a világ számos pontján felhőalapú POS-megoldásokat kínál kiskereskedőknek, vendéglősöknek és online eladóknak, ezért számos különböző típusú adatbázis-platformot használ a tranzakciós, elemzési és keresési felhasználási esetek széles skálájához. Ezen adatbázisplatformok mindegyikének megvannak a maga erősségei és gyengeségei. Ezért amikor a Google bemutatta a piacon a Cloud Spannert – amely a relációs adatbázisok világában még nem látott funkciókat ígért, mint például a gyakorlatilag korlátlan horizontális méretezhetőség és a 99,999%-os szolgáltatási szint megállapodás (SLA), — nem hagyhattuk ki a lehetőséget, hogy kézbe vehessük!
Annak érdekében, hogy átfogó áttekintést adjunk a Cloud Spannerrel kapcsolatos tapasztalatainkról, valamint az általunk használt értékelési kritériumokról, a következő témaköröket tárgyaljuk:
- Értékelési szempontjaink
- Felhőkulcs dióhéjban
- Értékelésünk
- Eredményeink
1. Értékelési szempontjaink
Mielőtt belemerülnénk a Cloud Spanner sajátosságaiba, hasonlóságaiba és különbségeibe a piacon lévő többi megoldással, először beszéljünk azokról a fő használati esetekről, amelyekre gondoltunk, amikor megfontoltuk, hogy infrastruktúránkban hol helyezzük el a Cloud Spannert:
- A (domináns) hagyományos SQL adatbázis-megoldás helyettesítőjeként
- OLTP megoldás OLAP támogatással
Megjegyzés: Az egyszerűség és az összehasonlítás megkönnyítése érdekében ez a cikk összehasonlítja a Cloud Spannert a GCP Cloud SQL és az Amazon AWS RDS megoldáscsalád MySQL-változataival.
A Cloud Spanner használata a hagyományos SQL adatbázis-megoldás helyettesítőjeként
A környezetben hagyományos adatbázisok esetén, amikor az adatbázis lekérdezési válaszideje megközelíti vagy akár meg is haladja az előre meghatározott alkalmazási küszöbértékeket (főleg a felhasználók és/vagy kérések számának növekedése miatt), többféle módon is csökkenthető a válaszidő elfogadható szintre. A legtöbb ilyen megoldás azonban kézi beavatkozást foglal magában.
Például az első lépés az, hogy megvizsgálja a különféle teljesítménnyel kapcsolatos adatbázis-paramétereket, és hangolja azokat úgy, hogy azok a legjobban illeszkedjenek az alkalmazások használati mintáihoz. Ha ez nem elég, választhatja az adatbázis függőleges vagy vízszintes méretezését.
Az alkalmazások függőleges méretezése magában foglalja a kiszolgálópéldány frissítését, jellemzően több processzor/mag hozzáadásával, több RAM-mal, gyorsabb tárolással stb. Több hardvererőforrás hozzáadása megnöveli az adatbázis-teljesítményt, elsősorban a második tranzakciókban mérve, valamint az OLTP-rendszerek tranzakciós késleltetését. A relációs adatbázis-rendszerek (amelyek többszálú megközelítést alkalmaznak), például a MySQL függőlegesen jól skálázhatók.
Ennek a megközelítésnek számos hátránya van, de a legnyilvánvalóbb a piacon elérhető maximális szerverméret. Ha elérte a legnagyobb szerverpéldány korlátját, már csak egy lehetőség marad: a vízszintes méretezés.
A vízszintes méretezés egy olyan megközelítés, amelyben több kiszolgálót adnak egy fürthöz, ideális esetben lineárisan növelve a teljesítményt a kiszolgálók számának hozzáadásával. Többség hagyományos Az adatbázisrendszerek nem vagy egyáltalán nem skálázódnak vízszintesen jól. Például a MySQL képes vízszintesen skálázni az olvasási műveletekhez szolga olvasók hozzáadásával, de nem skálázható vízszintesen az íráshoz.
Másrészt, természetéből adódóan a Cloud Spanner minimális beavatkozással könnyedén skálázható vízszintesen.
Teljes értékű DBMS mint szolgáltatás különböző szempontokból kell értékelni. Alapként a legnépszerűbb DBMS-t vettük a felhőben – a Google számára a GCP Cloud SQL, az Amazon esetében pedig az AWS RDS-t. Értékelésünk során a következő kategóriákra összpontosítottunk:
- Funkcióleképezés: kiterjedés SQL, DDL, DML; kapcsolati könyvtárak/csatlakozók, tranzakciós támogatás és így tovább.
- Fejlesztési támogatás: egyszerű fejlesztés és tesztelés.
- Adminisztrációs támogatás: példánykezelés – például a példányok fel/le méretezése és frissítése; SLA, biztonsági mentés és helyreállítás; biztonság/belépés ellenőrzés.
A Cloud Spanner használata OLAP-kompatibilis OLTP-megoldásként
Bár a Google nem állítja kifejezetten, hogy a Cloud Spannert analitikai feldolgozásra tervezték, bizonyos attribútumokat megoszt más motorokkal, például az Apache Impala & Kudu-val és a YugaByte-tal, amelyeket OLAP-munkaterhelésekre terveztek.
Még ha csak csekély esély is lenne arra, hogy a Cloud Spanner konzisztens skálázható HTAP (hibrid tranzakciós/analitikai feldolgozás) motort tartalmazzon (többé-kevésbé) használható OLAP funkciókészlettel, úgy gondoljuk, hogy érdemes lenne a figyelmünkre.
Ezt szem előtt tartva a következő kategóriákat vizsgáltuk:
- Adatbetöltés, indexek és particionálás támogatása
- Lekérdezési teljesítmény és DML
2. Felhőkulcs dióhéjban
A Google Spanner egy fürtözött relációs adatbázis-kezelő rendszer (RDBMS), amelyet a Google számos saját szolgáltatásához használ. A Google 2017 elején tette általánosan elérhetővé a Google Cloud Platform felhasználói számára.
Íme néhány Cloud Spanner attribútum:
- Nagyon konzisztens, méretezhető RDBMS-fürt: Hardveres időszinkronizálást használ az adatok konzisztenciájának biztosítása érdekében.
- Táblázatok közötti tranzakciók támogatása: A tranzakciók több táblára is kiterjedhetnek – nem feltétlenül korlátozódnak egyetlen táblára (ellentétben az Apache HBase-sel vagy az Apache Kudu-val).
- Elsődleges kulcs alapú táblák: Minden táblának rendelkeznie kell egy deklarált elsődleges kulccsal (PC), amely a táblázatban több oszlopból is állhat. A táblázatos adatok számítógépes sorrendben kerülnek tárolásra, így nagyon hatékonyak és gyorsak a számítógépes kereséshez. A többi PC-alapú rendszerhez hasonlóan a megvalósítást az előre megtervezett használati esetek figyelembevételével kell modellezni .
- Csíkos táblák: A tábláknak lehetnek fizikai függőségei. A gyermektábla sorai összevethetők a szülőtábla soraival. Ez a megközelítés felgyorsítja az adatmodellezési szakaszban azonosítható kapcsolatok keresését, mint például az ügyfelek és számláik közös elhelyezése.
- Indexek: A Cloud Spanner támogatja a másodlagos indexeket. Az index az indexelt oszlopokból és az összes PC oszlopból áll. Kívánt esetben az index más, nem indexelt oszlopokat is tartalmazhat. A lekérdezések felgyorsítása érdekében az indexet beilleszthetjük a szülőtáblába. Az indexekre számos korlátozás vonatkozik, például az indexben tárolt további oszlopok maximális száma. Ezenkívül előfordulhat, hogy az indexeken keresztüli lekérdezések nem olyan egyszerűek, mint más RDBMS-ekben.
„A Cloud Spanner csak ritka esetekben választ ki automatikusan egy indexet. A Cloud Spanner nem választ automatikusan másodlagos indexet, ha a lekérdezés olyan oszlopokat kér, amelyek nincsenek tárolva ".
- Szolgáltatási szint megállapodás (SLA): Telepítés egy régióban 99,99%-os SLA-val; több régióra kiterjedő telepítések 99,999%-os SLA-val. Noha maga az SLA csak egy megállapodás, nem pedig semmiféle garancia, úgy gondolom, hogy a Google munkatársai bizonyos kemény adatokkal rendelkeznek ahhoz, hogy ilyen erős állítást tegyenek. (Referenciaként a 99,999% azt jelenti, hogy a szolgáltatás havi 26,3 másodpercig nem érhető el.)
- tovább:
Megjegyzés: Az Apache Tephra projekt továbbfejlesztett tranzakciós támogatást ad az Apache HBase-hez (az Apache Phoenixben is béta verzióban).
3. Értékelésünk
Tehát mindannyian olvastuk a Google állításait a Cloud Spanner előnyeiről – gyakorlatilag korlátlan vízszintes skálázás a magas konzisztencia és nagyon magas SLA megőrzése mellett. Bár ezek a követelmények mindenesetre rendkívül nehezen teljesíthetők, nem az volt a célunk, hogy megcáfoljuk őket. Ehelyett összpontosítsunk más dolgokra, amelyek a legtöbb adatbázis-felhasználó számára fontosak: a paritásra és a használhatóságra.
A Cloud Spannert a Sharded MySQL helyettesítőjeként értékeltük
A Google Cloud SQL és az Amazon AWS RDS, a felhőpiac két legnépszerűbb OLTP DBMS-je, nagyon sok funkcióval rendelkezik. Ahhoz azonban, hogy ezeket az adatbázisokat egyetlen csomópont méretén túlra is méretezhesse, alkalmazásparticionálást kell végrehajtania. Ez a megközelítés további bonyolultságot teremt mind az alkalmazások, mind az adminisztráció számára. Megvizsgáltuk, hogy a Spanner hogyan illeszkedik abba a forgatókönyvbe, amikor több szilánkot egyetlen példányba kell kombinálni, és milyen funkciókat (ha van ilyen) kell feláldozni.
SQL, DML és DDL támogatás, valamint csatlakozó és könyvtárak?
Először is, ha bármilyen adatbázissal kezdi, létre kell hoznia egy adatmodellt. Ha úgy gondolja, hogy a JDBC Spannert csatlakoztathatja kedvenc SQL-eszközéhez, akkor azt fogja tapasztalni, hogy lekérdezheti vele adatait, de nem használhatja táblázat létrehozására, módosítására (DDL) vagy bármilyen beszúrásra/frissítésre/törlésre. műveletek (DML). A Google hivatalos JDBC-je ezek egyikét sem támogatja.
"Az illesztőprogramok jelenleg nem támogatják a DML vagy DDL utasításokat."
Villáskulcs dokumentációja
A GCP konzollal sem jobb a helyzet – csak SELECT lekérdezéseket küldhet. Szerencsére van egy JDBC-illesztőprogram, amely támogatja a DML-t és a DDL-t a közösségtől, beleértve a tranzakciókat is . Bár ez az illesztőprogram rendkívül hasznos, a Google saját JDBC-illesztőprogramjának hiánya meglepő. Szerencsére a Google meglehetősen széles körű támogatást kínál a klienskönyvtárak számára (gRPC-n alapul): C#, Go, Java, node.js, PHP, Python és Ruby.
A Cloud Spanner egyéni API-k szinte kötelező használata (a DDL és DML hiánya miatt a JDBC-ben) bizonyos korlátozásokat eredményez a kapcsolódó kódterületek, például a kapcsolatkészletek vagy az adatbázis-összerendelési keretrendszerek (pl. Spring MVC) tekintetében. A JDBC használatakor általában szabadon választhatja ki kedvenc kapcsolatkészletét (pl. HikariCP, DBCP, C3PO stb.), amely tesztelt és jól működik. Egyéni Spanner API-k esetén a saját magunk által létrehozott keretrendszerekre/kötőkészletekre/munkamenetekre kell hagyatkoznunk.
Az elsődleges kulcs (PC)-központú kialakítás lehetővé teszi a Cloud Spanner számára, hogy nagyon gyors legyen, amikor PC-n keresztül éri el az adatokat, de néhány lekérdezési problémát is bevezet.
- Az elsődleges kulcs értéke nem frissíthető; Először törölnie kell a bejegyzést az eredeti számítógépről, és újra be kell helyeznie az új értékkel. (Ez hasonló a többi PC-orientált adatbázis-/tárolómotorhoz.)
- Minden UPDATE és DELETE utasításnak meg kell adnia a PC-t a WHERE-ben, ezért nem lehet üres az összes DELETE utasítás - mindig kell lennie egy segédlekérdezésnek, például: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Hiányzik az automatikus növelés opció vagy bármi hasonló, amely beállítja a PC mező sorrendjét. Ahhoz, hogy ez működjön, létre kell hozni a megfelelő értéket az alkalmazás oldalán.
Másodlagos indexek?
A Google Cloud Spanner beépített támogatással rendelkezik a másodlagos indexekhez. Ez egy nagyon szép funkció, amely más technológiákban nem mindig van jelen. Az Apache Kudu jelenleg egyáltalán nem támogatja a másodlagos indexeket, az Apache HBase pedig nem támogatja közvetlenül az indexeket, de hozzáadhatja azokat az Apache Phoenixen keresztül.
A Kudu és a HBase indexei külön táblázatként modellezhetők az elsődleges kulcsok eltérő összetételével, de a szülőtáblán és a kapcsolódó indextáblákon végrehajtott műveletek atomitását az alkalmazás szintjén kell elvégezni, és nem triviális a helyes megvalósítás.
Amint azt a Cloud Spanner áttekintésében említettük, indexei eltérhetnek a MySQL indexeitől. Ezért különös gondot kell fordítani a lekérdezések és a profilalkotás során annak biztosítására, hogy a megfelelő indexet ott használják, ahol arra szükség van.
Reprezentáció?
Egy nagyon népszerű és hasznos objektum az adatbázisban a nézetek. Számos felhasználási esetben hasznosak lehetnek; a két kedvencem a logikai absztrakciós réteg és a biztonsági réteg. Sajnos a Cloud Spanner NEM támogatja a nézeteket. Ez azonban csak részben korlátoz minket, mert az oszlopok szintjén nincs részletes hozzáférési engedély, ahol a nézetek életképes megoldást jelenthetnek.
A kvótákat és korlátozásokat részletező szakaszt a Cloud Spanner dokumentációjában találja (), van egy különösen, amely bizonyos alkalmazásoknál problémát jelenthet: a Cloud Spanner azonnali korlátja legfeljebb 100 adatbázis lehet példányonként. Nyilvánvalóan ez komoly szűk keresztmetszet lehet egy olyan adatbázis számára, amelyet több mint 100 adatbázisra terveztek. Szerencsére, miután beszéltünk a Google műszaki képviselőjével, rájöttünk, hogy ez a korlát szinte bármilyen értékre növelhető a Google ügyfélszolgálatán keresztül.
Fejlesztési támogatás?
A Cloud Spanner meglehetősen tisztességes programozási nyelvi támogatást kínál az API-jával való együttműködéshez. A hivatalosan támogatott könyvtárak a C#, Go, Java, node.js, PHP, Python és Ruby területén találhatók. A dokumentáció meglehetősen részletes, de más fejlett technológiákhoz hasonlóan a közösség meglehetősen kicsi a legnépszerűbb adatbázis-technológiákhoz képest, ami miatt több időt kell fordítani a ritkább használati esetek vagy problémák megoldására.
Tehát mi a helyzet a helyi fejlesztés támogatásával?
Nem találtunk módot egy Cloud Spanner-példány helyszíni létrehozására. A legközelebbi dolog, amit kaptunk, egy Docker-kép volt. , ami elvileg hasonló, de a gyakorlatban nagyon eltérő. Például a CockroachDB használhatja a PostgreSQL JDBC-t. Mivel a fejlesztői környezetnek a lehető legközelebb kell állnia az éles környezethez, a Cloud Spanner nem ideális, mivel teljes csavarkulcs-példányra kell támaszkodnia. A költségek megtakarítása érdekében választhat egy régiós példányt.
Adminisztrációs támogatás?
A Cloud Spanner példány létrehozása nagyon egyszerű. Csak választania kell egy többrégiós vagy egyrégiós példány létrehozása között, adja meg a régió(ka)t és a csomópontok számát. Kevesebb, mint egy percen belül a példánya elindul és fut.
Számos kezdetleges mérőszám közvetlenül elérhető a Google Console Spanner oldaláról. Részletesebb nézetek a Stackdriveren keresztül érhetők el, ahol metrikus küszöbértékeket és riasztási szabályzatokat is beállíthat.
Hozzáférés az erőforrásokhoz?
A MySQL kiterjedt és nagyon részletes beállításokat kínál a felhasználói engedélyekhez/szerepekhez. Könnyen konfigurálhatja a hozzáférést egy adott táblához, vagy akár csak az oszlopainak egy részhalmazához. A Cloud Spanner a Google Identity & Access Management (IAM) eszközét használja, amely csak nagyon magas szintű házirendek és engedélyek beállítását teszi lehetővé. A legrészletesebb lehetőség az adatbázis-szintű felbontás, amely nem fér bele a legtöbb éles felhasználási esetbe. Ez a korlátozás arra kényszeríti, hogy további biztonsági intézkedéseket adjon a kódhoz, infrastruktúrához vagy mindkettőhöz, hogy megakadályozza a Spanner-erőforrások jogosulatlan használatát.
Biztonsági mentések?
Egyszerűen fogalmazva: a Cloud Spannerben nincs biztonsági másolat. Bár a Google magas SLA követelményei biztosítják, hogy ne veszítsen adatot hardver- vagy adatbázishibák, emberi hibák, alkalmazáshibák stb. miatt. Mindannyian ismerjük a szabályt: a magas rendelkezésre állás nem helyettesíti a megbízható biztonsági mentési stratégiát. Jelenleg az adatok biztonsági mentésének egyetlen módja az, hogy programozottan streameljük őket egy adatbázisból egy külön tárolókörnyezetbe.
Lekérdezi a teljesítményt?
Az adatok betöltésére és a lekérdezések tesztelésére a Yahoo!-t használtuk. Felhőalapú kiszolgálási referenciaérték. Az alábbi táblázat a YCSB B munkaterhelést mutatja 95%-os olvasási és 5%-os írási aránnyal.
* A terhelési tesztet az n1-standard-32 Compute Engine-n (CE) futtattuk (32 vCPU, 120 GB memória), és a tesztpéldány soha nem jelentett szűk keresztmetszetet a tesztekben.
** A szálak maximális száma egyetlen YCSB-példányban 400. Összesen hat párhuzamos YCSB-tesztet kellett futtatni, hogy összesen 2400 szálat kapjunk.
A benchmark eredményeket, különösen a CPU-terhelés és a TPS kombinációját tekintve egyértelműen láthatjuk, hogy a Cloud Spanner meglehetősen jól skálázható. A szálak nagy száma okozta nagy terhelést ellensúlyozza a Cloud Spanner-fürt csomópontjainak nagy száma. Noha a várakozási idő meglehetősen magasnak tűnik, különösen 2400 szálon futtatva, a számítási motor 6 kisebb példányával történő újratesztelésre lehet szükség a pontosabb számok eléréséhez. Minden példány egy YCSB-tesztet fog futtatni egy nagy CE-példány helyett, 6 párhuzamos teszttel. Így könnyebb lesz megkülönböztetni a Cloud Spanner kérés késését és a Cloud Spanner és a tesztet futtató CE-példány közötti hálózati kapcsolat által hozzáadott késést.
Hogyan működik a Cloud Spanner OLAP-ként?
Partícionálás?
Az adatok fizikailag és/vagy logikailag független szegmensekre, úgynevezett partíciókra való felosztása a legtöbb OLAP-motorban nagyon népszerű fogalom. A partíciók jelentősen javíthatják a lekérdezések teljesítményét és az adatbázis karbantarthatóságát. A particionálásba való mélyedés külön cikk(ek) lenne, szóval csak említsük meg a particionálási és alparticionálási séma fontosságát. Az adatok partíciókra és még tovább alpartíciókra bontásának képessége kulcsfontosságú az analitikai lekérdezések teljesítményéhez.
A Cloud Spanner önmagában nem támogatja a partíciókat. Az adatokat belsőleg ún osztott-s elsődleges kulcs tartományok alapján. A particionálás automatikusan megtörténik a Cloud Spanner-fürt terhelésének kiegyensúlyozása érdekében. A Cloud Spanner nagyon hasznos funkciója a szülőtábla alapterhelésének felosztása (olyan tábla, amely nincs átlapolva egy másikkal). A villáskulcs automatikusan érzékeli, hogy tartalmaz-e osztott olyan adatok, amelyeket gyakrabban olvasnak ki, mint mások adatait osztott-ah, és dönthet a további elválásról. Így több csomópont vonható be egy kérésbe, ami szintén hatékonyan növeli az átviteli sebességet.
Adatok betöltése?
A tömeges adatok Cloud Spanner módszere ugyanaz, mint a normál betöltésnél. A maximális teljesítmény elérése érdekében be kell tartania néhány irányelvet, többek között:
- Rendezze az adatokat elsődleges kulcs szerint.
- Osszuk el 10-zel*csomópontok száma külön szakaszok.
- Hozzon létre egy munkafeladat-készletet, amely párhuzamosan tölti be az adatokat.
Ez az adatbetöltés az összes Cloud Spanner csomópontot használja.
Az YCSB A munkaterhelést használtuk egy 10 millió sorból álló adatkészlet létrehozásához.
* A terhelési tesztet az n1-standard-32 számítási motoron futtatták (32 vCPU, 120 GB memória), és a tesztpéldány soha nem jelentett szűk keresztmetszetet a tesztekben.
**Az egycsomópont-beállítás semmilyen éles munkaterheléshez nem ajánlott.
Ahogy fentebb említettük, a Cloud Spanner automatikusan feldolgozza a felosztásokat a terhelésük alapján, így az eredmények több egymást követő tesztismétlés után javulnak. Az itt bemutatott eredmények az általunk elért legjobb eredmények. A fenti számokat tekintve láthatjuk, hogy a Cloud Spanner hogyan skálázódik (jól) a fürtben lévő csomópontok számának növekedésével. A kiemelkedő számok a rendkívül alacsony átlagos késleltetési idők, amelyek ellentétben állnak a vegyes munkaterhelések (95% olvasás és 5% írás) eredményeivel, amint azt a fenti szakaszban leírtuk.
Méretezés?
A Cloud Spanner csomópontok számának növelése és csökkentése egy kattintásos feladat. Ha gyorsan szeretné betölteni az adatokat, érdemes megfontolni a példány maximális növelését (esetünkben ez 25 csomópont volt az US-EAST régióban), majd csökkentse a normál betöltésre alkalmas csomópontok számát, miután az összes adat megérkezett. az adatbázis 2 TB/csomópont korlátra hivatkozva.
Emlékeztettünk erre a határra még egy sokkal kisebb adatbázisnál is. Többszöri terhelési teszt után az adatbázisunk körülbelül 155 GB méretű volt, és 1 csomópontos példányra kicsinyítve a következő hibát kaptuk:
Sikerült 25-ről 2-re kicsinyíteni, de két csomópontnál elakadtunk.
A Cloud Spanner-fürtben lévő csomópontok számának növelése és csökkentése automatizálható a REST API segítségével. Ez különösen hasznos lehet a megnövekedett rendszerterhelés csökkentése érdekében a forgalmas munkaidőben.
Az OLAP lekérdezések teljesítménye?
Eredetileg úgy terveztük, hogy jelentős időt töltünk a Spanner ezen a részének értékelésével. Több SELECT COUNT után azonnal rájöttünk, hogy a tesztelés rövid lesz, és a Spanner NEM lenne megfelelő motor az OLAP-hoz. A fürtben lévő csomópontok számától függetlenül a sorok számának egyszerű kiválasztása egy 10 millió soros táblázatban 55 és 60 másodperc között volt. Ezenkívül minden olyan lekérdezés, amely több memóriát igényelt a köztes eredmények tárolásához, OOM-hibával meghiúsult.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Néhány szám a TPC-H lekérdezésekhez Todd Lipcon cikkében található , 42. és 43. dia. Ezek a számok összhangban vannak saját eredményeinkkel (sajnos).
4. Következtetéseink
A Cloud Spanner szolgáltatásainak jelenlegi állapotát figyelembe véve nehéz elképzelni, hogy egyszerűen helyettesítheti a meglévő OLTP-megoldást, különösen akkor, ha az Ön igényei túlnőnek rajta. Jelentős mennyiségű időt kellene eltölteni a Cloud Spanner hiányosságaira megoldással.
Amikor elkezdtük a Cloud Spanner értékelését, arra számítottunk, hogy a felügyeleti funkciói egyenrangúak a Google SQL többi megoldásával, vagy legalábbis nem állnak távol azoktól. De meglepett minket a biztonsági mentések teljes hiánya és az erőforrásokhoz való hozzáférés nagyon korlátozott kontrollja. Nem beszélve a nézetek hiányáról, a helyi fejlesztői környezetről, a nem támogatott szekvenciákról, a DML és DDL támogatás nélküli JDBC-ről stb.
Tehát hová megy valaki, akinek szüksége van egy tranzakciós adatbázis méretére? Úgy tűnik, nincs egyetlen olyan megoldás a piacon, amely minden felhasználási esetnek megfelelne. Számos zárt és nyílt forráskódú megoldás létezik (amelyek közül néhányat említünk ebben a cikkben), mindegyiknek megvannak a maga erősségei és gyengeségei, de egyik sem kínál SaaS-t 99,999%-os SLA-val és magas konzisztenciával. Ha a magas szintű SLA a fő célja, és nem hajlandó egyedi többfelhős megoldást építeni, akkor a Cloud Spanner lehet a keresett megoldás. De tisztában kell lennie minden korlátjával.
Az igazság kedvéért a Cloud Spanner csak 2017 tavaszán jelent meg a nagyközönségnek, így joggal feltételezhető, hogy a jelenlegi hiányosságok egy része végül megszűnhet (remélhetőleg), és ha megtörténik, akkor akár játékot is megváltoztathat. Végül is a Cloud Spanner nem csak egy mellékprojekt a Google számára. A Google ezt használja más Google-termékek alapjául. És amikor a Google a közelmúltban a Megastore-t a Google Cloud Storage-ban a Cloud Spannerre cserélte, lehetővé tette, hogy a Google Cloud Storage rendkívül konzisztenssé váljon a globális méretű objektumok listáinál (ami még mindig nem így van ).
Szóval van még remény... reméljük.
Ez minden. A cikk írójához hasonlóan mi is továbbra is reménykedünk, de mit gondol erről? Írd meg kommentben
Mindenkit meghívunk, hogy látogassa meg amelyen belül részletesen elmondjuk a tanfolyamot az OTUS-tól.
Forrás: will.com