Uwielbiam technologię bezserwerową. Bawię się i tworzę wiele różnych aplikacji bezserwerowych, aby eksperymentować z innymi fajnymi technologiami. W ogromnym klastrze technologii, z którymi korzystam/eksperymentuję, PlanetScale było baza danych, której używałem głównie do moich osobistych projektów pobocznych, ponieważ nie było żadnej innej „dobrej” opcji, obsługiwanej przez Prisma ORM .
PlanetScale to bezserwerowa platforma MySQL, która po prostu sprzedaje Vitess, system klastrowania baz danych do poziomego skalowania MySQL. Nie napisali własnej bazy danych - prawdopodobnie mieli do niej swój wkład, ale jej nie napisali. Z dokumentacji Vitess:
Vitess powstał w 2010 aby rozwiązać wyzwania związane ze skalowalnością MySQL, przed którymi stanął zespół YouTube.
W tym artykule będziemy dążyć do zrozumienia struktury tych starszych baz danych, które nie są objęte ACID, dlaczego nie są w stanie obsługiwać czegoś tak ważnego jak integralność referencyjna i dlaczego powinniśmy unikać ich używania w naszych aplikacjach. Ten artykuł jest bardziej o technologii Vitess, chociaż w tytule umieściłem PlanetScale, ponieważ, jak wspomniałem powyżej, po prostu sprzedaje Vitess (z pewnym oprzyrządowaniem) jako usługę i zyskały na popularności w następnych miesiącach jako bycie "niezawodna" bezserwerowa baza danych.
Tło
Moje początkowe pytanie brzmiało, dlaczego mówi, że nie można skalować bazy danych PlanetScale z integralnością referencyjną, ponieważ w ich dokumentacji stwierdza się, że:
Sposób, w jaki FOREIGN KEY ograniczenia są zaimplementowane w MySQL (a raczej w silniku pamięci masowej InnoDB) zakłócają operacje Online DDL. Dowiedz się więcej z tego wpisu na blogu Vitess.
Ograniczony do pojedynczego zakresu serwera MySQL, FOREIGN KEY ograniczenia są niemożliwe do utrzymania, gdy dane rosną i są dzielone na wiele serwerów baz danych. Zwykle dzieje się tak, gdy wprowadzasz funkcjonalne partycjonowanie/sharding i/lub sharding poziomy.
To skłoniło mnie do myślenia:zrób FOREIGN KEY ograniczenia ogólnie wpływają na skalowalność? a jeśli tak, to w jaki sposób?
Myślę, że ważne jest, aby zdać sobie sprawę, że łączenia tabel SQL są dość kosztowne, ale o ile wiem, integralność referencyjna nie miała na to dużego wpływu? Teraz, jeśli robimy coś takiego jak analiza danych, oczywiście nie potrzebujemy integralności referencyjnej, ponieważ chcielibyśmy po prostu zrzucić nasze dane do jednej tabeli, ale PlanetScale i Vitess chwalą się, że są używane przez duże aplikacje internetowe takich jak YouTube.
To doprowadziło mnie do zdezorientowania, dlaczego porzucili FOREIGN KEY ograniczenia, takie jak bazy danych, takie jak CockroachDB i Spanner, nadal zachowują integralność referencyjną, a także są skalowalne.
Co to jest integralność referencyjna i dlaczego jest ważna?
Zacznijmy od podstaw, jeśli jesteś nowy. Domyślam się, że większość ludzi czytających ten post ma dobre pojęcie o tym, o czym mówią, ale wyjaśnię to jako formalność. W prostych słowach FOREIGN KEY ograniczenie to klucz bazy danych, którego możemy użyć do stworzenia relacji między dwiema różnymi tabelami poprzez odwołanie się do kolumny lub zestawu kolumn. Integralność referencyjna po prostu odnosi się do stanu bazy danych, w którym wszystkie wartości wszystkich kluczy są prawidłowe.
Dlaczego to ważne?
Teraz, gdy mamy już pewien pomysł na to, czym one są, przejdźmy do drugiej części:dlaczego są ważne?
Integralność referencyjna jest ważna, ponieważ zapobiega wprowadzaniu nowych błędów do bazy danych. Jest to funkcja często udostępniana przez relacyjne bazy danych, która uniemożliwia użytkownikom lub aplikacjom wprowadzanie do bazy niespójnych danych. Prowadzi to do lepszej jakości danych, szybszego rozwoju, znacznie mniejszej liczby błędów i spójności w całej aplikacji.
Dlaczego Vitess tego nie ma?
Tak więc, aby zrozumieć, dlaczego Vitess nie jest w stanie wspierać integralności referencyjnej, musimy zagłębić się w architekturę bazy danych. Vitess to podzielona na fragmenty baza danych bez ACID SQL, a nie prawdziwa rozproszona baza danych ACID SQL.
Teraz musisz się zastanawiać, jakie są te terminy. Pozwól, że ci je przedstawię:ACID to skrót od atomowości, spójności, izolacji i trwałości.
W tym przypadku niepodzielność odnosi się do akcji, która zakończyła się lub całkowicie zakończyła niepowodzeniem - brak częściowego zakończenia transakcji. Spójność odnosi się do transakcji, która pozostawia bazę danych w prawidłowym stanie. Izolacja oznacza po prostu, że dwie transakcje są wykonywane bez wzajemnej ingerencji, a trwałość oznacza, że zmiany transakcji są zapisywane.
Fragment to pozioma partycja danych w bazie danych, a każdy fragment jest przechowywany na osobnej instancji serwera bazy danych w celu rozłożenia obciążenia. Więc kiedy odwołujemy się do bazy danych, która jest shardowana, mówimy o czymś takim. Teraz, jak powiedziałem wcześniej, Vitess jest podzieloną na fragmenty bazą danych SQL bez ACID, co w zasadzie oznacza, że NIE GWARANTUJE właściwości ACID transakcji.
Po co to upuszczać?
Cóż, problem zaczyna się, gdy masz bazę danych MySQL z dobrze zdefiniowanym schematem, a Twoja usługa staje się popularna z powodu problemu zbyt wielu odczytów trafiających do bazy danych. Większość ludzi tutaj robi buforowanie często wykonywanych zapytań, ale odczyty nie są już KWAŚNE.
Wraz ze zbyt dużą liczbą odczytów, nadmierna liczba zapisów w bazie danych jest poważnym problemem, z którym może spotkać się wiele osób. Powiedzmy, że jesteśmy gotowi podpalić nasze kieszenie – możemy skalować w pionie, dodając więcej pamięci RAM, 16-rdzeniowy procesor i mnóstwo naprawdę szybkich dysków półprzewodnikowych.
Oczywiście nadal mamy problem z rosnącą złożonością złączeń tabel SQL, więc zaczynasz denormalizować, aby uniknąć złączeń między tabelami.
Jakiś czas temu wygłosiłem wykład na Prisma Meetup, w którym wyjaśniłem podstawy projektowania relacyjnej bazy danych. Tematem, który tu omówiłem, była denormalizacja, jeśli jesteś zainteresowany, koniecznie sprawdź to.
Ale denormalizacja to w zasadzie proces, w którym dodaje się nadmiarowe dane do tabel w bazie danych, co poprawia wydajność i zmniejsza koszt miejsca na dysku, ponieważ nie wykorzystujesz już mocy procesora do łączenia. Chociaż denormalizacja poprawia szybkość odczytów, należy zdać sobie sprawę, że spowalnia ona zapisy.
Niemniej jednak, pomimo tego wszystkiego, nasza baza danych jest nadal powolna, więc przenosimy obliczenia bazy danych na klienta, na przykład generowanie UUID lub przypisywanie daty.
Nawet po tym wszystkim zapytania będą nadal powolne - dlatego przechowujemy wyniki najczęściej pytanych danych w gotowości w procesie znanym jako materializacja bazy danych. Teraz odczyty mogą być szybsze, ale zapisy z dnia na dzień stają się wolniejsze. Jedyną logiczną sytuacją jest teraz usunięcie indeksów drugorzędnych.
W tym momencie nasza baza danych ma
- Brak właściwości ACID z powodu buforowania
- Brak znormalizowanego schematu
- Brak wyzwalaczy
- Brak obliczeń bazy danych
- Brak wtórnych indeksów
To utorowało drogę do baz danych Vitess i NoSQL, ponieważ firmy miały problemy ze skalowaniem swojej bazy danych. Sposób, w jaki został zaprojektowany, nie był w stanie zachować spójności danych, właściwości ACID, gdy transakcje obejmowały kilka różnych fragmentów. Integralność referencyjna polega na spójności, gdy dane obejmują wiele fragmentów, dlatego ma sens, że nie są w stanie dobrze ich obsługiwać.
Możemy zagłębić się w strukturę baz danych NoSQL bez FOREIGN KEY ograniczenia i problemy, które napotkamy, stosując ten model, ale to temat na inny post.
To nie tylko Vitess, to standardowa praktyka dla shardowanych baz danych, aby uniknąć integralności referencyjnej, ponieważ po prostu nie ma innego wyboru. Jeśli chodzi o model ACID, ich dokumentacja stwierdza, że gwarantują atomowość, ale nie izolację, a nawet posuwają się do stwierdzenia:
Zagwarantowanie izolacji ACID jest bardzo kontrowersyjne i wiąże się z wysokimi kosztami. Domyślne podanie go sprawiłoby, że Vitess byłoby niepraktyczne w najczęstszych przypadkach użycia.
Porozmawiajmy krótko o tym, czym jest izolacja ACID. Istnieją cztery poziomy (zgodnie ze standardami SQL-92), w tym możliwość serializacji, odczyt zatwierdzony, odczyt niezatwierdzony i odczyty powtarzalne. Mając to na uwadze, istnieje więcej poziomów izolacji, takich jak izolacja migawki, która nie jest standardem SQL, chociaż jest używana przez kilka baz danych, takich jak Firebase lub MongoDB. Jeśli jesteś tym bardziej zainteresowany, polecam przeczytanie tego posta. Krótko mówiąc, nie zamierzam omawiać, co każdy poziom izolacji ma/oznacza, ale jeśli chcesz przeczytać więcej na ten temat, sprawdź tę stronę w Dokumentacji MySQL.
Izolacja ACID odnosi się do transakcji bazy danych, które są ACIDic, co jest ważne, ponieważ gwarantują, że operacje zachowują się zgodnie z oczekiwaniami programistów. Nie jestem pewien, co mają na myśli, gdy mówią „Gwarancja izolacji ACID jest bardzo kontrowersyjna i wiąże się z wysokimi kosztami”, ale jeśli mają na myśli, że zagwarantowanie izolacji ACID wiąże się z wysokimi kosztami każdego produktu , są w błędzie. Kilka rozproszonych baz danych zgodnych z ACID ma najwyższy poziom izolacji (transakcje możliwe do serializacji), a jednocześnie zapewnia wysoką wydajność odczytu/zapisu. Jednak w kontekście Vitess nie są one błędne, ponieważ transakcje na wielu fragmentach nie mogą osiągnąć żadnego poziomu izolacji.
Wniosek
Biorąc to wszystko pod uwagę, musisz się zastanawiać:dlaczego ktokolwiek miałby chcieć używać PlanetScale lub Vitess? Cóż, zastanawiam się nad tym samym. W przypadku wielu firm i stron internetowych powodem było to, że wybrali Vitess z powrotem, gdy nie było żadnych lepszych opcji. Jeśli przejdziesz do początku artykułu, zwróć uwagę, jak została utworzona w 2010 roku. Teraz, gdy możemy cieszyć się skalowalną bazą danych zgodną z ACID z integralnością referencyjną, w naszym najlepszym interesie byłoby przejście na te nowe bazy danych, a ja już zacząłem to robić! Technologia zmienia się szybko, a utrzymywanie szybkości bazy danych jest kluczowym elementem każdej aplikacji.
