Aktualizacja dla leniwych: jak PostgreSQL 12 poprawia wydajność

PostgreSQL 12, najnowsza wersja „najlepszej na świecie relacyjnej bazy danych typu open source” ukaże się za kilka tygodni (jeśli wszystko pójdzie zgodnie z planem). Jest to zgodne ze zwykłym harmonogramem wydawania nowej wersji z mnóstwem nowych funkcji raz w roku i szczerze mówiąc, robi to wrażenie. Dlatego zostałem aktywnym członkiem społeczności PostgreSQL.

Moim zdaniem, w przeciwieństwie do poprzednich wydań, PostgreSQL 12 nie zawiera ani jednej, ani dwóch rewolucyjnych funkcji (takich jak partycjonowanie czy równoległość zapytań). Kiedyś zażartowałem, że główną cechą PostgreSQL 12 jest większa stabilność. Czy nie tego właśnie potrzebujesz, zarządzając krytycznymi danymi swojej firmy?

Ale PostgreSQL 12 na tym się nie kończy: dzięki nowym funkcjom i ulepszeniom aplikacje będą działać lepiej, i wszystko, co musisz zrobić, to dokonać aktualizacji!

(No cóż, może odbuduj indeksy, ale w tym wydaniu nie jest to tak straszne, jak jesteśmy przyzwyczajeni.)

Wspaniale będzie zaktualizować PostgreSQL i od razu cieszyć się znaczącymi ulepszeniami bez niepotrzebnego zamieszania. Kilka lat temu przeglądałem aktualizację z PostgreSQL 9.4 do PostgreSQL 10 i zobaczyłem, jak aplikacja przyspieszyła dzięki ulepszonemu równoległości zapytań w PostgreSQL 10. I co najważniejsze, prawie nic nie było ode mnie wymagane (wystarczy ustawić parametr konfiguracyjny max_parallel_workers).

Zgadzam się, to wygodne, gdy aplikacje działają lepiej natychmiast po aktualizacji. Bardzo staramy się zadowolić użytkowników, ponieważ PostgreSQL ma ich coraz więcej.

Jak więc prosta aktualizacja do PostgreSQL 12 może cię uszczęśliwić? Powiem ci teraz.

Główne ulepszenia indeksowania

Bez indeksowania baza danych nie zajdzie daleko. Jak jeszcze możesz szybko znaleźć informacje? Podstawowy system indeksowania PostgreSQL nazywa się Drzewo B. Ten typ indeksu jest zoptymalizowany pod kątem systemów pamięci masowej.

Po prostu używamy operatora CREATE INDEX ON some_table (some_column), a PostgreSQL wykonuje dużo pracy, aby zapewnić aktualność indeksu, podczas gdy my stale wstawiamy, aktualizujemy i usuwamy wartości. Wszystko działa samoistnie, jak za dotknięciem czarodziejskiej różdżki.

Ale indeksy PostgreSQL mają jeden problem – one są napompowane i zajmują dodatkowe miejsce na dysku oraz zmniejszają wydajność pobierania i aktualizowania danych. Przez „wzdęcie” mam na myśli nieskuteczne utrzymanie struktury indeksu. Może to - ale nie musi - być powiązane z krotkami śmieci, które usuwa ODKURZAĆ (dzięki Peterowi Gaghanowi za informację)Petera Geoghegana)). Rozdęcie indeksu jest szczególnie zauważalne w przypadku obciążeń, w których indeks aktywnie się zmienia.

PostgreSQL 12 znacznie poprawia wydajność indeksów B-drzewa, a eksperymenty z benchmarkami takimi jak TPC-C wykazały, że obecnie wykorzystywane jest średnio 40% mniej miejsca. Teraz spędzamy mniej czasu nie tylko na utrzymaniu indeksów drzewa B (czyli na operacjach zapisu), ale także na pobieraniu danych, ponieważ indeksy są znacznie mniejsze.

Aplikacje, które aktywnie aktualizują swoje tabele — zazwyczaj aplikacje OLTP (przetwarzanie transakcji w czasie rzeczywistym) - będzie znacznie wydajniej wykorzystywać dysk i przetwarzać żądania. Im więcej miejsca na dysku, tym więcej miejsca musi powiększyć baza danych bez konieczności modernizacji infrastruktury.

Niektóre strategie aktualizacji wymagają przebudowy indeksów drzewa B, aby skorzystać z tych korzyści (np. pg_upgrade nie odbuduje indeksów automatycznie). W poprzednich wersjach PostgreSQL odbudowa dużych indeksów w tabelach powodowała znaczne przestoje, ponieważ w międzyczasie nie można było wprowadzić zmian. Ale PostgreSQL 12 ma jeszcze jedną fajną funkcję: teraz możesz odbudowywać indeksy równolegle z poleceniem REINDEKSUJ RÓWNOCZEŚNIEaby całkowicie uniknąć przestojów.

Istnieją inne ulepszenia infrastruktury indeksowania w PostgreSQL 12. Kolejna rzecz, w której była trochę magii - dziennik zapisu z wyprzedzeniem, czyli WAL (dziennik zapisu z wyprzedzeniem). Dziennik zapisu z wyprzedzeniem rejestruje każdą transakcję w PostgreSQL w przypadku awarii i replikacji. Aplikacje używają go do archiwizacji i odzyskiwanie w określonym momencie. Oczywiście dziennik zapisu z wyprzedzeniem jest zapisywany na dysku, co może mieć wpływ na wydajność.

