Otwieram nowy cykl, w którym co jakiś czas pojawi się nowy wpis. Postaram się zrecenzować niektóre pozycje z literatury technicznej. Dzisiaj tematem będzie książka autorstwa Pramod J. Sadalage, Martin Fowler – „NoSQL. Kompendium wiedzy”.

Pamiętacie ten moment, kiedy dowiadujecie się do swojego znajomego jaki to ten NoSQL jest fajny. Fakt, kojarzycie słowo-klucz, ale by nie palnąć głupstwa tłumicie temat. Życie, jednak mimo wszystko warto zapytać o zalety, wady i w ogóle z czym to się je. Generalnie najczęściej swoją przygodę z bazą zaczynamy w towarzystwie nieśmiertelnego MySQL lub ewentualnie PostgreSQL. Uczymy się języka zapytań, budujemy i działamy na schematach, tabelach, krotkach i życie płynie. Przyzwyczajeni z ugruntowaną wiedzą, będąc panem świata bazodanowego, „lepimy” nowe aplikacje i rzadko kiedy coś nowego nas zaskoczy.

Czytasz i przeżywasz déjà vu. Uwierz, nie tylko Ty! Pierwsze zderzenie ze słowem NoSQL i próba logiczne interpretacji doprowadza Cię do wniosku, że to pewnie taka technologia, w której nie ma tabel, powiązań … generalnie jest sobie baza bez schematu. Co więcej, pierwszy lepszy kolega, który chce być lepszy od Ciebie, utwierdza Cię w tym i jest na tyle przekonujący, że nie brniesz dalej.

Jeśli Twoja wiedza jest na tym poziomie lub wiesz wszystko o NoSQL, ale nie masz jeszcze uporządkowanej wiedzy to książka jest zdecydowanie dla Ciebie.

 

Zrozumienie

Tak autorzy nazwali pierwszą z dwóch części książki. Hmm, jakby ją spuentować. Jest ciężko. Sporo nowych terminów, a opis choć konkretny i merytorycznego punktu widzenia nie można nic zarzucić autorowi (bądź tłumaczowi) to jednak wiedza ta jest ciężka do „strawienia” przez mózg.

Najważniejsze, co z tej części czytelnik powinien wynieść to to, że ten typ baz danych jest zorientowany na agregacje oraz brak schematu bazy jest tylko pozorny.

Nieważne, więc że nasza baza nie posiada schematu – i tak musi istnieć domniemany schemat. Ten domniemany schemat to zestaw założeń w kodzie manipulującym danymi, dotyczących struktury tych danych.

Posiadanie w kodzie domniemanego schematu wprowadza kilka problemów. Aby zrozumieć, jakie dane zawarte są w magazynie, musisz zagłębić się w kod aplikacji. Jeżeli ten kod jest dobrze napisany, powinieneś móc znaleźć miejsce, z którego łatwo odczytasz schemat. Nie ma jednak gwarancji […]. Co więcej, baza danych nie uznaje schematu – nie może wykorzystać go do określenia, jak lepiej przechowywać i pobierać dane. Nie może walidować danych, aby zapewnić, że różne aplikacje nie manipulują nimi w sposób niespójny.

„NoSQL. Kompendium wiedzy” str. 45

Opis jest otoczony informacjami o rodzajach baz danych, ale są one tak „surowe”, że wydaje mi się sensowne wspomaganie się nimi już w części drugiej, gdzie są pokazywane przykłady dla tych rodzajów.

W pakiecie otrzymujemy wiedzę nt. modeli dystrybucyjnych:

  • pojedynczy serwer
  • współdzielenie
  • replikacja master-slave
  • replikacja peer-to-peer
  • łączenie shardingu i replikacji

Nieodzowne jest zderzenie z terminami takimi, jak spójność, trwałość, transakcje, map-reduce, kompromis odczyt-zapis.

Przebrnięcie tej części dla osoby, która miała małą styczność z w/w terminami jest niezbyt przyjemne. Najgorsze jest to, że dochodzimy do wniosku iż przeczytaliśmy ok. 80 stron, ale pamiętamy z tego niewiele. Zdarzyć się może, że przeczytać obszerną część podrozdziału i dojdziecie do wniosku, że przyda się jeszcze raz to zrobić.

