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

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.