Friday, May 14, 2010

NOnsenSQL i zalety MongoDB

W serii wpisów dotyczącej pisanej przeze mnie wyszukiwarki chciałem podzielić się jeszcze swoimi wrażeniami z wyborem silnika baz danych. Realizując projekt tak nietypowy, ciekawy, fajny starałem się uczynić go okazją do poznania nowych ciekawych narzędzi na każdym szczeblu. Jednym z nich był wybór silnika baz danych.
Miałem do skatalogowania bardzo proste informacje. Listę tysiąca czterystu nazw, do każdej przypisany kod numeryczny. Banał. Najpierw przyszedł mi do głowy memcache, ale kiedyś gadałem z kolegą (dzięki Viciu), który opowiedział mi o tym, że istnieje coś tak fajnego jak Redis, który, w porzeciwieństwie do memcache, w którym traci się wszystko jak zamknie się serwer (restart/pad serwera), potrafi przy zamykaniu zrzucić dane do pliku i załadować je przy kolejnym starcie. To było fajne. Do tego pisane przez ludzi pracujących w Ruby więc generalnie :) w tym deseniu, w którym projektowałem aplikacje - jak znalazł. W Redis fajnie się projektuje listy, kolejki, stos, ale nie fajnie się wyszukuje. Można błyskawicznie pobrać wartość przypisaną do jakiegoś klucza, ale nie ma opcji "pobierz wszystkie dane, które zawierają w sobie wyraz Włocławska" no i kiszka. Kolega, do którego dzwoniłem nakierował mnie CauchDB. Jednak i tam nie znalazłem w dokumentacji nic o tego rodzaju zapytaniu do "bazy" (mówię, że nie znalazłem, nie znaczy, że nie ma). Swoją drogą dokumentacja do CauchDB to jakiś koszmar. Dawno nie widziałem czegoś tak ... nieintuicyjnego i .... ehh ... szkoda słów.
Po drodze wpadłem sobie na pomysł - a może B-drzewo. Na temat b-drzew w Redis nic nie znalazłem a to na co trafiłem w ramach narzędzia Tokyo Cabinet było jeszcze cięższe niż dokumentacja CauchDB. Poza tym nie byłem przekonany do b-drzewa w tym przypadku. To byłby bardziej workaround niż dobre rozwiązanie.
Te poszukiwania uświadomiły mi, że chociaż istnieje cały ruch NOSQL, który w niektórych wypowiedziach tak bardzo zdaje się krytykować SQL to nic nie mówi o tym, że "ich" bazy danych możesz zapytać o jedną wartość (albo ich listę), ale nie ma mowy o zapytaniach. Generalnie jak chcesz zrobić coś ala "LIKE %nazwa%" to w bazie danych NOSQL to jest ... niespotykane.
Jarek Zabiełło (wielkie dzięki) pokazał mi w końcu MongoDB (i odradził Sphinxa, który byłby wytaczaniem armaty na muchę). To brakujące ogniwo w tej całej przepaści, które z jednej strony trzyma dane jak CauchDB - w postaci hierarchicznych dokumentów, używa składni JSONowej obiektów i jest fajne :] a z drugiej posiada funkcję find, która może przyjąć wyrażenie regularne, jako parametr do odfiltrowania danych. Ba - posiada nawet indeksy :] Kurcze, to było to. Obiektowo, hierarchiczne, JSONowo, nie SQLowo, ale z możliwością robienia zapytań - miodzio. Biblioteka do Rubego była, podpięcie do sinatry banał - działa super :] Naprawdę!
Generalnie cała ta kampania NOSQL to jest mydlenie oczu bo co innego jak chcesz trzymać dane i nie musisz robić do nich skomplikowanych zapytań - a co innego jak jesteś do tego zmuszony. Jasne. Wiele aplikacji sieciowy jak Digg, który wyświetla "wszystko" albo "nic" może sobie na to spokojnie pozwolić, ale generalnie SQL to nie jest jakieś zło jak niektórzy przedstawiają ruch NOSQL, tylko czasem aplikacja ma taki model użycia danych, że istnieją lepsze rozwiązania niż *SQL. To wszystko :) Tak było z moją wyszukiwarką.
Generalnie było fajnie :] Wsio.

1 comment:

Anonymous said...

Rzeczywiście w świecie informatyki jest tak, że niektórzy jarają się każdą nowo powstałą technologią nie patrząc na jej ograniczenia, tak jak kiedyś było z EJB1, niby fajnie ale nie dało się tego używać, dopiero w wersji 3 stało się naprawdę przyjemne. Podobnie jest z nosql, co to za baza co nie wspiera transakcji, przecierz przez tyle lat dążono do tego by bazy to wspierały, dodatkowo brak funkcji agregujących, że nie wspomnę o joinach. Więc jak będę sobie chciał coś szukać w mapie to sobie napisze taki system w 10 min.