Architektura bazy jeziora

Usługa Lakebase oddziela magazyn od zasobów obliczeniowych. Silnik Postgres, który wykonuje Twoje zapytania, jest bezstanowy, a Twoje dane znajdują się w trwałej warstwie pamięci, która pozostaje niezależna. To rozdzielenie sprawia, że możliwe jest automatyczne skalowanie, skalowanie do zera, natychmiastowe rozgałęzienia, repliki odczytu i szybkie przełączanie awaryjne.

Aby pokazać, co zmienia Lakebase, ta strona zaczyna się od tradycyjnego projektu bazy danych dla jednej maszyny, a następnie wyjaśnia, jak Lakebase dzieli ten sam projekt na niezależne warstwy i co robi każdy element.

Jak zbudowana jest tradycyjna baza danych

Zanim spojrzysz na Lakebase, rozważ model, który zastępuje. Tradycyjna baza danych Postgresa to monolit. Jedna maszyna uruchamia silnik zapytań i zapisuje zarówno zapis zapisu (write-ahead log, WAL), jak i pliki danych na dysku podłączonym w lokalnym punkcie montażu. Tradycyjnie te dyski były naprawdę lokalne, częścią tej samej maszyny, ale wraz z rozwojem infrastruktury często stały się urządzeniami pamięci masowej podłączonymi do sieci.

WAL i pliki danych pełnią dwie uzupełniające się funkcje:

• WAL przyspiesza zapisy. Postgres dodaje każdą zmianę do logu kolejno, zanim potwierdzi commit, co jest szybkie i trwałe na jednym dysku.
• Pliki danych przyspieszają odczyty. Postgres materializuje aktualną wersję każdej strony w plikach danych, dzięki czemu zapytanie może odczytać wiersz bez odtwarzania logu ponownie.

Dostęp do wszystkich danych przez jeden komputer ma swoje wady:

• Trwałość jest bezpośrednio powiązana z fizyczną infrastrukturą tej maszyny. Musisz także wcześniej przygotować magazyn i przewidzieć, jak bardzo wzrośnie obciążenie, co komplikuje zarówno zarządzanie kosztami, jak i planowanie odporności.
• Wysoka dostępność i wiele rodzajów skalowania poziomego wymagają fizycznych klonów całej bazy danych.
• Jeśli ten komputer się zepsuje, możesz stracić dane. Techniki takie jak pamięć RAID zmniejszają to ryzyko, ale dodatkowa redundancja może znacząco zwiększyć koszty uruchomienia systemu.

Architektura bazy jeziora

Lakebase zachowuje te same obowiązki, ale dzieli je na dwie niezależne warstwy:

• Warstwa obliczeniowa uruchamiająca standardowy, bezstanowy Postgres.
• Warstwa pamięci składającej się z sejfów, serwerów stron oraz chmurowego przechowywania obiektów.

Dwie role z monolitu bezpośrednio pasują do nowych komponentów. WAL, który przyspieszył zapisy, staje się strażnikami sejfów, którzy zapisują na skalę. Pliki danych, które przyspieszały odczyty, stają się serwerami stron, które skalują odczyty.

Ponieważ dane znajdują się w chmurze obiektowej, a nie na jednej maszynie, Lakebase zapewnia elastyczne, skalowalne obliczenia i trwałe zapisy replikowane w strefach dostępności. Nie ma miejsca do udostępniania: płacisz tylko za zużywaną ilość i nie musisz planować na wypadki awarii, jak wyczerpanie dysku.

Ten model również poprawia wydajność. Lakebase zapisuje każdą zmianę bezpośrednio do wielu lokalizacji, dzięki czemu unika narzutu tradycyjnej ochrony przed zerwanym zapisem i wyrównania bloków. Ponieważ każdy zapis już trafia do wielu lokalizacji, wydajność pozostaje stała niezależnie od tego, czy jest włączona wysoka dostępność.

Poniższa tabela mapuje każdą część monolitu na jego odpowiednik w bazie jeziora.

