Ocena bazy danych: co pokazują testy poprawności

Ocenę bazy danych zacznij od reguł biznesowych i wyników, które potwierdzają, że wybrana baza potrafi ich przestrzegać. Oddzielnie sprawdź zgodność z klientami, działanie SQL, transakcje współbieżne i trwałość danych.

Zanim powierzysz jej dane rozstrzygające o stanie systemu, zapisz dokładną kompilację, ustawienia, wyniki i braki w weryfikacji.

Dobrym punktem wyjścia jest analiza ParticleDB opublikowana przez Jepsen 31 października. Badanie sfinansowane przez Orkes obejmowało działanie pojedynczego węzła w wersjach od 1.1.4 do 1.1.18.11.rc-22 i opisywało 96 problemów.

W ostatniej testowanej kompilacji wszystkie poza dziesięcioma wydawały się już usunięte. Jepsen przytacza deklarację Orkes o poprawkach w nowszej wersji 1.1.19-rc.13, a wpis Orkes z 30 października mówi o wersji 1.1.19. Opublikowane testy Jepsen nie obejmowały tych nowszych kompilacji.

Przy własnej ocenie ustal przede wszystkim, co dany wynik potwierdza w odniesieniu do potrzeb twojego systemu. Poniżej proponujemy sposób takiej oceny. Nie opisujemy testów bazy, które sami przeprowadziliśmy.

Zacznij od reguły biznesowej

Wybierz warunek, który musi pozostać spełniony także wtedy, gdy żądania nakładają się na siebie albo proces przestaje działać. To punkt wyjścia, często nazywany niezmiennikiem. W systemie rezerwacji liczba potwierdzonych miejsc nie może przekroczyć dostępnej puli.

W księdze finansowej przelew nie może pozostawić tylko jednego z dwóch zapisów. Sięgnij po reguły własnego oprogramowania i uwzględnij to, co użytkownik może zobaczyć po powodzeniu lub niepowodzeniu operacji.

Zapisz też, co pilnuje każdej reguły: ograniczenie w bazie, transakcja, kod programu czy zewnętrzny system. Baza nie zachowa zasady, której nie uwzględnia implementacja. Taka rozpiska ułatwi też ustalenie przyczyny błędu bez automatycznego obwiniania silnika bazy.

Zbieraj osobne wyniki dla każdej warstwy

Zaplanuj ocenę według poniższej tabeli. Każdy wiersz dotyczy innego pytania, więc pozytywny wynik w jednym nie rozstrzyga pozostałych.

Przy każdym wyniku zachowaj stan początkowy, wykonane operacje, oczekiwany rezultat i to, co rzeczywiście nastąpiło. Logi lub historia transakcji powinny pozwolić innej osobie sprawdzić twoją interpretację. Zielony panel niewiele wyjaśnia, jeśli nie wiadomo, co obejmował zestaw testów.

Sprawdź zgodność z PostgreSQL na własnym oprogramowaniu

Rozpisz zgodność na konkretne wymagania. Dokumentacja protokołu PostgreSQL opisuje komunikaty wymieniane między klientem a serwerem. Samo połączenie przez ten protokół potwierdza tylko część tego, czego potrzebuje twój system. Sprawdź operacje sterownika, z których rzeczywiście będziesz korzystać, a następnie funkcje SQL, na których się opierają.

Uwzględnij ograniczenia, wartości null, graniczne wartości liczbowe i obsługę błędów tam, gdzie wpływają na reguły biznesowe. Uruchom rzeczywiste zapytania swojego programu, także te używane rzadziej, choćby przy eksporcie administracyjnym.

Przed porównaniem wyników z PostgreSQL ustal dopuszczalne różnice. Wiersze bez zadanej kolejności sortowania nie muszą przychodzić w tej samej kolejności. Precyzja liczb, moment sprawdzania ograniczeń i kolejność zgłaszania błędów wymagają osobnych ustaleń. Oceniaj różnicę względem udokumentowanych gwarancji i potrzeb systemu, zamiast uznawać każdą rozbieżność za błąd.

Prześledź regułę limitu miejsc

Załóżmy hipotetyczne warsztaty z 30 miejscami i 29 potwierdzonymi rezerwacjami. Każda transakcja zlicza potwierdzone rezerwacje, dodaje następną tylko wtedy, gdy są jeszcze miejsca, a potem się zatwierdza. To wymyślony przykład; nie uruchamialiśmy go w żadnej bazie.

Zaplanuj próbę z dwoma osobnymi klientami:

1. Uruchom obie transakcje jednocześnie. Jeśli obie mogą odczytać liczbę 29, zanim którakolwiek doda rezerwację, zachowaj tę historię. Jeśli silnik wcześniej blokuje dostęp i wymusza wykonanie operacji po kolei, też to odnotuj.
2. Pozwól obu transakcjom spróbować warunkowego dodania rezerwacji i zatwierdzenia. Osobno zapisz wyniki instrukcji, potwierdzenia COMMIT i błędy.
3. Odczytaj ostateczny stan z bazy stanowiącej główne źródło danych przez nowe połączenie i sprawdź limit miejsc.
4. Jeśli transakcja kończy się błędem serializacji, ponów ją w całości: odczyt, sprawdzenie warunku i zapis. Zanotuj wynik ponownego podejścia.

Przy izolacji szeregowalnej wynik zatwierdzonych transakcji współbieżnych musi odpowiadać jakiemuś wykonaniu ich po kolei.

