I løbet af mine årtier som databaseapplikationsudvikler havde jeg aldrig forestillet mig i mine vildeste drømme, at jeg nogensinde ville have adgang til en transaktionsbaseret, distribueret database på planetskala, meget mindre at jeg ville sammenligne mange af dem. Men med Google Cloud Spanner, CockroachDB, Azure Cosmos DB, Neo4j Enterprise og senest YugaByte DB, der alle er tilgængelige i produktion, er den engangs rørdrøm nu ret ægte.
Generelt tilbyder Google Cloud Spanner en skalerbar, distribueret, stærkt konsistent SQL-database som en tjeneste, der kan håndtere omkring 2.000 skrivninger pr. Sekund og 10.000 læsninger pr. Sekund pr. Knude med en median latenstid på cirka fem millisekunder. For at fremskynde læsninger, der ikke har brug for absolut opdaterede data, kan du bede Spanner om forældede læsninger, da den understøtter tidsrejser. Spanner bruger en Google-dialekt af SQL og kører kun på Google Cloud Platform.
CockroachDB er en Spanner-lignende, open source SQL-database, der understøtter PostgreSQL wire-protokollen og PostgreSQL SQL-dialekt. CockroachDB er bygget oven på RocksDB, en open source transaktionel og konsekvent nøgleværdilager. Ligesom Spanner understøtter den tidsrejser-forespørgsler. CockroachDB kan køre på enhver sky, i Docker-containere med eller uden orkestrering eller på Linux-servere eller VM'er. Virksomhedsversionen af CockroachDB tilføjer geo-partitionering, rollebaseret adgangskontrol og support.
Azure Cosmos DB er en globalt distribueret, vandret partitioneret, multimodel database som en tjeneste. Det tilbyder fire datamodeller (nøgleværdi, kolonnefamilie, dokument og graf) og fem indstillelige konsistensniveauer (stærk, afgrænset stalhed, session, ensartet præfiks og eventuel). Det tilbyder fem API-sæt: SQL (dialekt), MongoDB-kompatibel, Azure Table-kompatibel, graf (Gremlin) og Apache Cassandra-kompatibel. Det kører kun på Microsoft Azure-skyen.
Neo4j er en skalerbar og overlevelig grafdatabase, der bruger Cypher-forespørgselssproget. Du kan installere dens open source, ikke-klyngede version på Windows, MacOS og Linux, i Docker-containere og i VM'er. Neo4j Enterprise understøtter høj tilgængelighed og kausale klynger; kausale klynger tillader asynkront opdaterede klynger af læse replikaer for at tillade høj ydeevne for geografisk distribuerede implementeringer.
Indtast Yugabyte DB
YugaByte DB, genstand for denne gennemgang, er en open source, transaktionshøjtydende database til applikationer på planetskala, der understøtter tre API-sæt: YCQL, kompatibel med Apache Cassandra Query Language (CQL); YEDIS, kompatibel med Redis; og PostgreSQL (i øjeblikket ufuldstændig og i beta). YugaWare er orkestrationslaget for YugaByte DB Enterprise Edition. YugaWare gør hurtigt arbejde med at spinde og nedbryde distribuerede klynger på Amazon Web Services, Google Cloud Platform og (på grund af 4. kvartal 2018) Microsoft Azure. YugaByte DB implementerer multiversion concurrency control (MVCC), men understøtter endnu ikke tidsrejser.
YugaByte DB er bygget oven på en forbedret gaffel i RocksDB-nøgleværdibutikken. YugaByte DB 1.0 blev sendt i maj 2018.
To af de nøgleteknologier, der bruges til at gøre distribuerede transaktionsdatabaser konsistente og hurtige, er klyngekonsensusalgoritmer og synkronisering af node-ur. Google Cloud Spanner og Azure Cosmos DB bruger begge Paxos-konsensusalgoritmen foreslået af Leslie Lamport. CockroachDB og YugaByte DB bruger Raft-konsensusalgoritmen foreslået af Diego Ongaro og John Ousterhout.
Google Cloud Spanner bruger Googles proprietære TrueTime API baseret på GPS og atomure. Azure Cosmos DB, CockroachDB og YugaByte DB bruger hybride logiske ur (HLC) tidsstempler og Network Time Protocol (NTP) ursynkronisering.
YugaByte design mål
Grundlæggerne af YugaByte - Kannan Muthukkaruppan, Karthik Ranganathan og Mikhail Bautin - var Apache HBase-forpligtelser, tidlige ingeniører på Apache Cassandra og opbyggerne af Facebooks NoSQL-platform (drevet af Apache HBase). Deres mål for YugaByte DB var en distribueret databaseserver filosofisk imellem Azure Cosmos DB og Google Cloud Spanner; det vil sige, at de ønskede at kombinere Cosmos DB's multimodel- og højtydende attributter med ACID-transaktionerne og den globale konsistens af Spanner. En anden måde at beskrive deres mål på er, at de ønskede, at YugaByte DB skulle være transaktionel, højtydende og planetskala, på én gang.
De brød processen op i fem trin, der hver tog ca. seks måneder at bygge. Det første skridt var at oprette en stærkt konsistent version af RocksDB, en højtydende nøgleværdilager skrevet i C ++ ved at tilføje Raft-konsensusprotokollen, sharding og belastningsafbalancering og fjerne transaktionslogning, point-in-time backup og opsving, som skulle implementeres i et højere lag.
Det næste trin var at opbygge en log-struktureret nøgle-til-dokument-lagringsmotor, der tilføjede ikke-primitive og indlejrede typer, såsom rækker, kort, samlinger og JSON. Derefter tilføjede de et tilslutbart API-lag som Azure Cosmos DB, implementering af Cassandra-kompatible og Redis-kompatible API'er og udsættelse af en PostgreSQL-kompatibel SQL API til et senere tidspunkt. Så kom udvidede forespørgselssprog.
YugaByte Cloud Query Language (YCQL) udvider Cassandra API med understøttelse af distribuerede transaktioner, stærkt konsistente sekundære indekser og JSON. YugaByte Dictionary Service (YEDIS) er en Redis-kompatibel API med tilføjelser af indbygget persistens, automatisk sharding og lineær skalerbarhed. YEDIS muliggør valgfrit tidslinjekonsistente læser med lav latens fra det nærmeste datacenter, mens stærke skriveoperationer opretholder global konsistens. YEDIS inkluderer også en ny dataserie for tidsserier.
Endelig tilføjer YugaByte DB Enterprise med version 1.0 et lag til orkestrering, sikker og overvågning af produktionsklasse-implementeringer på tværs af flere regioner og flere skyer og lagrer distribuerede sikkerhedskopier til et konfigurerbart slutpunkt såsom Amazon S3. PostgreSQL-support forbliver ufuldstændig og på et beta-testniveau.
Distribuerede ACID-transaktioner
Med risiko for fuldstændig overforenkling af processen, lad mig prøve at opsummere den måde, YugaByte udfører distribuerede ACID-transaktioner på. ACID (som står for atomicitet, konsistens, isolering og holdbarhed) blev tidligere betragtet som en egenskab begrænset til SQL-databaser.
Antag at du indsender en YCQL-forespørgsel, der indeholder opdateringer inde i en transaktion, for eksempel en parret debitering og kredit, som begge skal afbrydes, hvis en mislykkes for at opretholde konsistensen af en finansiel database. YugaByte DB accepterer transaktionen i en statsløs transaktionshåndtering, hvoraf den ene kører på hver node i klyngen. Transaktionsadministratoren forsøger derefter at planlægge transaktionen på den tabletserver, der ejer de fleste af de data, der er adgang til ved transaktionen, med henblik på ydeevne.
Transaktionsadministratoren tilføjer en transaktionspost med et unikt id i transaktionens statustabel. Så skriver det midlertidig registrerer alle tabletter, der er ansvarlige for de nøgler, som transaktionen prøver at ændre. Hvis der er konflikter, rulles en af de modstridende transaktioner tilbage.
Når alle de foreløbige poster er skrevet med succes, beder transaktionsadministratoren transaktionens statustablet om at erstatte alle midlertidige poster med regelmæssige poster ved hjælp af tidsstemplet for "transaktionsforpligtet" -post i sin Raft-log. Endelig sender transaktionsstatustabellen oprydningsanmodninger til hver af de tablets, der deltog i transaktionen.
For at forbedre ydeevnen cacher YugaByte aggressivt oplysninger for igangværende transaktioner, implementerer finkornede låse og bruger hybride tidsledere for at forhindre klienter i at læse uaktuelle værdier fra gamle ledere. ACID-transaktioner med en række er optimeret til at have lave latenstider, når der ikke er nogen modstridende handling. Distribuerede ACID-transaktioner bevarer korrekthed på bekostning af højere ventetid.
YCQL, YEDIS og PostgreSQL
YugaByte inkluderer en næsten komplet implementering af CQL plus nogle udvidelser. En enorm forbedring i forhold til Cassandra er, at YugaByte er stærkt konsistent, mens Cassandra i sidste ende er konsistent. De andre forbedringer er til distribuerede transaktioner, stærkt konsistente sekundære indekser og JSON. YugaByte overgår Cassandra for hver operation undtagen kort rækkevidde scanninger, i det mindste delvist på grund af dens stærke konsistens, hvilket giver mulighed for en enkelt læsning i stedet for den nødvendige kvorumlæsning i Cassandra.
Cassandra understøtter fire primitive datatyper, der endnu ikke understøttes i YugaByte: dato, tid, tuple og varint. YugaByte har også nogle begrænsninger for udtryk.
YugaByte's implementering af Redis mangler listen datatype, men tilføjer en tidsseriedatatype. Det tilføjer indbygget vedholdenhed, automatisk sharding og lineær skalerbarhed samt evnen til at læse fra det nærmeste datacenter for lav latenstid.
YugaByte's PostgreSQL-implementering er ikke langt væk. Lige nu mangler det UPDATE og SLET udsagn, udtryk, og SELECT-sætningen mangler en sammenføjningsklausul.
YugaByte installation og test
Du kan installere open source YugaByte DB fra kildekoden, fra tarballs på MacOS, Centos 7 og Ubuntu 16.04 eller nyere og fra Docker-billeder på Docker eller Kubernetes. Du kan derefter oprette klynger og teste de tre API-forespørgsler og nogle eksempler på arbejdsbelastningsgeneratorer.
Jeg valgte at installere YugaByte DB Enterprise på Google Cloud Platform. Mens der var flere manuelle trin at tage, end jeg ville have ønsket, var jeg i stand til at gennemgå min installation og test på en enkelt eftermiddag, efter at jeg havde min Enterprise Edition licensnøgle.
Når YugaWare-forekomsten kørte på en fire-CPU-forekomst i Google Cloud, konfigurerede jeg Google Cloud Platform som skyudbyder til min databaseklynge.
Derefter oprettede jeg en tre-node-klynge af otte-CPU-forekomster i regionen USA-øst.
Jeg kørte belastningstest ved hjælp af både CQL og Redis API'er.
Jeg var i stand til at forespørge både CQL- og Redis-data fra kommandolinjen.
Jeg oprettede også en tre-node-klynge i forskellige regioner spredt over hele verden (nedenfor). Dette tog længere tid at oprette (ca. 45 minutter) og havde meget højere skrivelatens, som forventet. Du kan desværre ikke komme rundt om lysets hastighed.
YugaByte omkostninger
Prisen på en YugaByte DB Enterprise Edition-licens med tre knudepunkter starter ved $ 40K om året. Derudover skal du medregne omkostningerne ved serverne. For en tre-node-klynge på Google Cloud Platform, der bruger otte-CPU VM-forekomster, ligger omkostningerne i området $ 800 til $ 900 om måneden plus netværkstrafik, måske $ 11K om året.
Mine egne omkostninger for en eftermiddag med test var $ 0,38 for instanserne og $ 0,01 for udgang mellem zoner. Det var nemt at slette databaseklynger fra YugaByte DB Enterprise-grænsefladen, og når jeg stoppede VM-forekomsten, der kørte grænsefladen til administration og orkestrering, påløb det ikke længere betydelige gebyrer.
Hurtigere, bedre, distribueret
Alt i alt optrådte YugaByte DB som annonceret. På dette tidspunkt i dens udvikling er det nyttigt som en hurtigere, bedre, distribueret Redis og Cassandra. Det skulle i sidste ende også være en bedre PostgreSQL, selvom det efter min erfaring tager lang tid (år snarere end måneder), især når du kommer til det punkt at forsøge at indstille relationelle sammenføjninger.
YugaByte DB konkurrerer endnu ikke med Google Cloud Spanner, CockroachDB eller SQL-grænsefladen til Azure Cosmos DB på grund af manglende SQL-grænseflade. Det konkurrerer endnu ikke med Neo4j eller grafgrænsefladen til Cosmos DB på grund af manglende grafdatabasesupport. Det konkurrerer med Redis, Cassandra og den Cassandra-kompatible grænseflade til Cosmos DB.
Skal du selv prøve YugaByte DB? Hvis du har brug for en distribueret version af Redis eller Cassandra, eller hvis du skal udskifte MongoDB for et globalt distribueret scenario, så ja. YugaByte DB kan også bruges til at standardisere på en enkelt database til flere formål, såsom at kombinere en Cassandra-database med Redis-caching, som YugaByte-kunde Narvar har gjort. YugaByte DB tilføjer også højtydende sekundære indekser og en JSON-type til Cassandra, hvilket øger dets anvendelighed som en transaktionsdatabase.
Uanset om du vil have open source- eller enterprise-versionen af YugaByte DB, afhænger af dit budget. I det store og hele, hvis du er en opstart, vil du sandsynligvis have open source-versionen. Hvis du er et etableret globalt firma med mange transaktionsbaserede databaseapplikationer, især hvis du ofte skal skalere klynger op og ned, kan du muligvis drage fordel af de ekstra funktioner i virksomhedsversionen.
