Neon nie był jedynie panelem nad standardową maszyną z PostgreSQL. Jego twórcy rozdzielili silnik wykonujący zapytania od rozproszonej warstwy przechowującej WAL i wersje stron. W Lakebase compute uruchamia silnik PostgreSQL i wykonuje zapytania, ale inaczej niż w typowej instalacji PostgreSQL, nie przechowuje trwale ani dziennika transakcyjnego, ani plików danych.
Informacje o każdej zmianie są najpierw zapisywane w dzienniku Write-Ahead Log (WAL), a następnie przesyłane do grupy węzłów safekeeper odpowiedzialnych za ich bezpieczne i redundantne przechowywanie. Na podstawie zapisów WAL serwery stron (pageservery) odtwarzają i tworzą kolejne wersje stron danych, które następnie zapisują cloud object storage.¹¹
Takie rozdzielenie umożliwia autoscaling, scale-to-zero, copy-on-write branching, read replicas korzystające ze wspólnej warstwy storage oraz odtwarzanie stanu z wybranego punktu w historii. Szybkie przełączenie po awarii compute wymaga jednak konfiguracji High Availability (HA). Są to rzeczywiste różnice względem klasycznego, monolitycznego PostgreSQL. Nie należy ich jednak mylić z gwarancją jednakowej wydajności dla każdego rodzaju obciążenia.
Scale-to-zero jest atrakcyjne kosztowo dla środowisk developerskich i nieregularnych workloadów. Po okresie bezczynności compute zostaje zatrzymany, a kolejne połączenie go uruchamia. Dokumentacja Databricks opisuje wznowienie w setkach milisekund, jednak rzeczywisty czas odpowiedzi aplikacji zależy również od czasu zestawienia połączenia, inicjalizacji procesu oraz od tego, czy potrzebne dane znajdują się już w pamięci podręcznej.¹²
Po restarcie compute część danych może wymagać ponownego pobrania, co zwiększa opóźnienie pierwszych zapytań. Databricks ogranicza ten problem za pomocą lokalnej pamięci podręcznej i wyprzedzającego pobierania danych. Warto jednak sprawdzić, jak Lakebase zachowuje się po wznowieniu, zmianie rozmiaru compute lub awarii oraz czy opóźnienia pozostają stabilne przy rzeczywistym obciążeniu. Średnia latencja zmierzona na rozgrzanym systemie nie daje pełnej odpowiedzi na te pytania.
Lakebase automatycznie dostosowuje zasoby compute do obciążenia procesora, wykorzystania pamięci i ilości często używanych danych. Zakres autoscalingu może różnić się maksymalnie o 16 jednostek obliczeniowych (CU) i nie może przekraczać 64 CU. Większe konfiguracje, do 112 CU, działają ze stałym rozmiarem.¹⁴
Funkcja scale-to-zero jest dostępna tylko dla konfiguracji do 32 CU i nie może być używana razem z wysoką dostępnością (HA), ponieważ HA wymaga stale gotowej instancji zapasowej.
Lakebase dobrze sprawdzi się przy zmiennym obciążeniu, jednak system działający przez całą dobę z włączonym HA będzie miał wyższy profil kosztowy niż środowisko demonstracyjne, które może skalować się do zera.
-
Wysoka dostępność (HA) w Lakebase wykorzystuje główną instancję compute oraz maksymalnie trzy instancje zapasowe działające w różnych strefach dostępności. W przypadku awarii jedna z nich automatycznie przejmuje rolę główną. Zatwierdzone transakcje są zachowane, a adres połączenia pozostaje bez zmian. Istniejące połączenia zostają jednak przerwane, dlatego aplikacja musi umieć automatycznie połączyć się ponownie.¹⁵ Ochrona przed awarią całego regionu jest mniej dojrzała. Cross-region Disaster Recovery (DR) znajduje się w Private Preview i nie jest jeszcze przeznaczone do zastosowań produkcyjnych. Replikacja odbywa się okresowo, przełączenie wymaga ręcznej decyzji, a aplikację trzeba skierować na nowy adres. Może również wystąpić utrata najnowszych transakcji oraz konieczność ponownej konfiguracji integracji.¹⁶ Samo włączenie HA nie zapewnia więc pełnej odporności systemu. Osobno należy zaplanować obsługę awarii compute, strefy dostępności i całego regionu.
-
Lakebase obsługuje standardowe sterowniki PostgreSQL, język SQL oraz wiele popularnych rozszerzeń. Nie jest jednak zwykłą instalacją PostgreSQL, lecz usługą zarządzaną, dlatego nakłada określone ograniczenia. Użytkownik nie ma dostępu do systemu operacyjnego ani do standardowego konta superuser. Lakebase nie obsługuje również wbudowanej replikacji logicznej PostgreSQL ani tablespaces, czyli możliwości rozmieszczania danych w różnych lokalizacjach dyskowych. Nie zapewnia też bezpośredniego dostępu do standardowych logów PostgreSQL. Parametry bazy można zmieniać tylko wtedy, gdy Lakebase pozwala ustawić je na poziomie sesji, roli lub bazy danych.¹⁷
Dodatkowe ograniczenia pojawiają się podczas korzystania ze scale-to-zero. Po okresie bezczynności Lakebase zamyka bezczynne połączenia, a następnie może zawiesić compute. Wraz z nimi znika stan sesji, między innymi tabele tymczasowe, przygotowane zapytania (prepared statements), blokady aplikacyjne (advisory locks) oraz subskrypcje LISTEN/NOTIFY. Po wyłączeniu compute nie są również zachowywane lokalne statystyki PostgreSQL.
Szczególnej uwagi wymagają unlogged tables, czyli tabele, których zmiany nie są zapisywane w dzienniku WAL. W Lakebase znajdują się one na lokalnym dysku compute i nie są zachowywane po jego restarcie ani przejściu do zera. Jest to istotna różnica względem standardowego PostgreSQL.
Migrację należy więc rozpocząć od sprawdzenia rozszerzeń, parametrów konfiguracyjnych, funkcji zależnych od stanu sesji, sposobu replikacji oraz wymagań dotyczących monitorowania i dostępu administracyjnego. Poprawne wykonanie pg_dump potwierdza możliwość eksportu bazy, ale nie gwarantuje, że cała aplikacja będzie działała w Lakebase bez zmian.
-
Branch w Lakebase jest tworzony z użyciem mechanizmu copy-on-write. W momencie utworzenia nie powstaje pełna kopia bazy – nowy branch początkowo korzysta z tych samych danych co parent branch. Dodatkowy storage jest zużywany dopiero wtedy, gdy w jednym z branchy pojawiają się zmiany. Dzięki temu można szybko tworzyć środowiska developerskie i testowe, sprawdzać migracje oraz odtwarzać bazę z wybranego punktu w czasie.¹⁸
Porównanie tego mechanizmu do Git jest jednak tylko częściowo trafne. Lakebase pozwala tworzyć niezależne branche, ale nie zapewnia uniwersalnego mechanizmu merge dla dwóch rozbieżnych historii danych. Branch utworzony na podstawie production branch zawiera również kopię logiczną danych produkcyjnych. Copy-on-write ogranicza zużycie storage, ale nie maskuje ani nie anonimizuje danych osobowych.
Podczas tworzenia brancha kopiowane są także Postgres roles, role memberships i grants istniejące w parent branch. Od tego momentu konfiguracja dostępu w każdym branchu rozwija się niezależnie – późniejsze zmiany nie są automatycznie synchronizowane pomiędzy parent branch i child branch. Project permissions Databricks, takie jak CAN_USE i CAN_MANAGE, działają jednak na poziomie całego project.
Jeżeli child branch jest tworzony z protected branch, Lakebase automatycznie generuje nowe passwords dla odpowiadających mu Postgres roles. Ogranicza to ryzyko użycia credentials z child branch do połączenia z production branch. Mechanizm ten nie zastępuje jednak maskowania i minimalizacji danych, kontroli dostępu ani automatycznego usuwania niepotrzebnych środowisk.¹⁹
-
Jedną z głównych zalet Lakebase jest uproszczenie przepływu danych pomiędzy PostgreSQL i Databricks. Synced Tables przesyłają dane z Unity Catalog do Lakebase, gdzie aplikacje mogą je odczytywać przez PostgreSQL. Lakebase CDF działa w przeciwnym kierunku — udostępnia w lakehouse zmiany powstające w Lakebase. Mechanizmy te ułatwiają wymianę danych, ale nie tworzą jednego systemu transakcyjnego. Transakcja wykonana w Lakebase nie obejmuje automatycznie operacji wykonywanych w Unity Catalog.
Synced Tables są przeznaczone do read-only, choć zapis nie zawsze jest technicznie zablokowany. Mają również ograniczenia dotyczące zmian schematu i wykorzystują część dostępnych połączeń do Lakebase. Lakebase CDF pozostaje w Public Preview i nie zastępuje native logical replication ani platformy komunikacyjnej, takiej jak Kafka. Jeżeli system wymaga natychmiastowego fan-outu, możliwości replay, obsługi dead-letter queue lub niezawodnego przetwarzania komend, nadal może potrzebować osobnego message brokera.
Lakebase ogranicza więc liczbę pipeline’ów potrzebnych do wymiany danych pomiędzy Databricks i PostgreSQL. Nie eliminuje jednak wszystkich integracji wymaganych w architekturze przedsiębiorstwa.
-
Lakebase jest jednym i drugim. Dla aplikacji pozostaje PostgreSQL, co obniża próg wejścia. Pod spodem wykorzystuje jednak nietradycyjną architekturę storage, która realnie umożliwia branching, autoscaling i rozdzielenie cyklu życia compute od danych.
To nie jest jedynie nowa nazwa dla hostowanej maszyny z PostgreSQL. Jednocześnie nie jest to uniwersalny następca każdej relacyjnej bazy danych. Największą wartość oferuje tam, gdzie organizacja już wykorzystuje Databricks i chce udostępniać aplikacjom wyniki obliczeń, cechy modeli lub dane operacyjne bez budowania kolejnej, odległej warstwy servingowej.
Decyzja produkcyjna powinna zależeć nie od listy funkcji, lecz od wyniku testów: latencji po wznowieniu, zachowania cache, HA i DR, zgodności aplikacji, ograniczeń synchronizacji oraz kosztu przy rzeczywistym profilu obciążenia. Lakebase otwiera interesujące możliwości. Dopiero POC pokaże, czy są one właściwe dla konkretnego systemu.
- Jestem doświadczoną inżynierką danych oraz pasjonatką technologii.W codziennej pracy cechuje mnie zdolność do szybkiej adaptacji, ambicja, silna wewnętrzna motywacja oraz pewność siebie w podejmowaniu nowych wyzwań. Obecnie zajmuję się optymalizacją wydajności, skalowalności i niezawodności systemów w obszarze Big Data. Mam na koncie projektowanie i budowanie modułowych platform danych typu end-to-end z wykorzystaniem środowisk Azure i Databricks. Moje doświadczenie obejmuje m.in. pracę z wrażliwymi danymi medycznymi (z zachowaniem rygorystycznych wymogów compliance, takich jak GDPR), automatyzację procesów przetwarzania danych (Delta Live Tables, Auto Loader) oraz migrację rozległych systemów z infrastruktury Cloudera/Hadoop do chmury. W swojej karierze wspierałam technologicznie globalnych liderów z branży medycznej, farmaceutycznej oraz wielkich sieci handlowych.
