SlideShare ist ein Scribd-Unternehmen logo
1 von 73
Downloaden Sie, um offline zu lesen
Skalowanie 
PostgreSQL 
Filip Rembiałkowski 
DBConf.pl 2014, Szczyrk
Skalowanie 
PostgreSQL - Agenda 
Skalowanie pionowe 
● CPU 
● RAM 
● I/O 
Skalowanie poziome 
● replikacja 
● agregacja 
● rozkładanie ruchu 
● sharding
Podstawy 
- czym jest PostgreSQL 
- metody konfiguracji 
- metody diagnostyki
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”
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.
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
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
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
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
Medody diagnostyki 
- Narzędzia systemu operacyjnego (top, ps, 
iostat, netstat, ...) 
- logi serwera 
- widok pg_stat_activity 
- monitoring ciągły (cacti, munin, zabbix itp..) 
- pgbench 
- EXPLAIN (ANALYZE, BUFFERS)
Poznaj Swe Workloady 
postgres=# select * from pg_stat_database where 
datname='prod'; 
-[ RECORD 1 ]-+--------------- 
datid | 16385 
datname | prod 
numbackends | 24 
xact_commit | 40514353778 
xact_rollback | 25485300 
blks_read | 27614252499 
blks_hit | 2277209676929 
tup_returned | 47020592916188 
tup_fetched | 1484013188102 
tup_inserted | 31088271924 
tup_updated | 227632003 
tup_deleted | 1827540389 
PgBadger / 
PgFouine / 
sed
Skalowanie 
PostgreSQL - CPU 
Skalowanie pionowe 
● CPU, czyli procesujmyż! 
● RAM 
● I/O 
Skalowanie poziome 
● replikacja 
● agregacja 
● rozkładanie ruchu 
● sharding
Skalowanie 
PostgreSQL - CPU 
● Architektura procesów, a wykorzystanie CPU 
● Operacje wrażliwe na CPU 
● Szybsze rdzenie czy więcej rdzeni? 
● Ograniczenia w skalowaniu
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
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
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
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
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
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”
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
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
Buforowanie R/W 
w PostgreSQL 
PostgreSQL 
Write-Ahead Log 
h/t Bruce Momjian
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
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
Pamięć robocza – zdrowy footprint 
h/t Where 2 Get It
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
Skalowanie 
PostgreSQL – I/O 
● WAL & fsync 
● RAID & Tablespaces 
● Indeksy & partycje 
● HDD & SSD
„iostat” 
avg-cpu: %user %nice %system %iowait %steal %idle 
40.55 1.75 2.85 3.28 0.00 51.56 
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s 
avgrq-sz avgqu-sz await svctm %util 
dm-0 0.00 0.50 220.90 111.10 3460.80 1140.15 
27.72 3.05 9.18 2.26 75.08
profil I/O
IOPS 
h/t Jignesh Shah
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
fsync 
h/t Bruce Momjian
fsync 
h/t Bruce Momjian
fsync 
h/t Bruce Momjian
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
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
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;
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
Indeksy. Są. Miłe.
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?
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)
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
HDD & SSD 
H/t: Michael March
„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.
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
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
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ę
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
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
Serwer zapasowy WAL-based 
DATA 
MASTER 
WAL 
Aktywny segment WAL 
(HOT) STANDBY 
Backup startowy 
(jednorazowo) 
Streaming 
archive_command 
DATA 
WAL 
archive 
Watchdog 
odpytywanie (HA-Linux, inne) sygnał przejęcia 
(failover) 
restore_ 
command 
Więcej → http://www.postgresql.org/docs/current/interactive/continuous-archiving.html
Replikacja WAL – postgresql.conf 
# format logów WAL umożliwiający pełne odtworzenie transakcji 
wal_level = hot_standby 
# włączenie archiwizacji logów WAL 
archive_mode = on 
# polecenie OS do archiwizacji segmentów WAL 
archive_command = 'cp %p /mnt/nas1/pg/wal/%f' 
# „strumieniowanie” WAL (uwaga na pg_hba.conf) 
max_wal_senders = 10 
# zapytania R/O po stronie odbiorcy 
hot_standby = on
Replikacja WAL – recovery.conf 
# polecenie OS do de-archiwizacji segmentów WAL 
restore_command = 'cp /mnt/nas1/pg/wal/%f %p' 
# przywracanie ciągłe (tryb „standby”) 
standby_mode = 'on' 
# streaming z serwera „master” 
primary_conninfo = 'host=master port=5900' 
# PITR - przywróć do punktu w czasie 
# recovery_target_time = '2014-07-01 14:07:01'
Replikacja „trigger-based” 
Tabele replikowane 
triggery replikator 
Tabela log zmian 
MASTER 
SLAVE 
Tabele replikowane 
- kopia
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.
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
Agregacja połączeń 
(connection pooling) 
● Cele 
– Ograniczenie ilości połączeń 
– Redukcja zużycia RAM 
– Szybsze nawiązywanie połączeń 
● Narzędzia 
– PgBouncer 
– PgPool 
● Wyniki 
– 1500 połączeń Apache - pgbouncer 
– 250 połączeń pgbouncer - backend
connection pooling
pgbouncer 
(c) Skype, na licencji BSD 
http://pgfoundry.org/projects/pgbouncer 
Agregator połączeń w architekturze 
„Store-Nothing” 
Poniżej 4 KiB / połączenie
pgbouncer.ini 
- Tryb pracy: sesja / transakcja / polecenie 
- konfiguracja połączeń do serwerów / baz 
Minimalny konfig: 
[databases] 
#db1 = host=192.168.1.101 port=5432 dbname=mydb 
#db2 = host=10.0.0.1 port=5432 dbname=mydb 
* = port=5432 
[pgbouncer] 
pool_mode = transaction # JDBC: protocolVersion=2 (bez PS) 
listen_port = 5433 
listen_addr = 192.168.1.1 
auth_type = md5 # trust - w zaufanych sieciach 
auth_file = /var/lib/postgresql/8.4/main/global/pg_auth 
logfile = /var/log/postgresql/pgbouncer.log 
pidfile = /var/log/postgresql/pgbouncer.pid 
admin_users = postgres # kto może administrować pgbouncerem
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
„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
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
pgpool: równoważenie ruchu
Pgpool: tworzenie klastrów
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
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
PL/Proxy 
http://pgfoundry.org/projects/plproxy/ 
„Application level proxy” 
zaimplementowany na poziomie wywołań 
języka proceduralnego
PL/Proxy 
← LB + backend replication 
LB + DB partitions ↓
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;
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
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
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
Kontakt z autorem: 
filip.rembialkowski@gmail.com

