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.

http://www.postgresql.org/about/featurematrix

Wersja 9.0 – wydana 2010wbudowana 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 2011replikacja 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 2012Ulepszenia 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 2013Widoki 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 2014wal_level = logical, format jsonb, ALTER SYSTEM, mniej blokujące ALTER TABLE, czas planowania w EXPLAIN ANALYZE, lepsze pg_basebackup, poprawki wydajnościowe

Nowości

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.orgpgsql-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 sesjiSET add_missing_from=off;

● Komenda ALTER: zmiana na stałe dla użytkownikaALTER USER fred SET add_missing_from=off;

● Komenda ALTER: zmiana na stałe dla bazy danychALTER DATABASE mydb SET add_missing_from=off;

● Edycja pliku: zmiana na stałe dla danej instancjiplik 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 | 16385datname | prodnumbackends | 24xact_commit | 40514353778xact_rollback | 25485300blks_read | 27614252499blks_hit | 2277209676929tup_returned | 47020592916188tup_fetched | 1484013188102tup_inserted | 31088271924tup_updated | 227632003tup_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 PostgreSQLCPU: 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

OgraniczeniaIPC & BlokadyW 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/FOSDEM2012-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/performance-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

PostgreSQLWrite-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ęć stron10% - 50% pamięci RAM (ale nie więcej niż 8-16GB)

● work_mem - pamięć indywidualna sesji do sortowania1 - 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 TABLESPACEDescription: define a new tablespaceSyntax: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łównaCREATE TABLE sales ( product text, year integer, date date, value numeric);

PartycjeCREATE 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 daneCREATE 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 partycjiSELECT 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_Serverhttp://wiki.postgresql.org/wiki/Performance_Optimizationhttp://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 blokowychnp. DRBD

● Oparte na binarnym logu WALReplikacja wbudowana od wersji 9.0

● Oparte na triggerachSlony-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/Ohttp://wiki.postgresql.org/wiki/Hot_Standby

Streaming Replication – kopiowanie rekordów WAL „w locie” - osobne połączenie TCP walsender - walreceiverhttp://wiki.postgresql.org/wiki/Streaming_Replication

Serwer zapasowy WAL-based

DATA

MASTER

WAL

Aktywny segment WAL

(HOT) STANDBY

archive_command

Backup startowy(jednorazowo)

Streaming

WAL archive

DATA

Watchdog(HA-Linux, inne)odpytywanie 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”

Tabela log zmian

Tabele replikowane

triggery replikator

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 BSDhttp://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 / bazMinimalny 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 = 5433listen_addr = 192.168.1.1auth_type = md5 # trust - w zaufanych sieciachauth_file = /var/lib/postgresql/8.4/main/global/pg_authlogfile = /var/log/postgresql/pgbouncer.logpidfile = /var/log/postgresql/pgbouncer.pidadmin_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 konfiguracyjneget_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/MEDCREATE FOREIGN DATA WRAPPER plproxy;CREATE SERVER mycluster FOREIGN DATA WRAPPER plproxyOPTIONS ( connection_lifetime '1800', p0 'dbname=part00 host=127.0.0.1', p1 'dbname=part01 host=127.0.0.1' ); # 2^nCREATE 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ącymCREATE 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-webscale-sauce/

Problem identyfikatorów→ http://instagram-engineering.tumblr.com/post/10853187575/sharding-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