Programmering

YugaByte anmeldelse: Cassandra og Redis på planetskala

I løpet av mine tiår som databaseapplikasjonsutvikler, trodde jeg aldri i mine villeste drømmer at jeg noen gang ville ha tilgang til en transaksjonsbasert, distribuert database på planetskala, langt mindre at jeg ville sammenligne mange av dem. Men med Google Cloud Spanner, CockroachDB, Azure Cosmos DB, Neo4j Enterprise og sist YugaByte DB alle tilgjengelige i produksjon, er den engangs pipedrømmen nå ganske ekte.

I store trekk tilbyr Google Cloud Spanner en skalerbar, distribuert, sterkt konsistent SQL-database som en tjeneste som kan håndtere rundt 2000 skriv per sekund og 10 000 lesinger per sekund, per node, med en median latens på omtrent fem millisekunder. For å øke hastigheten på avlesninger som ikke trenger absolutt oppdaterte data, kan du be Spanner om foreldede avlesninger, siden den støtter spørringer om tid. Spanner bruker en Google-dialekt av SQL og kjører bare på Google Cloud Platform.

CockroachDB er en Spanner-lignende, åpen kildekode SQL-database som støtter PostgreSQL wire-protokollen og PostgreSQL SQL-dialekt. CockroachDB er bygget på toppen av RocksDB, en åpen kildekodetransaksjonell og konsistent nøkkelverdilager. I likhet med Spanner støtter den spørringer om tid. CockroachDB kan kjøres på hvilken som helst sky, i Docker-containere med eller uten orkestrering, eller på Linux-servere eller virtuelle maskiner. Bedriftsversjonen av CockroachDB legger til geo-partisjonering, rollebasert tilgangskontroll og støtte.

Azure Cosmos DB er en globalt distribuert, horisontalt partisjonert, multimodell database som en tjeneste. Den tilbyr fire datamodeller (nøkkelverdi, kolonnefamilie, dokument og graf) og fem innstillbare konsistensnivåer (sterk, avgrenset stalhet, økt, konsistent prefiks og eventuell). Den tilbyr fem API-sett: SQL (dialekt), MongoDB-kompatibel, Azure Table-kompatibel, graf (Gremlin) og Apache Cassandra-kompatibel. Den kjører bare på Microsoft Azure-skyen.

Neo4j er en skalerbar og overlevbar grafdatabase som bruker spørringsspråket Cypher. Du kan installere den ikke-klyngede versjonen av åpen kildekode på Windows, MacOS og Linux, i Docker-containere og i virtuelle maskiner. Neo4j Enterprise støtter høy tilgjengelighet og kausale klynger; kausale klynger tillater asynkront oppdaterte klynger av leseeksemplarer, for å tillate høy ytelse for geografisk distribuerte distribusjoner.

Skriv inn Yugabyte DB

YugaByte DB, gjenstand for denne gjennomgangen, er en åpen kildekode, transaksjonshøy ytelsesdatabase for applikasjoner på planetskala som støtter tre API-sett: YCQL, kompatibel med Apache Cassandra Query Language (CQL); YEDIS, kompatibel med Redis; og PostgreSQL (foreløpig ufullstendig og i beta). YugaWare er orkestrasjonslaget for YugaByte DB Enterprise Edition. YugaWare gjør raskt arbeid med å spinne og rive distribuerte klynger på Amazon Web Services, Google Cloud Platform og (på grunn av 4. kvartal 2018) Microsoft Azure. YugaByte DB implementerer multiversion concurrency control (MVCC), men støtter foreløpig ikke spørsmål om tidsreiser.

YugaByte DB er bygget på toppen av en forbedret gaffel i RocksDB nøkkelverdilager. YugaByte DB 1.0 ble sendt i mai 2018.

To av nøkkelteknologiene som brukes til å gjøre distribuerte transaksjonsdatabaser konsistente og raske, er klyngekonsensusalgoritmer og synkronisering av noder. Google Cloud Spanner og Azure Cosmos DB bruker begge Paxos-konsensusalgoritmen foreslått av Leslie Lamport. CockroachDB og YugaByte DB bruker Raft-konsensusalgoritmen foreslått av Diego Ongaro og John Ousterhout.

Google Cloud Spanner bruker Googles proprietære TrueTime API, basert på GPS og atomur. Azure Cosmos DB, CockroachDB og YugaByte DB bruker hybride logiske klokker (HLC) tidsstempler og Network Time Protocol (NTP) kloksynkronisering.

YugaByte designmål

Grunnleggerne av YugaByte — Kannan Muthukkaruppan, Karthik Ranganathan og Mikhail Bautin — var Apache HBase-forpliktelser, tidlige ingeniører på Apache Cassandra, og byggere av Facebooks NoSQL-plattform (drevet av Apache HBase). Målet deres for YugaByte DB var en distribuert databaseserver filosofisk mellom Azure Cosmos DB og Google Cloud Spanner; det vil si at de ønsket å kombinere multimodell- og høyytelsesattributtene til Cosmos DB med ACID-transaksjonene og den globale konsistensen av Spanner. En annen måte å beskrive sitt mål på er at de ønsket at YugaByte DB skulle være transaksjons-, høyytelses- og planetskala, samtidig.

