Databricks ulepsza pamięć podręczną obliczeń Lakebase Postgres, ale prawdziwym testem jest autoskalowanie
Databricks poprawia wydajność pamięci podręcznej obliczeń Lakebase Postgres dzięki nowej konfiguracji, która w pomiarach produkcyjnych zapewniła nawet dwukrotnie większą przepustowość. Zmiana jest już aktywna dla obliczeń Databricks o stałym rozmiarze i co najmniej 80 jednostkach obliczeniowych. Trudniejszy problem pozostaje jednak nierozwiązany: wdrożenie tej samej strategii pamięci w obliczeniach, które rozszerzają się i kurczą podczas działania Postgresa.
Aktualizacja zmienia miejsce, w którym najczęściej żądane strony bazy danych spędzają czas. Duże obliczenia o stałym rozmiarze przeznaczają teraz do 75% dostępnej pamięci na współdzielone bufory Postgresa. Bufory te są najszybszą pamięcią podręczną silnika bazy danych. Databricks obsługuje tę pamięć również za pomocą stron huge pages o rozmiarze 2 MB, aby ograniczyć pracę związaną z translacją adresów wewnątrz systemu operacyjnego.
To połączenie jest odpowiedzią na kluczowe napięcie w rozproszonych bazach danych. Oddzielenie trwałej pamięci masowej od zasobów obliczeniowych umożliwia szybkie restarty, niezależne skalowanie i tanią pamięć obiektową. Jednocześnie zwiększa jednak dystans między wykonywanym zapytaniem a potrzebnymi mu danymi. Amazon Aurora, AlloyDB i inne chmurowe bazy danych mierzą się z wariantami tego problemu, lecz Databricks stosuje swoje rozwiązanie w architekturze Neon stanowiącej podstawę Lakebase.
Ulepszanie pamięci podręcznej obliczeń Lakebase Postgres zaczyna się od obliczeń stałych
Databricks przeniósł najczęściej używaną część pamięci podręcznej Lakebase z lokalnego dysku do pamięci Postgresa, ale tylko na odpowiednio dużych maszynach o stałym rozmiarze.
Zmiana została upubliczniona 9 września 2026 roku. Według firmowej aktualizacji pamięci podręcznej obliczeń jest aktywna dla obliczeń Lakebase o stałym rozmiarze i co najmniej 80 jednostkach obliczeniowych. Równoważne wdrożenie Neon obejmuje stałe obliczenia z co najmniej 18 jednostkami obliczeniowymi.
Lakebase wykorzystuje rozproszoną pamięć masową, co oznacza, że obliczenia Postgresa i trwałe przechowywanie danych działają jako oddzielne warstwy. Węzeł obliczeniowy uruchamia silnik bazy danych, ale nie przechowuje autorytatywnej kopii danych. Taka konstrukcja pozwala operatorom wymieniać, restartować lub zmieniać rozmiar zasobów obliczeniowych bez przenoszenia całej bazy danych.
Odczyty przechodzą przez hierarchię. Postgres najpierw sprawdza współdzielone bufory w DRAM. Jeśli strony tam nie ma, wcześniejsza konfiguracja sprawdza lokalną pamięć podręczną plików przechowywaną na dysku NVMe węzła obliczeniowego. Kolejne chybienie wysyła żądanie do warstwy rozproszonej pamięci masowej, gdzie pageservery rekonstruują i zwracają strony bazy danych.
Ta lokalna pamięć podręczna plików rozwiązała ważny początkowy problem. Standardowe instalacje Postgresa zwykle korzystają zarówno ze współdzielonych buforów, jak i z pamięci podręcznej stron systemu operacyjnego. Lakebase nie kieruje zdalnych odczytów stron przez konwencjonalny lokalny system plików, dlatego nie może polegać na tej standardowej drugiej warstwie.
Databricks i Neon stworzyły więc lokalną pamięć podręczną plików jako elastyczny substytut. Mogła ona wykorzystywać pojemność przekraczającą statyczny przydział buforów Postgresa i dostosowywać się do bezserwerowych zasobów obliczeniowych. Taki układ wspierał autoskalowanie bez konieczności zmiany rozmiaru współdzielonych buforów przez Postgresa podczas działania.
Wcześniejsza konfiguracja ograniczała jednak współdzielone bufory do około 1 GB. Większość pozostałej pojemności pamięci podręcznej obliczeń, która mogła sięgać 75% DRAM, trafiała do lokalnej pamięci podręcznej plików. Na dużych maszynach taki podział kierował wiele odczytów, które w innym wypadku mogłyby zostać obsłużone z pamięci podręcznej, przez NVMe zamiast przez pamięć.
Nowa konfiguracja dla stałych zasobów obliczeniowych usuwa lokalną pamięć podręczną plików z tej ścieżki. Przydziela 75% DRAM współdzielonym buforom, utrzymując znacznie większy zestaw roboczy wewnątrz Postgresa. Według ogłoszenia endpoint Databricks o mocy 80 jednostek powinien zwrócić 120 GB, gdy administrator uruchomi show shared_buffers.
Dostęp do DRAM eliminuje wejście i wyjście dyskowe wymagane przez lokalną pamięć podręczną. Daje też Postgresowi bezpośrednią wiedzę o stronach w pamięci podręcznej i sposobie ich używania. Pamięć podręczna systemu operacyjnego lub oddzielna warstwa dyskowa ma mniej informacji o stanie bazy danych, gdy decyduje, którą stronę usunąć.
To jest bezpośrednie znaczenie ulepszania pamięci podręcznej obliczeń Lakebase Postgres. Nie chodzi o nowy indeks, planer zapytań ani format przechowywania danych. Databricks zmienił przydział pamięci oraz mechanizmy pamięci wirtualnej otaczające istniejący silnik wykonawczy Postgresa.
Zakres tej zmiany ma znaczenie. Wdrożenia o stałym rozmiarze mogą przydzielać współdzielone bufory podczas uruchamiania, ponieważ ich limit pamięci pozostaje znany. Endpointy z autoskalowaniem nie mogą przyjąć tego samego założenia. Ich dostępna pamięć zmienia się wraz z zapotrzebowaniem obciążenia, podczas gdy standardowe ustawienie Postgresa pozostaje statyczne po uruchomieniu.
Dlatego pierwsza wersja jest istotna, choć niekompletna. Databricks pokazał, że bardziej bezpośrednie wykorzystanie pamięci może poprawić działanie dużych endpointów Lakebase. Nie wdrożył jeszcze tego samego projektu w bezserwerowym modelu działania, który czyni rozproszony Postgres atrakcyjnym.
Dlaczego wydajność pamięci podręcznej Lakebase stała się priorytetem
Rozdzielenie pamięci masowej zapewnia elastyczność operacyjną, ale każde chybienie pamięci podręcznej ujawnia koszty opóźnień i CPU ukryte przez tę elastyczność.
Tradycyjny Postgres zwykle łączy silnik zapytań, dziennik write-ahead log i pliki bazy danych na jednej maszynie lub w ściśle połączonej pamięci masowej. System operacyjny może utrzymywać ostatnio używane strony plików w swojej pamięci podręcznej stron. Postgres przechowuje także wybrane strony we współdzielonych buforach.
Taki układ może duplikować dane w pamięci. Databricks podaje przykład maszyny z 4 GB RAM i 1 GB przydzielonym współdzielonym buforom. Odczyt 1 GB przez system plików może pozostawić kolejną kopię w pamięci podręcznej systemu operacyjnego, zużywając 2 GB na buforowanie 1 GB stron bazy danych.
Lakebase zmienia tę ścieżkę. Jego architektura pamięci masowej dzieli system na bezstanowe obliczenia Postgresa i trwałą usługę przechowywania danych. Safekeepers replikują rekordy dziennika write-ahead log, podczas gdy pageservery rekonstruują wersje stron i utrwalają je w pamięci obiektowej.
Architektura pozwala skalować zasoby obliczeniowe niezależnie od przechowywanych danych. Obsługuje funkcje takie jak skalowanie do zera, szybkie rozgałęzianie, repliki do odczytu i przełączanie awaryjne bez kopiowania całej bazy danych. Te korzyści zależą od utrzymywania trwałego stanu poza węzłem obliczeniowym.
Bezstanowe zasoby obliczeniowe nadal potrzebują jednak stanu pod ręką podczas przetwarzania zapytań. Aplikacje wielokrotnie uzyskują dostęp do indeksów, stron tabel, rekordów katalogowych i innych struktur. Jeśli te strony pozostają w DRAM, odczyty kończą się w części hierarchii o najniższych opóźnieniach.
Chybienie we współdzielonych buforach wymaga dłuższej trasy. Lokalna pamięć podręczna NVMe jest szybsza niż zdalna pamięć masowa, ale wciąż wymaga dostępu do dysku i dodatkowego przetwarzania przez oprogramowanie. Chybienie w niej dociera do pageservera, potencjalnie dodając ruch sieciowy i pracę związaną z rekonstrukcją stron.
Wynikająca z tego presja dotyka zespołów korzystających z dużych instancji Lakebase dla aplikacji wrażliwych na opóźnienia. Klienci ci zapewniają znaczną ilość pamięci, lecz wcześniejszy limit 1 GB dla współdzielonych buforów uniemożliwiał Postgresowi wykorzystanie większości tej pamięci przez jego najszybszą ścieżkę pamięci podręcznej.
Niedopasowanie staje się bardziej widoczne wraz ze wzrostem zestawu roboczego. Zestaw roboczy to zbiór stron, do których aplikacja często uzyskuje dostęp w określonym okresie. Gdy przekracza on pojemność niewielkiej pamięci podręcznej, żądania trafiają do wolniejszych warstw, nawet jeśli maszyna ma dużo DRAM.
Databricks potrzebował lepszej odpowiedzi, ponieważ Lakebase obsługuje teraz obciążenia operacyjne, a nie tylko zadania analityczne. Aplikacje skierowane do użytkowników dbają o opóźnienia ogonowe, które odzwierciedlają wolniejsze żądania blisko końca rozkładu opóźnień. Średnie mogą pozostać akceptowalne, podczas gdy żądania p99 nadal powodują zauważalne przerwy.
Aplikacje AI również wywierają nierównomierną presję na operacyjne bazy danych. Agent może wywoływać serie pobrań, zapisów, punktów kontrolnych i równoczesnych wywołań narzędzi. Przewidywalne zachowanie pamięci podręcznej staje się ważniejsze, gdy ruch napływa grupami, a nie stałym strumieniem żądań.
Nie oznacza to, że każde obciążenie skorzysta w takim samym stopniu. Zbiór danych, który już mieści się w wcześniejszym przydziale współdzielonych buforów, ma mniej możliwości poprawy. Obciążenie intensywnie skanujące dane z niewielkim ponownym wykorzystaniem stron może nadal sięgać niższych poziomów pamięci podręcznej niezależnie od rozmiaru bufora.
Najlepszymi kandydatami są duże endpointy z zestawami roboczymi nadającymi się do ponownego użycia, które przekraczały wcześniejszy limit 1 GB. Ich istniejąca pamięć może teraz przechowywać więcej często używanych stron bezpośrednio wewnątrz Postgresa. Dlatego Databricks przedstawił przykłady produkcyjne zamiast obiecywać uniwersalne podwojenie wydajności.
Wydajność pamięci podręcznej Lakebase zależy więc od charakterystyki obciążenia w takim samym stopniu jak od rozmiaru maszyny. Nowa konfiguracja usuwa jedno architektoniczne wąskie gardło. Nie znosi jednak podstawowych zasad dotyczących lokalności pamięci podręcznej, projektu zapytań, indeksowania ani rywalizacji o pamięć.
Huge pages sprawiają, że większa pula buforów jest praktyczna
Przydzielenie większej ilości pamięci Postgresowi stworzyłoby własne narzuty, gdyby Lakebase nie ograniczył również kosztu mapowania tej pamięci między procesami bazy danych.
Postgres korzysta z architektury opartej na procesach. Każde aktywne połączenie zwykle otrzymuje proces backendu, a każdy backend mapuje obszar współdzielonych buforów do własnej przestrzeni adresów wirtualnych. System operacyjny utrzymuje wpisy tablic stron, które tłumaczą te adresy wirtualne na lokalizacje w pamięci fizycznej.
Standardowe strony pamięci Linux mają zazwyczaj 4 KB. Przy takim rozmiarze strony 1 GB współdzielonych buforów wymaga 262 144 wpisów tablic stron dla każdego procesu mapującego ten obszar. Databricks wylicza, że 32 GB współdzielonych buforów w 512 backendach może wymagać około 4,3 miliarda wpisów.
Firma szacuje, że wpisy te zużywałyby około 32 GB tablic stron tylko po to, aby zmapować pamięć podręczną o pojemności 32 GB. To skrajny przykład pokazujący, jak większy przydział buforów może przenieść narzut w inne miejsce. Większa pojemność pamięci podręcznej nie jest automatycznie użyteczna, gdy zarządzanie pamięcią zużywa nadmierną ilość RAM i czasu CPU.
Procesor utrzymuje także bufor translacji adresów, czyli TLB. Ta sprzętowa pamięć podręczna przechowuje ostatnie translacje adresów wirtualnych na fizyczne. Strona danych może znajdować się w pamięci Postgresa, a CPU nadal ponosi koszt jej zlokalizowania po chybieniu TLB.
Huge pages zmniejszają tę presję, mapując pamięć w większych jednostkach. Lakebase używa jawnych stron HugeTLB o rozmiarze 2 MB w nowej konfiguracji dla stałych zasobów obliczeniowych. Każda duża strona obejmuje 512 razy więcej pamięci niż standardowa strona 4 KB, zmniejszając o ten sam współczynnik liczbę wymaganych wpisów mapowania.
PostgreSQL udostępnia już mechanizmy kontroli huge pages systemu operacyjnego. Jego dokumentacja zasobów wyjaśnia, że jawne duże strony mogą ograniczać narzut związany z dużymi ciągłymi regionami pamięci współdzielonej. Korzyść jest szczególnie istotna, gdy shared_buffers staje się bardzo duże.
Wirtualizacja utrudnia wdrożenie. Lakebase uruchamia Postgresa w lekkich maszynach wirtualnych gościa na hostach bare-metal. Translacja adresów przechodzi więc zarówno przez warstwę gościa, jak i hosta. Huge pages muszą pozostawać spójnie obsługiwane przez hosta, hiperwizor i gościa, aby zachować zamierzone korzyści.
Databricks twierdzi, że dodał dedykowaną obsługę huge pages w całym tym stosie. Duże maszyny wirtualne o stałym rozmiarze uruchamiają się z wcześniej określoną liczbą huge pages. Po zainicjowaniu Postgresa system obliczeniowy zwalnia pojemność, której baza danych nie potrzebuje.
Firma wybrała jawne strony HugeTLB zamiast transparent huge pages. Transparent huge pages pozwalają systemowi operacyjnemu automatycznie promować pamięć, lecz ich działanie opiera się na mechanizmie best effort. Jawna rezerwacja zapewnia środowisku bazy danych ściślejszą kontrolę nad dostępnością i układem stron.
W testach porównawczych Databricks ogromne strony zmniejszyły opóźnienia odczytu w ogonie rozkładu nawet o około 40%. Wykorzystanie CPU spadło nawet o około 30%. Są to pomiary firmy, a nie niezależne gwarancje dla każdego obciążenia Lakebase.
To rozróżnienie ma znaczenie, ponieważ ogromne strony nie wyjaśniają całej zgłaszanej poprawy. Wprowadzono jednocześnie dwie zmiany: więcej danych pozostawało we współdzielonych buforach, a dostęp do tego większego obszaru wymagał mniejszej liczby tłumaczeń stron. Obciążenia mogą korzystać z każdego z tych mechanizmów w różnych proporcjach.
Administrator może sprawdzić wdrożone ustawienie w Postgres. Polecenie show huge_pages powinno zwrócić on dla kwalifikującego się 80-jednostkowego endpointu Lakebase. W połączeniu z wartością shared_buffers daje to bezpośredni sposób potwierdzenia, czy nowa konfiguracja trafiła do zasobu obliczeniowego.
Mechanizm ten wyjaśnia również, dlaczego samo zwiększenie shared_buffers nie jest pełną odpowiedzią dla zwykłych wdrożeń Postgres. Pamięć zarezerwowana dla bazy danych musi współistnieć z połączeniami, operacjami zapytań, zadaniami konserwacyjnymi i potrzebami systemu operacyjnego. Duża alokacja może stworzyć nowe ograniczenia, jeśli otaczający ją system nie został do tego zaprojektowany.
Databricks kontroluje maszyny wirtualne, obrazy zasobów obliczeniowych, ścieżkę cache i protokół magazynu. Ta kontrola od początku do końca pozwala firmie skoordynować rezerwację ogromnych stron ze startem Postgres. Zespół zarządzający infrastrukturą samodzielnie musiałby stroić te warstwy niezależnie i weryfikować wynik pod własnym obciążeniem.
Sposób działania cache Lakebase jest więc bardziej złożony niż „użyj więcej RAM-u”. Poprawa zależy od umieszczenia gorących danych we właściwym obszarze pamięci, efektywnego mapowania tego obszaru oraz zachowania wystarczającej ilości pamięci dla wszystkiego poza pulą buforów.
Wyniki produkcyjne pokazują zyski, a nie uniwersalną bazę odniesienia
Databricks raportuje znaczące usprawnienia w trzech produkcyjnych endpointach, lecz opublikowane przykłady nie ustanawiają średniej wydajności dla całej platformy.
Pierwszy przykład otrzymał nową konfigurację około 06:10 UTC 11 sierpnia. Liczba obsługiwanych bloków Postgres na sekundę podwoiła się, co Databricks wykorzystał jako wskaźnik przepustowości. Liczba żądań magazynowych GetPage spadła z około 8 000 na sekundę do około 1 500.
Klient zgłosił też niższe medianowe opóźnienie i p99 w porównaniu z poprzednim dniem, tygodniem i miesiącem. W komunikacie nie podano bazowych wartości opóźnień, definicji obciążenia, miksu zapytań ani środowiska kontrolnego porównania. Czytelnicy powinni traktować tę obserwację jako wynik produkcyjny, a nie standaryzowany benchmark.
Drugi endpoint zmieniono około 01:30 UTC 14 sierpnia. Raportowana przepustowość wzrosła o około 43%, a współczynnik trafień cache zasobu obliczeniowego zbliżył się do 100%. Po wdrożeniu żądania były obsługiwane niemal w całości ze współdzielonych buforów.
Trzeci endpoint zmieniono 15 sierpnia. Databricks podaje, że zużycie CPU spadło z 20 rdzeni do czterech, współczynnik trafień cache zbliżył się do 100%, a zmierzona przepustowość podwoiła się. Pięciokrotne ograniczenie wykorzystania CPU zwraca uwagę, ale publiczny wpis nie określa, czy wszystkie zewnętrzne warunki obciążenia pozostały niezmienne.
Łącznie przykłady wspierają wiarygodny mechanizm. Więcej żądań trafiało do DRAM, mniej odczytów docierało do rozproszonej usługi magazynowej, a procesory poświęcały mniej czasu na translację adresów. Takie wyniki są zgodne ze zmianami konstrukcyjnymi.
Nie dowodzą one, że każdy kwalifikujący się zasób obliczeniowy staje się dwa razy szybszy. Databricks używa sformułowania „do”, a trzy wyniki są zróżnicowane. W jednym odnotowano wzrost przepustowości o 43%, podczas gdy dwa osiągnęły mniej więcej dwukrotność wcześniejszego pomiaru.
Skład obciążenia pozostaje największą zmienną. Zapytania wrażliwe na cache, z powtarzalnym dostępem do dużego, lecz ograniczonego zestawu roboczego, powinny zyskać więcej. Obciążenia intensywnie zapisujące dane, skany o niskim ponownym użyciu, rywalizacja o blokady, nieefektywne zapytania lub logika aplikacji ograniczana siecią mogą ograniczyć widoczną poprawę.
Stary lokalny cache plików również wykonywał użyteczną pracę. Oferował większą pojemność niż pierwotna alokacja współdzielonych buforów i pozwalał uniknąć wielu żądań warstwy magazynowej. Przeniesienie gorących stron z NVMe do DRAM usprawnia najszybszą ścieżkę, ale usunięcie tej drugorzędnej warstwy zmienia zachowanie, gdy zestaw roboczy przekracza dostępną pamięć.
Databricks twierdzi, że na tych stałych zasobach obliczeniowych chybienie prowadzi teraz ze współdzielonych buforów do rozproszonego magazynu. Rodzi to ważne pytanie dla wyjątkowo dużych lub zmiennych obciążeń. Wyższy współczynnik trafień w pamięci może współistnieć z większą karą za strony, które wypadają poza powiększoną pulę buforów.
Opublikowane endpointy najwyraźniej skorzystały, ponieważ ich aktywne dane dobrze mieściły się w większej alokacji. Współczynniki trafień bliskie 100% w dwóch przykładach sugerują silną lokalność. Aplikacje o mniejszej lokalności mogą wykazać inną równowagę między szybszymi trafieniami a zdalnymi chybieniami.
Na uwagę zasługuje również zachowanie po restarcie. Współdzielone bufory są nietrwałe, dlatego nowo uruchomiony zasób obliczeniowy zwykle zaczyna bez swojego gorącego zestawu roboczego w pamięci. Databricks osobno dokumentuje automatyczne wstępne rozgrzewanie cache, które ponownie ładuje często używane dane podczas planowanych aktualizacji.
Wstępne rozgrzewanie może zmniejszyć karę zimnego cache po aktualizacji, ale aplikacje nadal mogą doświadczyć krótkiej przerwy w połączeniu podczas restartu. Sterowniki, pule połączeń i logika ponawiania prób muszą obsłużyć to zdarzenie. Usprawnienia cache nie eliminują potrzeby odporności połączeń.
Niezależne wyniki benchmarków wzmocniłyby ten argument. Przydatne testy ujawniałyby rozmiar zbioru danych, liczbę połączeń, rozkład zapytań, stan buforów, rozmiar zasobu obliczeniowego i percentyle opóźnień. Powinny również porównywać stare i nowe ścieżki cache zarówno przy stałych, jak i zmieniających się zestawach roboczych.
Na razie dowody uzasadniają węższy wniosek. Usprawnienie cache zasobów obliczeniowych Lakebase Postgres wydaje się skuteczne dla dużych produkcyjnych endpointów zmierzonych przez Databricks. Skala korzyści dla innej aplikacji pozostaje kwestią empiryczną, na którą operatorzy powinni odpowiedzieć własnymi metrykami opóźnień, współczynnika trafień, CPU i odczytów magazynu.
Główny konflikt dotyczy stałej pamięci i autoskalowania
Obecne wydanie usprawnia prostszą połowę Lakebase, podczas gdy obietnica serwerless produktu zależy od zmiany rozmiaru pamięci cache bez restartowania Postgres.
Ustawienie shared_buffers jest zwykle wybierane przed uruchomieniem Postgres. Jego zmiana wymaga restartu, ponieważ baza danych ustanawia obszar pamięci współdzielonej podczas inicjalizacji. Takie zachowanie bezpośrednio koliduje z automatycznie skalowanym zasobem obliczeniowym, który zmienia pojemność pamięci podczas obsługi ruchu.
Stały zasób obliczeniowy pozwala uniknąć tego konfliktu. Databricks zna ilość pamięci maszyny wirtualnej, przeznacza 75% na współdzielone bufory, rezerwuje odpowiadające im ogromne strony i uruchamia Postgres. Alokacja może pozostać niezmieniona przez cały okres działania maszyny.
Endpoint z autoskalowaniem musi się rozszerzać i kurczyć. Gdy rośnie zapotrzebowanie, Postgres powinien zyskać pojemność buforów, a gość powinien otrzymać dokładną liczbę ogromnych stron potrzebnych do jej efektywnego mapowania. Gdy zapotrzebowanie spada, oba zasoby powinny zostać zwrócone bez uszkadzania aktywnego stanu lub wymuszania zakłócających restartów.
To znacząco inne zadanie inżynieryjne. Pamięć współdzielona może zawierać strony, które aktywne backendy odczytują, modyfikują, przypinają lub sprawdzają. Zmniejszenie regionu wymaga bezpiecznej koordynacji z usuwaniem wpisów cache i równoległą aktywnością bazy danych.
Databricks twierdzi, że opracował protokół skalujący ogromne strony wraz z dynamicznymi współdzielonymi buforami. Firma planuje wyjaśnić tę implementację w drugim wpisie technicznym. Zamierza również współpracować ze społecznością open-source PostgreSQL nad mechanizmami bazowymi.
Dopóki ta praca nie zostanie wdrożona, Lakebase ma dwie strategie cache. Duże stałe zasoby obliczeniowe otrzymują powiększoną konstrukcję współdzielonych buforów. Zasoby z autoskalowaniem nadal opierają się na dotychczasowym połączeniu zachowawczo dobranych współdzielonych buforów i lokalnego cache plików.
Ten podział wywiera presję na pozycjonowanie produktu. Stała pojemność oferuje dziś najwyraźniejszą poprawę wydajności, podczas gdy autoskalowanie zapewnia elastyczność kojarzoną z bazą danych serverless. Klienci nie mogą jeszcze zakładać, że otrzymają obie cechy w tym samym trybie zasobu obliczeniowego.
Nie czyni to autoskalowania gorszym dla każdego wdrożenia. Zmienne lub sporadyczne aplikacje mogą bardziej cenić skalowanie do zera i elastyczną pojemność niż najniższe możliwe opóźnienie cache. Stabilna, intensywnie wykorzystująca pamięć usługa produkcyjna może preferować przewidywalne, stałe zasoby.
Decyzja zależy również od wzrostu obciążenia. Stałe zasoby obliczeniowe wymagają od operatorów wcześniejszego wyboru wystarczającej pojemności. Autoskalowanie może absorbować zmiany ruchu, lecz obecna ścieżka cache może kierować więcej trafień przez lokalne NVMe, gdy zestaw roboczy przekracza małą alokację współdzielonych buforów.
To jest rzeczywisty test konkurencyjny dla wydajności cache Lakebase. Inne zarządzane usługi Postgres również łączą rozproszoną trwałość, lokalne buforowanie, repliki i elastyczne zarządzanie zasobami. Szczegóły architektoniczne się różnią, więc nagłówkowe liczby z benchmarków rzadko pozwalają na jednoznaczny ranking produktów.
Databricks musi zamiast tego pokazać, że jego separacja warstwy magazynu nie nakłada możliwej do uniknięcia kary na obciążenia, do których jest kierowana. Dostarczenie dynamicznych współdzielonych buforów pozwoliłoby Lakebase zachować model obliczeń bezstanowych, jednocześnie oddając więcej elastycznej pamięci pod bezpośrednią kontrolę Postgres.
Współpraca z projektem nadrzędnym mogłaby rozszerzyć wpływ poza Lakebase. Dynamiczne określanie rozmiaru buforów ma znaczenie dla skonteneryzowanych i elastycznych środowisk Postgres, w których przydzielona pamięć zmienia się w czasie. Databricks nie opublikował jednak jeszcze kodu, statusu przeglądu ani ścieżki wydania opisanych w ogłoszeniu.
Ta niepewność powinna pozostać wyraźna. Firma określiła kierunek i twierdzi, że protokół autoskalowania istnieje. Nie podała daty wydania, obsługiwanego zakresu zasobów obliczeniowych ani pomiarów produkcyjnych dla współdzielonych buforów z autoskalowaniem.
Wdrożenie dla stałych zasobów obliczeniowych jest zatem zarówno usprawnieniem, jak i zapowiedzią. Potwierdza mechanizmy rozmieszczenia cache i ogromnych stron w warunkach stabilnej pamięci. Następna faza musi udowodnić, że mechanizmy te mogą podążać za zmieniającą się maszyną bez poświęcania dostępności lub przewidywalnej wydajności.
Co użytkownicy Lakebase powinni teraz mierzyć
Istotne pytanie nie brzmi, czy opublikowany benchmark wygląda imponująco, lecz czy kwalifikujące się obciążenie staje się szybsze bez pojawienia się nowej kary za chybienia.
Uprawnieni użytkownicy mogą najpierw potwierdzić konfigurację. show shared_buffers ujawnia bieżącą alokację buforów Postgres, a show huge_pages informuje, czy aktywne są jawne ogromne strony. Według przykładu firmy 80-jednostkowy endpoint Databricks powinien pokazać 120 GB i on.
Sama konfiguracja nie potwierdza wartości. Zespoły powinny porównywać współczynnik trafień cache, aktywność magazynową GetPage, zużycie CPU, przepustowość oraz opóźnienia zapytań p50 i p99 w równoważnych oknach ruchu. Porównanie powinno uwzględniać wdrożenia, wzrost danych, prace konserwacyjne i zmiany aplikacji.
Współczynnik trafień cache wymaga kontekstu. Wartość bliska 100% może wskazywać, że aktywny zestaw roboczy mieści się w pamięci. Może też ukrywać różnice w koszcie żądań, częstotliwości zapytań lub miksie obciążenia, jeśli analizuje się ją bez przepustowości i opóźnień.
Odczyty magazynu zapewniają kolejny bezpośredni sygnał. Spadek sugeruje, że więcej stron pozostaje wewnątrz Postgres, zamiast docierać do pageserverów. Databricks zgłosił około 5,3 razy mniej żądań GetPage w pierwszym przykładzie, na podstawie spadku z około 8 000 do 1 500 na sekundę.
Pomiary CPU mogą ujawnić korzyść wynikającą z ogromnych stron i unikniętej obsługi cache dyskowego. Niższe wykorzystanie CPU jest jednak najbardziej użyteczne, gdy towarzyszy mu stabilna lub rosnąca przepustowość. Spokojny okres może zmniejszyć zarówno użycie CPU, jak i liczbę ukończonych zadań, nie odzwierciedlając wzrostu efektywności.
Zespoły powinny również sprawdzić zachowanie podczas restartów i rozgrzewania. Planowane aktualizacje powodują restarty mocy obliczeniowej, choć Databricks twierdzi, że zwykle trwają one tylko kilka sekund. Testowanie ponownych prób połączeń i opóźnień ogonowych w tych okresach może ujawnić skutki operacyjne, których wykresy w stanie ustalonym nie pokazują.
Konkretnym przykładem jest aplikacja transakcyjna, której aktywne indeksy i często odczytywane wiersze zajmują dziesiątki gigabajtów. W poprzedniej konfiguracji tylko niewielka część mogła pozostawać w buforach współdzielonych. Wiele trafień schodziło do lokalnego cache NVMe mimo niewykorzystanego potencjału DRAM.
Po aktualizacji taki zestaw roboczy może niemal w całości zmieścić się w powiększonej puli buforów. Zespół powinien oczekiwać mniejszej liczby żądań do pamięci masowej, niższych opóźnień odczytu i mniejszego narzutu CPU. Jeśli te wskaźniki się nie zmienią, prawdopodobnie dominuje inne wąskie gardło.
Usługa agenta AI stanowi drugi scenariusz. Może przechowywać w Postgres stan rozmów, wyniki narzędzi, statusy zadań lub metadane wektorów. Gwałtowne, równoległe odczyty mogą skorzystać na pozostawaniu często ponownie używanych stron w pamięci, ale liczba połączeń i wzorce zapytań nadal określają obciążenie procesów backendowych.
Inżynierowie analizujący tego rodzaju zmianę potrzebują wspólnych dowodów, a nie odizolowanych zrzutów ekranu. Przeszukiwalna baza wiedzy dla zespołów inżynieryjnych może zachować warunki testów porównawczych, plany zapytań, migawki konfiguracji i obserwacje z wdrożenia do późniejszego porównania.
Ocena powinna obejmować także scenariusz awarii. Jeśli zestaw roboczy przekracza powiększony bufor współdzielony, stałe moce obliczeniowe nie mają już pośrodku poprzedniego lokalnego cache plików. Pomiar opóźnień podczas zimnych startów, dużych skanów i nagłych zmian zestawu roboczego pokaże, czy zdalne chybienia stają się bardziej widoczne.
Żaden z tych testów nie wymaga akceptowania ani odrzucania głównego twierdzenia firmy. Przekładają one proponowany mechanizm na obserwowalne sygnały. Jeśli więcej odczytów trafia do buforów współdzielonych, a CPU i opóźnienia ogonowe spadają przy porównywalnym obciążeniu, aktualizacja działa dla danego obciążenia.
Jeśli przepustowość pozostaje bez zmian, zespoły powinny przeanalizować oczekiwania na blokady, sieć aplikacji, plany zapytań, indeksy i presję zapisu, zanim przypiszą wynik Lakebase. Zmiana cache nie może wyeliminować każdego źródła opóźnień bazy danych.
Trzy sygnały zdecydują, czy przeprojektowanie cache ma znaczenie
Dostarczenie autoskalowania, niezależne dowody z obciążeń i postępy w nadrzędnym projekcie PostgreSQL zadecydują, czy stanie się to szeroką przewagą Lakebase.
Pierwszym sygnałem będzie produkcyjne wydanie dynamicznych buforów współdzielonych dla mocy obliczeniowych z autoskalowaniem. Databricks musi pokazać, że pojemność buforów współdzielonych może rosnąć i maleć wraz z pamięcią, przy zachowaniu właściwego rozmiaru obsługi dużych stron. Wydanie z ujawnionymi kryteriami kwalifikacji, zachowaniem podczas wdrożenia i limitami operacyjnymi wzmocniłoby argumenty architektoniczne firmy.
Publikacji powinny towarzyszyć pomiary produkcyjne. Użyteczne porównanie nie polega na zestawieniu autoskalowania z niezwiązanym benchmarkiem stałej konfiguracji. Chodzi o to samo elastyczne obciążenie przed i po zastosowaniu dynamicznych buforów, z uwzględnieniem zdarzeń skalowania w górę i w dół, wskaźników trafień cache, użycia CPU oraz opóźnienia p99.
Jeśli autoskalowanie osiągnie porównywalną efektywność cache bez zakłócających restartów, obecna analiza stanie się mocniejsza. Pokazałoby to, że rozproszony Postgres może łączyć elastyczne zasoby obliczeniowe z dużym cache pamięciowym zarządzanym przez silnik. Długotrwałe opóźnienie pozostawiłoby najszybszą ścieżkę ograniczoną do stałej pojemności.
Drugim sygnałem będą szersze dowody z benchmarków. Databricks opublikował trzy korzystne przykłady produkcyjne, lecz użytkownicy potrzebują wyników dla różnych rozmiarów zestawów roboczych i wzorców zapytań. Niezależne testy powinny uwzględniać transakcje z przewagą odczytów, mieszane odczyty i zapisy, dużą liczbę połączeń, zimne starty oraz obciążenia większe niż dostępna pamięć DRAM.
Dowody na konsekwentne zyski wsparłyby deklarowany mechanizm. Silnie zmienne wyniki nie unieważniłyby wydania, ale zawęziłyby grupę aplikacji, które prawdopodobnie odniosą korzyści. Regresja przy chybieniach cache wymagałaby dokładniejszej uwagi po usunięciu lokalnej warstwy dyskowej.
Trzecim sygnałem będzie widoczny postęp w otwartoźródłowym PostgreSQL. Databricks twierdzi, że planuje współpracować z projektem nadrzędnym nad dynamicznymi buforami współdzielonymi. Konkretne propozycje, poprawki, dyskusje techniczne i opinie recenzentów pokażą, jaka część rozwiązania powinna trafić do samego Postgres.
Akceptacja przez projekt nadrzędny zapewniłaby projektowi szerszą kontrolę techniczną i uczyniła go użytecznym poza jednym dostawcą. Mogłaby też zmniejszyć długoterminową lukę między elastycznymi środowiskami chmurowymi a ustawieniami Postgres projektowanymi wokół stałej maszyny.
Brak przeniesienia tej pracy do projektu nadrzędnego nie uniemożliwiłby Databricks dostarczenia implementacji specyficznej dla platformy. Utrudniłby jednak zewnętrznym obserwatorom ocenę kompatybilności, utrzymania i przenośności.
Ulepszenie cache obliczeniowego Lakebase Postgres już przynosi mierzalne wyniki na wybranych stałych konfiguracjach obliczeniowych. Ważniejszym testem będzie to, czy Databricks zdoła uczynić cache dynamicznym bez osłabiania elastyczności zapewnianej przez separację pamięci masowej.
Dla zespołów korzystających z kwalifikujących się endpointów kolejny krok jest prosty: zweryfikować ustawienia, uchwycić stabilny punkt odniesienia i porównać metryki rzeczywistego obciążenia po wdrożeniu. Użytkownicy autoskalowania powinni poczekać na drugie wydanie inżynieryjne, zanim założą, że dotyczą ich te same korzyści. Co ma dziś większe znaczenie dla Twojej aplikacji: wydajność przy stałej pamięci czy swoboda skalowania pojemności wraz z popytem?
