w swojej pracy często muszę korzystać ze zdalnych baz danych.

to oznacza, że mam pewien “problem".

muszę albo:

1. zapamiętać wszystkie opcje do połączenia do każdej bazy
2. porobić aliasy/jednolinijkowce do łączenia do baz
3. przerzucić się z ulubionego psql'a do czegoś typu pgadmin
4. napisać coś własnego

opcja 1 – odpada. z paru powodów. głównym jest lenistwo. dodatkowo rozwala mnie fakt iż mam na dysku postgresa 8.2 (z cvs'u) i to jego psql jest domyślny. a łączę się do baz 8.1, 8.0 czy 7.4. a psql z wersją postgresa powinien być zgodny. więc musiałbym jeszcze pamiętać który psql do której bazy. tragedia.

opcja 2 – aliasy – no, może i by się dało, ale ani to proste ani miłe, ani przesadnie skalowalne.

opcja 3 – odpada. graficzne toole do baz danych mają jedną wspólną cechę: wkurzają mnie.

pozostała więc opcja 4.

pomyślałem, pokombinowałem i napisałem skrypcik “sql“. a jak napisałem to i udostępnię – może się jeszcze komuś nada.

skrypcik jest w perlu. wymaga kilku niestandardowych bibliotek:

• Readonly
• IO::Prompt
• IO::All

zakłada on, że w katalogu domowym w podkatalogu .sql-profiles będą pliki *.conf o takiej budowie:

user=cos
database=cosmix
host=db123.internal
port=5811
psql=/usr/bin/psql

opcje te służą do uruchomienia psql'a w odpowiedni sposób. no i odpowiedniego psql'a (jak nie podam psql=…, to sql uruchomi domyślnego psql'a).

jak to działa.

odpalam: sql

i dostaję menu z listą konfiguracji. wybieram jedną i sql wykonuje “exec" na odpowiedniego psql'a z odpowiednimi parametrami.

co więcej. załóżmy, że mam 2 konfigi: cos.conf i ble.conf. wystarczy, że napiszę: sql c i sql automatycznie załaduje cos.conf (technicznie – sprawdza czy jest tylko 1 takie plik konfiguracyjny którego nazwa zaczyna się od parametru jaki podano).

inne parametry są przekazywane do psql'a.

więc mogę np.:

sql b -c "select version()"

co połączy mnie z bazą zapisaną w ble.conf i wykona polecenie (switch -c, oraz “select version()" zostaną przekazane do psql'a).

oczywiście do tego używam pliku .pgpass, ale to raczej oczywiste 🙂

tak więc – jeśli aby się połączyć z bazą musicie podac jakies parametry – może użyjcie sql'a (programu) – da się parametry skrócić nawet do jednego znaku 🙂

ci z was którzy używają postgresa na pewno przynajmniej słyszeli o rozwiązaniu “pgpool".

w dużym skrócie – interfejs między klientem a bazą danych, pozwalający buforować połączenia, zapewniający prostą replikację (zasadniczo multi-master, ale sprawa jest trochę bardziej skomplikowana), śliczny failover i ogólnie same fajne rzeczy.

pgpool doczekał się niedawno wersji 3.0.

natomiast ostatnio – bardzo ostatnio pojawiła się wersja 1.0 programu pgpool 2.

co to jest? praktycznie zupełnie nowy kod. stworzony w firmie “sra" – największej firmie zajmującej się postgresem w japonii. mają własną “dystrybucję" postgresa, własne toole, itd.

i na własne potrzeby zrobili, a potem udostępnili światu pgpool2.

czym się różni pgpool2 od pgpool?

• obsługuje “parallel query" – czyli możliwość partycjonowania danych między serwery (podpięte pod pgpoola) i wykonywania zapytań jednocześnie na wszystkich serwerach, a potem łączenie wyników
• obsługuje więcej niż 2 serwery “backendowe"!

do tego został dorzucony graficzny (web-based) program do zarządzania pgpoolem – pgpooladmin.

dla wszystkich którzy kiedykolwiek zastanawiali się nad pgpool'em, ale odrzucili go bo np. nie mógł pracować z więcej niż 2 bazami – pora wrócić do tego projektu 🙂

continuent (dosyć znana w świecie postgresowym (i nie tylko) firma) zaoferowała nowe rozwiązanie – uni/cluster.

jest to rozwiązanie bazujące na ich wcześniejszym produkcie – p/cluster.

potrafi całkiem sporo:

• obsługuje postgresa od 7.4 do 8.x na większości platform systemowych
• dane są commitowane na wszystkich node'ach jednocześnie – dzięki czemu nie ma opóźnień replikacyjnych
• brak opóźnień powoduje, że system jest w stanie zdecydowanie efektywniej load-balance'ować
• automatycznie przekierowywanie zapytań do najmniej obciążonej maszyny
• prawie liniowa skalowalność przy dodawaniu nowych serwerów
• całkowicie automatyczny i bardzo szybki failover. przełączenie trwa poniżej sekundy, transakcje które działały na “padniętym" node'dzie są restartowane
• system będzie działał poprawnie nawet jeśli na poszczególnych node'ach są inne wersje postgresa. pozwala to na wykonanie w pełni przezroczystego upgrade'u
• maszyny mogą być dodawane lub usuwane z klastra całkowicie real-time bez żadnych przerw w funkcjonowaniu aplikacji

całość wygląda bardzo interesująco. niestety nie jest rozwiązanie open source ani nawet darmowe, ale jeśli potrzebujesz wysokiej wydajności i bezpieczeństwa danych – powinieneś się poważnie zastanowić.

jakiś czas temu pisałem nt. hstore. w dużym skrócie – jest do moduł do postgresa pozwalający na przechowywanie w pojedynczym polu dowolnej ilości par klucz-wartość. i wyszukiwanie – oczywiście indeksowane.

wtedy, jedyną możliwością zdobycia hstore'a było wyszukanie adresu strony twórców, ściągnięcie paczki i kompilacja.

skomplikowane – zwłaszcza dlatego, że hstore wymaga kompilacji wewnątrz oryginalnych źródeł.

temat włączenia hstore'a do dystrybucji był kilkukrotnie poruszany. pojawiło się kilka nieporozumień, ale ostatnio tom lane napisał, że nie widzi przeszkód by hstore'a wrzucić w contriby!

co powoduje, że przy odrobinie farta paczka postgresql-8.2.tar.bz2 będzie zawierała kolejne naprawdę potężne narzędzie 🙂

do całkiem niedawna jedyną metodą wykonywania okresowych, automatycznych zadań w postgresie było użycie crona.

teraz sytuacja się zmieniła. pojawił się pakiet pgagent. a dokładniej nie tyle pakiet, co rozwiązanie. gdyż pgagent jest częścią pgadmina.

pgagent jest daemonem działającym “obok" bazy danych, który przechowuje w bazie informacje co i kiedy i jak należy wykonać. i wykonuje.

każde zadanie może składać się z wielu “kroków", gdzie krokiem może być zarówno zapytanie sql jak i np. wykonanie skryptu shellowego.

soft wygląda interesująco i na pewno znajdzie sporo zwolenników. mnie aktualnie boli w nim jednakże kilka rzeczy:

1. silne powiązanie z pgadminem. pgadmina nie używam i niespecjalnie lubię. jestem miłośnikiem psql'a i nakładki graficzne traktuję jako “dziwne pomysły".
2. wszystko jest odpalane z konta superusera. co oznacza, że jeśli np. z agenta tworzymy tabelkę (np. comiesięczna archiwizacja) to potem musimy pamiętać oodpowiednich grantach albo alter table set owner'ach. niby niewielki problem, ale jednak
3. powiązane z powyższym – sporo wszystko działa z konta superusera, to nie można dać prawa definiowania zadań zwykłym userom. bo to by była dziura bezpieczeństwa.

mimo tych wad, uważam, że jest to krok w dobrym kierunku i na pewno każdy admin doceni możliwość zgrania wszystkiego co tyczy się bazy danych poprzez jeden prosty dump.

enterprisedb, firma której przedstawiać chyba nie muszę, od wczoraj oferuje swoje rozwiązanie replikacyjne: EnterpriseDB Replication Server.

co to i co potrafi?

na pierwszy rzut oka to co slony:

• asynchronicznie
• master + multi-slave

do tego niby jakieś narządka tylko replication console.

diabeł (a w tym przypadku raczej anioł) tkwi w szczegółach.

po pierwsze – do rzeczonego silnika replikacyjnego jest coś o nazwie: “Database Pooling Connection Framework". z tego co zrozumiałem z jednozdaniowego opisu, wynika, że zarządza to rozrzucaniem zapytań po bazach master/slave. i to w sposób w miarę inteligentny – wykrywając zapytania modyfikujące?!

po drugie – ten silnik replikacyjny pozwala replikować między postgresem i enterprisedb – co jest oczywiste, bo enterprisedb to też postgres. ale potrafi też replikować z/na oracle'a!

jest to o tyle dodatkowo ciekawe, że enterprisedb (firma) oferuje też pakiet do postgresa dla zachowania dużej kompatybilności zapytań. idea jest taka, że zapytania z oracle'a, działają na postgresie (a dokładniej na enterprisedb).

czyli całośc pozwala na zrobienie live migracji na postgresa a potem przepięcie aplikacji klienckich, albo ich część, na bazę która jest sporo tańsza!
całość pewnie będzie trochę kosztowała, ale może się okazać interesującą alternatywą dla slony'ego w zastosowaniach bardziej komercyjnych.

dostałem informację ile kosztowały te maszynki.

starsza, w/g ceny z 27 lipca 2005 – około $8300 (podaję ceny w dolarach, bo maszyny były kupowane w różnych krajach, od różnych dostawców).

nowa – (w/g ceny z 22 czerwca 2006) – około $55700.

czyli starsza jest 6.7 raza tańsza niż nowsza, a daje wydajność (w/g testów) na poziomie 6.1 raza wolniej niż nowsza.

czyli teoretycznie starsza jest lepsza.

ale z drugiej strony – są zadania których starsza w ogóle nie zrobi, gdyż ma tylko 4 giga ramu i mało dysków. za większe pieniądze dostaliśmy sporo szybszą maszynę, która potrafi robić też rzeczy które są fizycznie nieosiągalne dla tańszej (no chyba, żeby ją rozbudować, ale to też koszt).

reasumując – maszynka (nowa) jest w/g mnie całkowicie warta swojej ceny i mogę każdemu polecić taką konfigurację.

tak jak obiecałem – zrobiłem mocniejsze testy.

najpierw tylko takie info – jak pamiętacie poprzednio robiłem pgbencha -s 750. i na ustawieniach praktycznie “defaultowych" robił maksymalnie 830 tps. po dokonfigurowaniu robił (przy 100 połączeniach jednocześnie, czyli wtedy gdy poprzedni config robił 780-790) w zależności od nie wiem czego od 960 do 1070 tps'ów. całkiem ładnie.

potem zrobiłem bazę ze skalą pgbencha 7500. wielkość bazy – 120 giga, czas robienia pgbench -i – 150 minut.

ponieważ każdy test (każde concurrency) robię na czystej bazie, stwierdziłem, że robienie za każdym razem inicjalizacji po 150 minut odpada.

skopiowałem więc cały katalog $PGDATA na bok, i robiłem testy kopiując co test czysty katalog na miejsce “zużytego".

skrypt testujący:

#!/bin/bash -x<br />
export TOTAL_TRANS=1000000<br />
for C in 1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 125 130 135 140 145 150 155 160 165 170 175 180 185 190 195 200<br />
do<br />
rm logs/* -f<br />
pg_ctl -w -l logs/x.log start<br />
TRANS=$[ $TOTAL_TRANS / $C ]<br />
pgbench -s 750 -c $C -t $TRANS -U pgdba -d bench 2> /dev/null > /home/pgdba/bench-$C.std<br />
pg_ctl -m immediate stop<br />
killall -9 postgres<br />
killall -9 postmaster<br />
killall -9 postgres<br />
killall -9 postmaster<br />
rm -rf /mnt/postgres/pgdba/data<br />
cp -a /mnt/postgres/pgdba/data.back /mnt/postgres/pgdba/data<br />
done

proste i miłe 🙂

wyniki wyglądają tak:

jest lepiej niż poprzednio – nie ma takiego spadku wydajności.

co interesujące – są skoki o amplitudzie około 50tps, ale wydaje mi się, że mogą one być spowodowane aktywnością poza-bazodanową (cron).
całość osięgnęła stabilną średnią około 640 tps. dla przypomnienia – przy wielkości bazy 4 razy większej niż ram. całkiem przyjemny wynik.