Hallo, inwoners van Khabrovsk. Zoals gewoonlijk blijven we interessant materiaal delen voorafgaand aan de start van nieuwe cursussen. Speciaal voor jou hebben we vandaag, ter gelegenheid van de lancering van de cursus, een artikel over Google Cloud Spanner gepubliceerd .
Oorspronkelijk gepubliceerd in .
Als bedrijf dat een verscheidenheid aan cloudgebaseerde POS-oplossingen biedt aan detailhandelaren, restauranthouders en online verkopers over de hele wereld, gebruikt Lightspeed verschillende soorten databaseplatforms voor een verscheidenheid aan transactionele, analytische en zoekgebruiksscenario's. Elk van deze databaseplatforms heeft zijn eigen sterke en zwakke punten. Toen Google Cloud Spanner op de markt introduceerde – veelbelovende functies die ongezien zijn in de wereld van relationele databases, zoals vrijwel onbeperkte horizontale schaalbaarheid en een Service Level Agreement (SLA) van 99,999%, — we konden de kans niet missen om het in handen te krijgen!
Om een uitgebreid overzicht te geven van onze ervaring met Cloud Spanner, evenals de evaluatiecriteria die we hebben gebruikt, behandelen we de volgende onderwerpen:
- Onze evaluatiecriteria
- Cloud Spanner in een notendop
- Onze beoordeling
- Onze bevindingen
1. Onze evaluatiecriteria
Voordat we ingaan op de specifieke kenmerken van Cloud Spanner en de overeenkomsten en verschillen met andere oplossingen op de markt, laten we het eerst hebben over de belangrijkste gebruiksscenario's die we in gedachten hadden toen we nadachten over waar we Cloud Spanner in onze infrastructuur zouden inzetten:
- Als vervanging voor de (overheersende) traditionele SQL-databaseoplossing
- Hoe OLTP-oplossing met OLAP-ondersteuning te gebruiken
Opmerking: Voor eenvoud en vergelijkingsgemak vergelijkt dit artikel Cloud Spanner met de MySQL-varianten van de GCP Cloud SQL- en Amazon AWS RDS-oplossingsfamilies.
Cloud Spanner gebruiken als vervanging voor een traditionele SQL-databaseoplossing
In het milieu traditioneel databases, wanneer de responstijd van databasequery's de vooraf gedefinieerde applicatiedrempels benadert of zelfs overschrijdt (voornamelijk als gevolg van een toename van het aantal gebruikers en/of verzoeken), zijn er verschillende manieren om de responstijd terug te brengen tot aanvaardbare niveaus. Bij de meeste van deze oplossingen gaat het echter om handmatige tussenkomst.
De eerste stap die u moet zetten, is bijvoorbeeld kijken naar de verschillende prestatiegerelateerde databaseparameters en deze afstemmen op de beste afstemming op de gebruikspatronen van toepassingen. Als dit niet genoeg is, kunt u ervoor kiezen om de database verticaal of horizontaal te schalen.
Het verticaal schalen van een applicatie houdt het upgraden van de serverinstantie in, meestal door het toevoegen van meer processors/cores, meer RAM, snellere opslag, enz. Het toevoegen van meer hardwarebronnen resulteert in betere databaseprestaties, voornamelijk gemeten in transacties op de tweede plaats, en transactielatentie voor OLTP-systemen. Relationele databasesystemen (die een multi-threaded aanpak gebruiken) zoals MySQL schalen goed verticaal.
Er zijn verschillende nadelen aan deze aanpak, maar het meest voor de hand liggende is de maximale servergrootte op de markt. Zodra de limiet van de grootste serverinstantie is bereikt, blijft er nog maar één optie over: horizontaal schalen.
Horizontaal schalen is een aanpak waarbij meer servers aan een cluster worden toegevoegd, waarbij de prestaties idealiter lineair worden verhoogd naarmate het aantal servers wordt toegevoegd. Meerderheid traditioneel Databasesystemen schalen horizontaal niet goed of helemaal niet. MySQL kan bijvoorbeeld horizontaal schalen voor leesbewerkingen door slave-lezers toe te voegen, maar kan niet horizontaal schalen voor schrijfbewerkingen.
Aan de andere kant kan Cloud Spanner vanwege zijn aard eenvoudig horizontaal schalen met minimale tussenkomst.
Volledig uitgerust DBMS als een service moet vanuit verschillende invalshoeken worden beoordeeld. Als basis hebben we het populairste DBMS in de cloud genomen - voor Google, GCP Cloud SQL en voor Amazon, AWS RDS. Bij onze beoordeling hebben we ons gericht op de volgende categorieën:
- Functietoewijzing: omvang SQL, DDL, DML; verbindingsbibliotheken/connectoren, transactieondersteuning, enzovoort.
- Ontwikkelingsondersteuning: eenvoudig ontwikkelen en testen.
- Administratieve ondersteuning: instancebeheer - bijvoorbeeld het op- en afschalen en upgraden van instances; SLA, back-up en herstel; beveiliging/toegangscontrole.
Cloud Spanner gebruiken als een OLAP-compatibele OLTP-oplossing
Hoewel Google niet expliciet beweert dat Cloud Spanner is ontworpen voor analytische verwerking, deelt het enkele kenmerken met andere zoekmachines, zoals Apache Impala & Kudu en YugaByte, die zijn ontworpen voor OLAP-workloads.
Zelfs als er maar een kleine kans was dat Cloud Spanner een consistente scale-out HTAP-engine (hybride transactionele/analytische verwerking) zou bevatten met een (min of meer) bruikbare OLAP-functieset, denken we dat dit onze aandacht waard zou zijn.
Met dit in gedachten hebben we naar de volgende categorieën gekeken:
- Ondersteuning voor het laden van gegevens, indexen en partities
- Queryprestaties en DML
2. Cloud Spanner in een notendop
Google Spanner is een geclusterd relationeel databasebeheersysteem (RDBMS) dat Google gebruikt voor verschillende van zijn eigen services. Google heeft het begin 2017 algemeen beschikbaar gemaakt voor Google Cloud Platform-gebruikers.
Hier volgen enkele kenmerken van Cloud Spanner:
- Zeer consistent schaalbaar RDBMS-cluster: maakt gebruik van hardwaretijdsynchronisatie om gegevensconsistentie te garanderen.
- Ondersteuning voor cross-table transacties: Transacties kunnen meerdere tabellen omvatten - niet noodzakelijkerwijs beperkt tot een enkele tabel (in tegenstelling tot Apache HBase of Apache Kudu).
- Op primaire sleutels gebaseerde tabellen: Alle tabellen moeten een gedeclareerde primaire sleutel (PC) hebben, die uit meerdere kolommen in de tabel kan bestaan. Gegevens in tabelvorm worden in pc-volgorde opgeslagen, waardoor zoeken op de pc zeer efficiënt en snel gaat. Net als bij andere pc-gebaseerde systemen moet de implementatie worden gemodelleerd met vooraf ontworpen gebruiksscenario's in gedachten .
- Gestreepte tabellen: Tabellen kunnen fysieke afhankelijkheden van elkaar hebben. Rijen in een onderliggende tabel kunnen worden vergeleken met rijen in een bovenliggende tabel. Deze aanpak versnelt het zoeken naar relaties die kunnen worden geïdentificeerd tijdens de datamodelleringsfase, zoals het colocatie van klanten en hun facturen.
- Indexen: Cloud Spanner ondersteunt secundaire indexen. De index bestaat uit de geïndexeerde kolommen en alle pc-kolommen. Indien gewenst kan de index ook andere niet-geïndexeerde kolommen bevatten. De index kan worden verweven met de bovenliggende tabel om zoekopdrachten te versnellen. Er zijn verschillende beperkingen van toepassing op indexen, zoals het maximale aantal extra kolommen dat in de index wordt opgeslagen. Bovendien zijn zoekopdrachten via indexen mogelijk niet zo eenvoudig als in andere RDBMS's.
“Cloud Spanner selecteert alleen in zeldzame gevallen automatisch een index. In het bijzonder selecteert Cloud Spanner niet automatisch een secundaire index als een query kolommen opvraagt die niet zijn opgeslagen .
- Service Level Agreement (SLA): Implementatie in één regio met een SLA van 99,99%; multiregionale implementaties met een SLA van 99,999%. Hoewel de SLA zelf slechts een overeenkomst is en geen enkele garantie, denk ik dat de mensen bij Google over een aantal harde gegevens beschikken om zo'n sterke claim te maken. (Ter referentie: 99,999% betekent 26,3 seconden onbeschikbaarheid van de service per maand.)
- meer:
Opmerking: Het Apache Tephra-project voegt verbeterde transactieondersteuning toe aan Apache HBase (nu ook geïmplementeerd in Apache Phoenix als bèta).
3. Onze beoordeling
We hebben dus allemaal de beweringen van Google gelezen over de voordelen van Cloud Spanner: vrijwel onbeperkte horizontale schaling met behoud van hoge consistentie en een zeer hoge SLA. Hoewel deze eisen hoe dan ook uiterst moeilijk te verwezenlijken zijn, was het niet ons doel om ze te weerleggen. Laten we ons in plaats daarvan concentreren op andere dingen waar de meeste databasegebruikers om geven: pariteit en bruikbaarheid.
We hebben Cloud Spanner geëvalueerd als vervanging voor Sharded MySQL
Google Cloud SQL en Amazon AWS RDS, twee van de meest populaire OLTP DBMS'en op de cloudmarkt, hebben een zeer groot aantal functies. Als u deze databases echter verder wilt schalen dan de grootte van één enkel knooppunt, moet u toepassingspartitionering uitvoeren. Deze aanpak zorgt voor extra complexiteit voor zowel applicaties als beheer. We hebben gekeken hoe Spanner past in het scenario van het combineren van meerdere shards in één exemplaar en welke functies (indien aanwezig) mogelijk moeten worden opgeofferd.
SQL-, DML- en DDL-ondersteuning, evenals connectoren en bibliotheken?
Als u met een database begint, moet u eerst een gegevensmodel maken. Als u denkt dat u JDBC Spanner kunt verbinden met uw favoriete SQL-tool, zult u merken dat u daarmee uw gegevens kunt opvragen, maar dat u deze niet kunt gebruiken om een tabel te maken of te wijzigen (DDL) of iets in te voegen/bij te werken/verwijderen bewerkingen (DML). De officiële JDBC van Google ondersteunt geen van beide.
"Stuurprogramma's ondersteunen momenteel geen DML- of DDL-instructies."
Spanner-documentatie
Met de GCP-console is de situatie niet beter: u kunt alleen SELECT-query's verzenden. Gelukkig is er een JDBC-driver met ondersteuning voor DML en DDL uit de community, inclusief transacties . Hoewel deze driver buitengewoon nuttig is, is het ontbreken van Google's eigen JDBC-driver verrassend. Gelukkig biedt Google vrij brede ondersteuning voor clientbibliotheken (gebaseerd op gRPC): C#, Go, Java, node.js, PHP, Python en Ruby.
Het bijna verplichte gebruik van aangepaste API's van Cloud Spanner (vanwege het ontbreken van DDL en DML in JDBC) resulteert in enkele beperkingen voor gerelateerde codegebieden zoals verbindingspools of database-bindende raamwerken (bijv. Spring MVC). Wanneer u JDBC gebruikt, bent u doorgaans vrij om uw favoriete verbindingspool te kiezen (bijvoorbeeld HikariCP, DBCP, C3PO, enz.) die is getest en goed werkt. In het geval van aangepaste Spanner API's zijn we aangewezen op raamwerken/bindende pools/sessies die we zelf hebben gemaakt.
Het op de primaire sleutel (PC) gerichte ontwerp zorgt ervoor dat Cloud Spanner zeer snel toegang heeft tot gegevens via de pc, maar introduceert ook enkele queryproblemen.
- U kunt de primaire sleutelwaarde niet bijwerken; U moet de vermelding eerst van de oorspronkelijke pc verwijderen en opnieuw invoegen met de nieuwe waarde. (Dit is vergelijkbaar met andere pc-georiënteerde database-/opslagengines.)
- Alle UPDATE- en DELETE-instructies moeten PC specificeren in de WHERE. Daarom kunnen DELETE all-instructies niet leeg zijn - er moet altijd een subquery zijn, bijvoorbeeld: UPDATE xxx WHERE id IN (SELECT id FROM tabel1)
- Gebrek aan een optie voor automatisch verhogen of iets dergelijks dat de volgorde voor het pc-veld instelt. Om dit te laten werken, moet de overeenkomstige waarde aan de applicatiezijde worden gecreëerd.
Secundaire indexen?
Google Cloud Spanner heeft ingebouwde ondersteuning voor secundaire indexen. Dit is een erg leuke functie die niet altijd aanwezig is in andere technologieën. Apache Kudu ondersteunt momenteel helemaal geen secundaire indexen, en Apache HBase ondersteunt indexen niet rechtstreeks, maar kan deze toevoegen via Apache Phoenix.
Indexen in Kudu en HBase kunnen worden gemodelleerd als een afzonderlijke tabel met een andere samenstelling van primaire sleutels, maar de atomiciteit van de bewerkingen die worden uitgevoerd op de bovenliggende tabel en de bijbehorende indextabellen moet op applicatieniveau worden uitgevoerd en is niet triviaal om correct te implementeren.
Zoals vermeld in de Cloud Spanner-recensie, kunnen de indexen ervan verschillen van MySQL-indexen. Daarom moet speciale aandacht worden besteed aan het samenstellen van query's en profilering om ervoor te zorgen dat de juiste index wordt gebruikt waar deze nodig is.
Vertegenwoordiging?
Een zeer populair en nuttig object in een database zijn views. Ze kunnen nuttig zijn voor een groot aantal gebruiksscenario's; mijn twee favorieten zijn de logische abstractielaag en de beveiligingslaag. Helaas ondersteunt Cloud Spanner GEEN weergaven. Dit beperkt ons echter slechts gedeeltelijk, omdat er geen granulariteit is voor toegangsrechten op kolomniveau, waar weergaven een haalbare oplossing kunnen zijn.
Zie de Cloud Spanner-documentatie voor een sectie met details over quota's en beperkingen (), is er één in het bijzonder die voor sommige applicaties problematisch kan zijn: Cloud Spanner heeft standaard een limiet van maximaal 100 databases per instance. Uiteraard kan dit een groot knelpunt zijn voor een database die is ontworpen om te schalen naar meer dan 100 databases. Gelukkig kwamen we er na een gesprek met onze technische vertegenwoordiger van Google achter dat deze limiet via Google Support tot vrijwel elke waarde kan worden verhoogd.
Ontwikkelingsondersteuning?
Cloud Spanner biedt behoorlijk behoorlijke programmeertaalondersteuning voor het werken met zijn API. Officieel ondersteunde bibliotheken bevinden zich op het gebied van C#, Go, Java, node.js, PHP, Python en Ruby. De documentatie is vrij gedetailleerd, maar net als bij andere geavanceerde technologieën is de gemeenschap vrij klein in vergelijking met de meest populaire databasetechnologieën, wat ertoe kan leiden dat er meer tijd wordt besteed aan het oplossen van minder vaak voorkomende gebruiksscenario's of problemen.
Hoe zit het dan met het ondersteunen van lokale ontwikkeling?
We hebben geen manier gevonden om op locatie een Cloud Spanner-instantie te maken. Het dichtstbij dat we kwamen was een Docker-image. , wat in principe vergelijkbaar is, maar in de praktijk heel anders. CockroachDB kan bijvoorbeeld PostgreSQL JDBC gebruiken. Omdat de ontwikkelomgeving zo dicht mogelijk bij de productieomgeving moet liggen, is Cloud Spanner niet ideaal omdat deze moet vertrouwen op een volledige Spanner-instantie. Om kosten te besparen, kunt u een exemplaar met één regio selecteren.
Administratie hulp?
Het maken van een Cloud Spanner-instantie is heel eenvoudig. U hoeft alleen maar te kiezen tussen het maken van een exemplaar met meerdere regio's of een exemplaar met één regio, en specificeert de regio('s) en het aantal knooppunten. Binnen een minuut is uw exemplaar operationeel.
Verschillende basisstatistieken zijn rechtstreeks toegankelijk via de Spanner-pagina in de Google Console. Meer gedetailleerde weergaven zijn beschikbaar via Stackdriver, waar u ook metrische drempelwaarden en waarschuwingsbeleid kunt instellen.
Toegang tot hulpbronnen?
MySQL biedt uitgebreide en zeer gedetailleerde instellingen voor gebruikersrechten/rollen. U kunt eenvoudig de toegang tot een specifieke tabel configureren, of zelfs slechts tot een subset van de kolommen ervan. Cloud Spanner maakt gebruik van de Identity & Access Management (IAM) tool van Google, waarmee u alleen beleid en rechten op een zeer hoog niveau kunt instellen. De meest gedetailleerde optie is resolutie op databaseniveau, die niet past in de meeste productiegebruiksscenario's. Deze beperking dwingt u om extra beveiligingsmaatregelen toe te voegen aan uw code, infrastructuur of beide om ongeoorloofd gebruik van Spanner-bronnen te voorkomen.
Back-ups?
Simpel gezegd: er zijn geen back-ups in Cloud Spanner. Hoewel de hoge SLA-eisen van Google ervoor kunnen zorgen dat u geen gegevens verliest door hardware- of databasestoringen, menselijke fouten, applicatiedefecten, etc. We kennen allemaal de regel: hoge beschikbaarheid is geen vervanging voor een goede back-upstrategie. Momenteel is de enige manier om een back-up van gegevens te maken, deze programmatisch vanuit een database naar een afzonderlijke opslagomgeving te streamen.
Queryprestaties?
We gebruikten Yahoo! om gegevens te laden en zoekopdrachten te testen. Benchmark voor cloudservices. De onderstaande tabel toont YCSB-werkbelasting B met een lees- en 95% schrijfratio van 5%.
* De belastingstest werd uitgevoerd op de n1-standaard-32 Compute Engine (CE) (32 vCPU, 120 GB geheugen) en de testinstantie vormde nooit een knelpunt in de tests.
** Het maximale aantal threads in één YCSB-instantie is 400. Er moesten in totaal zes parallelle instanties van YCSB-tests worden uitgevoerd om een totaal van 2400 threads te verkrijgen.
Als we naar de benchmarkresultaten kijken, met name naar de combinatie van CPU-belasting en TPS, kunnen we duidelijk zien dat Cloud Spanner behoorlijk goed schaalt. De zware belasting die wordt veroorzaakt door het grote aantal threads wordt gecompenseerd door het grote aantal knooppunten in het Cloud Spanner-cluster. Hoewel de latentie behoorlijk hoog lijkt, vooral als er met 2400 threads wordt gewerkt, kan het opnieuw testen met zes kleinere instanties van de rekenengine nodig zijn om nauwkeurigere cijfers te krijgen. Elke instantie voert één YCSB-test uit in plaats van één grote CE-instantie met zes parallelle tests. Op deze manier wordt het gemakkelijker om onderscheid te maken tussen de latentie van Cloud Spanner-verzoeken en de latentie die wordt toegevoegd door de netwerkverbinding tussen Cloud Spanner en de CE-instantie die de test uitvoert.
Hoe presteert Cloud Spanner als OLAP?
Verdeling?
Het verdelen van gegevens in fysiek en/of logisch onafhankelijke segmenten, partities genoemd, is een zeer populair concept dat in de meeste OLAP-engines wordt aangetroffen. Partities kunnen de queryprestaties en het onderhoud van de database aanzienlijk verbeteren. Een diepere uitleg over het partitioneren zou een apart artikel(en) zijn, dus laten we even het belang van het hebben van een partitie- en subpartitioneringsschema vermelden. De mogelijkheid om gegevens op te splitsen in partities en zelfs nog verder in subpartities is essentieel voor de prestaties van analytische query's.
Cloud Spanner ondersteunt geen partities als zodanig. Het verdeelt de gegevens intern in zogenaamde spleet-s gebaseerd op primaire sleutelbereiken. Partitionering wordt automatisch uitgevoerd om de belasting in een Cloud Spanner-cluster te verdelen. Een zeer nuttige functie van Cloud Spanner is het splitsen van de basisbelasting van de bovenliggende tabel (een tabel die niet met een andere is interleaved). Spanner detecteert automatisch of er sprake is van spleet gegevens die vaker worden gelezen dan gegevens in andere spleet-ah, en kan beslissen over verdere scheiding. Op deze manier kunnen meer knooppunten bij een verzoek betrokken zijn, wat ook de doorvoer effectief verhoogt.
Data laden?
De Cloud Spanner-methode voor bulkgegevens is hetzelfde als voor normaal laden. Om maximale prestaties te bereiken, moet u enkele richtlijnen volgen, waaronder:
- Sorteer uw gegevens op primaire sleutel.
- Deel ze door 10*aantal knooppunten aparte secties.
- Creëer een set werktaken die gegevens parallel laden.
Bij het laden van gegevens worden alle Cloud Spanner-nodes gebruikt.
We hebben YCSB-werklast A gebruikt om een dataset van 10 miljoen rijen te genereren.
* De belastingstest werd uitgevoerd op de n1-standaard-32 compute-engine (32 vCPU, 120 GB geheugen) en de testinstantie vormde nooit een knelpunt in de tests.
**Instelling met één knooppunt wordt niet aanbevolen voor productiewerklasten.
Zoals hierboven vermeld, verwerkt Cloud Spanner automatisch splitsingen op basis van hun belasting, zodat de resultaten verbeteren na verschillende opeenvolgende testherhalingen. De hier gepresenteerde resultaten zijn de beste resultaten die we hebben behaald. Als we naar de bovenstaande cijfers kijken, kunnen we zien hoe Cloud Spanner (goed) schaalt naarmate het aantal knooppunten in het cluster toeneemt. De cijfers die opvallen zijn de extreem lage gemiddelde latenties, die contrasteren met de resultaten voor gemengde werkbelastingen (95% lezen en 5% schrijven) zoals beschreven in het bovenstaande gedeelte.
Schalen?
Het verhogen of verlagen van het aantal Cloud Spanner-nodes is een taak met één klik. Als u gegevens snel wilt laden, kunt u overwegen uw exemplaar tot het maximum te verhogen (in ons geval waren dit 25 knooppunten in de US-OOST-regio) en vervolgens het aantal knooppunten te verminderen dat in aanmerking komt voor uw normale belasting zodra alle gegevens binnen zijn. de database, verwijzend naar de limiet van 2TB/node.
Zelfs met een veel kleinere database werden we aan deze limiet herinnerd. Na verschillende uitvoeringen van belastingstests was onze database ongeveer 155 GB groot, en toen we deze terugschaalden naar een instantie met één knooppunt, ontvingen we de volgende foutmelding:
We zijn erin geslaagd om terug te schalen van 25 naar 2 instanties, maar we zaten vast op twee knooppunten.
Het vergroten en verkleinen van het aantal knooppunten in een Cloud Spanner-cluster kan worden geautomatiseerd met behulp van de REST API. Dit kan vooral handig zijn om de verhoogde systeembelasting tijdens drukke werkuren te verminderen.
Prestaties van OLAP-query's?
Oorspronkelijk waren we van plan om aan dit onderdeel een aanzienlijke hoeveelheid tijd te besteden aan onze evaluatie van Spanner. Na verschillende SELECT COUNTs realiseerden we ons onmiddellijk dat het testen kort zou zijn en dat Spanner GEEN geschikte engine voor OLAP zou zijn. Ongeacht het aantal knooppunten in het cluster duurde het simpelweg selecteren van het aantal rijen in een rijtabel van 10 miljoen tussen 55 en 60 seconden. Bovendien mislukte elke query waarvoor meer geheugen nodig was om tussenresultaten op te slaan, met een OOM-fout.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Enkele cijfers voor TPC-H-query's zijn te vinden in het artikel van Todd Lipcon , dia's 42 en 43. Deze cijfers komen (helaas) overeen met onze eigen resultaten.
4. Onze conclusies
Gezien de huidige staat van de functies van Cloud Spanner is het moeilijk voor te stellen dat dit een eenvoudige vervanging is voor uw bestaande OLTP-oplossing, vooral wanneer uw behoeften deze ontgroeien. Er zou een aanzienlijke hoeveelheid tijd moeten worden besteed aan het bouwen van een oplossing rond de tekortkomingen van Cloud Spanner.
Toen we Cloud Spanner begonnen te evalueren, verwachtten we dat de beheerfuncties vergelijkbaar zouden zijn met, of in ieder geval niet te ver verwijderd zouden zijn van, andere Google SQL-oplossingen. Maar we waren verrast door het volledige gebrek aan back-ups en de zeer beperkte controle over de toegang tot bronnen. Om nog maar te zwijgen van geen views, geen lokale ontwikkelomgeving, niet-ondersteunde sequenties, JDBC zonder DML- en DDL-ondersteuning, enzovoort.
Dus waar gaat iemand heen die een transactionele database moet schalen? Er lijkt geen enkele oplossing op de markt te zijn die voor alle gebruiksscenario's geschikt is. Er zijn veel gesloten en open source-oplossingen (waarvan er enkele in dit artikel worden genoemd), elk met hun eigen sterke en zwakke punten, maar geen enkele biedt SaaS met een SLA van 99,999% en een hoge consistentie. Als een hoge SLA jouw voornaamste doel is en je bent niet geneigd om een multi-cloud oplossing op maat te bouwen, dan is Cloud Spanner wellicht de oplossing die jij zoekt. Maar u moet zich bewust zijn van al zijn beperkingen.
Om eerlijk te zijn, werd Cloud Spanner pas in het voorjaar van 2017 aan het publiek vrijgegeven, dus het is redelijk om te verwachten dat sommige van de huidige tekortkomingen uiteindelijk zullen verdwijnen (hopelijk), en als ze dat doen, zou het een game changer kunnen zijn. Cloud Spanner is immers niet zomaar een bijproject van Google. Google gebruikt het als basis voor andere Google-producten. En toen Google onlangs Megastore in Google Cloud Storage verving door Cloud Spanner, kon Google Cloud Storage zeer consistent worden voor lijsten met objecten op mondiale schaal (wat nog steeds niet het geval is voor ).
Er is dus nog hoop... we hopen.
Dat is alles. Net als de auteur van het artikel blijven ook wij hopen, maar wat vind jij hiervan? Schrijf in de reacties
Wij nodigen iedereen uit om onze te bezoeken waarin wij u uitgebreid vertellen over de cursus van OTUS.
Bron: www.habr.com