Tradycyjny monolit	Lakebase	Rola
Pojedyncza maszyna	Obliczenia bezstanowe	Uruchamia silnik zapytań Postgres
Lokalny dysk WAL	Strażnicy	Trwało rejestruje każdą zobowiązaną zmianę
Lokalne pliki danych	Serwery stronicowania i pamięć obiektowa	Materializuje i przechowuje wersje strony

Warstwa obliczeniowa

Warstwa obliczeniowa uruchamia Postgres. Przechowuje tylko stan przejściowy: Postgres współdzielił bufory w pamięci oraz lokalną pamięć obliczeniową wspieraną przez szybki lokalny dysk. Nie posiada żadnych trwałych danych.

Ponieważ obliczenia nie posiadają trwałego stanu:

• Można go wymienić, zrestartować, automatycznie skalować lub skalować do zera bez przenoszenia lub utraty danych.
• Zamiast zapisywać do lokalnego systemu plików, przesyła WAL do warstwy pamięci masowej.
• Wiele instancji obliczeniowych może być podłączonych do tej samej warstwy pamięci, co właśnie w Lakebase działa z replikami odczytu i szybkim przełączaniem awaryjnym .

Warstwa przechowywania

Warstwa pamięci jest trwała i działa niezależnie od obliczeń. Składa się z trzech składników.

Strażnicy

Safekeeperzy to WAL, wyjęci z jednej maszyny i udostępnieni w dużej mierze. Ponieważ Postgres tworzy rekordy WAL, przesyła je do grupy keeperów, którzy replikują logi na kworum, korzystając z protokołu konsensusu opartego na Paxos.

Transakcja potwierdza się, gdy kworum strażników potwierdzi rekord WAL, a nie gdy pojedyncza maszyna kończy lokalne fsync. Trwałość wynika z replikacji między węzłami, a nie z jednego dysku.

Serwery stron

Serwery stron to pliki danych, wyciągane i odbudowane z WAL. Serwer stron konsumuje strumień WAL od strażników sejfów i materializuje wersje stron na żądanie. Gdy przetwarzanie żąda strony o określonym numerze sekwencji logów (LSN), serwer stron rekonstruuje i zwraca ją.

Serwery stron działają jako pamięć podręczna do zapisu nad pamięcią obiektową. Asynchronicznie utrzymują zmaterializowane strony do chmurowego przechowywania obiektów, a rekonstrukcja stron nie blokuje zatwierdzenia transakcji.

Magazyn obiektów w chmurze

Przechowywanie obiektów w chmurze to podstawa trwałości całej warstwy magazynowej. Przechowuje dane strony, które serwery stron zachowują.

Na Azure, Lakebase persistuje data do Azure Blob Storage.

Pamięć obiektowa pozostaje poza ścieżką gorącego zapytania. Tylko serwery stron czytają z niej. Szczegóły dotyczące działania redundancji pamięci masowej i dlaczego jest niezależna od ustawień wysokiej dostępności obliczeniowej, można znaleźć w artykule Architektura pamięci.

Jak działa pisanie

Zapis przepływa z obliczeń przez warstwę pamięci:

1. Postgres modyfikuje dotknięte strony w pamięci i generuje rekordy WAL.
2. Compute przesyła zapisy WAL do strażników.
3. Gdy kworum osób potwierdza dokumentację, transakcja zostaje zatwierdzona i klient odnosi sukces.
4. Serwery stron stosują WAL asynchronicznie i utrzymują zaktualizowane strony na pamięci obiektowej.

Transakcja jest trwała, gdy kworum keeperów posiada rekord WAL, ponieważ sam log wystarcza do odtworzenia danych. Serwery stron odbudowują i przechowują strony danych później, poza ścieżką commit, więc zapisy pozostają szybkie bez ryzyka przy jakiejkolwiek zobowiązanej zmianie.

Jak działa czytanie

