tak jak już d- mi zauważył pojawiła się druga część podpowiedzi nt. tunintowania aplikacji – napisana oczywiście przez josha berkusa.

w tej części podpowiedzi:

• delete jest kosztowny
• używanie prepare/execute dla wywoływania zapytań w pętli
• używanie connection-pool'i (buforów połączeń?)

heh

wykryłem pierwszego poważnego buga w postgresie 🙂

w 8.2rc1 jest bug który wykłada postgresa (segfault, sig 11) przy vacuumowaniu indeksów gin 🙂

w sumie szkoda – bo giny są niesamowicie szybkie – ale i dobrze, bo bug namierzony to bug zniszczony. i mogę się chwalić, że przyczyniłem się do poprawienia stabilności postgresa 🙂

josh berkus, osoba dosyć znana w światku postgresowym, opublikował na swoim blogu pierwszy (z serii?) wpis nt. tuningowania aplikacji.

wpis zawiera wstęp teoretyczny i 3 hinty.

hinty sa proste:

1. nigdy nie używaj wielu małych zapytań gdy jedno większe załatwiłoby sprawę.
2. grupuj wielokrotne insert/update/delete w pojedyńcze operujące na większej ilości danych, lub gdy sie nie uda – w transakcje.
3. rozważ zastosowanie bulk-loadingu (copy) zamiast serii insertów.

wstęp teoretyczny jest także istotny, ale ani tego ani dokładnego uzasadnienia hintów tłumaczyć nie będę – przeczytajcie sami.

w postgresie jest coś takiego jak tsearch – silnik do wyszukiwania pełnotekstowego.

jednym z elementów silników pełnotekstowych jest stemmer – soft który zamienia słowa na ich wersje podstawowe – np. “depeszowi" na “depesz".

stemmerem którego użycie ludzie od tsearcha polecają jest snowball. zasadniczo nie jest to nawet stemmer, tylko specjalizowany język programowania do pisania stemmerów. kompilowanych potem do kodu w c.

niestety – nie ma stemmera snowballowego dla języka polskiego. jest rosyjski, angielski węgierski i kilka(naście) innych. polskiego brak.

niezrażony poszukałem na google‘ach. i co znalazłem na pierwszym miejscu? aaargh. 🙂

właśnie (dziś w nocy) źródła w cvs'ie postgresa zostały otagowane jako rc1! czyli wyjście 8.2 jest już nie tyle na horyzoncie, co już tuż-tuż za rogatkami 🙂

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ć.