Cloud Deployments
Het is mogelijk om CockRoachDB dichtbij de gebruikers te brengen, verspreid over regio’s, datacenters en verschillende cloud providers. Data kan dynamisch verplaatsen naar de locatie waar het nodig is. CockRoachDB schaalt, balanceert en repareert automatisch. Handmatige sharding is niet nodig en ACID transacties zijn mogelijk.
Maar hoe zorgt CockRoachDB dan voor die consistentie?
CockRoachDB garandeert “serializable” isolation level, de hoogst gedefinieerde in de SQL standard. Het kan dit doen door het Raft consensus algoritme voor schrijven te combineren met op tijd gebaseerde synchronisatie algoritmes voor lezen.
- Opgeslagen data heeft een versie binnen MVCC, dus lees acties zijn gelimiteerd tot de versie op het moment dat
de lees transactie begon; - De schrijf acties gebruiken het Raft consensus algoritme wat inhoud dat een meerderheid van de nodes samen
bepalen of een update succesvol is geweest. Updates (schrijf acties) moeten een meerderheid van de nodes hebben
bereikt (standaard 2 van de 3) voordat ze als succesvol worden ervaren.
Om er zeker van te zijn dat een schrijf actie een lees actie die daarna is gestart niet dwarszit gebruikt CockRoachDB een “timestamp cache” die onthoud wanneer data het laatst is gelezen door lopende transacties.
Dit zorgt ervoor dat gebruikers (clients) altijd serializable consistentie zullen ervaren ten opzichte van andere gelijktijdige transacties.
Maar hoe is CockRoachDB dan zowel high available als sterk consistent?
De CAP theorie stelt dat het onmogelijk is voor gedistribueerde systemen om tegelijkertijd meer dan 2 van de volgende eigenschappen te hebben:
- consistency – consistentie
- availability – beschikbaarheid
- partition tolerance – partitie tolerantie
CockRoachDB is een CP (consistent en partitie tolerant) systeem. Dat betekent dat, indien er partities aanwezig zijn, het systeem eerder onbeschikbaar wordt dan dat het wordt toegelaten dat er inconsistente resultaten ontstaan. Bijvoorbeeld, schrijf acties vereisen bevestiging van een meerderheid van de nodes, en lees acties vereisen een lease, die alleen van een andere node kunnen komen als schrijf acties mogelijk zijn.
Daarnaast is CockRoachDB high available, hoewel “available” in dit kader iets anders betekent dan de manier waarop het gebruikt wordt in de CAP theorie. In de CAP theorie is het een binaire eigenschap, maar bij High Availability hebben wij het hier over een spectrum (zoals de term “five nines” voor een systeem dat 99,999% van de tijd beschikbaar is).
CP en HA als eigenschap hebben betekent dat in geval een meerderheid van de nodes tegen elkaar kan praten ze blijven werken. Wanneer je bijvoorbeeld CockRoachDB installeert in 3 datacenters en het netwerk naar 1 van deze datacenters raakt onbeschikbaar, dan zullen de andere 2 datacenters verder kunnen werken met slechts seconden onderbreking. CockRoachDB doet dit door partities en fouten snel en efficiënt te ontdekken en vervolgens de leiding over te dragen aan nodes die wel kunnen communiceren met de meerderheid, daarna wordt intern verkeer omgeleid van de nodes af die weg gepartitioneerd zijn.
Waarom is CockRoachDB compatible met PostgreSQL?
De bedenkers van CockRoachDB wilden zich focussen op datgene wat belangrijk is, het ontwikkelen van een eenvoudige, sterk gedistribueerde, consistente database. Dan wil je niet teveel tijd besteden aan zaken als het ontwikkelen van een netwerk protocol.
In eerste instantie speelde CockRoachDB met het idee om compatible te zijn met MySQL. Door een aantal factoren is de keuze uiteindelijk toch op PostgreSQL gevallen.
Het was vanaf het begin duidelijk dat de documentatie over het netwerk protocol van PostgreSQL veel duidelijker en uitgebreider was. Daarnaast ook veel meer supportive voor third-party implementaties dan MySQL.
De PostgreSQL licentie is compatible met CockRoachDB’s eigen Apache licentie wat inhoudt dat (een deel van) de source code niet aangepast hoefde te worden. In tegenstelling tot MySQL (en MariaDB) die onder de GNU GPL licentie vallen wat direct gebruik van de source code uitsluit voor CockRoachDB.
Hoe gaat het verder in de toekomst met die compatibiliteit met PostgreSQL?
Begin 2016 werd het duidelijk dat client drivers niet de enige drijfveer zijn om een product succesvol te maken. Development frameworks moeten ook een snelle adoptie van een nieuwe product mogelijk maken. Dit betekent dat niet alleen het netwerk protocol van PostgreSQL compatible moet worden gehouden maar de hele SQL laag. Of de investeren in ontwikkeling van uitbreidingen op het bestaande PostgreSQL framework.
CockRoachDB beseft dit en is feitelijk bezig met investeringen in beide richtingen.
Prioriteit heeft nu het vergroten van de compatibiliteit met PostgreSQL semantics out-of-the-box, zoals het toevoegen van meer en meer van PostgreSQL built-in functions en operators, en verstrekken van compatibele data via het information_schema. En pg_catalog meta-informatie tabellen. Hier zal de komende versies van CockRoachDB naar worden gestreefd.
Er zullen wel altijd een aantal bestaande features van CockRoachDB blijven bestaan die nooit volledig compatibel zullen worden omdat ze fundamenteel anders zijn qua database architectuur. Bijvoorbeeld PostgreSQL’s “FOR Locking clauses” kunnen niet worden geïmplementeerd in CockRoachDB omdat de beginselen voor concurrency control in CockRoachDB zo anders zijn. Wanneer bestaande client frameworks zulke PostgreSQL features nodig hebben zal CockRoachDB investeren in de ontwikkeling van een specifieke CockRoachDB versie ervoor.
Meer weten?
OptimaData BV volgt de ontwikkelingen van NewSQL databases op de voet om haar klanten te kunnen ondersteunen bij
het maken van een toekomstbestendige keuze tussen database platformen. Neem gerust contact op, We denken graag met je mee!