serwis tweakers.net zajmuje się benchmarkowaniem różnych rzeczy – m.in. serwerów. im zawdzięczam swoją fascynację kontrolerami raid areca, im zawdzięczam kilka innych ciekawostek jakich się dowiedziałem.

ostatnio przeprowadzili benchmark nowego serwera – maszyny dell power edge 1950, z nowymi procesorami intela i kupą innych zabawek.

maszyna oczywiście wypadła super.

ale nie o to mi chodzi.

jednym z przeprowadzonych testów była wydajność i skalowalność ich własnego serwisu (kopii) postawionego na testowanej maszynie.

testy te przeprowadzali na mysql'u 4.1.20, 5.0.20a, oraz snapshotcie postgresa 8.2 prosto z cvs'u 🙂

wyniki?

tak wygląda wykres (przypominam, te wykresy porównują zachowanie systemu na jednej bazie na wielu różnych maszynach) od mysql'a 4.1:

a tak od mysql'a 5.0:

ok?

to teraz wykres dla postgresa:

na wypadek jeśli nie łapiecie o co mi chodzi – nie, nie chodzi mi wcale o to, że postgres robi więcej requestów na sekundę – to kwestia wtórna, optymalizowalna i łatwo fałszowalna.

to co mnie w mysql'u boli to to, że w pewnym momencie, wraz ze wzrostem ilości klientów prędkość obsługi dramatycznie spada. oczywiście najlepiej to widać na niagarze przy mysql 5.0, ale na każdym serwerze mysql ma tendencje spadkowe po osiągnięciu około 10 jednoczesnych zapytań. postgres natomiast nie.

oczywiście – tweakersi mogli zafałszować dane. true. ale ten schemat zachowania przewijał mi się wiele razy gdy czytałem o mysql'u. i chyba dlatego jakoś nigdy nie mogłem tej bazy polubić.

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