Miluji technologii bez serveru. Hraju si a vytvářím spoustu různých aplikací bez serveru, abych mohl experimentovat s dalšími skvělými technologiemi. PlanetScale byl v obrovském shluku technologií, které používám/experimentuji s nimi databázi, kterou jsem primárně používal pro své osobní vedlejší projekty, protože neexistovala žádná jiná „dobrá“ možnost, kterou Prisma ORM podporoval .

PlanetScale je platforma MySQL bez serveru, která jednoduše prodává Vites, databázový clusteringový systém pro horizontální škálování MySQL. Nenapsali vlastní databázi – možná do ní přispěli, ale nenapsali ji. Z dokumentace Vites:

Vites byl vytvořen v 2010 k vyřešení problémů se škálovatelností MySQL, kterým tým na YouTube čelil.

V tomto článku se budeme pohybovat směrem k pochopení struktury těchto starších databází bez ACID, proč nejsou schopny podporovat něco tak zásadního, jako je referenční integrita, a proč bychom se měli vyhnout jejich použití v našich aplikacích. Tento článek je více o technologii Vites, i když jsem do názvu zahrnul PlanetScale, protože, jak jsem zmínil výše, pouze prodává Vitess (s určitými nástroji) jako službu a v následujících měsících získaly popularitu jako "spolehlivá" databáze bez serveru.

Pozadí

Moje počáteční otázka byla, proč se říká, že je nemožné škálovat databázi PlanetScale s referenční integritou, protože v jejich dokumentaci je uvedeno, že:

Způsob FOREIGN KEY omezení jsou implementována v MySQL (nebo spíše v úložišti InnoDB) narušuje online operace DDL. Více se dozvíte v tomto příspěvku na blogu Vites.

Omezeno na jeden rozsah serveru MySQL, FOREIGN KEY Jakmile vaše data narostou a budou rozdělena na více databázových serverů, nelze omezení udržet. K tomu obvykle dochází, když zavedete funkční dělení/sharding a/nebo horizontální dělení.

To mě přivedlo k myšlence:udělejte FOREIGN KEY omezení ovlivňují škálovatelnost obecně? a pokud ano, jak?

Myslím, že je důležité si uvědomit, že spojení tabulek SQL jsou poměrně nákladné, ale pokud vím, nebylo to příliš ovlivněno referenční integritou? Nyní, když děláme něco jako analýzu dat, očividně nepotřebujeme referenční integritu, protože bychom chtěli naše data uložit do jediné tabulky, ale PlanetScale a Vites se chlubí tím, že je používají velké webové aplikace. jako je YouTube.

To mě vedlo ke zmatení, proč vyřadili FOREIGN KEY omezení, protože databáze jako CockroachDB a Spanner si stále zachovávají referenční integritu a zároveň jsou škálovatelné.

Co je referenční integrita a proč je důležitá?

Začněme základy, pro případ, že jste noví. Hádám, že většina lidí, kteří čtou tento příspěvek, má dobrou představu o tom, o čem mluví, ale vysvětlím to jako formalitu. Jednoduše řečeno, FOREIGN KEY constraint je databázový klíč, který můžeme použít k vytvoření vztahů mezi dvěma různými tabulkami odkazem na sloupec nebo sadu sloupců. Referenční integrita jednoduše odkazuje na stav databáze, ve kterém jsou platné všechny hodnoty všech klíčů.

Proč je to důležité?

Nyní, když máme trochu představu o tom, co to je, přeskočme k druhé části:proč jsou důležité?

Referenční integrita je důležitá, protože vám brání v zavádění nových chyb do databáze. Je to funkce, kterou často poskytují relační databáze, která brání uživatelům nebo aplikacím zadávat do databáze nekonzistentní data. To vede ke zlepšení kvality dat, rychlejšímu vývoji, mnohem menšímu počtu chyb a konzistenci napříč vaší aplikací.

Proč to Vites nemá?

Abychom pochopili, proč Vites není schopen podporovat referenční integritu, musíme se ponořit do architektury databáze. Vites je rozdělená non-ACID SQL databáze, nikoli skutečná distribuovaná ACID SQL databáze.

Nyní vás jistě zajímá, jaké jsou tyto pojmy. Dovolte mi je pro vás rozebrat:ACID je zkratka slov Atomicity, Consistency, Isolation and Durability.

Zde atomicita odkazuje na akci, která se buď dokončí, nebo úplně selže – žádné částečné dokončení transakce. Konzistence se týká transakce, která ponechá databázi v platném stavu. Izolace jednoduše znamená, že se provedou dvě transakce, aniž by se vzájemně ovlivňovaly, a trvanlivost znamená, že změny transakce jsou uloženy.

Úlomek je horizontální oddíl dat v databázi a každý fragment je uložen na samostatné instanci databázového serveru, aby se rozložila zátěž. Takže když odkazujeme na databázi, která je shardovaná, mluvíme o něčem takovém. Nyní, jak jsem již řekl dříve, Vites je sharded non-ACID SQL databáze, což v podstatě znamená, že NEZARUČUJE KYSELINNÉ vlastnosti transakcí.

Proč to zahodit?

