Spędziłem tydzień we wspaniałej Lizbonie, uczestnicząc w corocznej Europejskiej Konferencji PostgeSQL. To była 10. rocznica od pierwszej europejskiej konferencji PostgreSQL i mojej szóstej obecności.
Pierwsze wyświetlenia
Miasto było super, atmosfera była świetna i wydawało się, że będzie to bardzo produktywny i pouczający tydzień pełen ciekawych rozmów z inteligentnymi i przyjaznymi ludźmi. Więc w zasadzie pierwszą fajną rzeczą, której nauczyłem się w Lizbonie, jest to, jak wspaniała jest Lizbona i Portugalia, ale myślę, że przyjechałeś tutaj przez resztę historii!
Współdzielone bufory
Wzięliśmy udział w sesji szkoleniowej „Pas narzędzi PostgreSQL DBA do codziennych operacji”
autor:Kaarel Moppel (Cybertec) . Jedną z rzeczy, które zauważyłem, było ustawienie shared_buffers. Ponieważ shared_buffers faktycznie konkurują lub uzupełniają pamięć podręczną systemu, nie powinny być ustawione na żadną wartość między 25% a 75% całkowitej dostępnej pamięci RAM. Tak więc, chociaż ogólnie zalecanym ustawieniem dla typowych obciążeń jest 25% pamięci RAM, w szczególnych przypadkach można je ustawić na>=75%, ale nie pomiędzy.
Inne rzeczy, których nauczyliśmy się podczas tej sesji:
- niestety łatwa aktywacja/włączanie online (lub offline) sum kontrolnych danych nie jest jeszcze w 11 (initdb/logiczna replikacja pozostaje jedyną opcją)
- uważaj na vm.overcommit_memory, lepiej wyłącz go, ustawiając go na 2. Ustaw vm.overcommit_ratio na około 80.
Zaawansowana replikacja logiczna
W przemówieniu Petra Jelinka (2. kwadrant) , pierwotni autorzy replikacji logicznej, dowiedzieliśmy się o bardziej zaawansowanych zastosowaniach tej nowej ekscytującej technologii:
- Scentralizowane gromadzenie danych:możemy mieć wielu wydawców, a następnie centralny system z subskrybentem każdego z tych wydawców, udostępniając dane z różnych źródeł w systemie centralnym. (typowe zastosowanie:OLAP)
- Udostępnione dane globalne lub innymi słowy centralny system do utrzymywania globalnych danych i parametrów (takich jak waluty, akcje, wartości rynkowe/towarowe, pogoda itp.), który jest publikowany dla jednego lub większej liczby subskrybentów. Wtedy dane te są utrzymywane tylko w jednym systemie, ale dostępne dla wszystkich subskrybentów.
- Replikacja logiczna może być asynchroniczna, ale także synchroniczna (gwarantowana przy zatwierdzeniu)
- Nowe możliwości dzięki logicznemu dekodowaniu:
- integracja z Debezium/Kafka poprzez logiczne wtyczki dekodujące
- Wtyczka wal2json
- Dwukierunkowa replikacja
- Uaktualnienia prawie do zera przestojów:
- skonfiguruj replikację logiczną na nowym serwerze (prawdopodobnie initdb z włączeniem sum kontrolnych danych)
- poczekaj, aż opóźnienie będzie stosunkowo małe
- z pgbouncera wstrzymaj bazy danych
- poczekaj, aż opóźnienie wyniesie zero
- zmień konfigurację pgbouncera, aby wskazywał nowy serwer, przeładuj konfigurację pgbouncera
- z pgbouncera wznów bazy danych
Co nowego w PostgreSQL 11
W tej ekscytującej prezentacji Magnus Hagander (Redpill Linpro AB) przedstawił nam cuda PostgreSQL 11:
- pg_stat_statements obsługuje identyfikator zapytania 64-bitowego.
- pg_prewarm (metoda podgrzewania pamięci podręcznej systemu lub współdzielonych buforów):dodanie nowych parametrów konfiguracyjnych
- Nowe domyślne role ułatwiające odejście od postgresa (mam na myśli użytkownika :) )
- Procedury składowane z kontrolą xactional
- Ulepszone wyszukiwanie pełnotekstowe
- Replikacja logiczna obsługuje TRUNCATE
- Podstawowe kopie zapasowe (pg_basebackup) weryfikują sumy kontrolne
- Kilka ulepszeń w zrównoleglaniu zapytań
- Partycjonowanie jeszcze bardziej wyrafinowane niż w 10
- domyślna partycja
- aktualizacje na różnych partycjach (przenosi wiersze z jednej partycji do drugiej)
- lokalne indeksy partycji
- unikalny klucz na wszystkich partycjach (nadal nie do odwołania)
- partycjonowanie haszujące
- połączenia partycjonowane
- agregaty partycjonujące
- partycje mogą być obcymi tabelami na różnych obcych serwerach. Otwiera to ogromne możliwości drobniejszego shardingu.
- Kompilacja JIT
zheap:odpowiedź na nieszczęścia PostgreSQL
To wciąż nie jest w 11, ale brzmi tak obiecująco, że musiałem umieścić go na liście fajnych rzeczy. Prezentację wygłosił Amit Kapila (EnterpriseDB) jeden z głównych autorów tej nowej technologii, która ma zostać ostatecznie zintegrowana z rdzeniem PostgreSQL jako alternatywny rodzaj sterty. Zostanie to zintegrowane z nowym interfejsem API Pluggable Storage w PostgreSQL, który będzie obsługiwać wiele metod dostępu do tabel (w taki sam sposób, jak różne metody dostępu [Indeks] omówione w moim pierwszym blogu).
To spróbuje rozwiązać chroniczne niedociągnięcia PostgreSQL za pomocą:
- rozdęcie stołu
- trzeba (auto)odkurzać
- potencjalnie zawinięcie identyfikatora transakcji
Wszystko to nie jest problemem dla przeciętnego średniego i dużego biznesu (chociaż jest to wysoce względne), znamy banki i inne instytucje finansowe, które bez problemów uruchamiają PostgreSQL z dziesiątkami TB danych i kilkoma tysiącami transakcji na sekundę. Nadmiar tabeli jest obsługiwany przez autovacuum, a zamrażanie wierszy rozwiązuje problem zawinięcia identyfikatora transakcji, ale nadal nie jest to bezobsługowe. Społeczność PostgreSQL pracuje nad prawdziwie bezobsługową bazą danych, dlatego proponuje się architekturę zheap. To przyniesie:
- nowy dziennik UNDO
- Dziennik UNDO sprawi, że dane będą widoczne dla starych transakcji, które będą widzieć stare wersje
- COFNIJ zostanie użyty do cofnięcia skutków przerwanych transakcji
- zachodzą zmiany. Stare wersje nie są już przechowywane w plikach danych.
Cele wysokiego poziomu:
- lepsza kontrola wzdęć
- mniej zapisów
- mniejsze nagłówki krotek
Dzięki temu PostgreSQL będzie pod tym względem porównywalny z MySql i Oracle.
Kwerendy równoległe w PostgreSQL:jak tego nie używać?
W tej prezentacji Amita Kapili i Rafii Sabih (EnterpriseDB) poznaliśmy wewnętrzne elementy paralelizacji, a także wskazówki dotyczące unikania typowych błędów, a także niektóre zalecane ustawienia GUC:
- równoległość obsługuje tylko indeksy B-drzewa
- max_parallel_workers_per_gather ustawiono na 1→ 4 (w zależności od dostępnych rdzeni)
- zwróć uwagę na następujące ustawienia:
- parallel_tuple_cost:koszt przeniesienia jednej krotki z równoległego procesu roboczego do innego procesu
- parallel_setup_cost:koszt uruchamiania równoległych procesów roboczych i inicjowania dynamicznej pamięci współdzielonej
- min_parallel_table_scan_size:minimalny rozmiar relacji branych pod uwagę podczas skanowania sekwencji równoległych
- min_parallel_index_scan_size:minimalny rozmiar indeksu brany pod uwagę przy skanowaniu równoległym
- random_page_cost:szacowany koszt dostępu do losowej strony na dysku
