Programmering

CockroachDB gennemgang: En skalerbar SQL-database bygget til overlevelse

Indtil for nylig, da du handlede efter en database, måtte du vælge: Skalerbarhed eller konsistens? SQL-databaser som MySQL garanterer stærk konsistens, men skaleres ikke godt vandret. (Manuel afskærmning for skalerbarhed er ingen idé om sjov.) NoSQL-databaser som MongoDB skalerer smukt, men tilbyder kun en eventuel konsistens. ("Vent længe nok, og du kan læse det rigtige svar" - hvilket ikke er nogen måde at foretage finansielle transaktioner på.)

Google Cloud Spanner, en fuldt administreret relationsdatabasetjeneste, der kører på Google Compute Engine (GCE) udgivet i februar 2017, har skalerbarheden af ​​NoSQL-databaser, mens den bevarer SQL-kompatibilitet, relationelle skemaer, ACID-transaktioner og stærk ekstern konsistens. Spanner er en splittet, globalt distribueret og replikeret relationsdatabase, der bruger en Paxos-algoritme til at nå til enighed blandt sine noder.

Et alternativ til Spanner, og emnet for denne gennemgang, er CockroachDB, en open source, vandret skalerbar distribueret SQL-database udviklet af ex-Googlers, der var fortrolige med Spanner. CockroachDB låner fra Googles Spanner til designet af dets datalagringssystem, og det bruger en Raft-algoritme til at nå til enighed blandt sine noder.

Ligesom Cloud Spanner er CockroachDB en distribueret SQL-database, der er bygget oven på en transaktionel og konsistent nøgleværdilager, i CockroachDB's tilfælde på RocksDB. CockroachDBs primære designmål er support til ACID-transaktioner, vandret skalerbarhed og (mest af alt) overlevelsesevne, deraf navnet.

CockroachDB er designet til at overleve disk-, maskine-, rack- og endda datacenterfejl med minimal latensforstyrrelse og uden manuel indgriben. Selvfølgelig skal du køre en for at opnå det klynge af mange forekomster af CockroachDBs symmetriske knudepunkter ved hjælp af flere diske, maskiner, stativer og datacentre.

I modsætning til Cloud Spanner, der bruger TrueTime API, der er tilgængelig til tidssynkronisering i Google datacentre, kan CockroachDB ikke stole på tilstedeværelsen af ​​atomure og GPS-satelliture til at synkronisere tiden nøjagtigt på tværs af noder og datacentre. Det har en række konsekvenser. Til at begynde med giver Google TrueTime en øvre grænse for urforskydninger mellem noder i en klynge på syv millisekunder. Det er lille nok til, at en Spanner-knude bare venter syv millisekunder efter en skrivning, før han rapporterer, at en transaktion er begået, for at garantere ekstern konsistens.

Uden TrueTime eller en lignende facilitet skal CockroachDB falde tilbage til NTP, hvilket giver øvre grænser for ursynkronisering mellem 100 millisekunder og 250 millisekunder. I betragtning af det større tidsvindue venter CockroachDB ikke efter skrivning. I stedet for det Sommetider venter før læsning, grundlæggende genstart af en transaktion, hvis den læser en værdi med et tidsstempel større end begyndelsen af ​​transaktionen, igen for at garantere konsistens.

Når alle knudepunkterne i en CockroachDB-klynge har de små øvre grænser for urforskydninger, som du kan få fra GPS eller atomure, hvilket er noget, der bare bliver tilgængeligt i større offentlige skyer, kan det give mening at køre dem med --linjerbar flag. Det får dem til at vente på den maksimale urforskydning, inden de returnerer en vellykket forpligtelse, ligesom Spanner.

Sådan fungerer CockroachDB

Hver CockroachDB-node består af fem lag:

  • SQL, som oversætter klient-SQL-forespørgsler til nøgleværdifunktioner
  • Transaktion, som tillader atomændringer i flere nøgleværdiposter
  • Distribution, som præsenterer replikerede nøgleværdiområder som en enkelt enhed
  • Replikering, som konsekvent og synkront replikerer nøgleværdiområder på tværs af mange noder og muliggør ensartet læsning via leasingaftaler
  • Storage, som skriver og læser nøgleværdidata på disken

SQL-laget analyserer forespørgsler mod en Yacc-fil og gør dem til et abstrakt syntaks-træ. Fra det abstrakte syntaks-træ genererer CockroachDB et træ med plannoder, der indeholder nøgleværdikode. Planknudepunkterne udføres derefter og kommunikerer med transaktionslaget.

