Jeśli kogoś zainteresował poprzedni post, a jeszcze nie zainstalował, to poniżej znajduje się mały helper.

Opis dotyczy CouchDB w wersji 0.8.1

Ubuntu 8.04

Potrzebne będzie trochę narzędzi i bibliotek:

sudo apt-get install automake autoconf help2man checkinstall
sudo apt-get install libtool subversion-tools build-essential libreadline5-dev
sudo apt-get install libicu38 libicu-dev
sudo apt-get install erlang

Następnie trzeba zainstalować silnik JS SpiderMonkey, który standardowo wykorzystywany jest przez CouchDB do wykonywania funkcji map i reduce.

sudo apt-get install libmozjs-dev

Oczywiście trzeba także pobrać CouchDB. Po ściągnięciu i rozpakowaniu wchodzimy do katalogu ze źródłami, aby rozpocząć budowanie.

tar -xzvf apache-couchdb-0.8.1-incubating.tar.gz
cd apache-couchdb-0.8.1-incubating
./configure
make && sudo make install

Następnie możemy utworzyć użytkownika, z którego będziemy uruchamiać, nadać odpowiednie prawa itd.

sudo adduser couchdb
sudo mkdir -p /usr/local/var/lib/couchdb
sudo chown -R couchdb /usr/local/var/lib/couchdb
sudo mkdir -p /usr/local/var/log/couchdb
sudo chown -R couchdb /usr/local/var/log/couchdb
sudo mkdir -p /usr/local/var/run
sudo chown -R couchdb /usr/local/var/run

Na zakończenie pozostaje nam wrzucenie skryptu startowego w odpowiednie miejsce:

sudo cp /usr/local/etc/init.d/couchdb /etc/init.d/
sudo update-rc.d couchdb defaults
sudo /etc/init.d/couchdb start

Ubuntu 8.10 Tu ponoć jest już łatwiej…

sudo apt-get install couchdb

…i to by było na tyle.

Mac OS X

Na maku jest trochę prościej niż na Ubuntu 8.04, ale nie aż tak prosto jak na 8.10 ;)

sudo port install couchdb +server

MacPorts zadba o zainstalowanie wszystkich zależności. Pozostaje nam jeszcze nakarmienie LaunchDeamon’a odpowiednim plikiem plist:

sudo launchctl load -w /opt/local/Library/LaunchDaemons/org.apache.couchdb.plist

Plik wskazany przez porty podczas instalacji może nie działać.

Po odpaleniu bazy:

sudo couchdb -b

Jakby ktoś marzył o binarce na maka to mam dobrą/złą (niepotrzebne skreślić) wiadomość. Dla Leoparda na Intelu dostępny jest CouchDBX.

Po instalacji

Otwieramy przeglądarkę i wchodzimy na http://127.0.0.1:5984/_utils/ Powinniśmy zobaczyć:

Możemy odpalić testy, aby sprawdzić czy nasza instalacja działa poprawnie:

Jeśli odpaliliśmy CouchDB w konsoli, to łatwo możemy zaobserwować RESTowe żądania (GET, POST, PUT, DELETE):

CouchDB, czyli baza danych zorientowana na dokumenty, całkowicie schema-free i co za tym wszystkim idzie, pozbawiona relacji. Napisana w Erlangu, języku współbierznym, dzięki czemu z łatwością może efektywnie wykorzystać wszystkie rdzenie procesora(ów). Komunikacja odbywa się via RESTful HTTP/JSON API. Obsługuje także replikację z dwu kierunkowym wykrywaniem i rozwiązywaniem konfliktów.

buzz… buzz…

Jak to widać na uroczym obrazku na stronie CouchDB, bebechy można podzielić na silnik “widoków”, storage i replikacje. Pisząc o widokach należy wspomnieć, że nasza znajomość SQL-92 i pochodnych nie zda się na nic. Nie ma klasycznych zapytań, zamiast tego stosowana jest metoda MapReduce. Funkcje map i reduce piszemy w JavaScripcie, ale tak naprawdę można dodać obsługę funkcji w dowolnym języku (o tym za chwilę). Na temat samego MapReduce można wiele napisać, dlatego nie będę w tej chwili rozwijał tego tematu. Zainteresowanych odsyłam do Wikipedii i, na przykład, tego wpisu.

