chore skojarzenia google’a :)

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

kluster postgresów na płytkach?

austriacka firma cybertec zaoferowała nowy produkt: “out of the box cluster".

w założeniach jest to zestaw oprogramowania który po instalacji na serwerach daje gotowy, skonfigurowany klaster bazodanowy.

funkcje:

  • replikacja multi-master (nie wiem jeszcze czy jest to replikowanie zapytań czy danych, wysłałem zapytanie, zobaczymy co powiedzą)
  • pełna obsługa 2-fazowych commitów (to jest interesujące – może wreszcie zrobili replikację danych przy użyciu tej technologii?)
  • rozszerzone funkcje monitorujące poprzez dedykowany serwer
  • automat sprawdzający spójność bazy danych
  • pełny support 24/7
  • po instalacji na serwerze jest zasadniczo debian (jak rozumiem jest to ubuntu dapper, wersja serwerowa)
  • system jest gotowy do użytku od razu po instalacji

ceny – całkiem sensowne – wersja na 3 node'y już od 2000 euro. jak coś będę wiedział więcej – napiszę.

korzystanie z różnych postgresów z konsoli

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 🙂

pgpool – nowa, zupełnie nowa odsłona

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 🙂

replikacja multi-master z dodatkowymi feature’ami

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

hstore będzie w oficjalnych źródłach?

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 🙂

serwer pocztowy oparty na bazie danych

daaawno temu zastanawiałem się ze znajomymi nad napisaniem serwera pocztowego który trzymałby wszystko – włącznie z mailami – w bazie danych.

mieliśmy kilka pomysłów, ale finalnie brak czasu projekt zabił na etapie gdy jeszcze nie było nawet linijki kodu.

dziś przeczytałem o projekcie archiveopteryx.

jest to rozwiązanie służące zasadniczo do tego co my chcieliśmy. ale z kilkoma rozwiązaniami zaczerpniętymi z gmaila (labele).

co większe feature'y:

  • zaprojektowany tak by nie wprowadzać żadnych sztucznych ograniczeń na maile
  • skalowalny. w tym – obsługujący jakąś (nie testowałem jeszcze więc nie znam szczegółów) formę clustrowania
  • maile (i załączniki jak rozumiem) są przechowywane w mocno znormalizowanej postaci dla uniknięcia duplikatów (ma znaczenie przy oparciu o to np. list mailingowych)
  • obsługa folderów pocztowych
  • obsługa folderów “wirtualnych" – zapisanych reguł filtrowania maili. przykładowo:
    • wszystkie maile do/od pana x
    • wszystkie listy z listy mailingowej y
    • nowe maile do mnie
  • pojedynczy mail może należeć do wielu folderów
  • obsługuje praktycznie wszystkie istotne standardy: smtp, imap, pop3, sasl, tls, sieve, lmtp
  • przezroczysta obsługa funkcji “undelete"

standardowa instalacja obejmuje jakiś front-endowy serwer pocztowy zajmujący się np. tagowaniem spamu, relayowaniem czy odsiewaniem wirusów. dopiero potem, maile lokalne, trafiają do archiveopteryxa.

system jest zaprojektowany pod długotrwałą archiwizację.

całość działa na postgresie (stąd się o tym dowiedziałem) i podobno jest bardzo sympatyczne – aczkolwiek posługuję się tu opiniami osób trzecich – sam nie miałem okazji potestować.

wykonywanie automatycznych zadań w postgresie

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.