PostgreSQL 12 zmniejszył obciążenie rekordami WAL tworzonymi przez indeksy GiST, GIN i SP-GiST podczas konstruowania indeksu. Zapewnia to kilka wymiernych korzyści: rekordy WAL zajmują mniej miejsca na dysku, a dane są odtwarzane szybciej, na przykład podczas odzyskiwania po awarii lub odzyskiwania do określonego momentu. Jeśli używasz takich indeksów w swoich aplikacjach (na przykład aplikacje geoprzestrzenne oparte na PostGIS często korzystają z indeksu GiST), jest to kolejna funkcja, która znacznie poprawi doświadczenie bez żadnego wysiłku z Twojej strony.

Partycjonowanie - większe, lepsze, szybsze

Wprowadzono PostgreSQL 10 deklaratywny podział. W PostgreSQL 11 korzystanie z niego stało się znacznie łatwiejsze. W PostgreSQL 12 możesz zmienić skalę sekcji.

W PostgreSQL 12 wydajność systemu partycjonowania uległa znacznej poprawie, zwłaszcza jeśli w tabeli znajdują się tysiące partycji. Na przykład, jeśli zapytanie dotyczy tylko kilku partycji w tabeli zawierającej tysiące partycji, zostanie wykonane znacznie szybciej. Wydajność poprawia się nie tylko w przypadku tego typu zapytań. Zauważysz także, jak szybsze są operacje INSERT na tabelach z wieloma partycjami.

Rejestrowanie danych za pomocą KOPIA - swoją drogą, to świetny sposób zbiorcze pobieranie danych a oto przykład odbieranie JSON-a — partycjonowane tabele w PostgreSQL 12 również stały się bardziej wydajne. Z COPY wszystko było już szybkie, ale w PostgreSQL 12 to absolutnie leci.

Dzięki tym zaletom PostgreSQL umożliwia przechowywanie jeszcze większych zbiorów danych i ułatwia ich odzyskiwanie. I żadnego wysiłku z twojej strony. Jeśli aplikacja ma wiele partycji, np. rejestruje dane szeregów czasowych, prosta aktualizacja znacząco poprawi jej wydajność.

Chociaż nie jest to do końca ulepszenie typu „uaktualnij i ciesz się”, PostgreSQL 12 umożliwia tworzenie kluczy obcych odwołujących się do partycjonowanych tabel, dzięki czemu partycjonowanie jest przyjemnością.

Funkcja Z zapytaniami stała się znacznie lepsza

Kiedy zastosowano łatkę dla wbudowanych typowych wyrażeń tabelowych (aka CTE, czyli Z zapytaniami), nie mogłem się doczekać, aż napiszę artykuł na temat jak szczęśliwi byli twórcy aplikacji dzięki PostgreSQL. To jedna z tych funkcji, która przyspieszy aplikację. Chyba, że ​​używasz CTE.

Często stwierdzam, że nowicjusze w SQL uwielbiają używać współczynników CTE; jeśli napiszesz je w określony sposób, naprawdę poczujesz się, jakbyś pisał program imperatywny. Osobiście lubiłem przepisywać te zapytania, aby się poruszać без CTE i zwiększyć produktywność. Teraz wszystko jest inne.

PostgreSQL 12 pozwala na wstawienie określonego typu CTE bez skutków ubocznych (SELECT), który jest używany tylko raz pod koniec żądania. Gdybym śledził przepisane przeze mnie zapytania CTE, większość z nich należałaby do tej kategorii. Pomaga to programistom w pisaniu przejrzystego kodu, który teraz działa również szybko.

Co więcej, PostgreSQL 12 optymalizuje samo wykonanie SQL, bez konieczności wykonywania jakichkolwiek czynności przez Ciebie. I chociaż prawdopodobnie nie będę musiał teraz optymalizować takich zapytań, to wspaniale, że PostgreSQL nadal pracuje nad optymalizacją zapytań.

Just-in-Time (JIT) — teraz domyślnie

W systemach PostgreSQL 12 z obsługą LLVM Kompilacja JIT jest domyślnie włączona. Przede wszystkim otrzymujesz wsparcie JIT dla niektórych operacji wewnętrznych, a po drugie, zapytania z wyrażeniami (najprostszy przykład to x + y) na listach wyboru (które masz po SELECT), agregaty, wyrażenia z klauzulami WHERE i inne mogą używać JIT do poprawy wydajności.

Ponieważ JIT jest domyślnie włączony w PostgreSQL 12, wydajność poprawi się sama, ale zalecam przetestowanie aplikacji w PostgreSQL 11, w którym wprowadzono JIT, aby zmierzyć wydajność zapytań i sprawdzić, czy trzeba coś dostroić.

A co z resztą nowych funkcji w PostgreSQL 12?

PostgreSQL 12 ma mnóstwo nowych, ciekawych funkcji, od możliwości eksplorowania danych JSON przy użyciu standardowych wyrażeń trasy SQL/JSON po uwierzytelnianie wieloskładnikowe za pomocą parametru clientcert=verify-full, utworzone kolumny i wiele więcej. Wystarczy na osobny post.

Podobnie jak PostgreSQL 10, PostgreSQL 12 poprawi ogólną wydajność natychmiast po aktualizacji. Ty oczywiście możesz postąpić po swojemu - przetestuj aplikację w podobnych warunkach na systemie produkcyjnym przed włączeniem ulepszeń, tak jak ja to zrobiłem z PostgreSQL 10. Nawet jeśli PostgreSQL 12 jest już bardziej stabilny niż się spodziewałem, nie zwlekaj z testowaniem aplikacji przed dopuszczeniem ich do produkcji.

Źródło: www.habr.com