Postgres

PostgreSQL – okrągła, 10. wersja

Bez większego wahania można stwierdzić, że ostatni kwartał 2017 roku w świecie baz danych będzie należał do PostgreSQL 10, ponieważ ilość (i jakość) zmian, jaką wnosi to wydanie, naprawdę robi wrażenie. Nadmienić trzeba, że są to zmiany w stylu typowym dla Postgresa, polegające na ciągłej i stabilnej ewolucji narzędzia.

Bez większego wahania można stwierdzić, że ostatni kwartał 2017 roku w świecie baz danych będzie należał do PostgreSQL 10. Ilość (i jakość) zmian, jaką wnosi to wydanie, naprawdę robi wrażenie. Nadmienić trzeba, że są to zmiany w stylu typowym dla Postgresa, polegające na ciągłej i stabilnej ewolucji narzędzia.

Okiem administratora

Z punktu widzenia administratora bazy na pierwszy plan wysuwają się funkcjonalności związane z replikacją. Począwszy od wersji 9.4, wdrażane były zmiany mające nas przybliżyć do replikacji logicznej, a w konsekwencji do multimaster. Wersja ta wprowadzała logical decoding, czyli proces przetworzenia po stronie repliki informacji zawartej w pliku WAL, na przykład na polecenie SQL. W bieżącej wersji dotarliśmy do momentu, w którym możemy replikować pojedyncze tabele z różnych baz (nawet z różnych wersji silników), aby przykładowo, stworzyć osobną bazę dla celów analitycznych.

PostgreSQL był niemal od zawsze jednym z najbezpieczniejszych RDBMS, a przede wszystkim dbającym o bezpieczeństwo w różnych obszarach. W wersji 10. umożliwia uwierzytelnienia za pomocą metody SCRAM, wypierając jednocześnie utworzenie użytkownika z hasłem przechowywanym w niezaszyfrowanej formie. Otrzymujemy także wsparcie dla wielu serwerów RADIUSa, co w połączeniu z innymi metodami – LDAP, GSSAPI z Kerberos, SSPI dla Windows, SSL, PAM, BSD tworzy pełen wachlarz możliwości. Bonus – wszystkie zdefiniowane w pliku pg_hba.conf metody możemy podejrzeć z konsoli za pomocą nowego widoku systemowego pg_hba_file_rules.

Zmiany w modułach

Cieszą także zmiany, jakie dotknęły dodatkowe moduły postgresa – na przykład postgres_fdw. Jest rozszerzeniem ze standardu SQL/MED umożliwiające dostęp do baz przechowywanych na innych serwerach, często używane do migracji danych między różnymi aplikacjami. W pracach do bieżącej wersji skupiono się na optymalizacji wykonywania funkcji agregujących na mapowanych tabelach – doniesienia mówią o 80% wzroście wydajności.

W zasadzie marginalną modyfikacją jest zmiana katalogów pg_xlog i pg_clog na odpowiednio pg_wal i pg_xact. Jak twierdzą autorzy, administratorzy często zakładali, że znajdują się tam logi tekstowe i z chęci zwolnienia powierzchni dyskowej – usuwali je. W ramach konsekwencji nazewniczej wszystkie funkcje, narzędzia i opcje, które w nazwie zawierały „xlog”, teraz zawierają „wal”. Warto jednak pamiętać o tej zmianie, ponieważ po migracji trzeba zadbać także o narzędzia monitorujące.

Z myślą o kontroli bieżącego działania serwera pojawiła się kolejna domyślna rola pg_monitor. Z domyślnymi rolami zostaliśmy zaznajomieni już w wersji 9.6. Są to predefiniowane zestawy uprawnień (ROLE NOLOGIN). które można nadać utworzonemu użytkownikowi za pomocą polecenia GRANT. pg_monitor nie jest jednak mało uprzywilejowaną rolą – jest zdolna do terminowania sesji innych użytkowników.

Nie dziwi, że jest tak niewiele graficznych narzędzi do zarządzania PostgreSQL, gdy wiersz poleceń posiada tak wiele, ciągle rozwijanych funkcji. Czymś długo wyczekiwanym w wersji 10. psql są meta-polecenia do obsługi instrukcji warunkowych (trzeba przyznać, że bardzo tego brakowało).

Okiem programisty

Dla programistów dużym krokiem naprzód jest wdrożenie natywnego partycjonowania tabel. Wcześniej rozwiązanie to wymagało rozbudowanego systemu triggerów, stosunkowo trudnego do implementacji i utrzymania. Wersja 10. wdraża na poziomie tworzenia tabeli konstrukcje PARTITION BY {RANGE | LIST}. W tym obszarze jest jeszcze sporo pracy związanej z redukcją ograniczeń i optymalizacją. Jednak już widoczna jest zwiększona wydajność polecenia INSERT.

Obsługa triggerów AFTER staje się łatwiejsza dzięki transition tables – tabelom przejściowym, za pomocą których można odwołać się do wszystkich rekordów modyfikowanych za pomocą zapytania (także wówczas, gdy trigger uruchamia się w trybie EACH STATMENT).

Wersja 9.3 wprowadziła wbudowany typ danych json oraz podstawowe funkcje i operatory. Każde kolejne wydanie poszerzało ten zestaw oraz poprawiało istniejące elementy. Nie inaczej rzecz ma się w PostgreSQL 10 – json i jsonb otrzymały wsparcie pełnotekstowego wyszukiwania.

Podsumowanie

Powyższy artykuł jest listą najbardziej inspirujących, w opinii autora, funkcjonalności (nie jest to ani pełna lista, ani lista rzeczy najważniejszych), ponieważ zmian ciekawych i „na lepsze” jest dużo więcej. Artykuł ten jest także wstępem do serii kolejnych, podchodzących już bardziej szczegółowo do wybranych zagadnień.

Źródła:
https://www.postgresql.org/docs/current/static/release-10.html
https://www.depesz.com/tag/pg10/
https://postgrespro.ru/media/2017/10/05/postgres-10-hse-2017.pdf
https://wiki.postgresql.org/wiki/Multimaster

Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.