Problém začíná, když máte databázi MySQL s dobře definovaným schématem a vaše služba se stane oblíbenou kvůli problému s příliš velkým počtem čtení, které zasahují do databáze. Většina lidí zde dělá, že začnou ukládat často prováděné dotazy do mezipaměti, ale čtení již nejsou KYSELÉ.

Spolu s příliš mnoha čteními je nadměrné množství zápisů do databáze vážným problémem, kterému by mnozí mohli čelit. Řekněme, že jsme připraveni zapálit si kapsy – můžeme vertikálně škálovat, přidat další RAM, 16jádrový procesor a spoustu opravdu rychlých SSD disků.

Samozřejmě stále máme problém s narůstající složitostí spojení tabulek SQL, takže začnete denormalizovat, abyste se vyhnuli spojením mezi tabulkami.

Před chvílí jsem měl přednášku na Prisma Meetup, kde jsem vysvětlil základy návrhu relační databáze. Téma, kterým jsem se zde zabýval, byla denormalizace, pokud vás to zajímá, určitě se podívejte na toto.

Ale denormalizace je v podstatě proces, kdy do tabulek v databázi přidáváte redundantní data, což zvyšuje výkon s ohledem na cenu místa na disku, protože již nepoužíváte výkon procesoru pro spojení. Denormalizace sice zlepšuje rychlost čtení, ale je důležité si uvědomit, že zpomaluje zápis.

Přes to všechno je však naše databáze stále pomalá, takže výpočty databáze přesouváme na klienta, například generujeme UUID nebo přiřazujeme datum.

I po tom všem budou dotazy stále pomalé – takže výsledek nejvíce dotazovaných dat udržujeme připravený v procesu známém jako materializace databáze. Nyní může být čtení rychlejší, ale zápisy jsou den ode dne pomalejší. Jedinou logickou situací je nyní vypustit sekundární indexy.

Takže v tomto bodě má naše databáze

• Žádné vlastnosti ACID kvůli ukládání do mezipaměti
• Žádné normalizované schéma
• Žádné spouštěče
• Žádné databázové výpočty
• Žádné sekundární indexy

To připravilo cestu pro databáze Vites a NoSQL, protože společnosti měly problémy se škálováním své databáze. Způsob, jakým byl navržen, nebyli schopni udržet konzistenci dat, vlastnost ACID, když transakce zahrnovaly několik různých fragmentů. Referenční integrita je o konzistenci, když data pokrývají více fragmentů, proto dává smysl, že je nemohou dobře podporovat.

Můžeme jít hluboko do struktury NoSQL databází bez FOREIGN KEY omezení a problémy, kterým budeme čelit při přijetí tohoto modelu, ale to je téma pro jiný příspěvek.

Není to jen Vites, u shardovaných databází je standardní praxí vyhnout se referenční integritě, protože prostě neexistuje žádná jiná možnost. Pokud jde o model ACID, jejich dokumentace uvádí, že zaručují atomicitu, ale ne izolaci, a dokonce jdou tak daleko, že říkají:

Zajištění izolace ACID je velmi sporné a má vysoké náklady. Pokud byste jej poskytli ve výchozím nastavení, Vites by byl pro nejběžnější případy použití nepraktický.

Pojďme si krátce říci, co je to ACID Isolation. Existují čtyři úrovně (podle standardů SQL-92), včetně serializace, čtení potvrzené, čtení bez potvrzení a opakovatelného čtení. S tím, co bylo řečeno, existuje více úrovní izolace, jako je izolace Snapshot, která není standardem SQL, ačkoli ji používá několik databází, jako je Firebase nebo MongoDB. Pokud vás to dále zajímá, doporučuji přečíst si tento příspěvek. Aby to bylo stručné, nebudu se zabývat tím, co každá úroveň izolace dělá/znamená, ale pokud si o tom chcete přečíst více, podívejte se na tuto stránku z dokumentace MySQL.

Izolace ACID odkazuje na to, že databázové transakce jsou ACIDické, což je důležité, protože zaručují, že se operace chovají tak, jak je vývojáři očekávají. Nejsem si jistý, co mají na mysli, když říkají „Zaručení izolace ACID je velmi sporné a má vysoké náklady“, ale pokud tím myslí, že záruka izolace ACID má vysoké náklady na jakýkoli produkt , mýlí se. Několik distribuovaných databází kompatibilních s ACID má nejvyšší úroveň izolace (serializovatelné transakce), přičemž jsou stále výkonné s vysokou rychlostí čtení/zápisu. V kontextu Vites se však nemýlí, protože transakce s více fragmenty nemohou dosáhnout žádné úrovně izolace.

Závěr

S tím vším si musíte klást otázku:proč by někdo chtěl používat PlanetScale nebo Vitess? No, zajímalo by mě to samé. U mnoha společností a webových stránek bylo důvodem to, že si vybrali Vites zpět, když nebyly žádné lepší možnosti. Pokud půjdete na začátek článku, všimněte si, jak byl vytvořen v roce 2010. Nyní, když si můžeme užívat ACID kompatibilní škálovatelnou databázi s referenční integritou, bylo by v našem nejlepším zájmu přejít k těmto novým databázím. už jsem s tím začal! Technologie se rychle mění a udržování rychlosti vaší databáze je klíčovou součástí každé aplikace.