De brøt prosessen i fem trinn, som hver tok omtrent seks måneder å bygge. Det første trinnet var å lage en sterkt konsistent versjon av RocksDB, en høyytelses nøkkelverdilager skrevet i C ++, ved å legge til Raft-konsensusprotokollen, skjæring og belastningsbalansering, og fjerne transaksjonslogging, sikkerhetskopier på tid, og utvinning, som måtte implementeres i et høyere lag.

Det neste trinnet var å bygge en loggstrukturert lagringsmotor for nøkkel til dokument, og legge til ikke-primitive og nestede typer, for eksempel rader, kart, samlinger og JSON. Deretter la de til et pluggbart API-lag, som Azure Cosmos DB, implementering av Cassandra-kompatible og Redis-kompatible APIer, og utsettelse av et PostgreSQL-kompatibelt SQL API til et senere stadium. Så kom utvidede spørrespråk.

YugaByte Cloud Query Language (YCQL) utvider Cassandra API med støtte for distribuerte transaksjoner, sterkt konsistente sekundære indekser og JSON. YugaByte Dictionary Service (YEDIS) er en Redis-kompatibel API med tillegg av innebygd utholdenhet, automatisk skjæring og lineær skalerbarhet. YEDIS tillater valgfritt tidslinjekonsistente, lavforsinkede avlesninger fra nærmeste datasenter, mens sterke skriveoperasjoner opprettholder global konsistens. YEDIS inkluderer også en ny datatype for tidsserier.

Til slutt, med versjon 1.0, legger YugaByte DB Enterprise til et lag for å orkestrere, sikre og overvåke distribusjoner av produksjonsklasse over flere regioner og flere skyer, og lagrer distribuerte sikkerhetskopier til et konfigurerbart sluttpunkt som Amazon S3. PostgreSQL-støtte forblir ufullstendig og på et beta-testnivå.

Distribuerte ACID-transaksjoner

Med fare for fullstendig forenkling av prosessen, la meg prøve å oppsummere måten YugaByte utfører distribuerte ACID-transaksjoner. ACID (som står for atomicitet, konsistens, isolasjon og holdbarhet) ble ansett som en egenskap begrenset til SQL-databaser.

Anta at du sender inn et YCQL-spørsmål som inneholder oppdateringer i en transaksjon, for eksempel en paret debet og kreditt som begge må avbrytes hvis en mislykkes for å opprettholde konsistensen i en finansiell database. YugaByte DB godtar transaksjonen i en statsløs transaksjonsbehandling, hvorav den ene kjører på hver node i klyngen. Transaksjonsansvarlig prøver deretter å planlegge transaksjonen på nettbrettserveren som eier mesteparten av dataene som transaksjonen får tilgang til, for ytelsesformål.

Transaksjonssjefen legger til en transaksjonsoppføring med en unik ID i tabellen for transaksjonsstatus. Så skriver det provisorisk registrerer til alle nettbrettene som er ansvarlige for nøklene transaksjonen prøver å endre. Hvis det er konflikter, rulles en av de motstridende transaksjonene tilbake.

Når alle de foreløpige postene er skrevet vellykket, ber transaksjonsansvarlig transaksjonsstatusbrettet om å erstatte alle foreløpige poster med vanlige poster ved hjelp av tidsstempelet for "transaksjonsforpliktet" -oppføringen i sin Raft-logg. Til slutt sender transaksjonsstatusnettbrettet oppryddingsforespørsler til hver av nettbrettene som deltok i transaksjonen.

For å forbedre ytelsen, lagrer YugaByte aggressivt informasjon for pågående transaksjoner, implementerer finkornede låser og bruker hybride tidslederleier for å forhindre at klienter leser foreldede verdier fra gamle ledere. Enradige ACID-transaksjoner er optimalisert for å ha lave ventetider når det ikke er motstridende handlinger. Distribuerte ACID-transaksjoner bevarer korrektheten på bekostning av høyere ventetid.

YCQL, YEDIS og PostgreSQL

YugaByte inkluderer en nesten fullstendig implementering av CQL, pluss noen utvidelser. En stor forbedring i forhold til Cassandra er at YugaByte er sterkt konsistent, mens Cassandra til slutt er konsistent. De andre forbedringene gjelder distribuerte transaksjoner, sterkt konsistente sekundære indekser og JSON. YugaByte overgår Cassandra for hver operasjon bortsett fra kortdistanseskanninger, i det minste delvis på grunn av dens sterke konsistens, noe som gir mulighet for en enkeltlesing i stedet for det antall lesinger som er nødvendig i Cassandra.

