Jeg elsker serverløs teknologi. Jeg leger og laver en masse forskellige serverløse applikationer for at eksperimentere med anden cool teknologi. Inden for den enorme klynge af teknologier, jeg bruger/eksperimenterer med, var PlanetScale databasen, som jeg primært brugte til mine personlige sideprojekter, da der ikke var nogen anden "god" mulighed som Prisma ORM understøttede .
PlanetScale er en MySQL serverløs platform, som simpelthen sælger Vitess, et databaseklyngesystem til horisontal skalering af MySQL. De skrev ikke deres egen database – bidrog muligvis til den, men de skrev den ikke. Fra Vitess dokumentation:
Vitess blev oprettet i 2010 at løse MySQL-skalerbarhedsudfordringerne, som teamet på YouTube stod over for.
I denne artikel vil vi bevæge os i retning af at forstå strukturen af disse ikke-ACID-legacy sharded-databaser, hvorfor de ikke er i stand til at understøtte noget så afgørende som referentiel integritet, og hvorfor vi bør undgå at bruge dem i vores applikationer. Denne artikel handler mere om Vitess teknologi, selvom jeg har inkluderet PlanetScale i titlen, fordi, som jeg nævnte ovenfor, det bare sælger Vitess (med noget værktøj) som en service, og de har vundet indpas i de følgende måneder som værende en "pålidelig" serverløs database.
Baggrund
Mit første spørgsmål var, hvorfor der står, at det er umuligt at skalere en PlanetScale-database med referenceintegritet, da det i deres dokumentation hedder, at:
Vejen FOREIGN KEY begrænsninger er implementeret i MySQL (eller rettere sagt i InnoDB-lagermotoren) forstyrrer online DDL-operationer. Lær mere i dette Vitess blogindlæg.
Begrænset til enkelt MySQL-serveromfang, FOREIGN KEY begrænsninger er umulige at vedligeholde, når først dine data vokser og er delt over flere databaseservere. Dette sker typisk, når du introducerer funktionel partitionering/sharding og/eller horisontal sharding.
Dette fik mig til at tænke:gør FOREIGN KEY begrænsninger påvirker skalerbarheden generelt? og hvis ja, hvordan?
Jeg tror, det er vigtigt at indse, at SQL-tabel-sammenføjninger er ret dyre, men mig bekendt blev det ikke påvirket meget af referentiel integritet? Hvis vi nu laver noget som dataanalyse, har vi naturligvis ikke et behov for referenceintegritet, da vi bare vil dumpe vores data i en enkelt tabel, men PlanetScale og Vitess praler af at blive brugt af store webapplikationer såsom YouTube.
Dette førte mig til at blive forvirret over, hvorfor de ville droppe FOREIGN KEY begrænsning, da databaser såsom CockroachDB og Spanner stadig opretholder referentiel integritet sammen med at de er skalerbare.
Hvad er referentiel integritet, og hvorfor er det vigtigt?
Lad os starte med det grundlæggende, hvis du er ny. Jeg gætter på, at de fleste, der læser dette indlæg, har en god idé om, hvad de taler om, men jeg vil forklare det som en formalitet. Med enkle ord, en FOREIGN KEY constraint er en databasenøgle, som vi kan bruge til at skabe relationer mellem to forskellige tabeller ved at referere til en kolonne eller et sæt kolonner. Referenceintegritet refererer blot til databasens tilstand, hvor alle værdier af alle nøgler er gyldige.
Hvorfor er det vigtigt?
Nu hvor vi har en lille idé om, hvad de er, lad os springe til anden del:hvorfor er de vigtige?
Referenceintegritet er vigtig, da det forhindrer dig i at introducere nye fejl i din database. Det er en funktion, der ofte leveres af relationelle databaser, der forhindrer brugere eller applikationer i at indtaste inkonsistente data i databasen. Dette fører til forbedret datakvalitet, hurtigere udvikling, meget færre fejl og konsistens på tværs af din applikation.
Hvorfor har Vitess det ikke?
Så for at forstå, hvorfor Vitess ikke er i stand til at understøtte referenceintegritet, er vi nødt til at tage et dyk ned i databasens arkitektur. Vitess er en sharded ikke-ACID SQL-database, ikke en ægte distribueret ACID SQL-database.
Nu må du undre dig over, hvad disse udtryk er. Lad mig opdele dem for dig:ACID er et akronym af Atomicity, Consistency, Isolation and Durability.
Her refererer atomicitet til en handling, der enten fuldfører eller fejler helt - ingen delvis fuldførelse af en transaktion. Konsistens refererer til transaktionen, der forlader databasen i en gyldig tilstand. Isolation betyder simpelthen, at to transaktioner udføres uden nogen indblanding med hinanden, og holdbarhed betyder, at ændringerne af transaktionen gemmes.
Et shard er en vandret partition af data i en database, og hvert shard holdes på en separat databaseserverinstans for at sprede belastningen. Så når vi refererer til en database, som er opdelt, taler vi om noget som dette. Som jeg sagde tidligere, er Vitess en shard ikke-ACID SQL-database, hvilket grundlæggende betyder, at den IKKE garanterer ACID-egenskaber for transaktioner.
Hvorfor droppe det?
Nå, problemet starter, når du har en MySQL-database med et veldefineret skema, og din tjeneste bliver populær med problemet med for mange læsninger, der rammer databasen. Det, de fleste gør her, er, at de begynder at cache hyppigt udførte forespørgsler, men læsningerne er ikke længere SYRE.
Sammen med for mange læsninger er det et alvorligt problem, som mange kan stå over for, at have en overskydende mængde skrivninger til din database. Lad os sige, at vi er klar til at sætte ild til vores lommer - vi kan skalere lodret, tilføje mere RAM, en 16-core processor og masser af virkelig hurtige solid-state-drev.
Vi har selvfølgelig stadig problemet med at SQL-tabelsammenføjninger øges i kompleksitet, så du begynder at denormalisere for at undgå joinforbindelser mellem tabeller.
Jeg holdt et foredrag på Prisma Meetup for et stykke tid siden, hvor jeg forklarede det grundlæggende i at designe en relationsdatabase. Et emne, jeg dækkede her, var denormalisering, hvis du er interesseret, så sørg for at tjekke dette ud.
Men denormalisering er dybest set den proces, hvor du tilføjer redundante data til tabeller i din database, hvilket forbedrer ydeevnen på omkostningerne til diskplads, da du ikke længere bruger CPU-kraft til joins. Mens denormalisering forbedrer læsehastigheden, er det vigtigt at indse, at det gør skrivningen langsommere.
Ikke desto mindre, på trods af alt dette, er vores database stadig langsom, så vi flytter databaseberegninger til klienten, for eksempel ved at generere et UUID eller tildele en dato.
Selv efter alt dette vil forespørgsler stadig være langsomme - så vi holder resultatet af de mest forespurgte data klar i en proces kendt som databasematerialisering. Nu kan læsninger være hurtigere, men skrivninger bliver langsommere dag for dag. Den eneste logiske situation nu er at droppe sekundære indekser.
Så på dette tidspunkt har vores database
- Ingen ACID-egenskaber på grund af caching
- Intet normaliseret skema
- Ingen udløsere
- Ingen databaseberegninger
- Ingen sekundære indekser
Dette banede vejen for Vitess- og NoSQL-databaser, da virksomheder havde problemer med at skalere deres database. Som det var designet, var de ikke i stand til at opretholde datakonsistens, en ACID-egenskab, når transaktioner strakte sig over flere forskellige shards. Referenceintegritet handler om konsistens, når data spænder over flere shards, derfor giver det mening, at de ikke er i stand til at understøtte det godt.
Vi kan gå dybt ind i strukturen af NoSQL-databaser uden FOREIGN KEY begrænsninger og problemer, som vi står over for ved at adoptere den model, men det er emnet for et andet indlæg.
Det er ikke kun Vitess, det har været en standardpraksis for opdelte databaser for at undgå referentiel integritet, da der simpelthen ikke er noget andet valg. Med hensyn til ACID-modellen angiver deres dokumentation, at de garanterer atomicitet, men ikke isolation, og går endda så langt som til at sige:
At garantere SYRE-isolering er meget omstridt og har høje omkostninger. At give det som standard ville have gjort Vitess upraktisk til de mest almindelige brugssager.
Lad os kort tale om, hvad ACID Isolering er. Der er fire niveauer til det (i henhold til SQL-92-standarderne), herunder serialiserbarhed, læst committed, read uncommitted og repeterbare læsninger. Når det er sagt, er der flere niveauer af isolation, såsom Snapshot-isolering, som ikke er en SQL-standard, selvom den bruges af flere databaser såsom Firebase eller MongoDB. Hvis du er mere interesseret i dette, anbefaler jeg at læse dette indlæg. For at holde det kort vil jeg ikke gennemgå, hvad hvert niveau af isolation betyder/betyder, men hvis du gerne vil læse mere om det, så tjek denne side fra MySQL-dokumentationen.
ACID-isolering refererer til, at databasetransaktionerne er ACIDiske, hvilket er vigtigt, da de garanterer, at operationer opfører sig, som udviklere forventer, at de skal. Jeg er usikker på, hvad de mener, når de siger "at garantere syreisolering er meget omstridt og har høje omkostninger", men hvis de betyder, at sikring af syreisolering har høje omkostninger for ethvert produkt , de tager fejl. Adskillige distribuerede ACID-kompatible databaser har det højeste niveau af isolation (serialiserbare transaktioner), mens de stadig fungerer med høje læse-/skrivehastigheder. I forbindelse med Vitess tager de dog ikke fejl, da transaktioner på tværs af flere shards ikke kan opfylde nogen grad af isolation.
Konklusion
Med alt dette må du undre dig:hvorfor skulle nogen ønske at bruge PlanetScale eller Vitess? Nå, jeg undrer mig over det samme. Med mange virksomheder og websteder var årsagen, at de valgte Vitess tilbage, da der ikke var nogen bedre muligheder. Hvis du går til begyndelsen af artiklen, så læg mærke til, hvordan den blev oprettet tilbage i 2010. Nu hvor vi kan nyde en ACID-kompatibel skalerbar database med referenceintegritet, ville det være i vores bedste interesse at skifte til disse nye databaser, og jeg er allerede begyndt at gøre det! Teknologien ændrer sig hurtigt, og at holde din database opdateret er en afgørende komponent i enhver applikation.