Odczyty sprawdzają hierarchię pamięci podręcznych, od najszybszej do najwolniejszej, i zatrzymują się na pierwszej warstwie, na której znajduje się strona:

1. Pula buforowa (pamięć): Postgres współdzielił bufory w pamięci obliczeniowej.
2. Lokalna pamięć podręczna obliczeniowa: Pamięci podręcznej z podtrzymywaniem dysku na węźle obliczeniowym, o rozmiarze względem pamięci obliczeniowej.
3. Pageserver: W przypadku błędu pamięci podręcznej obliczenia żąda strony od serwera stron, który rekonstruuje ją na żądanym LSN.
4. Przechowywanie obiektów: Serwer stron odczytuje z pamięci obiektowej wewnętrznie, gdy jest to potrzebne. Zapytania nie docierają bezpośrednio do pamięci obiektowej.

Co umożliwia ta architektura

Oddzielenie bezstanowiowych obliczeń od trwałego przechowywania to właśnie to, co umożliwia wykonanie kilku funkcji Lakebase:

Funkcja	Co umożliwia
Skalowanie automatyczne	Ponieważ obliczenia są bezstanowe, Lakebase skaluje rozmiar obliczeniowy w odpowiedzi na obciążenie bez przenoszenia danych.
Skalowanie do zera	Obliczenia mogą całkowicie zostać wstrzymane, gdy pamięć pozostaje aktywna, a dane są natychmiast dostępne po wznowieniu obliczeń.
Natychmiastowe gałęzie	Stwórz izolowaną, zapisywalną kopię swojej bazy danych w ciągu kilku sekund. Ponieważ rozgałęzienie jest operacją kopiowania przy zapisie metadanych na współdzielonej pamięci, nie duplikuje danych.
Repliki do odczytu	Wiele instancji obliczeniowych odczytuje się z tej samej warstwy pamięci, więc repliki nie wymagają kopii danych i uruchamiają się w kilka sekund.
Zapytania punktowe	Ponieważ warstwa pamięci masowej zachowuje historię, komputer może przyłączyć się do przeszłego momentu i odczytać bazę danych tak, jak istniała wtedy, bez konieczności kopiowania danych z powrotem na miejsce.
Szybkie przełączanie awaryjne	Failover promuje wtórną instancję obliczeniową, która dołącza się do istniejącej pamięci masowej, bez danych do przeniesienia.
RPO = 0 (brak zobowiązanej utraty danych)	Lakebase trwale rejestruje każdą zadeklarowaną transakcję przed jej potwierdzeniem, więc nie tracisz żadnych zobowiązanych danych, gdy obliczenia zawodzą, restartują się lub skalują do zera.

Jak ta architektura wspiera LTAP

Ponieważ Lakebase trwało przechowuje każdą zadeklarowaną zmianę w chmurze obiektowej pamięci, te same dane mogą obsługiwać obciążenia analityczne obok transakcji bez osobnego potoku replikacyjnego. To podstawa Lake Transactional and Analytical Processing (LTAP), gdzie jedna kopia Twoich danych wspiera zarówno silniki transakcyjne, jak i analityczne. Aby dowiedzieć się, jak LTAP opiera się na tej architekturze, zobacz architekturę LTAP.

Następne kroki

• Architektura pamięci masowej: Dowiedz się, jak działa redundancja pamięci masowej i dlaczego jest niezależna od ustawienia wysokiej dostępności obliczeniowej. Zobacz Architektura magazynu.
• Gałęzie bazy danych: Zobacz, jak gałęzie wykorzystują pamięć copy-on-write do tworzenia natychmiastowych, izolowanych środowisk. Zobacz Gałęzie.
• Czytaj repliki: Dodaj instancje obliczeniowe tylko do odczytu, które dzielą tę samą warstwę pamięci. Zobacz Repliki do odczytu.
• Podstawowe koncepcje: Przejrzyj pełny zestaw koncepcji, które czynią Lakebase wyjątkowym. Zobacz Podstawowe koncepcje.