Transaktionslaget implementerer ACID-transaktionssemantik med tofaseforpligtelser på tværs af hele klyngen inklusive transaktioner på tværs af områder og krydstabeller og behandler enkeltopgørelser som transaktioner (også kaldet auto-commit-tilstand). Den tofasede forpligtelse opnås ved at bogføre transaktionsregistreringer og skrivehensigter, udføre læseoperationer og behandle eventuelle skrivehensigter, der opstår som transaktionskonflikter.

Distributionslaget modtager anmodninger fra transaktionslaget på den samme node. Derefter identificeres, hvilke noder der skal modtage anmodningen, og sender anmodningen til det korrekte nodes replikeringslag.

Replikationslaget kopierer data mellem noder og sikrer sammenhæng mellem disse kopier ved at implementere en Raft-konsensusalgoritme. Du kan styre replikationsfaktoren på klyngen, databasen og tabelleniveau ved hjælp af replikationszoner. Konsensusalgoritmen bruges kun til skrivning og kræver, at et kvorum af replikaer er enige om ændringer i et interval, før disse ændringer begås.

Lagringslaget gemmer data som nøgleværdipar på disken ved hjælp af RocksDB. CockroachDB er stærkt afhængig af multi-version concurrency control (MVCC) til at behandle samtidige anmodninger og garantere konsistens. Meget af dette arbejde udføres ved hjælp af hybride logiske ur (HLC) tidsstempler.

Ligesom Spanner understøtter CockroachDB tidsforespørgsler (aktiveret af MVCC). Disse kan gå så langt tilbage som din seneste databaseaffaldsindsamling, udført som standard dagligt.

CockroachDB installation og brug

CockroachDB kører på Mac-, Linux- og Windows-operativsystemer, i det mindste til udvikling og test. Produktion af kakerlak-databaser kører normalt på Linux-VM'er eller orkestrerede containere, ofte hostet i offentlige skyer i flere datacentre. Windows-binær fra CockroachDB er stadig i en beta-fase og anbefales ikke til produktion, og Apple fremstiller ikke længere serverhardware.

Kakerlak Labs

Som du kan se i skærmbilledet ovenfor, er der fire muligheder for at installere CockroachDB på en Mac. Jeg valgte Homebrew som sandsynligvis den nemmeste af de fire.

Forresten sender Cockroach Labs en advarsel på webstedet, der siger, at kørsel af en stateful applikation som CockroachDB i Docker er vanskelig, anbefales ikke til produktionsinstallationer, og at bruge et orkestreringsværktøj som Kubernetes eller Docker Swarm til at køre en klynge i stedet. Jeg diskuterer muligheder for containerorkestrering i det næste afsnit.

Installation på en Mac er lige så let som bryg installer kakerlak som vist ovenfor. I mit tilfælde tog den automatiske opdatering af Homebrew meget længere tid (nok tid til at brygge te) end den faktiske CockroachDB installation, som kun tog et par sekunder.

Når du har installeret CockroachDB, er det ret nemt at skrue op for en lokal klynge, selvom der er det ekstra trin at generere sikkerhedscertifikater med kakerlak cert kommando, hvis du ønsker, at klyngen skal være sikker. Når du har en klynge kørende (ved hjælp af kakerlak start kommando en gang for hver node, med efterfølgende noder indstillet til at slutte sig til den første nodes klynge), kan du oprette forbindelse til webadministrationssiden på enhver node med en browser og bruge den integrerede kakerlak sql klient til at sende SQL-forespørgsler til en hvilken som helst node. De fleste browsere klager over websteder med CockroachDB-genererede certifikater, men du skal være i stand til at klikke igennem den dystre advarsel og fortsætte til webstedet.

De anbefalede produktionsindstillinger for CockroachDB er forskellige fra standardindstillingerne, som blev konfigureret til udviklings- og testforekomster. Du kan udvikle dig i en klynge med en node, hvis du ønsker det. Til produktion skal du have mindst tre noder, køre hver node på en separat maskine, VM eller container og give hver forekomst ekstra cache og SQL-hukommelse. Standardindstillingerne er 128 MB hver for cache og SQL-hukommelse; de anbefalede produktionsindstillinger er at give hver 25 procent RAM:

start på kakerlak - cache = 25% --max-sql-hukommelse = 25%

Jo flere knudepunkter du kører, desto bedre er fleksibiliteten. Jo større og hurtigere noderne er, jo bedre er ydelsen. Hvis du vil have noder med ydeevne, der stort set kan sammenlignes med Google Cloud Spanner-noder, der leverer 2.000 skrivninger pr. Sekund og 10.000 læsninger pr. Sekund, vil du gerne have noget som GCE's n1-highcpu-8-forekomster, som har otte CPU'er og 8 GB RAM , med lokale SSD-diske (snarere end roterende diske).