Dane…

…przechowywane są w postaci zserializowanej do JSON’a. Każdy dokument posiada unikalny ID oraz, co ciekawe, numer rewizji. Jest on wykorzystywany do rozwiązywania konfliktów przy replikacji. Ponad to, dokumenty nie są nadpisywane — zamiast tego tworzone są nowe dokumenty, z nowymi numerami rewizji. Powoduje to, co prawda, rozrastanie się bazy jednak starych rekordów można się łatwo pozbyć (opcja “Compact”). Poza rozwiązywaniem konfliktów, dopisywania zamiast nadpisywania ma jeszcze jeden, poważny plus — brak locków. Przy czytaniu z bazy nigdy nie musimy czekać, aż zakończy się dodawanie czy modyfikacja dokumentów.

Wyciąganie wyników…

…odbywa się poprzez wspomniane wcześniej widoki. Jest możliwość tworzenia ich ad-hoc oraz zapisania do bazy i ponownego wykorzystywania w przyszłości. Zapytania ad-hoc zmuszają system do przeszukiwania całego zbioru danych praktycznie za każdym razem, bez użycia indeksów. Z moich, bardzo wstępnych, obserwacji, na małych zbiorach danych, pierwsze zapytanie bywa nawet 10x wolniejsze od kolejnych w serii. Po “rozgrzaniu”, używanie non stop tego samego widoku nie jest problemem. Niestety, taki tymczasowy widok równie szybko “stygnie” i po kilkunastosekundowej przerwie, znów będziemy musieli odczekać swoje. Dlatego preferowane jest używanie widoków, które są zapisane do bazy i podobnie jak dane, replikowane do innych instancji. Po utworzeniu takiego widoku automatycznie budowane są dla niego indeksy. Przy dodawaniu czy modyfikacji danych indeksy są na bieżąco odświeżane. Wyłączenie prądu w trakcie dopisywania do indeksu nie powoduje konieczności jego budowania od nowa po ponownym włączeniu. Aktualizacja powinna zacząć się praktycznie od miejsca w którym została przerwana.

Jak nie JavaScript to…

…praktycznie dowolny język programowania. Jak wspomniałem wcześniej, standardowo piszemy je w JavaScripcie. Do ich obsługi wykorzystywany jest silnik Spider Monkey — osadzony w wielu produktach Mozilli. Gdy zapragniemy zmian wystarczy do konfiguracji dopisać moduł obsługujący funkcje w innym języku. Na nieco ubogim wiki CouchDB znajdziemy opis jak obsłużyć inne języki. Zawiera ona także informacje o wspieranych już językach.

Skalowanie

Dzięki wbudowanym mechanizmom dwu kierunkowej replikacji można myśleć o środowisku rozproszonym. Pomyślcie ile daje dostęp via HTTP. Narzędzi do rozkładania obciążenia na dowolną liczbę maszyn mamy pełno (perlbal, nginx, itd.). Jakby zaszła potrzeba trzymania w pamięci wyników, zawsze można użyć Squida czy Varnisha i nie musimy przy tym ingerować w aplikację. Analiza, jakiego typu “zapytań” jest najwięcej? Nic trudnego, narzędzi do analizy logów serwerów WWW też jest pełno. Zresztą, jakie by te logi nie były Splunk i tak sobie z nimi poradzi.

Tylko po co to wszystko?

Sporo szumu robi się w około denormalizacji danych, partycjonowania, spłaszczania struktury. Ostatecznie wychodzi na to, że bardzo często chcemy uniknąć relacji. Warto się zastanowić czy robienie tego nie jako na siłę ma sens, czy nie lepiej użyć czegoś co w sposób całkowicie naturalny daje nam płaską, dynamiczną strukturę, gdzie denormalizacja jest codziennością. Oczywiście wszystko zależy od konkretnego przypadku i nie można generalizować, że relacyjne bazy są złe, a ich czas dobiega końca.

Coś do poczytania

• Technical Overview
• Polska prezentacja o CouchDB
• A może tagi do tego?
• Joiny
• Tworzenie widoków
• Python i CouchDB
• Jak to działa