Najważniejsze! Nie zrażajcie się taką topornością materiału. Od teraz już jest tylko przyjemniej.

 

Implementacja

Część, dla której warto poświęcić czas (oczywiście przez osoby niedoświadczone w temacie, jaką jestem i ja). Pierwsze cztery rozdziały to opis kolejno: baz klucz-wartość, baz dokumentów, baz rodziny kolumn, baz grafowych. Otrzymujemy tutaj definicje, przykład(y), opis w kontekście spójności, transakcji, dostępności, możliwości zapytań konsolowych, skalowania bazy. Mega przydatne jest pokazanie do czego nadaje się określony typ, oraz w jakich zastosowaniach mogą wystąpić problemy (lub na pewno wystąpią).

 

Bazy klucz-wartość

Wymieniane są jako pierwsze, gdyż są rdzenne i najbardziej prymitywne (choć nietrywialne) w terminologii NoSQL. Do wartości odwołujemy się „po kluczu”, a w wyniku otrzymujemy blob. Zadaniem aplikacji obsługującej tę bazę jest zrozumiem co i jak jest poukładane w tym blobie.

Przykład w oparciu o bazę Riak w 100% pokazuje, jak działa ten mechanizm w rozproszonych magazynach. Wyjaśniono problem konfliktów aktualizacji, transakcje w kontekście kworum zapisu.

Odpytujemy bazę – wiadomo – po kluczu, ale do indywidualnego zagłębienia w temat otrzymujemy tutaj informację o istnieniu narzędzia Riak Search.

Najpopularniejsze bazy klucz-wartość to Riak [Riak], Redis (często nazywany też serwerem Data Structure) [Redis], Memcached DB i pochodne [Memcached], Berkeley DB [Berkeley DB], HamsterDB (szczególnie dobrze przystosowana do osadzania w programach) [HamsterDB], Amazon DynamoDB (nie open source) [Amazon’s Dynamo] i Project Voldemort [Project Voldemort] (implementacja open source bazy Dynamo DB).

„NoSQL. Kompendium wiedzy” str. 91

 

Bazy dokumentów

Kolejny typ baz NoSQL, pochodna baz klucz-wartość, gdzie w wartościach znajdują się dokumenty. Dodatkowo w tych bazach można przeglądać wartości.

Przykład oparty jest o MongoDB. Opis zawiera komplet informacji, jak w poprzednim typie. Generalnie przejrzyście opisano uzależnienie od replik w kontekście spójności i dostępności. Przy okazji transakcji dostajemy bezcenne naprowadzenie na produkt RavenDB, który jak jeden z nielicznych w swoim typie wspiera transakcje pomiędzy wieloma operacjami.

Wreszcie możemy przeszukiwać po wartościach. Po krótkiej wzmiance, jak robimy to w bazie CouchDB (poprzez tzw. widoki, czyli zaawansowane zapytania na wartościach = dokumentach), dostajemy cały pięknie opisany przykład zapytania w MongoDB, którego język opiera się na notacji JSON.

Muszę przyznać, że zostałem zachęcony do skorzystania z MongoDB :).

Bezcenne informacje dotyczące skalowania albo zorientowanego na duży ruch odczytu, albo zapisu, utwierdziły mnie tylko w tym.

Niektóre z najbardziej popularnych baz dokumentów, z jakimi się spotkaliśmy, to MongoDB [MongoDB], CouchDB [CouchDB], Terrastore [Terrastore], OrientDB [OrientDB], RavenDB [RavenDB] i oczywiście dobrze znany i często piętnowany Lotus Notes [Notes Storage Facility], który wykorzystuje magazyn dokumentów.

„NoSQL. Kompendium wiedzy” str. 45

Bazy rodziny kolumn

Rodziny kolumn to grupy powiązanych w luźny sposób danych, które zazwyczaj pobierane są jednocześnie. Książka podaje przykład Klienta, gdzie najczęściej potrzebujemy dane o Profilu, ale niekoniecznie o jego Zamówieniach. Właśnie w takim wyspecyfikowaniu pomagają bazy rodziny kolumn, jak np. Cassandra.

Tam pojawiają się pojęcia: standardowa rodzina kolumn oraz rodzina superkolumn. Brzmi abstrakcyjnie. Jednak w tej metodzie jest logika.