Cassandra støtter fire primitive datatyper som ennå ikke støttes i YugaByte: dato, tid, tuple og varint. YugaByte har også noen begrensninger på uttrykk.

YugaBytes implementering av Redis mangler listedatatypen, men legger til en tidsseriedatatype. Det legger til innebygd utholdenhet, automatisk skjæring og lineær skalerbarhet, samt muligheten til å lese fra nærmeste datasenter for lav ventetid.

YugaBytes PostgreSQL-implementering er ikke veldig langt. Akkurat nå mangler den OPPDATERING og SLETT uttalelser, uttrykk, og SELECT-setningen mangler en sammenføyningsklausul.

YugaByte installasjon og testing

Du kan installere åpen kildekode YugaByte DB fra kildekoden, fra tarballs på MacOS, Centos 7 og Ubuntu 16.04 eller nyere, og fra Docker-bilder på Docker eller Kubernetes. Deretter kan du opprette klynger og teste de tre API-ene for spørring og noen eksempler på arbeidsbelastningsgeneratorer.

Jeg valgte å installere YugaByte DB Enterprise på Google Cloud Platform. Mens det var flere manuelle skritt å ta enn jeg hadde ønsket, var jeg i stand til å gå gjennom installasjonen og testene på en enkelt ettermiddag etter at jeg hadde Enterprise Edition-lisensnøkkelen.

Når YugaWare-forekomsten kjørte på en fire-CPU-forekomst i Google Cloud, konfigurerte jeg Google Cloud Platform som skyleverandør for databaseklyngen min.

Så opprettet jeg en tre-node-klynge av åtte-CPU-forekomster i USA-Øst-regionen.

Jeg kjørte belastningstester med både CQL og Redis APIer.

Jeg var i stand til å spørre både CQL- og Redis-data fra kommandolinjen.

Jeg opprettet også en tre-node-klynge i forskjellige regioner spredt over hele verden (nedenfor). Dette tok lengre tid å opprette (ca. 45 minutter) og hadde mye høyere latens, som forventet. Du kan dessverre ikke komme rundt lysets hastighet.

YugaByte koster

Prisen på en YugaByte DB Enterprise Edition-lisens med tre noder starter på $ 40K per år. I tillegg til det må du ta hensyn til kostnadene for serverne. For en tre-node-klynge på Google Cloud Platform som bruker åtte-CPU VM-forekomster, ligger kostnaden i området $ 800 til $ 900 i måneden pluss nettverkstrafikk, kanskje $ 11K i året.

Mine egne kostnader for en ettermiddag med testing var $ 0,38 for tilfellene og $ 0,01 for utgang mellom sonene. Det var enkelt å slette databaseklynger fra YugaByte DB Enterprise-grensesnittet, og når jeg stoppet VM-forekomsten som kjørte administrasjons- og orkestrasjonsgrensesnittet, påløp det ikke lenger betydelige kostnader.

Raskere, bedre, distribuert

Totalt sett opptrådte YugaByte DB som annonsert. På dette punktet i utviklingen er det nyttig som en raskere, bedre, distribuert Redis og Cassandra. Det burde etter hvert også bli en bedre PostgreSQL, selv om det etter min erfaring tar lang tid (år i stedet for måneder), spesielt når du kommer til poenget med å prøve å stille inn relasjonelle sammenføyninger.

YugaByte DB konkurrerer ennå ikke med Google Cloud Spanner, CockroachDB eller SQL-grensesnittet til Azure Cosmos DB på grunn av manglende SQL-grensesnitt. Den konkurrerer ennå ikke med Neo4j eller grafgrensesnittet til Cosmos DB på grunn av mangel på grafdatabasesupport. Det konkurrerer med Redis, Cassandra og det Cassandra-kompatible grensesnittet til Cosmos DB.

Bør du prøve YugaByte DB selv? Hvis du trenger en distribuert versjon av Redis eller Cassandra, eller du må erstatte MongoDB for et globalt distribuert scenario, så ja. YugaByte DB kan også brukes til å standardisere på en enkelt database for flere formål, for eksempel å kombinere en Cassandra-database med Redis-caching, slik YugaByte-kunden Narvar har gjort. YugaByte DB legger også til høyytelses sekundære indekser og en JSON-type til Cassandra, noe som øker nytten som transaksjonsdatabase.

Om du vil ha åpen kildekode eller enterprise-versjon av YugaByte DB, avhenger av budsjettet ditt. I det store og hele, hvis du er en oppstart, vil du sannsynligvis ha åpen kildekodeversjon. Hvis du er et etablert globalt selskap med mange transaksjonelle databaseapplikasjoner, spesielt hvis du trenger å skalere klynger ofte opp og ned, kan du dra nytte av tilleggsfunksjonene i bedriftsversjonen.

$config[zx-auto] not found$config[zx-overlay] not found