skalowanie postgresql @ dbconf.pl 2014
Post on 21-Jun-2015
716 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
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
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 - 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
top related