, najnowsza wersja "najlepszej na świecie relacyjnej bazy danych z otwartym źródłem", zostanie wydana za kilka tygodni (jeśli wszystko pójdzie zgodnie z planem). To pasuje do standardowego harmonogramu — nowa wersja z mnóstwem nowych funkcji wydawana jest raz w roku, a szczerze mówiąc, to robi wrażenie. Dlatego stałem się aktywnym członkiem społeczności PostgreSQL.
Moim zdaniem, w odróżnieniu od poprzednich wydań, PostgreSQL 12 nie zawiera jednej czy dwóch rewolucyjnych funkcji (jak na przykład partycjonowanie czy równoległość zapytań). Żartowałem, że główną zaletą PostgreSQL 12 jest większa stabilność. A czy nie tego potrzebujesz, gdy zarządzasz krytycznymi danymi swojego biznesu?
Jednak PostgreSQL 12 na tym się nie kończy: nowe możliwości i udoskonalenia sprawią, że aplikacje będą działać lepiej, a od Ciebie wystarczy jedynie wykonać aktualizację!
(Cóż, może jeszcze przebudować indeksy, ale w tej wersji nie jest to takie straszne, jak się przyzwyczailiśmy.)
Będzie super — zaktualizować PostgreSQL i od razu cieszyć się znacznymi poprawami bez zbędnych działań. Kilka lat temu analizowałem aktualizację z PostgreSQL 9.4 do PostgreSQL 10 i zauważyłem, jak zwiększyła się wydajność aplikacji dzięki lepszemu paralelizmowi zapytań w PostgreSQL 10. I co najważniejsze, niemal niczego ode mnie nie wymagano (tylko ustawienie parametru konfiguracyjnego) max_parallel_workers).
Zgódź się, że to wygodne, gdy aplikacje działają lepiej tuż po aktualizacji. Bardzo staramy się zadowolić użytkowników, ponieważ PostgreSQL ma ich coraz więcej.
A jak zwykła aktualizacja do PostgreSQL 12 uczyni cię szczęśliwym? Już opowiem.
Poważne udoskonalenia w indeksowaniu
Bez indeksowania baza danych daleko nie zajdzie. Jak inaczej szybko znajdować informacje? Fundamentalny system indeksowania PostgreSQL nazywa się . Ten typ indeksu jest zoptymalizowany dla systemów przechowywania.
Po prostu używamy operatora CREATE INDEX ON some_table (some_column), a PostgreSQL wykonuje dużą część pracy, aby utrzymać indeks aktualny, podczas gdy my ciągle wstawiamy, aktualizujemy i usuwamy wartości. Wszystko działa samo z siebie, jak za pomocą magii.
Jednak indeksy PostgreSQL mają jeden problem — są i zajmują dodatkowe miejsce na dysku, a wydajność pobierania i aktualizacji danych jest obniżona. Przez 'przerost' rozumiem nieefektywne zarządzanie strukturą indeksu. Może to być — a może i nie być — związane z usuniętymi krotkami, które obsługuje (dzięki za informację dla Petera Geoghegana ()). Przerost indeksu jest szczególnie widoczny w obciążeniach roboczych, gdzie indeks jest aktywnie zmieniany.
PostgreSQL 12 poważnie poprawia działanie indeksów B-drzew i eksperymenty z testami typu TPC-C wykazały, że wykorzystanie miejsca jest średnio o 40% mniejsze. Teraz spędzamy mniej czasu nie tylko na konserwacji indeksów B-drzew (czyli operacjach zapisu), ale również na pobieraniu danych, ponieważ indeksy stały się znacznie mniejsze.
Aplikacje aktywnie aktualizujące swoje tabele — zazwyczaj są to aplikacje OLTP () — będą znacznie efektywniej wykorzystywać dysk i przetwarzać zapytania. Im więcej miejsca na dysku, tym więcej przestrzeni ma baza danych na rozwój bez aktualizacji infrastruktury.
Niektóre strategie aktualizacji wymagają przebudowy indeksów drzewa B, aby skorzystać z tych zalet (na przykład, nie dokonuje automatycznej przebudowy indeksów). W poprzednich wersjach PostgreSQL przebudowa dużych indeksów w tabelach prowadziła do znacznych przestojów, ponieważ w tym czasie nie można było wprowadzać zmian. Jednak w PostgreSQL 12 jest jeszcze jedna niesamowita funkcja: teraz można przebudować indeksy równolegle za pomocą komendy , aby całkowicie uniknąć przestojów.
W PostgreSQL 12 są także inne ulepszenia infrastruktury indeksowania. Jeszcze jedna rzecz, w której nie zabrakło magii, to , znany jako WAL (write-ahead log). Dziennik zapisu wstępnego zapisuje każdą transakcję w PostgreSQL na wypadek awarii i replikacji. Aplikacje wykorzystują go do archiwizacji i . Oczywiście, dziennik zapisu wstępnego jest zapisywany na dysku, co może wpłynąć na wydajność.
W PostgreSQL 12 zredukowano koszty zapisów WAL generowanych przez indeksy GiST, GIN i SP-GiST podczas tworzenia indeksu. Przynosi to kilka zauważalnych korzyści: zapisy WAL zajmują mniej miejsca na dysku, a dane szybciej się odtwarzają, na przykład podczas przywracania po awarii lub przywracania do określonego momentu. Jeśli w swoich aplikacjach korzystasz z takich indeksów (na przykład aplikacje geoprzetwarzające oparte na PostGIS często używają indeksu GiST), to dodatkowa funkcja, która znacznie poprawi działanie bez żadnego wysiłku z Twojej strony.
Partycjonowanie — więcej, lepiej, szybciej
W PostgreSQL 10 wprowadzono . W PostgreSQL 11 jego użycie stało się znacznie łatwiejsze. W PostgreSQL 12 można zmieniać skalę sekcji.
W PostgreSQL 12 wydajność systemu partycjonowania znacząco się poprawiła, szczególnie gdy w tabeli znajduje się tysiące partycji. Na przykład, jeśli zapytanie dotyczy tylko kilku partycji w tabeli, gdzie jest ich tysiące, jego wykonanie będzie znacznie szybsze. Wydajność została poprawiona nie tylko dla tego typu zapytań. Ponadto zauważysz, jak przyspieszyły operacje INSERT w tabelach z wieloma partycjami.
Wprowadzanie danych za pomocą — nawiasem mówiąc, to doskonały sposób a oto przykład — w tabelach partycjonowanych w PostgreSQL 12 również stało się bardziej efektywne. Z COPY wszystko było już szybkie, a w PostgreSQL 12 działa jak szalony.
Dzięki tym zaletom w PostgreSQL można przechowywać jeszcze większe zbiory danych, a ich wydobywanie stało się łatwiejsze. I nie wymaga to żadnego wysiłku z twojej strony. Jeśli twoja aplikacja ma wiele partycji, na przykład zapisuje dane szeregów czasowych, prosty upgrade znacznie poprawi jej wydajność.
Choć to poprawienie nie jest typowym 'ulepszeniem', w PostgreSQL 12 można tworzyć klucze obce, które odwołują się do tabel partycjonowanych, co sprawia, że praca z partycjonowaniem staje się przyjemnością.
Zapytania WITH stały się znacznie lepsze.
Kiedy (zwanych również CTE, czyli zapytaniami WITH), nie mogłem się doczekać, aby napisać artykuł na temat To jedna z tych funkcji, które przyspieszą aplikację. Oczywiście, jeśli używasz CTE.
Często zauważam, że nowicjusze w SQL lubią korzystać z CTE: jeśli napiszesz je w określony sposób, odczuwa się, że piszesz program imperatywny. Osobiście lubiłem przepisywać te zapytania, aby obejść się bez CTE i zwiększyć wydajność. Teraz wszystko jest inaczej.
PostgreSQL 12 pozwala na wbudowanie określonego rodzaju CTE bez efektów ubocznych (SELECT), który jest używany tylko raz bliżej końca zapytania. Gdybym prowadził statystyki zapytań z CTE, które przerabiałem, większość z nich znalazłaby się w tej kategorii. Pomaga to programistom pisać zrozumiały kod, który teraz działa szybko.
Co więcej, PostgreSQL 12 optymalizuje wykonywanie SQL samodzielnie, nie musisz nic robić. I chociaż prawdopodobnie nie będę musiał już optymalizować takich zapytań, miło, że PostgreSQL kontynuuje pracę nad optymalizacją zapytań.
Just-in-Time (JIT) — teraz domyślnie
W systemach PostgreSQL 12 z obsługą Kompilacja JIT jest włączona domyślnie. Po pierwsze, zyskujesz wsparcie dla niektórych wewnętrznych operacji, a po drugie, zapytania z wyrażeniami (najprostszy przykład — x + y) w listach wyboru (które masz po SELECT), agregatach, wyrażeniach w klauzulach WHERE i innych mogą korzystać z JIT w celu zwiększenia wydajności.
Kiedy JIT jest domyślnie włączony w PostgreSQL 12, wydajność poprawi się sama, ale zalecam przetestowanie aplikacji w PostgreSQL 11, gdzie JIT dopiero się pojawił, aby zmierzyć wydajność zapytań i dowiedzieć się, czy potrzebne są jakiekolwiek ustawienia.
A co z pozostałymi nowymi funkcjami PostgreSQL 12?
W PostgreSQL 12 jest mnóstwo nowych, ciekawych funkcji — od możliwości pracy z danymi JSON za pomocą standardowych wyrażeń SQL/JSON, po wieloskładnikową autoryzację z parametrem clientcert=verify-full, kolumny wirtualne i wiele więcej. To materiał na osobny wpis.
Podobnie jak PostgreSQL 10, PostgreSQL 12 poprawi ogólną wydajność zaraz po aktualizacji. Oczywiście możesz mieć swoją metodę — przetestuj aplikację w podobnych warunkach w środowisku produkcyjnym przed włączeniem ulepszeń, tak jak ja zrobiłem z PostgreSQL 10. Nawet jeśli PostgreSQL 12 jest już teraz stabilniejszy, niż się spodziewałem, nie zapomnij starannie przetestować aplikacji, zanim wprowadzisz je do produkcji.
Źródło: habr.com
