Ahoj, Khabrovites. Tradične pokračujeme v zdieľaní zaujímavého materiálu v predvečer štartu nových kurzov. Dnes sme špeciálne pre vás preložili článok o Google Cloud Spanner, ktorý je načasovaný na začiatok kurzu .
Pôvodne uverejnené v .
Ako spoločnosť, ktorá ponúka množstvo cloudových riešení POS pre maloobchodníkov, reštaurátorov a online obchodníkov po celom svete, Lightspeed používa niekoľko rôznych typov databázových platforiem pre rôzne prípady použitia v oblasti transakcií, analýzy a vyhľadávania. Každá z týchto databázových platforiem má svoje silné a slabé stránky. Keď teda spoločnosť Google uviedla na trh Cloud Spanner – sľubné funkcie, ktoré vo svete relačných databáz ešte neboli nevídané, ako napríklad prakticky neobmedzenú horizontálnu škálovateľnosť a 99,999 % zmluvu o úrovni služieb (SLA) , Nemohli sme si nechať ujsť príležitosť mať ju vo svojich rukách!
Aby sme poskytli komplexný prehľad o našich skúsenostiach s Cloud Spanner, ako aj o kritériách hodnotenia, ktoré sme použili, pokryjeme nasledujúce témy:
- Naše hodnotiace kritériá
- Cloud Spanner v skratke
- Naše hodnotenie
- Naše zistenia
1. Naše hodnotiace kritériá
Skôr než sa ponoríme do špecifík Cloud Spanner, jeho podobností a rozdielov s inými riešeniami na trhu, povedzme si najprv o hlavných prípadoch použitia, ktoré sme mali na mysli, keď sme zvažovali, kde nasadiť Cloud Spanner v našej infraštruktúre:
- Ako náhrada (prevládajúceho) tradičného databázového riešenia SQL
- Ako riešenie OLTP s podporou OLAP
Poznámka: Pre uľahčenie porovnania tento článok porovnáva Cloud Spanner s variantmi MySQL z rodín riešení GCP Cloud SQL a Amazon AWS RDS.
Používanie Cloud Spanner ako náhrady za tradičné riešenie databázy SQL
V prostredí tradičný databázy, keď sa čas odozvy na databázový dotaz blíži alebo dokonca prekročí preddefinované aplikačné prahy (predovšetkým kvôli zvýšeniu počtu používateľov a/alebo požiadaviek), existuje niekoľko spôsobov, ako skrátiť čas odozvy na prijateľnú úroveň. Väčšina týchto riešení však zahŕňa manuálny zásah.
Prvým krokom, ktorý treba napríklad urobiť, je pozrieť sa na rôzne nastavenia databázy súvisiace s výkonom a vyladiť ich tak, aby čo najlepšie zodpovedali vzorom scenárov používania aplikácií. Ak to nestačí, môžete si zvoliť škálovanie databázy vertikálne alebo horizontálne.
Škálovanie aplikácie si vyžaduje aktualizáciu inštancie servera, zvyčajne pridaním ďalších procesorov/jadier, väčšej pamäte RAM, rýchlejšieho úložiska atď. Pridanie ďalších hardvérových prostriedkov má za následok zvýšený výkon databázy, meraný predovšetkým v transakciách za sekundu, a latenciu transakcií pre systémy OLTP. Relačné databázové systémy (ktoré používajú viacvláknový prístup), ako napríklad MySQL, sa dobre vertikálne škálujú.
Tento prístup má niekoľko nevýhod, ale najzrejmejšou je maximálna veľkosť servera na trhu. Po dosiahnutí najväčšieho limitu inštancie servera zostáva už len jedna cesta: zmenšiť.
Scale-out je prístup, ktorý pridáva viac serverov do klastra, aby sa v ideálnom prípade lineárne zvýšil výkon, keď sa pridávajú ďalšie servery. Väčšina tradičný databázové systémy sa neškálujú dobre alebo sa neškálujú vôbec. Napríklad MySQL môže škálovať pre operácie čítania pridaním slave čítačiek, ale nemôže škálovať pre operácie zápisu.
Na druhej strane, vďaka svojej povahe môže Cloud Spanner ľahko horizontálne škálovať s minimálnym zásahom.
Plne vybavený DBMS ako služba treba hodnotiť z rôznych uhlov pohľadu. Ako základ sme zobrali najpopulárnejší DBMS v cloude – pre Google GCP Cloud SQL a pre Amazon AWS RDS. V našom hodnotení sme sa zamerali na tieto kategórie:
- Mapovanie funkcií: rozsah SQL, DDL, DML; knižnice/konektory pripojení, podpora transakcií atď.
- Podpora vývoja: Jednoduchosť vývoja a testovania.
- Podpora správy: Správa inštancií, ako je škálovanie nahor/nadol a inovácia inštancií; SLA, zálohovanie a obnova; zabezpečenie/kontrola prístupu.
Používanie Cloud Spanner ako riešenia OLTP s podporou OLAP
Aj keď Google výslovne neuvádza, že Cloud Spanner je určený na analýzu, zdieľa niektoré atribúty s inými nástrojmi, ako sú Apache Impala & Kudu a YugaByte, ktoré sú navrhnuté pre pracovné zaťaženie OLAP.
Aj keby existovala len malá šanca, že Cloud Spanner obsahuje konzistentný škálovateľný HTAP (Hybrid Transactional/Analytic Processing) engine s (viac či menej) použiteľnou sadou funkcií OLAP, myslíme si, že by si to zaslúžilo našu pozornosť.
S ohľadom na to sme sa pozreli na nasledujúce kategórie:
- Podpora načítania dát, indexov a delenia
- Výkon dotazov a DML
2. Cloud Spanner v skratke
Google Spanner je klastrový systém správy relačných databáz (RDBMS), ktorý Google používa pre niekoľko vlastných služieb. Google ho verejne sprístupnil používateľom platformy Google Cloud Platform začiatkom roka 2017.
Tu sú niektoré z atribútov Cloud Spanner:
- Vysoko konzistentný, škálovateľný klaster RDBMS: Používa hardvérovú synchronizáciu času na zabezpečenie konzistencie údajov.
- Podpora transakcií medzi tabuľkami: Transakcie môžu zahŕňať viacero tabuliek – nie sú nevyhnutne obmedzené na jednu tabuľku (na rozdiel od Apache HBase alebo Apache Kudu).
- Tabuľky založené na primárnom kľúči: Všetky tabuľky musia mať deklarovaný primárny kľúč (PC), ktorý môže pozostávať z viacerých stĺpcov tabuľky. Tabuľkové údaje sú uložené v PC poradí, vďaka čomu sú veľmi efektívne a rýchle pre vyhľadávanie na PC. Rovnako ako u iných systémov založených na PC, implementácia musí byť modelovaná podľa vopred vytvorených prípadov použitia, aby sa to dosiahlo .
- Pruhované tabuľky: Tabuľky môžu mať na sebe fyzické závislosti. Riadky podradenej tabuľky sa môžu zhodovať s riadkami nadradenej tabuľky. Tento prístup urýchľuje hľadanie vzťahov, ktoré možno určiť vo fáze modelovania údajov, napríklad pri spájaní zákazníkov a ich faktúr.
- Indexy: Cloud Spanner podporuje sekundárne indexy. Index pozostáva z indexovaných stĺpcov a všetkých stĺpcov PC. Voliteľne môže index obsahovať aj iné neindexované stĺpce. Index môže byť preložený s nadradenou tabuľkou, aby sa urýchlili dotazy. Na indexy sa vzťahuje niekoľko obmedzení, napríklad maximálny počet ďalších stĺpcov, ktoré možno uložiť do indexu. Dopyty cez indexy tiež nemusia byť také jednoduché ako v iných RDBMS.
„Cloud Spanner vyberá index automaticky iba v zriedkavých prípadoch. Cloud Spanner predovšetkým automaticky nevyberie sekundárny index, ak dotaz vyžaduje stĺpce, ktoré nie sú uložené ".
- Service Level Agreement (SLA): Nasadenie v jednom regióne s 99,99 % SLA; multiregionálne nasadenia s 99,999 % SLA. Aj keď samotná zmluva SLA je len zmluvou a nie je zárukou akéhokoľvek druhu, verím, že ľudia z Google majú nejaké tvrdé údaje, aby mohli vzniesť také silné tvrdenie. (Pre informáciu, 99,999 % znamená 26,3 sekundy výpadku služby za mesiac.)
- viac:
Poznámka: Projekt Apache Tephra pridáva pokročilú podporu transakcií do Apache HBase (teraz implementovaný aj v Apache Phoenix ako beta).
3. Naše hodnotenie
Všetci sme teda čítali vyhlásenia Google o výhodách Cloud Spanner – prakticky neobmedzené horizontálne škálovanie pri zachovaní vysokej konzistencie a veľmi vysokej SLA. Hoci tieto tvrdenia je v každom prípade mimoriadne ťažké dosiahnuť, naším cieľom nebolo ich vyvrátiť. Namiesto toho sa sústreďme na iné veci, ktoré zaujímajú väčšinu používateľov databáz: paritu a použiteľnosť.
Cloud Spanner sme ohodnotili ako náhradu za Sharded MySQL
Google Cloud SQL a Amazon AWS RDS, dve z najpopulárnejších databáz OLTP na cloudovom trhu, majú veľmi veľkú sadu funkcií. Ak však chcete škálovať tieto databázy nad veľkosť jedného uzla, musíte vykonať rozdelenie aplikácií. Tento prístup vytvára dodatočnú zložitosť pre aplikácie aj správu. Pozreli sme sa na to, ako Spanner zapadá do scenára kombinovania viacerých úlomkov do jednej inštancie a aké funkcie (ak nejaké) možno bude potrebné obetovať.
Podpora pre SQL, DML a DDL, ako aj konektor a knižnice?
Po prvé, keď začínate s akoukoľvek databázou, musíte vytvoriť dátový model. Ak si myslíte, že môžete pripojiť JDBC Spanner k svojmu obľúbenému nástroju SQL, zistíte, že pomocou neho môžete vyhľadávať údaje, ale nemôžete ho použiť na vytvorenie tabuľky alebo aktualizácie (DDL) alebo akéhokoľvek vloženia/aktualizácie/odstránenia. operácie (DML). Oficiálne JDBC spoločnosti Google nepodporuje ani jednu.
"Ovládače momentálne nepodporujú príkazy DML alebo DDL."
Dokumentácia kľúča
S konzolou GCP nie je situácia o nič lepšia – posielať môžete len SELECT dopyty. Našťastie existuje ovládač JDBC s podporou DML a DDL od komunity vrátane transakcií . Aj keď je tento ovládač mimoriadne užitočný, absencia vlastného JDBC ovládača od Google je prekvapivá. Našťastie Google ponúka pomerne širokú podporu klientskych knižníc (založená na gRPC): C#, Go, Java, node.js, PHP, Python a Ruby.
Takmer povinné používanie vlastných API Cloud Spanner (kvôli nedostatku DDL a DML v JDBC) vedie k určitým obmedzeniam pre súvisiace oblasti kódu, ako je združovanie pripojení alebo rámce viazania databáz (ako Spring MVC). Vo všeobecnosti si pri používaní JDBC môžete vybrať svoj obľúbený fond pripojení (napr. HikariCP, DBCP, C3PO atď.), ktorý je otestovaný a funguje dobre. V prípade vlastných Spanner API sa musíme spoliehať na frameworky/binding/session pools, ktoré sme si sami vytvorili.
Dizajn orientovaný na primárny kľúč (PC) umožňuje, aby bol Cloud Spanner veľmi rýchly pri prístupe k údajom cez PC, ale tiež prináša niektoré problémy s dotazmi.
- Nemôžete aktualizovať hodnotu primárneho kľúča; Najprv musíte vymazať pôvodný záznam PC a znova ho vložiť s novou hodnotou. (Je to podobné ako v prípade iných databázových/úložných strojov orientovaných na PC.)
- Akékoľvek príkazy UPDATE a DELETE musia špecifikovať PC v WHERE, preto nemôžu byť prázdne príkazy DELETE all - vždy musí existovať poddotaz, napríklad: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Chýba možnosť automatického zvýšenia alebo niečo podobné, čo nastavuje postupnosť poľa PC. Aby to fungovalo, musí byť na strane aplikácie vytvorená zodpovedajúca hodnota.
Sekundárne indexy?
Google Cloud Spanner má vstavanú podporu pre sekundárne indexy. Toto je veľmi príjemná funkcia, ktorá nie je vždy prítomná v iných technológiách. Apache Kudu momentálne vôbec nepodporuje sekundárne indexy a Apache HBase nepodporuje indexy priamo, ale môže ich pridať cez Apache Phoenix.
Indexy v Kudu a HBase je možné modelovať ako samostatnú tabuľku s rôznym zložením primárnych kľúčov, ale atomicita operácií vykonávaných na nadradenej tabuľke a súvisiacich indexových tabuľkách sa musí vykonávať na aplikačnej úrovni a nie je triviálna na správnu implementáciu.
Ako je uvedené v recenzii Cloud Spanner, jeho indexy sa môžu líšiť od indexov MySQL. Preto je potrebné venovať osobitnú pozornosť vytváraniu dotazov a profilovaniu, aby sa zabezpečilo, že sa tam, kde je to potrebné, použije správny index.
zastupovanie?
Veľmi obľúbeným a užitočným objektom v databáze sú pohľady. Môžu byť užitočné pre veľký počet prípadov použitia; moje dve obľúbené sú vrstva logickej abstrakcie a vrstva zabezpečenia. Cloud Spanner bohužiaľ nepodporuje zobrazenia. To nás však obmedzuje len čiastočne, pretože neexistuje žiadna podrobnosť na úrovni stĺpcov pre prístupové povolenia, kde môžu byť zobrazenia prijateľným riešením.
Pozrite si dokumentáciu Cloud Spanner, kde nájdete časť s podrobnými informáciami o kvótach a limitoch (), existuje jedna konkrétna, ktorá môže byť pre niektoré aplikácie problematická: Cloud Spanner má po vybalení maximálne 100 databáz na inštanciu. Je zrejmé, že to môže byť hlavnou prekážkou pre databázu, ktorá je navrhnutá tak, aby sa škálovala na viac ako 100 databáz. Našťastie sme po rozhovore s naším technickým zástupcom Google zistili, že tento limit je možné prostredníctvom podpory Google zvýšiť takmer na akúkoľvek hodnotu.
Podpora rozvoja?
Cloud Spanner ponúka celkom slušnú podporu programovacieho jazyka pre prácu s jeho API. Oficiálne podporované knižnice sú v oblasti C#, Go, Java, node.js, PHP, Python a Ruby. Dokumentácia je pomerne podrobná, ale rovnako ako pri iných špičkových technológiách je komunita v porovnaní s najpopulárnejšími databázovými technológiami pomerne malá, čo môže viesť k viac času strávenému menej bežnými prípadmi použitia alebo problémami.
Ako je to teda s podporou miestneho rozvoja?
Nenašli sme spôsob, ako vytvoriť lokálnu inštanciu Cloud Spanner. Najbližšie sme sa dostali k obrázku Docker ktorý je v princípe podobný, ale v praxi veľmi odlišný. Napríklad CockroachDB môže používať PostgreSQL JDBC. Keďže vývojové prostredie by malo byť čo najbližšie k produkčnému prostrediu, Cloud Spanner nie je ideálny, pretože sa musíte spoľahnúť na plnú inštanciu Spanner. Ak chcete ušetriť náklady, môžete vybrať jednu inštanciu regiónu.
Administratívna podpora?
Vytvorenie inštancie Cloud Spanner je veľmi jednoduché. Stačí si vybrať medzi vytvorením inštancie s viacerými oblasťami alebo s jednou oblasťou, špecifikovať oblasť (regióny) a počet uzlov. Za menej ako minútu bude inštancia v prevádzke.
Niekoľko základných metrík je dostupných priamo na stránke Spanner v konzole Google. Podrobnejšie zobrazenia sú dostupné cez Stackdriver, kde môžete nastaviť aj prahové hodnoty metrík a zásady upozornení.
Prístup k zdrojom?
MySQL ponúka rozsiahle a veľmi podrobné nastavenia používateľských povolení/rolí. Prístup ku konkrétnej tabuľke alebo dokonca len k podmnožine jej stĺpcov môžete jednoducho prispôsobiť. Cloud Spanner používa nástroj Google Identity & Access Management (IAM), ktorý vám umožňuje nastaviť pravidlá a povolenia len na veľmi vysokej úrovni. Najpodrobnejšou možnosťou je povolenie na úrovni databázy, ktoré sa nehodí do väčšiny produkčných prípadov. Toto obmedzenie vás núti pridať dodatočné bezpečnostné opatrenia do vášho kódu, infraštruktúry alebo oboch, aby ste zabránili neoprávnenému použitiu zdrojov Spanner.
Zálohy?
Zjednodušene povedané, v Cloud Spanner nie sú žiadne zálohy. Aj keď vysoké požiadavky spoločnosti Google na SLA môžu zabezpečiť, že nestratíte žiadne údaje v dôsledku zlyhania hardvéru alebo databázy, ľudskej chyby, chýb aplikácií atď. Všetci poznáme pravidlo: vysoká dostupnosť nenahrádza stratégiu inteligentného zálohovania. V súčasnosti je jediným spôsobom zálohovania údajov ich programové streamovanie z databázy do samostatného úložného prostredia.
Výkon dopytu?
Na načítanie údajov a testovanie dopytov sme použili Yahoo!. Porovnanie poskytovania cloudu. Nižšie uvedená tabuľka zobrazuje pracovné zaťaženie B YCSB s pomerom 95 % čítania k 5 % zápisu.
* Záťažový test bol vykonaný na n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB pamäte) a testovacia inštancia nikdy nebola prekážkou v testoch.
** Maximálny počet vlákien v jednej inštancii YCSB je 400. Celkovo bolo potrebné spustiť šesť paralelných inštancií testov YCSB, aby sa získalo celkovo 2400 vlákien.
Pri pohľade na výsledky benchmarku, najmä na kombináciu zaťaženia procesora a TPS, jasne vidíme, že Cloud Spanner sa škáluje celkom dobre. Veľké zaťaženie vytvárané veľkým počtom vlákien je kompenzované veľkým počtom uzlov v klastri Cloud Spanner. Aj keď latencia vyzerá dosť vysoká, najmä keď beží na 2400 vláknach, môže byť potrebné zopakovať test so 6 menšími inštanciami výpočtového stroja, aby ste získali presnejšie čísla. Každá inštancia spustí jeden test YCSB namiesto jednej veľkej inštancie CE so 6 paralelnými testami. To uľahčí rozlíšenie medzi oneskoreniami požiadaviek Cloud Spanner a oneskoreniami pridanými sieťovým pripojením medzi Cloud Spanner a inštanciou CE, na ktorej prebieha test.
Ako funguje Cloud Spanner ako OLAP?
Rozdelenie?
Rozdelenie údajov do fyzicky a/alebo logicky nezávislých segmentov, nazývaných oddiely, je veľmi populárny koncept, ktorý nájdeme vo väčšine OLAP motorov. Oddiely môžu výrazne zlepšiť výkon dotazov a udržiavateľnosť databázy. Ďalšie ponorenie sa do delenia by bolo na samostatný článok (články), takže spomeňme len dôležitosť schémy delenia a podrozdelenia. Schopnosť rozdeliť údaje na oddiely a ešte viac na pododdiely je kľúčom k výkonu analytických dopytov.
Cloud Spanner nepodporuje oddiely ako také. Údaje interne oddeľuje na tzv rozdeliť-s na základe rozsahov primárnych kľúčov. Rozdelenie sa vykonáva automaticky, aby sa vyrovnalo zaťaženie klastra Cloud Spanner. Veľmi praktickou funkciou Cloud Spanner je rozdelenie základného zaťaženia nadradenej tabuľky (tabuľky, ktorá nie je preložená inou). Spanner automaticky zistí, či obsahuje rozdeliť údaje, ktoré sa čítajú častejšie ako údaje v iných rozdeliť-ah, a môže rozhodnúť o ďalšom oddelení. Do požiadavky teda môže byť zapojených viac uzlov, čo tiež efektívne zvyšuje priepustnosť.
Načítavajú sa údaje?
Metóda Cloud Spanner pre hromadné údaje je rovnaká ako pre bežné nahrávanie. Ak chcete dosiahnuť maximálny výkon, musíte dodržiavať niektoré pokyny vrátane:
- Zoraďte údaje podľa primárneho kľúča.
- Vydeľte ich 10*počet uzlov jednotlivé sekcie.
- Vytvorte skupinu pracovných úloh, ktoré načítavajú údaje paralelne.
Toto načítanie údajov využíva všetky uzly Cloud Spanner.
Použili sme pracovné zaťaženie A YCSB na vygenerovanie množiny údajov riadkov s veľkosťou 10 miliónov.
* Test záťaže bol spustený na výpočtovom jadre n1-standard-32 (32 vCPU, 120 GB pamäte) a testovacia inštancia nikdy nebola prekážkou v testoch.
** Nastavenie 1 uzla sa neodporúča pre žiadnu produkčnú záťaž.
Ako už bolo spomenuté vyššie, Cloud Spanner automaticky spracováva rozdelenia v závislosti od ich zaťaženia, takže výsledky sa zlepšujú po niekoľkých po sebe nasledujúcich iteráciách testu. Tu prezentované výsledky sú najlepšími výsledkami, ktoré sme dostali. Pri pohľade na vyššie uvedené čísla vidíme, ako sa Cloud Spanner mení (dobre), ako sa zvyšuje počet uzlov v klastri. Čísla, ktoré vynikajú, sú extrémne nízka priemerná latencia, ktorá kontrastuje s výsledkami zmiešaného pracovného zaťaženia (95 % čítanie a 5 % zápis), ako je opísané v časti vyššie.
Škálovanie?
Zvýšenie a zníženie počtu uzlov Cloud Spanner je úloha na jedno kliknutie. Ak chcete rýchlo načítať dáta, možno budete chcieť zvážiť zvýšenie inštancie na maximum (v našom prípade to bolo 25 uzlov v regióne US-EAST) a potom znížiť počet uzlov vhodných pre vaše bežné zaťaženie po všetkých dátach. v databáze, pričom treba pamätať na limit 2 TB/uzol.
Túto hranicu sme si pripomenuli aj pri oveľa menšej databáze. Po niekoľkých testoch záťaže mala naša databáza veľkosť približne 155 GB a pri zmenšení na inštanciu 1 uzla sme dostali nasledujúcu chybu:
Dokázali sme zmenšiť z 25 na 2 inštancie, ale uviazli sme na dvoch uzloch.
Zvyšovanie a znižovanie počtu uzlov v klastri Cloud Spanner je možné automatizovať pomocou REST API. To môže byť užitočné najmä na zníženie zvýšeného zaťaženia systému počas rušných hodín.
Výkon dotazu OLAP?
Pôvodne sme plánovali venovať veľa času nášmu hodnoteniu Spannera v tejto časti. Po niekoľkých SELECT COUNTS sme si okamžite uvedomili, že test bude krátky a že Spanner NEBUDE vhodný engine pre OLAP. Bez ohľadu na počet uzlov v klastri, jednoduchý výber počtu riadkov v tabuľke riadkov s veľkosťou 10 miliónov trval 55 až 60 sekúnd. Tiež každý dotaz, ktorý vyžadoval viac pamäte na uloženie medzivýsledkov, zlyhal s chybou OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Niektoré čísla pre dopyty TPC-H nájdete v článku Todda Lipcona , snímky 42 a 43. Tieto čísla sú v súlade s našimi vlastnými výsledkami (bohužiaľ).
4. Naše zistenia
Vzhľadom na súčasný stav funkcií Cloud Spanner je ťažké ho považovať za jednoduchú náhradu za existujúce riešenie OLTP, najmä ak ho vaše potreby prerastajú. Vytvorenie riešenia nedostatkov Cloud Spanner by si vyžiadalo značné množstvo času.
Keď sme začali vyhodnocovať Cloud Spanner, očakávali sme, že jeho funkcie správy budú na rovnakej úrovni, alebo aspoň nie sú vzdialené od iných riešení Google SQL. Prekvapil nás však úplný nedostatok záloh a veľmi obmedzená kontrola prístupu k zdrojom. Nehovoriac o žiadnych pohľadoch, lokálnom vývojovom prostredí, nepodporovaných sekvenciách, JDBC bez podpory DML a DDL atď.
Takže, kam sa obrátiť na niekoho, kto potrebuje škálovať transakčnú databázu? Zdá sa, že na trhu zatiaľ neexistuje jediné riešenie, ktoré by vyhovovalo všetkým prípadom použitia. Existuje mnoho uzavretých a otvorených riešení (niektoré z nich sú uvedené v tomto článku), každé má svoje silné a slabé stránky, ale žiadne z nich neponúka SaaS s 99,999% SLA a vysokou konzistenciou. Ak je vaším primárnym cieľom vysoká SLA a nechcete si vytvoriť vlastné riešenie pre viacero cloudov, Cloud Spanner môže byť riešením, ktoré hľadáte. Mali by ste si však uvedomiť všetky jeho obmedzenia.
Aby sme boli spravodliví, Cloud Spanner bol vydaný pre verejnosť až na jar 2017, takže je rozumné očakávať, že niektoré z jeho súčasných nedostatkov môžu nakoniec zmiznúť (dúfajme), a keď sa tak stane, môže to zmeniť hru. Cloud Spanner totiž nie je len vedľajším projektom pre Google. Google ho používa ako základ pre ďalšie produkty Google. A keď spoločnosť Google nedávno nahradila Megastore v službe Google Cloud Storage službou Cloud Spanner, umožnila službe Google Cloud Storage stať sa vysoko konzistentnou pre zoznamy objektov v globálnom meradle (čo stále neplatí pre ).
Takže, stále je tu nádej... dúfame.
To je všetko. Rovnako ako autor článku, aj my naďalej dúfame, ale čo si o tom myslíte? Napíšte do komentárov
Pozývame všetkých na návštevu našej v ktorej vám podrobne povieme o kurze od spoločnosti OTUS.
Zdroj: hab.com