Jo mere du distribuerer dine noder til forskellige datacentre, desto bedre kan du sikre immunitet mod fejl på datacenterniveau. Der er dog en pris: Retur latenstid mellem datacentre vil have en direkte indvirkning på din databases ydeevne, hvor klynger på tværs af kontinent klarer sig markant dårligere end klynger, hvor alle noder er geografisk tæt sammen.

Cockroach Labs leverer detaljerede instruktioner til implementering på AWS, Digital Ocean, GCE og Azure. De anbefalede konfigurationer bruger load balancers, enten de indfødte administrerede load balancing-tjenester eller open source load balancers såsom HAProxy.

Orkestrering kan sænke driftsomkostningerne for en CockroachDB-klynge til næsten ingenting. Cockroach Labs dokumenterer, hvordan man gør dette til produktion med Kubernetes og Docker Swarm. CockroachDB-CloudFormation-arkivet på GitHub viser, hvordan man bruger AWS CloudFormation og Kubernetes i en enkelt tilgængelighedszone til udvikling og test. At tilpasse dette til produktion vil indebære ændring af CloudFormation-skabelonen for at bruge flere tilgængelighedszoner.

CockroachDB programmering og test

CockroachDB understøtter PostgreSQL wire-protokollen, så du skriver din kode, som om du programmerede mod Postgres eller i det mindste en delmængde af Postgres. Denne side viser de testede drivere til forskellige programmeringssprogbindinger, inklusive de mest populære sprog på serversiden. Denne side viser eksempler på 10 programmeringssprog og fem ORM'er. Jeg stødte ikke på store overraskelser, da jeg læste koden igennem, selvom jeg så et par sandsynlige mindre bugs i listerne i dokumentationen. Du kan også køre din SQL ved hjælp af den interaktive klient, der er indbygget i kakerlak eksekverbar.

Mens der er en repo dedikeret til CockroachDB-belastningsgeneratorer og en anden til præstationstest, er benchmarking af CockroachDB-klynger ikke let, især hvis du prøver at sammenligne CockroachDB med andre databaser på en meningsfuld måde. Et problem er, at netværket blandt noderne kan være det hastighedsbegrænsende trin i CockroachDB-klynger.

En anden kendsgerning at tage i betragtning er, at de fleste konventionelle SQL-databaser ikke kører i SERIALISERbar isolationstilstand som standard; i stedet bruger de en mindre streng tilstand med bedre ydeevne. CockroachDB bruger standardiserbar isolationstilstand. Derudover ville det være lidt uretfærdigt at teste CockroachDB's SQL join-ydeevne, som stadig er i gang med TPC-C-pakken.

Og alligevel kan du let se CockroachDB's operationelle kraft. For eksempel skal mange databaser stoppes og genstartes for at skalere dem op. Tilføjelse af noder under belastning i CockroachDB er en leg, især hvis du bruger et orkestreringsværktøj. For eksempel viser skærmbilledet ovenfor kommandoerne til at ændre og vise noderne i en Kubernetes-klynge, og skærmbilledet nedenfor viser den overvågede klynge, når noderne tilføjes. Et værktøj til belastningsgenerering kørte kontinuerligt gennem hele processen.

En endnu mere imponerende demonstration viser automatisk migrering på tværs af skyer inden for en CockroachDB-klynge. Det kræver virkelig video for at gøre det retfærdigt; videoen hostes i det linkede blogindlæg.

Kakerlak DB SQL

SQL i CockroachDB er mere eller mindre standard i modsætning til SQL i Cloud Spanner, der bruger ikke-standard syntaks til databehandling. CockroachDB SQL mangler dog stadig mange funktioner.

For eksempel mangler V1.1 JSON-support, som er planlagt til V1.2. Det mangler også XML-parsing, som ikke findes på køreplanen. Det mangler kaskader på række, planlagt til V1.2, og mangler markører og udløsere, som ikke er på køreplanen. Geospatiale indekser er "potentielle" tilføjelser, der kan gøre det til køreplanen i fremtiden.

Mest bemærkelsesværdigt var den indledende CockroachDB-implementering af SQL-tilslutninger i 2016 bevidst forenklet og udstillede kvadratisk skalering, hvilket gjorde den ubrugelig til forespørgsel om store datasæt. Versionen i V1.0, udført af en co-op-studerende, implementerede hash-sammenføjninger, hvilket gør, at mange deltagelsesoperationer skaleres lineært; der fik CockroachDB til niveauet SQLite. Engang i 2018, givet en nylig finansieringsrunde, skulle CockroachDB have deltaget i ydeevne, der skalerer mere som PostgreSQL-sammenføjninger, samt SQL-joinforarbejdning fordelt over klyngen.