Poziom trudności w zrozumieniu tematyki spójności, jak i dostępności są może trochę bardziej złożone, ale opierają się o poznane wcześniej mechanizmy i poparte są przykładami.

Cassandra nie wspiera transakcji, ale zasugerowano tutaj zapoznanie się zewnętrznymi bibliotekami: ZooKeeperCages.

Przy okazji pokazano jak wykorzystywać język zapytań CQL, co nie powinno stawić najmniejszego problemu osobom, które miały styczność dotychczas z SQLem.

Magazyny rodziny kolumn, takie jak Cassandra [Cassandra], HBase [HBase], Hypertable [Hypertable] czy Amazon SimpleDB [Amazon SimpleDB], pozwalają przechowywać dane z kluczami zmapowanymi na wartości i wartości zgrupowane w rodziny kolumn, a każda rodzina kolumn to mapa danych.

„NoSQL. Kompendium wiedzy” str. 109

Bazy grafowe

Coś co pewnie wielu z Was by wykorzystało w stworzonych aplikacja lub aktualnie tworzonych, jeśli tylko byście mogli. Tak, tak, naprawdę warto pomyśleć czasami o wykorzystaniu kilku silników bazodanowych w jednym systemie zamiast trzymać się kurczowo jednego … z przyzwyczajenia.

Jeśli mamy do zmagazynowania jakieś encje (węzły), przy czym pomiędzy encjami występują relacje (krawędzie), które oprócz swoistego jestestwa również mogą posiadać właściwości (konkretyzujące relacje) to wręcz idealnie do tego pasuje baza grafowa.

Wszystko możemy przedstawić na grafie, a skoro na grafie to zapytanie do takiej bazy z łatwością możemy na takim grafie śledzić (zapytanie = trawersowanie po grafie).

Jak możecie się domyślić, skoro mamy graf i relacje w nim to wszystko powinno być w jednym miejscu, na jednym serwerze, a nie w architekturze rozproszonej. Możemy pomyśleć, że inny przypadek nie wchodzi w grę, ale istnieją rozwiązania wspierające dystrybucję danych w takim typie – Infinite Graph, FlockDB.

Spójność, transakcje (oczywiście nawet konieczne) i dostępność opisane są i poparte przykładami z Neo4J.

Z bazami grafowymi w pakiecie otrzymujemy możliwość zapytań z wykorzystaniem specyficznych języków Gremlin, Cypher lub poprzez wiązania wewnątrzprogramowe.

Dostępnych jest wiele baz grafowych, np. Neo4J [Neo4J], Infinite Graph [Infinite Graph], OrientDB [OrientDB] czy FlockDB [FlockDB] (która jest specjalnym przypadkiem: to baza grafowa, która wspiera tylko jednopoziomowe relacje lub listy graniczenia i której nie możesz trawersować przez więcej niż jeden poziom).

„NoSQL. Kompendium wiedzy” str. 120

Ta część książki zawiera jeszcze jeden podrozdział szczególnie ważny z punktu widzenia projektantów baz danych (w przypadku NoSQL raczej twórców aplikacji współpracującej z bazą, która wymaga od nich zmian wraz ze zmianami w aplikacji – eh, zakręcone to wszystko :)). Mowa o zmianach „schematu” w magazynach danych NoSQL.

Wcześniej wspomniałem, że schemat jest niejawny. Tak, jest on zdefiniowany operacjami w aplikacji korzystającej z owej bazy. O ile przyrost pól w obiektach nie stanowi problemu, o tyle temat zmiany „schematu” na potrzeby odczytu danych z bazy jest już tematem nietrywialnym i bardzo przejrzyście opisanym w książce.

Należy dążyć, aby obie wersje aplikacji – stara i nowa – działały na tych samych obiektach.

Dla ciekawych świata znajduje się tutaj kilkustronicowy dział pt. „Poliglotyczne przechowywanie danych”. Nie będę go opisywał, bo stanowi swego rodzaju uzupełnienie wiedzy wcześniej przedstawionej, popartej doświadczeniem autorów. Jeśli wystarczająco zachęciłem Was do tej książki, to ten dział przeczytacie „do kawy”, a na deser pozostanie Wam już tylko (choć nadal ciekawy) wywód na temat wyboru bazy na potrzeby chwili.

Polecam, pozdrawiam!