3. Podstawy
- czym jest PostgreSQL
- metody konfiguracji
- metody diagnostyki
4. Czym jest PostgreSQL
system zarządzania relacyjnymi bazami danych
„The world's most advanced open source database”
Silnik SQL maks. zgodny ze standardem ISO
Pełna transakcyjność, ACID
Programowalny i rozszerzalny
Niezawodność i poprawność danych
Open Source + licencja „używaj jak tylko chcesz”
5. Wersje PostgreSQL
X.Y – wersja główna (wprowadza zmiany,
"major")
Przy zmianie głównej wersji wewnętrzny format danych może się
zmieniać, co komplikuje proces aktualizacji. Tradycyjną metodą jest
użycie pg_dump oraz przeładowanie bazy. Nowe wersje główne zwykle
wprowadzają pewne widoczne dla użytkownika różnice, które mogą
wymagać zmiany sposobu programowania aplikacji.
{X.Y}.{Z} – wersja mała (tylko naprawia
błędy, "minor")
Małe ("minor") wydania nigdy nie zmieniają wewnętrznego formatu
danych i są zawsze kompatybilne z wcześniejszymi i późniejszymi
wydaniami tej samej wersji głównej. Żeby zaktualizować serwer do
innej małej wersji, wystarczy podmienić pliki wykonywalne serwera,
gdy jest zatrzymany, i uruchomić go ponownie. Katalog danych
pozostaje bez zmian - upgrade do małej wersji jest bardzo prosty.
6. Nowości
http://www.postgresql.org/about/featurematrix
Wersja 9.0 – wydana 2010
wbudowana replikacja binarna (Hot Standby+Streaming Replication),
ulepszenia w PL/xxx (DO, nazwane argumenty), GRANT/REVOKE all, triggery
warunkowe i na kolumnach, wsparcie dla Win64, EXCLUDE constraints,
ulepszenia funkcji analitycznych, lepsze wsparcie LDAP i RADIUS
Wersja 9.1 – wydana 2011
replikacja synchroniczna (Synchronous Replication), „sepgsql”
(integracja z SE Linux), ulepszenie obsługi rozszerzeń ‑ (EXTENSION),
COLLATE na kolumnach, prawdziwy tryb SERIALIZABLE, algorytm KNN-Gist
(najbliższy sąsiad), aktualizacja języka PL/Python, obsługa modyfikacji danych
w klauzuli WITH
7. Nowości
Wersja 9.2 – wydana 2012
Ulepszenia odczytu (index-only scans), lepsze plany zapytań dla
„prepared statements”, kaskadowa replikacja, row-level views security
(security_barrier), typy zakresowe (range data types), pg_receivexlog,
wsparcie dla JSON
Wersja 9.3 – wydana 2013
Widoki zmaterializowane, auto-update na widokach, więcej funkcji JSON,
Foreign-Data Wrappers, sumy kontrolne, mniej blokujące FK, lepsze indeksy,
poprawki wydajnościowe
Wersja 9.4 – wydana 2014
wal_level = logical, format jsonb, ALTER SYSTEM, mniej blokujące ALTER
TABLE, czas planowania w EXPLAIN ANALYZE, lepsze pg_basebackup,
poprawki wydajnościowe
8. Dokumentacja / źródła informacji
● Strona główna projektu:
http://www.postgresql.org
● Pełna dokumentacja:
http://www.postgresql.org/docs/current/
http://www.postgresql.org/docs/manuals/
wyszukiwarka, indeks rzeczowy, SQL reference
+ pomoc wbudowana w psql
● Listy mailingowe:
http://archives.postgresql.org
pgsql-sql, pgsql-general, pgsql-performance
● Wiki http://wiki.postgresql.org
● Rozszerzenia: http://pgfoundry.org/
● Fora i usenet (np. pl.comp.bazy-danych)
● Google Is Your Friend
9. Konfiguracja PostgreSQL
● Komenda SET: zmiana tylko dla bieżącej sesji
SET add_missing_from=off;
● Komenda ALTER: zmiana na stałe dla użytkownika
ALTER USER fred SET add_missing_from=off;
● Komenda ALTER: zmiana na stałe dla bazy danych
ALTER DATABASE mydb SET add_missing_from=off;
● Edycja pliku: zmiana na stałe dla danej instancji
plik postgresql.conf – lub komenda ALTER SYSTEM
Odczyt: komenda SHOW , widok pg_settings
12. Skalowanie
PostgreSQL - CPU
Skalowanie pionowe
● CPU, czyli procesujmyż!
● RAM
● I/O
Skalowanie poziome
● replikacja
● agregacja
● rozkładanie ruchu
● sharding
13. Skalowanie
PostgreSQL - CPU
● Architektura procesów, a wykorzystanie CPU
● Operacje wrażliwe na CPU
● Szybsze rdzenie czy więcej rdzeni?
● Ograniczenia w skalowaniu
14. Procesy serwera
każda sesja to osobny proces.
$ ps xf
PID TTY STAT TIME COMMAND
1378 ? S 0:00 /usr/lib/postgresql/9.3/bin/postgres -D /var/lib/pos...
1380 ? Ss 0:00 _ postgres: logger process
1383 ? Ss 0:00 _ postgres: checkpointer process
1384 ? Ss 0:00 _ postgres: writer process
1385 ? Ss 0:00 _ postgres: wal writer process
1386 ? Ss 0:00 _ postgres: autovacuum launcher process
1387 ? Ss 0:00 _ postgres: archiver process last was 0000000200...
1388 ? Ss 0:01 _ postgres: stats collector process
18169 ? Ss 0:12 _ postgres: db1 app1 [local] SELECT
18170 ? Ss 0:12 _ postgres: db1 app1 [local] COMMIT
18276 ? Ds 0:03 _ postgres: db1 app2 127.0.0.1(42090) SELECT
18277 ? Ss 0:03 _ postgres: db1 app2 127.0.0.1(42091) UPDATE waiting
komunikacja przez SHM i semafory
15. CPU - parametry
max_connections - dostosowanie do zasobów
SSL – koszty połączenia
join_collapse_limit, from_collapse_limit, geqo
cpu_tuple_cost, cpu_operator_cost
log_lock_waits
16. CPU – operacje wrażliwe: COPY
(a także INSERT)
● COPY do tej samej tabeli - do wersji 9.2 bardzo
wrażliwe na wal_level.
● Zabójcze: triggery użytkownika, zwłaszcza z
efektami zewnętrznymi
● Nieco mniej zabójcze: CHECK, klucze obce
17. CPU – operacje wrażliwe: inne
1. Dla wersji 9.1 i starszych: równoległa praca na
wielu rdzeniach - np. SELECT z tej samej tabeli.
Hasło: „lock contention”
2. Funkcje użytkownika
18. Skalowanie PostgreSQL
CPU: HOW TO FAIL
● Zbyt małe lub zbyt duże max_connections (np.
max_connections = 10 na 12-core'owym
serwerze, albo max_connections=100 na 1-
core'owym)
● Wszystkie sesje wiszące na COPY IN lub na
funkcjach uzytkownika (UDF)
● UDF: B. dużo arytmetyki, złożone regexpy,
programowanie wszystkiego w bazie
● Wersja 9.1 i 2k TPS na jednej tabeli
19. Ograniczenia w skalowaniu
Szybsze rdzenie czy więcej rdzeni?
Bez dużego znaczenia, dzięki efektywnemu
schedulerowi na poziomie O/S
Ograniczenia
IPC & Blokady
W nowszych wersjach lepiej ... ale.
→ Minimalizujcie ilość sesji!
→ Unikajcie scenariuszy z „HOW TO FAIL”
20. CPU - Linki
● Heikki Linnakangas, prezentacja „Multi-CPU
performance in PostgreSQL 9.2”
http://wiki.postgresql.org/images/e/e8/FOSDEM
2012-Multi-CPU-performance-in-9.2.pdf
● Robert Haas, „Scalability, in Graphical Form,
Analyzed”
http://rhaas.blogspot.com/2011/09/scalability-in
-graphical-form-analyzed.html
● Oficjalne „PostgreSQL performance tips”
http://www.postgresql.org/docs/current/static/pe
rformance-tips.html
21. Skalowanie
PostgreSQL - RAM
Skalowanie pionowe
● CPU, czyli procesujmyż!
● RAM, czyli o czym słonie (nie) zapominają.
● I/O, czyli o trudnej sztuce wchodzenia i wychodzenia.
Skalowanie poziome
● replikacja, czyli trąby w górę
● agregacja, czyli nie wszyscy na raz
● rozkładanie ruchu, czyli po co nam nadzorca
● sharding, czyli słoń to czy zebra
22. Buforowanie R/W
w PostgreSQL
PostgreSQL
Write-Ahead Log
h/t Bruce Momjian
23. Zużycie pamięci roboczej
Pojedyncza sesja
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1196 postgres 20 0 4531m 3.3g 3.1g S 0 2.6 5:15.14 postgres
PID UID URES SHR VIRT data exe
1196 postgres 198596 3255988 4639784 201368 4756
Globalnie
total used free shared buffers cached
Mem: 129180 127753 1427 0 53 124091
-/+ buffers/cache: 3609 125571
Swap: 16385 125 16260
24. Pamięć robocza - ustawienia
● shared_buffers – współdzielona pamięć stron
10% - 50% pamięci RAM (ale nie więcej niż 8-16GB)
● work_mem - pamięć indywidualna sesji do sortowania
1 - 20 MB (stosownie do max_connections)
● maintenance_work_mem dla VACUUM, CREATE INDEX,
100-1000 MB
● effective_cache_size – oszacowanie rozmiaru pamięci
podręcznej stron na poziomie systemu operacyjnego,
5% - 40% pamięci RAM
● log_temp_files – ujawnia niedostatki work_mem
http://www.postgresql.org/docs/current/static/runtime-config-resource.html
26. Skalowanie
PostgreSQL – I/O
Skalowanie pionowe
● CPU, czyli procesujmyż!
● RAM, czyli o czym słonie (nie) zapominają.
● I/O, czyli o sztuce wchodzenia i wychodzenia.
Skalowanie poziome
● replikacja, czyli trąby w górę
● agregacja, czyli nie wszyscy na raz
● rozkładanie ruchu, czyli po co nam nadzorca
● sharding, czyli słoń to czy zebra
31. WAL
Przy każdym COMMIT, kolejne bloki logu transakcji
są zapisywane na dysk i wywoływana jest na nich
funkcja fsync/fdatasync (synchronizacja danych na
nośnik). COMMIT jest relatywnie tani i szybki.
Przy każdym CHECKPOINT, ten log jest scalany do
bazy, a zużyte segmenty WAL są usuwane.
CHECKPOINT wykonuje się automatycznie, gdy log
się zapełni (albo upłynie określony czas).
CHECKPOINT jest drogi i powolny.
http://www.postgresql.org/docs/current/static/wal-reliability.html
35. I/O – ustawienia WAL & fsync
fsync wymusza synchronizację na nośnik (ACID!)
„off” tylko tam, gdzie można sobie pozwolić na
utratę transakcji! (np. bazy testowe, redundantne)
full_page_writes „off” tylko tam, gdzie nie ma ryzyka partial page
writes! (sprawdzalne narzędziem)
checkpoint_segments Większa ilość segmentów WAL to rzadsze
checkpointy
checkpoint_completion
_target
rozłożenie I/O wywołanego przez checkpoint w
czasie, zalecane 0.9
log_checkpoints przydatna informacja diagnostyczna
effective_io
_concurrency
Ilość niezależnych kanałów zapisu. 1,2,3,4, … -
stosownie do układu macierzy RAID
Więcej → http://www.postgresql.org/docs/current/static/wal-configuration.html
36. I/O – RAID & tablespaces
●More Spindles is Good
● RAID 10 lub zarządzanie ręczne wieloma
dyskami (tablespace, dowiązania)
● logi transakcji (WAL) na innym dysku niż
dane
● indeksy na innym dysku niż dane
37. Tablespace
Command: CREATE TABLESPACE
Description: define a new tablespace
Syntax:
CREATE TABLESPACE tablespacename [ OWNER username ]
LOCATION 'directory'
CREATE TABLESPACE data3 LOCATION '/mnt/data3';
ALTER TABLE foo SET TABLESPACE data3;
ALTER USER foo SET default_tablespace TO data3;
ALTER TABLESPACE data3 SET random_page_cost = 2;
38. partycjonowanie
Tabela główna
CREATE TABLE sales (
product text, year integer, date date, value numeric
);
Partycje
CREATE TABLE sales10 ( check(year=2010) ) INHERITS(sales);
CREATE TABLE sales11 ( check(year=2011) ) INHERITS(sales);
CREATE TABLE sales12 ( check(year=2012) ) INHERITS(sales);
Trigger rozdzielający dane
CREATE TRIGGER trg_insert_sales BEFORE INSERT OR UPDATE ON sales
FOR EACH ROW EXECUTE PROCEDURE trg_sales_insert ();
Zapytanie do tabeli głównej, które używa partycji
SELECT sum(value) FROM sales WHERE year=2012;
Pełne informacje →
http://www.postgresql.org/docs/current/static/ddl-partitioning.html
40. Indeksy
CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] name
ON table [ USING method ]
( { column | ( expression ) } [ opclass ] [, ...] )
[ WITH ( storage_parameter = value [, ... ] ) ]
[ TABLESPACE tablespace ] [ WHERE predicate ]
Uwaga na klasy operatorów.
Ten sam typ indeksu może się różnie zachowywać w zależności od opclass
Pytanie: jakie operacje mogą zyskać na indeksach?
Pytanie: skąd mam wiedzieć, która tabela/kolumna potrzebuje indeksu?
Pytanie: a co z indeksami wielokolumnowymi?
41. Indeksy częściowe
CREATE INDEX idx_active_articles_act
ON articles (id) WHERE active=true;
CREATE INDEX idx_active_articles_inact
ON articles (id) WHERE active=false;
(odpowiednik partycjonowania)
42. HDD & SSD
- Dyski SSD to „rewolucja” w tradycyjnym
przetwarzaniu danych
- Uwaga na starsze modele SSD
- Konieczność dostosowania parametrów, a co
najmniej tego: random_page_cost
44. „tuning”: linki / narzędzia
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
http://wiki.postgresql.org/wiki/Performance_Optimization
http://wiki.postgresql.org/wiki/Community_Disk_Tuning_Guide
http://momjian.us/main/writings/pgsql/hw_performance/
https://blogs.oracle.com/jkshah/resource/pgeast_ssd.pdf
http://pgfoundry.org/projects/pgtune
FAQ: Database servers, unlike many other applications, are usually I/O and memory
constrained, so it is wise to focus on the I/O subsystem first, then memory
capacity, and lastly consider CPU issues. A good quality, high performance SSD is
often the cheapest way to improve database performance.
45. Skalowanie
PostgreSQL - replikacja
Skalowanie pionowe
● CPU, czyli procesujmyż!
● I/O, czyli o trudnej sztuce wchodzenia i wychodzenia.
● RAM, czyli o czym słonie (nie) zapominają.
Skalowanie poziome
● replikacja, czyli trąby w górę
● agregacja, czyli nie wszyscy na raz
● rozkładanie ruchu, czyli po co nam nadzorca
● sharding, czyli słoń to czy zebra
46. Replikacja – definicja i cele
Replikacja to synchronizacja danych na więcej niż
jeden serwer.
Cele:
● Wysoka dostępność
● Wyrównywanie obciążenia
● Konserwacja / migracje danych
47. Replikacja – narzędzia
Replikacja możliwa jest w wielu warstwach
● Oparte na urządzeniach blokowych
np. DRBD
● Oparte na binarnym logu WAL
Replikacja wbudowana od wersji 9.0
● Oparte na triggerach
Slony-I, inne
● Wbudowane w aplikację
48. Archiwizacja ciągła plików WAL
i mechanizm PITR
PITR = point in time recovery
● zaczynamy od kopii bazy („online backup”) z przeszłości
● “replay” aktywności bazy do pewnego punktu w czasie
wymagania
● backup podstawowy ( kopia katalogu $PGDATA )
● “strumień zmian” w postaci archiwum logów WAL
ograniczenia
● dużo miejsca na dysku
● dużo czasu na „replay” danych
49. Replikacja wbudowana (9.0+)
Hot Standby - tryb „standby” z możliwością zapytań R/O
http://wiki.postgresql.org/wiki/Hot_Standby
Streaming Replication – kopiowanie rekordów WAL „w
locie” - osobne połączenie TCP walsender - walreceiver
http://wiki.postgresql.org/wiki/Streaming_Replication
54. Replikacja „trigger-based”
Narzędzia: Slony-I, londiste, inne
Co jest replikowane:
● TYLKO zmiany w danych (na poziomie wiersza tabeli)
NIE są replikowane:
● zmiany struktury - czyli polecenia DDL (CREATE, ALTER)
● obiekty globalne (użytkownicy, bazy, “large objects”, …)
Główna zaleta w stosunku do replikacji WAL:
Możliwość replikacji jednej lub kilku tabel a nie całej instancji.
55. Skalowanie PostgreSQL
- agregacja połączeń
Skalowanie pionowe
● CPU, czyli procesujmyż!
● I/O, czyli o trudnej sztuce wchodzenia i wychodzenia.
● RAM, czyli o czym słonie (nie) zapominają.
Skalowanie poziome
● replikacja, czyli trąby w górę
● agregacja, czyli nie wszyscy na raz
● rozkładanie ruchu, czyli po co nam nadzorca
● sharding, czyli słoń to czy zebra
58. pgbouncer
(c) Skype, na licencji BSD
http://pgfoundry.org/projects/pgbouncer
Agregator połączeń w architekturze
„Store-Nothing”
Poniżej 4 KiB / połączenie
60. Skalowanie
PostgreSQL - rozkładanie ruchu
Skalowanie pionowe
● CPU, czyli procesujmyż!
● I/O, czyli o trudnej sztuce wchodzenia i wychodzenia.
● RAM, czyli o czym słonie (nie) zapominają.
Skalowanie poziome
● replikacja, czyli trąby w górę
● agregacja, czyli nie wszyscy na raz
● rozkładanie ruchu, czyli po co nam nadzorca
● sharding, czyli słoń to czy zebra
61. „load balancing”
Definicja: Dynamiczne rozłożenie obciążenia
poprzez kierowanie ruchu na wiele serwerów
Założenia dodatkowe
● wymaga replikacji danych
● wymaga middleware i/lub obsługi w aplikacji
Narzędzia: PgPool
62. pgpool-II
http://www.pgpool.net/
Funkcje:
● Pule połączeń
● Replikacja (zapytań, nie danych!)
● Równoważenie ruchu
● Zrównoleglanie zapytań
● Dowolnie wiele serwerów składających się na klaster
● Narzędzia administracyjne – pcp
● Współpraca z Slony-I lub innym systemem replikacji
http://www.slideshare.net/adorepump/pgpoolii-demonstration
65. Skalowanie
PostgreSQL - sharding
Skalowanie pionowe
● CPU, czyli procesujmyż!
● I/O, czyli o trudnej sztuce wchodzenia i wychodzenia.
● RAM, czyli o czym słonie (nie) zapominają.
Skalowanie poziome
● replikacja, czyli trąby w górę
● agregacja, czyli nie wszyscy na raz
● rozkładanie ruchu, czyli po co nam nadzorca
● sharding, czyli słoń to czy zebra
66. Sharding
● Definicja: tak jak partycjonowanie, tylko na
wielu serwerach.
„sharding” w najprostszej formie to podział
tabeli na wiele instancji, gdzie każda posiada
podzbiór wierszy.
● Cele: Skalowanie odczytów i zapisów
● Narzędzia: PL/Proxy
69. PL/Proxy - konfiguracja
-- (Pg <= 8.3) Stworzyć funkcje konfiguracyjne
get_cluster_partitions(clustername text)
get_cluster_version(clustername text)
get_cluster_config(in clustername text, out key text,
out val text)
-- (Pg >= 8.4) zapis definicji wg SQL/MED
CREATE FOREIGN DATA WRAPPER plproxy;
CREATE SERVER mycluster FOREIGN DATA WRAPPER plproxy
OPTIONS ( connection_lifetime '1800',
p0 'dbname=part00 host=127.0.0.1',
p1 'dbname=part01 host=127.0.0.1' ); # 2^n
CREATE USER MAPPING FOR PUBLIC SERVER mycluster;
GRANT USAGE ON SERVER mycluster TO PUBLIC;
70. PL/Proxy - przykład
-- na bazach składowych (= partycjach)
CREATE FUNCTION insert_user(i_username text, i_email
text)
RETURNS integer AS $$
INSERT INTO users (username, email) VALUES
($1,$2);
SELECT 1;
$$ LANGUAGE SQL;
-- na serwerze partycjonującym
CREATE FUNCTION insert_user(i_username text, i_email
text)
RETURNS integer AS $$
CLUSTER 'mycluster';
RUN ON hashtext(i_username);
$$ LANGUAGE plproxy;
-- Uwaga: każde wywołanie to połączenie do partycji
71. Sharding - linki
Plproxy Step-by-step→
http://www.depesz.com/2011/12/02/the-secret-ingredient-in-the-we
bscale-sauce/
Problem identyfikatorów→
http://instagram-engineering.tumblr.com/post/10853187575/shardin
g-ids-at-instagram
72. Podziękowania
Dla Was, drodzy słuchacze!
Oraz:
- żona Marylka za cierpliwość
- Dariusz Grzesista / dBConf
- Compendium Centrum Edukacyjne
- Stefan Batory & eo Networks
- Hubert „depesz” Lubaczewski
- Konrad Mazurkiewicz