Postgres-XC – czyli klaster serwerów PostgreSQL o wysokiej dostępności z równoważeniem obciążenia

Czym jest Postgres-XC?

Postgres-XC jest rozszerzeniem PostgreSQL i dziedziczy większość jego funkcji. Oprogramowanie to udostępnia skalowalne dla zapisu, synchroniczne, symetryczne i transparentne dla urzytkownika rozwiązanie klastra PostgreSQL. Jest to zbiór ściśle połączonych elementów bazy danych, które działają jako całość mogąc być zainstalowane na więcej niż jednej maszynie.

Skalowalne dla zapisu (ang. Write-scalable) — oznacza, że Postgres-XC można skonfigurować do wpółdziałania dowolnej ilości serwerów baz danych. Powstały klaster będzie mógł obsługiwać wiele więcej operacji zapisu (SQL UPDATE, INSERT) niż mógł by zapewnić pojedyńczy serwer bazy danych.

Symetryczność oznacza, że ​​możesz mieć więcej niż jeden serwer bazy danych, do którego klienci łącząc się dostają jednen spójny dla całego klastra widok bazy danych.

Synchroniczność oznacza, że, każda aktualizacja bazy danych z dowolnego serwera bazy danych jest natychmiast widoczna dla innych transakcji działających na pozostałych serwerach master.

Transparentność oznacza, że nie musisz (i twoje aplikacje) martwić się, jak dane są przechowywane wewnętrznie na poszczególnych serwerach baz danych. Oczywiście możesz skorzystać z informacji w jaki sposób tabele są przechowywane wewnętrznie podczas projektowania bazy danych, aby uzyskać jak najwięcej z Postgres-XC.

Dane mogą być przechowywane w sposób rozproszony, to znaczy, że są partycjonowane/dzielone lub replikowanie, tak jak wybierzesz dla każdej tabeli. Kiedy wydajesz zapytanie, Postgres-XC określa, gdzie przechowywane są docelowe dane i zleca odpowiednie zapytanie do serwerów zawierających docelowe dane.

Po co mi Postgre-XC?

W typowych systemach internetowych, łatwo można mieć wiele niezależnych serwerów WWW i serwerów aplikacji w celu równoważenia obciążenia i zapewnienia wysokiej dostępności (ang. HA — hight avalibility). Jednak nie można tego równie łatowo zrobić dla serwerów baz danych, ponieważ wszystkie zmieniające się dane muszą być widoczne dla wszystkich transakcji. W przeciwieństwie do innych rozwiązań, klaster baz danych Postgres-XC zapewnia taką możliwość. Każdy serwer Postgres-XC w ramach klastra zapewnia jednolity widok danych dla aplikacji. Każda aktualizacja bazy danych z dowolnego serwera jest natychmiast widoczna dla aplikacji łączących się do bazy danych za pośrednictwem innych serwerów. Ta funkcja jest zwana „synchronicznym multi-master” i jest najważniejszą cechą Postgres’a-XC.

Kluczowe komponenty Postgres-XC

Postgres-XC składa się z trzech głównych komponentów, zwanych GTM (ang. Global Transaction Manager), Coordinator i Datanode.

GTM (Globalny Menadżer Tranzakcji)

Jest elementem Postgres-XC niezbędnym do zapewnienia spójnego zarządzania transakcjami i kontroli widoczności krotek. Zarządzanie transakcjami PostgreSQL jest oparte na technologii MVCC (ang. Multi-Version Concurrency Control). Postgres-XC wydobywa tę technologię jako  odzielny moduł nazwany GTM, tak, że każdy komponent Postgres-XC zarządzaniający transakcjami bazuje na jednym globalnym statusie. Szczegóły opisane są w dokumentacji w rozdziale 43.

Koordynator (ang. Coordinator)

Koordynator jest interfejsem, w tym sensie działa on podobnie jak konwencjonalny proces PostgreSQL. Jednak koordynator nie przechowuje żadnych rzeczywistych danych. Rzeczywiste dane zapisane przez węzły danych (ang. Datanode). Koordynator odbiera zapytania SQL, pobiera dla nich Globalny Identyfikator Transakcji (ang. Global Transaction Id) i jeśli potrzeba (ang. Global Snapshot), określa które węzły danych są zaanagarzowane i wysyła do nich zapytaie o wykonanie (ich części) tranzakcji. Kiedy zlecane jest zapytanie do Datanodes, jest ono związane z GTID i Global Snapshot, aby węzeł danych nie był zdezorientowany, jeśli otrzyma kolejne zapytanie pochodzące z innej transakcji zainicjowanej przez innego koordynatora.

Węzeł danych (ang. Datanode)

Datanode odpowiada za fizyczne przechowywanie danych. Tabele mogą być rozproszone między węzły danych lub replikowane do wszystkich Datanodes. Węzeł danych nie ma ogólnego obrazu całej bazy danych, on po prostu zajmuje się lokalnym przechowywaniem danych. Przychodzące zapytanie jest analizowane przez koordynatora i przebudowane do wykonania na każdym zaangażowanym węźle danych. To jest następnie przekazywane do każdego z zaangażowanych Datadnodes wraz z GXID i Globalną Migawką. Datanode może odbierać zapytania od różnych koordynatorów. Jednakże, ponieważ każda transakcja jest jednoznacznie identyfikowana i związana globalną migawką, węzeły danych nie muszą się martwić, od którego koordynatora pochdzi transakcja lub zapytanie.

Podsumowanie — czyli co dalej?

Więcej informacji na temat tego rozwiąznia i porównia go z altrnatywnymi przedstawie w przyszłych postach. Dodatkowe informacje można też znaleźć na wiki.postgresql.org/wiki/Postgres-XC, postgresxc.wikia.com, dokumentacji na postgres-xc.github.io i w postgres-xc.sourceforge.net/docs/.

Dodaj komentarz