Weitere ähnliche Inhalte

Ähnlich wie Skalowanie PostgreSQL @ DBConf.PL 2014

[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegro
[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegro[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegro
[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegroallegro.tech
 
PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...
PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...
PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...PROIDEA
 
PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...
PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...
PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...PROIDEA
 
100 M pakietów na sekundę dla każdego.
100 M pakietów na sekundę dla każdego. 100 M pakietów na sekundę dla każdego.
100 M pakietów na sekundę dla każdego. Redge Technologies
 
Automatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHPAutomatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHPLaravel Poland MeetUp
 
Agregacja i analiza logów
Agregacja i analiza logówAgregacja i analiza logów
Agregacja i analiza logówDivante
 
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...PROIDEA
 
Gluster FS
Gluster FSGluster FS
Gluster FS3camp
 
Wjug from java to big data
Wjug   from java to big dataWjug   from java to big data
Wjug from java to big dataPiotr Guzik
 
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOpsPLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOpsPROIDEA
 
PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...
PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...
PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...PROIDEA
 
"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbać
"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbać"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbać
"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbaćBartosz Ratajczyk
 
Skalowalność Magento - MMPL13
Skalowalność Magento - MMPL13Skalowalność Magento - MMPL13
Skalowalność Magento - MMPL13Divante
 
IT od kuchni w Nokaut.pl
IT od kuchni w Nokaut.pl IT od kuchni w Nokaut.pl
IT od kuchni w Nokaut.pl 3camp
 
OceanQuery - język zapytań edytora raportów
OceanQuery - język zapytań edytora raportówOceanQuery - język zapytań edytora raportów
OceanQuery - język zapytań edytora raportówmatmis
 
Shall we play a game? PL version
Shall we play a game? PL versionShall we play a game? PL version
Shall we play a game? PL versionMaciej Lasyk
 
Apache http server - proste i zaawansowane przypadki użycia
Apache http server - proste i zaawansowane przypadki użyciaApache http server - proste i zaawansowane przypadki użycia
Apache http server - proste i zaawansowane przypadki użyciaWojciech Lichota
 

Ähnlich wie Skalowanie PostgreSQL @ DBConf.PL 2014 (20)

[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegro
[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegro[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegro
[WHUG] Wielki brat patrzy - czyli jak zbieramy dane o użytkownikach allegro
 
PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...
PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...
PLNOG16: Nowe założenia dla zbieranie logów, statystyk i alertów, Maciej Kałk...
 
PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...
PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...
PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...
 
100 M pakietów na sekundę dla każdego.
100 M pakietów na sekundę dla każdego. 100 M pakietów na sekundę dla każdego.
100 M pakietów na sekundę dla każdego.
 
Automatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHPAutomatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHP
 
Agregacja i analiza logów
Agregacja i analiza logówAgregacja i analiza logów
Agregacja i analiza logów
 
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
 
Gluster FS
Gluster FSGluster FS
Gluster FS
 
EXADATA - Infrastruktura Przyszłości
EXADATA - Infrastruktura PrzyszłościEXADATA - Infrastruktura Przyszłości
EXADATA - Infrastruktura Przyszłości
 
Wjug from java to big data
Wjug   from java to big dataWjug   from java to big data
Wjug from java to big data
 
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOpsPLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
 
PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...
PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...
PLNOG 6: Łukasz Bromirski, Rafał Szarecki - Przełączniki i Routery - co jest ...
 
"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbać
"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbać"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbać
"Administrator z przypadku" - Jak działa SQL Server i jak o niego dbać
 
OpenEmbedded
OpenEmbeddedOpenEmbedded
OpenEmbedded
 
Skalowalność Magento - MMPL13
Skalowalność Magento - MMPL13Skalowalność Magento - MMPL13
Skalowalność Magento - MMPL13
 
It od kuchni w nokaut.pl
It od kuchni w nokaut.plIt od kuchni w nokaut.pl
It od kuchni w nokaut.pl
 
IT od kuchni w Nokaut.pl
IT od kuchni w Nokaut.pl IT od kuchni w Nokaut.pl
IT od kuchni w Nokaut.pl
 
OceanQuery - język zapytań edytora raportów
OceanQuery - język zapytań edytora raportówOceanQuery - język zapytań edytora raportów
OceanQuery - język zapytań edytora raportów
 
Shall we play a game? PL version
Shall we play a game? PL versionShall we play a game? PL version
Shall we play a game? PL version
 
Apache http server - proste i zaawansowane przypadki użycia
Apache http server - proste i zaawansowane przypadki użyciaApache http server - proste i zaawansowane przypadki użycia
Apache http server - proste i zaawansowane przypadki użycia
 

Skalowanie PostgreSQL @ DBConf.PL 2014

  • 1. Skalowanie PostgreSQL Filip Rembiałkowski DBConf.pl 2014, Szczyrk
  • 2. Skalowanie PostgreSQL - Agenda Skalowanie pionowe ● CPU ● RAM ● I/O Skalowanie poziome ● replikacja ● agregacja ● rozkładanie ruchu ● sharding
  • 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
  • 10. Medody diagnostyki - Narzędzia systemu operacyjnego (top, ps, iostat, netstat, ...) - logi serwera - widok pg_stat_activity - monitoring ciągły (cacti, munin, zabbix itp..) - pgbench - EXPLAIN (ANALYZE, BUFFERS)
  • 11. Poznaj Swe Workloady postgres=# select * from pg_stat_database where datname='prod'; -[ RECORD 1 ]-+--------------- datid | 16385 datname | prod numbackends | 24 xact_commit | 40514353778 xact_rollback | 25485300 blks_read | 27614252499 blks_hit | 2277209676929 tup_returned | 47020592916188 tup_fetched | 1484013188102 tup_inserted | 31088271924 tup_updated | 227632003 tup_deleted | 1827540389 PgBadger / PgFouine / sed
  • 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
  • 25. Pamięć robocza – zdrowy footprint h/t Where 2 Get It
  • 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
  • 27. Skalowanie PostgreSQL – I/O ● WAL & fsync ● RAID & Tablespaces ● Indeksy & partycje ● HDD & SSD
  • 28. „iostat” avg-cpu: %user %nice %system %iowait %steal %idle 40.55 1.75 2.85 3.28 0.00 51.56 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util dm-0 0.00 0.50 220.90 111.10 3460.80 1140.15 27.72 3.05 9.18 2.26 75.08
  • 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
  • 32. fsync h/t Bruce Momjian
  • 33. fsync h/t Bruce Momjian
  • 34. fsync h/t Bruce Momjian
  • 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
  • 43. HDD & SSD H/t: Michael March
  • 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
  • 50. Serwer zapasowy WAL-based DATA MASTER WAL Aktywny segment WAL (HOT) STANDBY Backup startowy (jednorazowo) Streaming archive_command DATA WAL archive Watchdog odpytywanie (HA-Linux, inne) sygnał przejęcia (failover) restore_ command Więcej → http://www.postgresql.org/docs/current/interactive/continuous-archiving.html
  • 51. Replikacja WAL – postgresql.conf # format logów WAL umożliwiający pełne odtworzenie transakcji wal_level = hot_standby # włączenie archiwizacji logów WAL archive_mode = on # polecenie OS do archiwizacji segmentów WAL archive_command = 'cp %p /mnt/nas1/pg/wal/%f' # „strumieniowanie” WAL (uwaga na pg_hba.conf) max_wal_senders = 10 # zapytania R/O po stronie odbiorcy hot_standby = on
  • 52. Replikacja WAL – recovery.conf # polecenie OS do de-archiwizacji segmentów WAL restore_command = 'cp /mnt/nas1/pg/wal/%f %p' # przywracanie ciągłe (tryb „standby”) standby_mode = 'on' # streaming z serwera „master” primary_conninfo = 'host=master port=5900' # PITR - przywróć do punktu w czasie # recovery_target_time = '2014-07-01 14:07:01'
  • 53. Replikacja „trigger-based” Tabele replikowane triggery replikator Tabela log zmian MASTER SLAVE Tabele replikowane - kopia
  • 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
  • 56. Agregacja połączeń (connection pooling) ● Cele – Ograniczenie ilości połączeń – Redukcja zużycia RAM – Szybsze nawiązywanie połączeń ● Narzędzia – PgBouncer – PgPool ● Wyniki – 1500 połączeń Apache - pgbouncer – 250 połączeń pgbouncer - backend
  • 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
  • 59. pgbouncer.ini - Tryb pracy: sesja / transakcja / polecenie - konfiguracja połączeń do serwerów / baz Minimalny konfig: [databases] #db1 = host=192.168.1.101 port=5432 dbname=mydb #db2 = host=10.0.0.1 port=5432 dbname=mydb * = port=5432 [pgbouncer] pool_mode = transaction # JDBC: protocolVersion=2 (bez PS) listen_port = 5433 listen_addr = 192.168.1.1 auth_type = md5 # trust - w zaufanych sieciach auth_file = /var/lib/postgresql/8.4/main/global/pg_auth logfile = /var/log/postgresql/pgbouncer.log pidfile = /var/log/postgresql/pgbouncer.pid admin_users = postgres # kto może administrować pgbouncerem
  • 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
  • 67. PL/Proxy http://pgfoundry.org/projects/plproxy/ „Application level proxy” zaimplementowany na poziomie wywołań języka proceduralnego
  • 68. PL/Proxy ← LB + backend replication LB + DB partitions ↓
  • 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
  • 73. Kontakt z autorem: filip.rembialkowski@gmail.com