PostgreSQL 13 – szczęśliwa liczba w świecie Postgresa

PostgreSQL 13

Wielu ludzi cierpi na irracjonalny lęk przed liczbą 13, co fachowo określa się mianem triskaidekafobii. W przypadku szykującego się najnowszego wydania PostgreSQL, opatrzonego właśnie tą liczbą, obawy są jednak bezzasadne. Niemal każdy będzie mógł w nim znaleźć zmiany poprawiające wykorzystywane na co dzień aspekty Postgresa.

Przejrzyjmy zatem dostępną notkę dotyczącą wydania 13 beta 3 i spróbujmy „odczarować” pozorną pechowość tego akurat wydania. Pierwszą rzucającą się w oczy sprawą jest ogrom pracy włożony w to wydanie. Nie ma chyba podsystemów, na których polega wiele produkcyjnych wdrożeń, których to wydanie w jakiś sposób by nie dopieszczało.

Kilka ostatnich głównych wydań to duże zmiany w świecie PostgreSQL. Każde z nich przyniosło ogrom zmian i nowych funkcji jak na przykład partycjonowanie, natywna replikacja logiczna czy wsparcie dla typu JSON. W przypadku tego wydania sprawy mają się jednak inaczej i otrzymamy w nim poprawki dla już istniejących funkcji. Co nie znaczy, że nie mamy się czym ekscytować!

Mniejsze indeksy

Pierwszym ulepszeniem, które zdecydowanie przyda się wszystkim użytkownikom Postgresa, jest zmiana w wielkości standardowych indeksów opartych o B-drzewa. Ten typ indeksu jest najczęściej wykorzystywany, ponieważ to właśnie on zostanie utworzony po wykonaniu polecenia CREATE INDEX. Zmniejszenie jego rozmiaru zdecydowanie cieszy, szczególnie że wraz z mniejszym rozmiarem można również spodziewać się szybszego dostępu do przechowywanych w nim informacji. Poprawka w wielkości indeksów głównie odnosi się do zmian w wykrywaniu zduplikowanych wartości (można o tym poczytać w dokumentacji implementacji B-drzew w Postgresie).

Jak to wygląda w praktyce? Korzystając z poniższego dość „zabawkowego” przykładu, możemy pokazać, jak zmiana pomiędzy głównymi wersjami może mieć wpływ na zajętość produkcyjnych dysków.

--- Przykładowa tablica
CREATE TABLE index_test(id int PRIMARY KEY, value int);
CREATE INDEX ON index_test (value);

--- Dodanie danych do tablicy
INSERT INTO index_test
    SELECT i, i % 12345
    FROM generate_series(1,1000000) i;

W przypadku wersji 12 wielkość indeksu, w którym znajdują się zduplikowane dane, prezentuje się następująco:

--- Wynik dla wersji 12
postgres=# select pg_size_pretty(pg_relation_size('index_test_pkey'));
 pg_size_pretty
----------------
 21 MB
(1 row)

Natomiast dla wersji 13 widać ogromny spadek wielkości:

postgres=# select pg_size_pretty(pg_relation_size('index_test_value_idx'));
 pg_size_pretty
----------------
 8664 kB
(1 row)

Jak wygląda porównanie wydajności? Od razu warto zaznaczyć, że tworzenie poprawnych testów tego typu to nietrywialne zadanie. Wydajność zależy od ogromnej ilości czynników, o niekoniecznie ortogonalnych czy nawet linearnych relacjach. Poniżej podajemy więc nasze wyniki, raczej jako anecdata niż twarde dane 😉

Skorzystaliśmy z poniższego zapytania:

EXPLAIN ANALYZE
SELECT count(*)
FROM index_test
WHERE value = 42;

Poniżej plan zapytania dla wersji 12:

                                                             QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=297.39..297.40 rows=1 width=8) (actual time=0.433..0.434 rows=1 loops=1)
   ->  Bitmap Heap Scan on index_test  (cost=5.05..297.19 rows=81 width=0) (actual time=0.118..0.394 rows=81 loops=1)
         Recheck Cond: (value = 42)
         Heap Blocks: exact=81
         ->  Bitmap Index Scan on index_test_value_idx  (cost=0.00..5.03 rows=81 width=0) (actual time=0.036..0.036 rows=81 loops=1)
               Index Cond: (value = 42)
 Planning Time: 0.490 ms
 Execution Time: 0.509 ms

Oraz dla wersji 13:

                                                                  QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------- ------
 Aggregate  (cost=6.04..6.05 rows=1 width=8) (actual time=0.059..0.060 rows=1 loops=1)
   ->  Index Only Scan using index_test_value_idx on index_test  (cost=0.42..5.84 rows=81 width=0) (actual time=0.046..0.052 rows=81 loops=1)
         Index Cond: (value = 42)
         Heap Fetches: 0
 Planning Time: 0.237 ms
 Execution Time: 0.082 ms