Dla opisanej logiki dwie nowe rezerwacje, które zwiększą liczbę potwierdzeń do 31, naruszałyby tę gwarancję. Jedna transakcja może zamiast tego zakończyć się błędem, a po ponowieniu stwierdzić, że nie ma już miejsc.

Dokumentacja izolacji w PostgreSQL wyjaśnia szeregowalność i konieczność ponawiania całych transakcji. Wskazuje też, że poziom Repeatable Read dopuszcza anomalie serializacji. Jeśli wybierzesz słabszy poziom, który pozwala na taki przebieg, przekroczenie limitu oznacza niedopasowanie logiki programu do gwarancji bazy. Samo w sobie nie dowodzi błędu silnika.

Przekroczenie czasu oczekiwania po stronie klienta zapisz jako osobny rodzaj wyniku. Gdy połączenie urwie się w okolicy zatwierdzania, klient może nie wiedzieć, czy rezerwacja została zapisana.

Zanim ponowisz operację biznesową, wyjaśnij jej stan przy użyciu stałego identyfikatora operacji. W tym rozwiązaniu identyfikator zapisz atomowo razem z rezerwacją, wymuś jego unikalność i używaj go ponownie przy kolejnych próbach. Chwilowy brak rekordu nie dowodzi wycofania transakcji, przy której klient przekroczył czas oczekiwania. Sam poziom izolacji w bazie nie zapobiegnie wysłaniu przez twój program dwóch potwierdzeń e-mail ani dwukrotnemu pobraniu płatności.

Określ, jakie awarie obejmuje gwarancja trwałości

Sprawdź, co gwarantuje baza po potwierdzeniu COMMIT przy ustawieniach, które chcesz wdrożyć. Dopiero do tej gwarancji dobierz testy. Konkretny przykład zawiera dokumentacja zatwierdzania asynchronicznego w PostgreSQL. W takiej konfiguracji baza może potwierdzić transakcje, które później zginą wskutek awarii. To udokumentowany kompromis, a nie niedotrzymanie gwarancji wynikającej z wybranych ustawień.

W odizolowanym środowisku testowym zapisz identyfikatory potwierdzonych operacji, wywołaj wybraną awarię i porównaj odzyskane rekordy. Osobno oznacz operacje o niepewnym wyniku i potwierdzone zatwierdzenia. Zatrzymanie procesu serwera nie odtwarza utraty zasilania nośników, a restart jednego węzła nie sprawdza przełączenia na replikę. Dokumentacja niezawodności PostgreSQL wyjaśnia, dlaczego znaczenie ma także sposób działania całej warstwy przechowywania danych.

Dobierz wyniki do planowanego wdrożenia. Jeśli potrzebujesz przełączenia do innego regionu po awarii, pomyślny restart lokalny nadal nie odpowiada na to wymaganie.

Oddziel deklarację poprawki od wyniku ponownego testu

Deklaracja dostawcy, że usunął problem, to przydatna informacja. Zapisz, od kogo pochodzi i której wersji dotyczy, a następnie zachowaj ją obok wcześniejszego wyniku do czasu ponownej weryfikacji wymaganego zachowania.

Odnotuj, który przykład odtwarzający błąd uruchomiono ponownie, czy sprawdzono też szerszy zestaw operacji i czy zmieniła się kompilacja lub konfiguracja. Rozróżniaj stany takie jak zaobserwowano poprawne działanie, zaobserwowano błąd, dostawca deklaruje poprawkę, potrzebny ponowny test i nie sprawdzono.

Pozytywny wynik jednego przykładu nie dowodzi, że obejmuje on wszystkie powiązane przypadki. Pozytywny wynik większego zestawu testów też nie dowodzi poprawności w każdych warunkach.

Brak wyników musi wpływać na decyzję. Załóżmy, że oceniana baza przechodzi testy SQL, ale nie masz danych o zachowaniu potwierdzonych zapisów podczas przełączania po awarii w potrzebnej konfiguracji. Jeśli to wymaganie obowiązkowe, nadal zapisuj rezerwacje w dotychczasowej bazie, która pozostaje głównym źródłem tych danych. Nową możesz nadal oceniać jako odbudowywalny indeks wyszukiwania, z osobnymi wymaganiami. Nie ukrywaj nierozstrzygniętego warunku w uśrednionej ocenie i nie zatwierdzaj na tej podstawie obu zastosowań.

Zapisz decyzję tak, żeby inna osoba mogła ją sprawdzić

Na koniec zanotuj planowane zastosowanie, wymagane gwarancje, dokładnie oceniane wdrożenie, odnośniki do wyników i nierozstrzygnięte wymagania. Wskaż, kto akceptuje każde pozostałe ryzyko i jakie nowe wyniki zmieniłyby decyzję. Wyniki wydajności zapisuj dla tej samej konfiguracji, żeby porównania szybkości nadal miały sens.

Gdy zatwierdzisz już zmianę bazy, nasz artykuł o migracji z Deno Deploy opisuje osobny etap: testowanie docelowego środowiska i przygotowanie przełączenia. Tutaj decyzja zapada wcześniej: czy zebrane wyniki wystarczają, by powierzyć tej bazie konkretną rolę w twoim systemie? Zacznij od reguły, której nie możesz naruszyć, i podejmij decyzję dopiero wtedy, gdy masz wyniki potwierdzające wymagane zachowanie.