Inntil veldig nylig, da du handlet etter en database, måtte du velge: Skalerbarhet eller konsistens? SQL-databaser som MySQL garanterer sterk konsistens, men skaleres ikke horisontalt. (Manuell skjæring for skalerbarhet er ingen ide om moro.) NoSQL-databaser som MongoDB skalerer vakkert, men tilbyr bare eventuell konsistens. ("Vent lenge nok, så kan du lese det riktige svaret" - som ikke er noen måte å gjøre økonomiske transaksjoner på.)
Google Cloud Spanner, en fullstendig administrativ relasjonell databasetjeneste som kjører på Google Compute Engine (GCE), utgitt i februar 2017, har skalerbarhet av NoSQL-databaser mens den beholder SQL-kompatibilitet, relasjonsskjemaer, ACID-transaksjoner og sterk ekstern konsistens. Spanner er en splittet, globalt distribuert og replikert relasjonsdatabase som bruker en Paxos-algoritme for å oppnå enighet blant nodene.
Et alternativ til Spanner, og gjenstanden for denne anmeldelsen, er CockroachDB, en åpen kildekode, horisontalt skalerbar distribuert SQL-database utviklet av tidligere Googlers som var kjent med Spanner. CockroachDB låner fra Googles Spanner for utformingen av datalagringssystemet, og det bruker en Raft-algoritme for å oppnå enighet blant nodene.
I likhet med Cloud Spanner er CockroachDB en distribuert SQL-database bygget på toppen av en transaksjonell og konsistent nøkkelverdilager, i CockroachDBs tilfelle på RocksDB. CockroachDBs primære designmål er støtte for ACID-transaksjoner, horisontal skalerbarhet og (mest av alt) overlevelsesevne, derav navnet.
CockroachDB er designet for å overleve feil på disk, maskin, stativ og til og med datasenter med minimal latensforstyrrelse og ingen manuell inngrep. Selvfølgelig, for å oppnå det må du kjøre en klynge av mange forekomster av CockroachDBs symmetriske noder, ved bruk av flere disker, maskiner, stativer og datasentre.
I motsetning til Cloud Spanner, som bruker TrueTime API tilgjengelig for tidssynkronisering i Googles datasentre, kan CockroachDB ikke stole på tilstedeværelsen av atomur og GPS-satellittklokker for å synkronisere tiden nøyaktig på tvers av noder og datasentre. Det har en rekke implikasjoner. Til å begynne med gir Google TrueTime en øvre grense for tidsforskyvning mellom noder i en klynge på syv millisekunder. Det er lite nok til at en Spanner-node bare venter syv millisekunder etter en skriving før han rapporterer at en transaksjon har begått, for å garantere ekstern konsistens.
Uten TrueTime eller et lignende anlegg, må CockroachDB falle tilbake til NTP, noe som gir øvre grenser for kloksynkronisering mellom 100 millisekunder og 250 millisekunder. Gitt det større tidsvinduet, venter ikke CockroachDB etter skrivinger. I stedet for det noen ganger venter før lesing, starter i utgangspunktet en transaksjon hvis den leser en verdi med et tidsstempel større enn begynnelsen av transaksjonen, igjen for å garantere konsistens.
Når alle nodene i en CockroachDB-klynge har de små øvre grensene for klokkeforskyvninger du kan få fra GPS eller atomur, noe som bare blir tilgjengelig i store offentlige skyer, kan det være fornuftig å kjøre dem med --linjerbar flagg. Det får dem til å vente på maksimal tidsforskyvning før de returnerer en vellykket forpliktelse, akkurat som Spanner.
Hvordan CockroachDB fungerer
Hver CockroachDB-node består av fem lag:
- SQL, som oversetter klient-SQL-spørsmål til nøkkelverdier
- Transaksjon, som tillater atomendringer i flere nøkkelverdier
- Distribusjon, som presenterer replikerte nøkkelverdier som en enhet
- Replikering, som konsekvent og synkront replikerer nøkkelverdier på tvers av mange noder, og muliggjør konsekvent lesing via leieavtaler
- Storage, som skriver og leser nøkkelverdidata på disk
SQL-laget analyserer forespørsler mot en Yacc-fil og gjør dem til et abstrakt syntaks-tre. Fra det abstrakte syntakstreet genererer CockroachDB et tre av plannoder som inneholder nøkkelverdikode. Plannodene blir deretter utført, og kommuniserer med transaksjonslaget.
Transaksjonslaget implementerer ACID-transaksjonssemantikk med to-fase forpliktelser på tvers av hele klyngen, inkludert kryssområde- og kryssbordstransaksjoner, og behandler enkeltuttalelser som transaksjoner (også kalt auto-commit-modus). Tofaseforpliktelsen oppnås ved å legge ut transaksjonsoppføringer og skriveintensjoner, utføre leseoperasjoner og behandle eventuelle skriveintensjoner som oppstår som transaksjonskonflikter.
Distribusjonslaget mottar forespørsler fra transaksjonslaget på samme node. Den identifiserer deretter hvilke noder som skal motta forespørselen, og sender forespørselen til den riktige nodens replikasjonslag.
Replikasjonslaget kopierer data mellom noder og sørger for konsistens mellom disse kopiene ved å implementere en Raft-konsensusalgoritme. Du kan kontrollere replikasjonsfaktoren på klyngen, databasen og tabellnivået ved hjelp av replikeringssoner. Konsensusalgoritmen brukes bare til skriving, og krever at et antall replikaer er enige om eventuelle endringer i et område før disse endringene blir begått.
Lagringslaget lagrer data som nøkkelverdipar på disken ved hjelp av RocksDB. CockroachDB er sterkt avhengig av multi-version concurrency control (MVCC) for å behandle samtidige forespørsler og garantere konsistens. Mye av dette arbeidet gjøres ved hjelp av tidsstempler for hybrid logisk klokke (HLC).
I likhet med Spanner støtter CockroachDB tidsreiser (aktivert av MVCC). Disse kan gå tilbake så langt som den siste databaseavfallssamlingen din, utført som standard hver dag.
CockroachDB installasjon og bruk
CockroachDB kjører på Mac, Linux og Windows-operativsystemer, i det minste for utvikling og test. Produksjons kakerlakk-databaser kjøres vanligvis på Linux-virtuelle maskiner eller orkestrerte containere, ofte på offentlige skyer i flere datasentre. Windows-binærprogrammet til CockroachDB er fortsatt i en beta-fase og anbefales ikke for produksjon, og Apple lager ikke lenger serverhardware.
Cockroach Labs Som du kan se på skjermbildet ovenfor, er det fire alternativer for å installere CockroachDB på en Mac. Jeg valgte Homebrew som sannsynligvis den enkleste av de fire.
Forresten, Cockroach Labs legger ut en advarsel på nettstedet som sier at det å kjøre et statelig program som CockroachDB i Docker er vanskelig, ikke anbefalt for distribusjon av produksjon, og å bruke et orkestreringsverktøy som Kubernetes eller Docker Swarm for å kjøre en klynge i stedet. Jeg vil diskutere alternativene for orkestrering av containere i neste avsnitt.
Installasjon på en Mac er like enkel som bryg installer kakerlakk som vist ovenfor. I mitt tilfelle tok den automatiske oppdateringen av Homebrew mye lenger tid (nok tid til å brygge te) enn den faktiske CockroachDB-installasjonen, som bare tok noen få sekunder.
Når du har installert CockroachDB, er det ganske enkelt å spinne opp en lokal klynge, selv om det er det ekstra trinnet å generere sikkerhetssertifikater med kakerlakkesert kommandoen hvis du vil at klyngen skal være sikker. Når du har en klynge i gang (ved hjelp av kakerlakkstart kommandoen en gang for hver node, med påfølgende noder satt til å bli med i den første nodens klynge), kan du koble til webadministrasjonssiden på hvilken som helst node med en nettleser, og bruke den innebygde kakerlakk kvl klient for å sende SQL-spørsmål til hvilken som helst node. De fleste nettlesere vil klage på nettsteder med CockroachDB-genererte sertifikater, men du bør kunne klikke gjennom den alvorlige advarselen og fortsette til nettstedet.
De anbefalte produksjonsinnstillingene for CockroachDB er forskjellige enn standardinnstillingene som ble konfigurert for utviklings- og testforekomster. Du kan utvikle deg i en klynge med en node hvis du ønsker det. For produksjon bør du ha minst tre noder, kjøre hver node på en egen maskin, VM eller container, og gi hver forekomst ekstra cache og SQL-minne. Standardinnstillingene er 128 MB for cache og SQL-minne; de anbefalte produksjonsinnstillingene er å gi hver 25 prosent RAM:
kakerlakk start - cache = 25% - max-sql-minne = 25%
Jo flere noder du kjører, jo bedre blir elastisiteten. Jo større og raskere nodene er, desto bedre ytelse. Hvis du vil ha noder med ytelse som er omtrent sammenlignbare med Google Cloud Spanner-noder, som leverer 2000 skriv per sekund og 10 000 lesinger per sekund, vil du ha noe som GCEs forekomster n1-highcpu-8, som har åtte CPUer og 8 GB RAM , med lokale SSD-disker (i stedet for spinnende disker).
Jo mer du distribuerer nodene dine til forskjellige datasentre, jo bedre kan du sikre immunitet mot feil på datasenternivå. Det er imidlertid en kostnad: Tidsforsinkelsen mellom datasentre vil ha en direkte innvirkning på databasens ytelse, med klynger på tvers av kontinentene som gjør det merkbart dårligere enn klynger der alle noder er geografisk nær hverandre.
Cockroach Labs leverer detaljerte instruksjoner for distribusjon på AWS, Digital Ocean, GCE og Azure. De anbefalte konfigurasjonene bruker lastbalansere, enten de opprinnelige administrerte lastbalanseringstjenestene eller åpen kildekode-belastningsbalansere, for eksempel HAProxy.
Orkestrering kan senke driftsomkostningene til en CockroachDB-klynge til nesten ingenting. Cockroach Labs dokumenterer hvordan du gjør dette for produksjon med Kubernetes og Docker Swarm. CockroachDB-CloudFormation repository på GitHub viser hvordan du bruker AWS CloudFormation og Kubernetes i en enkelt tilgjengelighetssone for utvikling og test. Å tilpasse dette for produksjon vil innebære endring av CloudFormation-malen for å bruke flere tilgjengelighetssoner.
CockroachDB programmering og testing
CockroachDB støtter PostgreSQL wire-protokollen, slik at du skriver koden din som om du programmerte mot Postgres, eller i det minste en delmengde av Postgres. Denne siden viser de testede driverne for forskjellige programmeringsspråkbindinger, inkludert de mest populære serversidespråk. Denne siden viser eksempler på 10 programmeringsspråk og fem ORM-er. Jeg møtte ingen store overraskelser da jeg leste gjennom koden, selv om jeg fikk øye på noen sannsynlige mindre feil i oppføringene i dokumentasjonen. Du kan også kjøre SQL ved å bruke den interaktive klienten som er innebygd i kakerlakk kjørbar.
Selv om det er en repo dedikert til CockroachDB-lastgeneratorer og en annen for ytelsestester, er det ikke lett å sammenligne CockroachDB-klynger, spesielt hvis du prøver å sammenligne CockroachDB med andre databaser på en meningsfull måte. Et problem er at nettverket blant nodene kan være det hastighetsbegrensende trinnet i CockroachDB-klynger.
Et annet faktum å ta i betraktning er at de fleste konvensjonelle SQL-databaser ikke kjører i SERIALISERbar isolasjonsmodus som standard; i stedet bruker de en mindre streng modus med bedre ytelse. CockroachDB bruker standardiserbar isolasjonsmodus. I tillegg ville det være litt urettferdig å teste CockroachDBs SQL join-ytelse, som fremdeles pågår, med TPC-C-suiten.
Og likevel kan du enkelt se CockroachDBs operasjonelle kraft. For eksempel må mange databaser stoppes og startes på nytt for å skalere dem opp. Å legge til noder under belastning i CockroachDB er en lek, spesielt hvis du bruker et orkestreringsverktøy. For eksempel viser skjermbildet kommandoene for å endre og vise nodene i en Kubernetes-klynge, og skjermbildet nedenfor viser den overvåkede klyngen når nodene blir lagt til. Et lastgenereringsverktøy kjørte kontinuerlig gjennom hele prosessen.
En enda mer imponerende demonstrasjon viser automatisk migrering på tvers av skyer i en CockroachDB-klynge. Det krever virkelig video for å gjøre det rettferdighet; videoen er vert i det koblede blogginnlegget.
CockroachDB SQL
SQL i CockroachDB er mer eller mindre standard, i motsetning til SQL i Cloud Spanner, som bruker ikke-standard syntaks for datamanipulering. CockroachDB SQL mangler likevel mange funksjoner.
For eksempel mangler V1.1 JSON-støtte, som er planlagt for V1.2. Det mangler også XML-parsing, som ikke er på veikartet. Det mangler kaskader på radnivå, planlagt for V1.2, og mangler markører og utløsere, som ikke er på veikartet. Geospatiale indekser er "potensielle" tillegg som kan gjøre det til veikartet i fremtiden.
Spesielt var den første CockroachDB-implementeringen av SQL-sammenføyninger i 2016 bevisst forenklet og viste kvadratisk skalering, noe som gjorde den ubrukelig for spørring av store datasett. Versjonen i V1.0, utført av en co-op student, implementerte hash sammenføyninger, noe som gjør at mange delta operasjoner skaleres lineært; som fikk CockroachDB til nivået med SQLite. En gang i 2018, gitt en nylig finansieringsrunde, burde CockroachDB ha med seg ytelse som skalerer mer som PostgreSQL blir med, samt SQL join behandling fordelt over klyngen.