Jak widać, nawet tak podstawowe elementy bazy danych jak indeksy mogą wiele zyskać przy wprowadzeniu odpowiednich poprawek przez społeczność Open Source. W przypadku upgrade'u z poprzednich wersji, aby skorzystać z tej zmiany, trzeba będzie dokonać przebudowania indeksu. Na szczęście poprzednie 12 wydanie PostgreSQL dodało możliwość skorzystania z opcji REINDEX CONCURRENTLY. Nie trzeba więc przygotowywać okna serwisowego przez blokującą opcję REINDEX.

Nowe parametry ułatwiające monitorowanie

Monitorowanie działania bazy danych to jedna z podstawowych czynności administracyjnych. Jednym z nieprzebranych wręcz źródeł informacji są logi systemowe pozwalające na określenie stanu zdrowia bazy danych i wskazujące, gdzie kierować swoją uwagę w celu poprawienia jej wydajności. Jednym z narzędzi do analizy logów jest moduł EuroDB LogAnalyzer.

Aby najlepiej wykorzystać możliwości analizatora, należałoby zapisywać wszystkie zdarzenia w bazie danych. Nie jest to oczywiście możliwe w praktyce dla systemów produkcyjnych, ponieważ najwyższy poziom szczegółowości jest bardzo obciążający i powoduje obniżenie wydajności. Do czasu wersji 12 administratorzy mieli do wykorzystania parametr log_min_duration_statement powodujący zapisanie zapytania w logu, jeśli czas jego wykonania był dłuższy niż wartość graniczna. Pomagało to zidentyfikować pojedyncze długie zapytania. Jednak w dość oczywisty sposób powodowało to skupianie się jedynie na wycinku rzeczywistości, nie dając poglądu na system bazodanowy jako całość.

W wersji 12 pojawił się parametr log_transaction_sample_rate, dzięki czemu można określić, jaki procent ze wszystkich zapytań zostanie zapisany w logu. Pozwala to na zmitgowanie problemu obniżenia wydajności, jednocześnie dając ogląd na stan całej bazy danych. Trzynastka jednak rozwija ten pomysł i pozwala na dokładniejsze sterowanie logowaniem dzięki nowym parametrom konfiguracyjnym. Są to:

  • log_min_duration_sample – dodający możliwość logowania wolniejszych zapytań podobnie jak log_min_duration_statement
  • log_statement_sample_rate – kontrolujący próbkowanie dla powyższego parametru.

Dobranie odpowiednich wartości dla każdej aplikacji korzystającej z Postgresa mocno wykracza poza zakres tego artykułu. Warto jednak wspomnieć, że prawdopodobnie jedynie praktyczne testy pozwalają na znalezienia optymalnych ustawień.

Jak przetestować PostgreSQL 13?

W jaki sposób można przetestować niewydaną jeszcze wersję beta Postgresa 13? Twórcy bardzo ten proces ułatwiają, ponieważ udostępniają wydania beta w postaci pakietów m.in. dla Enterprise Linux. Mając zainstalowane repozytorium PGDG wystarczy wydać poniższe polecenie, aby zainstalować niewydaną jeszcze wersję trzynastą:

$ sudo yum install postgresql13 postgresql13-server \
    --enablerepo=pgdg-common-testing \
    --enablerepo=pgdg13-updates-testing

Dzięki niemu włączymy na czas instalacji repozytorium testowe i zainstalujemy wydanie beta wersji 13.

Kiedy zostanie wydany PostgreSQL 13?

Dotychczas większość głównych wydań PostgreSQL miało miejsce jesienią. Wydania poprawkowe (minor) pojawiają się z częstotliwością przynajmniej raz na kwartał. Dlaczego przynajmniej raz? W przypadku wykrycia jakichś poważnych błędów czy to bezpieczeństwa, czy też związanych z uszkodzeniem danych, zachodzi naturalna potrzeba stworzenia dodatkowego wydania będącego „łatą” na te problemy. W innych przypadkach w ten sposób osoby, które (z różnych względów) nie mogą skorzystać z najnowszego wydania, dalej mogą cieszyć się z poprawek, często wpływających na wydajność wykorzystywanej bazy.

W przypadku 13 głównego wydania Postgresa wszystko wskazuje na to, że nastąpi ono zgodnie z planami twórców, czyli pod koniec trzeciego kwartału 2020 r.

Podsumowanie

Jak widać, „trzynastka” to zdecydowanie szczęśliwa liczba w świecie Postgresa. Nie możemy doczekać się momentu opublikowania stabilnej wersji tego wydania. Mamy też nadzieję, że tym artykułem uda nam się przekonać do wypróbowania tej wersji PostgreSQL (gdy będzie już dostępna).

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *