Czy NoSQL to przyszłość baz danych?

Relacyjne bazy królują od wielu lat na rynku. Ich zalet nie trzeba wymieniać, stały się powszechnym w użytku narzędziem. Mają jednak swoje wady. Czy okażą się gwoździem do trumny? Raczej takiego scenariusza bym nie przewidywał, sporą część rynku odbiorą im jednak pewnie tzw. bazy „NoSQL”. Znajdą one zastosowanie zwłaszcza w celach specjalistycznych i dedykowanych. Co sprawiło, że pozycja relacyjnych baz danych jest zagrożona, skąd wzięło się aktualnie bardzo modne określenie „NoSQL” i czy aby na pewno jest trafne – o tym przeczytasz w niniejszym artykule. Zapraszam wszystkich do świata, w którym relacje przestają mieć znaczenie.

„Przechowywanie danych z myślą jedynie o danych to najkrótsza droga do katastrofy”.

Odkąd zaczęto tworzyć biznesowe oprogramowanie (ale nie tylko), relacyjne bazy danych były narzędziem, które w naturalny sposób implementowało się w takich rozwiązaniach jako podstawowy magazyn danych. Jako programista, przy budowaniu nowego projektu zastanawiam się raczej, którą z dostępnych baz danych wybrać, jakie narzędzia będą mi potrzebne, który producent dostarcza najlepsze mechanizmy niezbędne dla mnie w danym momencie, i kluczowy aspekt – na które mnie stać. Mamy do wyboru bazy danych MySql, PostgreSql, Oracle, Microsoft SQL, które mają największy udział w rynku, ale istnieją też inne, o których teraz nie będę wspominał. W czasie studiów usłyszałem o czymś nowym – obiektowych bazach danych. Chociaż idea tej technologii wywodzi się jeszcze z lat 90. i przedstawia dość ciekawą koncepcję, nie zagroziła silnemu rynkowi relacyjnych baz danych. To właśnie w czasie stadiów zacząłem zgłębiać tematykę baz danych określanych jako strumieniowe i NoSQL.

Dlaczego relacyjne bazy danych mają tak silną pozycję na rynku?

Odpowiedź wbrew pozorom jest bardzo prosta – ponieważ reprezentują sobą wartości, które naprawdę trzeba docenić. Jakie cechy są najważniejsze?

• Możliwość trwałego składowania danych – po utracie zasilania i ponownym uruchomieniu serwera, nasze dane nadal tam się znajdują.
• Relacyjne bazy danych oferują większą elastyczność niż system plików, kiedy chcemy uzyskać dostęp do pewnych fragmentów informacji, a nasza baza jest duża – realizuje się to w miarę szybko (szybkość jest w tym wypadku pojęciem względnym, ponieważ zależy oczywiście od zapytania, czy następuje jakaś konkatenacja, jakie dane są wybierane i jak porównywane).
• Współbieżność, czyli mechanizm, który gwarantuje nam, że wszystkie operacje wykonywane przez użytkowników w tym samym czasie na tej samej jednostce informacji zostaną skoordynowane poprawnie. O co w tym chodzi? Załóżmy, że mamy do wynajęcia samochód – pan Kowalski i pan Nowak w tym czasie są na stronie internetowej i znaleźli auto, każdy chce je wynająć na najbliższy weekend. W naszym systemie musi być zagwarantowany mechanizm, który umożliwi tylko jednemu panu wynajem tego auta, a drugiemu uniemożliwi. Mimo, że z pozoru wydaje się to proste, zachowanie współbieżności jest bardzo trudne, a błędy mogę pojawić się nawet w najlepiej zaprojektowanych systemach. Pomocą w tej sytuacji są oczywiście mechanizmy transakcji.
• Obsługa błędów – dzięki transakcjom mamy dostarczony dobry i sprawdzony mechanizm wycofywania zmian w przypadku wystąpienia błędów. Jeżeli pojawią się problemy z przeprowadzeniem i realizacją zapytania, wszystkie zmiany możemy wycofać.
• Dzięki systemowi transakcji możemy również integrować wiele aplikacji poprzez współdzielenie zasobów jednej bazy danych. Dzięki temu zmiany wprowadzone przez wiele rożnych systemów są widoczne dla innych, a dane są spójne.
• Język SQL – jego dialekty w różnych systemach, dostarczanych przez każdego z dostawców, są podobne, a np. mechanizmy transakcji działają prawie tak samo. Dzięki takiej sytuacji programiści i specjaliści zajmujący się bazami danych, znając podstawy modelu relacyjnego, mogą go wykorzystywać na wielu platformach. Wszystko jest w pewnym stopniu ustandaryzowane.

Jakie są wady modelu relacyjnego?

Zalety relacyjnego modelu baz danych są nieocenione, jednak bazy transakcyjne mają również swoje słabe strony.

Negatywne cechy:

• W bazach transakcyjnych ACID przeszkadza w pracy w klastrze.
• Model danych w relacyjnych bazach danych jest mniej elastyczny, niż w przypadku rozwiązania z rodziny NoSQL.

Są to dwie kluczowe sprawy, które należy wziąć pod uwagę przy wyborze odpowiedniej bazy danych dla rozwiązania, które projektujemy.

Rozwiązania

Jaki mamy wybór w przypadku NoSQL?

• Obiektowe bazy danych. Jak wspomniałem wcześniej, jako pierwszy na rynku pojawił się mechanizm obiektowych baz danych, jednak z uwagi na znaczną popularność ustandaryzowanego języka SQL oraz wąskich specjalizacji pracowników sektora IT, nie udało się go spopularyzować. Główną przyczyną był podział obowiązków między osoby zajmujące się stricte bazami danych a programistów.
  Choć z punktu widzenia języków programowania, żonglowanie strukturami opartymi o obiekty wydaje się być najbardziej naturalne i logiczne, o tyle w przypadku baz danych, odwzorowanie relacji wymaga sporego nakładu pracy, ponieważ w przypadku operacji na relacjach, dane nie mogą zawierać struktur i muszą być przechowywane w sposób maksymalnie uproszczony. Przykładem bazy danych obiektowych jest db4o.

Do przechowania obiektów w bazie danych db4o użyta została metoda store klasy ObjectContainer. Przykładowy kod:

ObjectContainer container =
Db4oEmbedded.openFile("db4objectsPodstawy.db4o");
try {
Kierowca kierowca = new Kierowca("Xinski",19);
container.store(kierowca);
} finally {
container.close();
}

• Baza klucz wartość – z informacji, jakie znalazłem w Internecie, wynika, że jest to najprostsza implementacja NoSQL. W tym wypadku opieramy się na mapie, która pozwala dodawać i odczytywać wartości poprzez odwołanie się do klucza. Przykładem bazy danych klucz wartość jest np. Riak, bądź Redis.

Przykładowy kod, który można wykorzystać w kontrolerze, jeżeli korzystamy z REDIS:

$redis = Redis::connection();
$redis->set('company', 'Grupa Tense');
$company= $redis->get('company');
echo $company;

Redis głównie jest stosowany podczas optymalizacji i skalowaniu
– dane które nie zmieniają się przy każdym odświeżeniu strony jak np. tytuł strony www
– skrypty które długo się wykonują

• Bazy zorientowane dokumentowo – dokumenty to samoopisujące się, hierarchiczne struktury drzewiaste, które mogą składać się z map, kolekcji i wartości. Przechowywane dokumenty są do siebie podobne, ale nie muszą być dokładnie takie same. Bazy tego typu przechowują dane w postaci klucz-klucz wartość.

Przykład struktury danych:

{ imie: "Jan",
nazwisko: "Nowak",
nr_indeksu: 1174145,
oceny: [5, 3, 4.5, 3.5, 4]
dzienny: true
}

Przykładem bazy danych kluczem wartość jest np. MongoDB, RavenDB.

• Rodzina kolumn – podstawową jednostką przechowywania danych jest kolumna. Kolumna to para nazwa: wartość, gdzie nazwa jest kluczem dla wartości. Dalej dane są przechowywane w postaci wierszy, do których jest przypisany klucz. To z kolei rozszerza się na rodzinę kolumn. Przykładem magazynu rodziny kolumn jest np. Cassandra.

• Bazy grafowe – baza danych, która wykorzystuje struktury grafów z węzłami. Można myśleć o węźle jako instancji obiektu, z krawędziami i własnościami do przedstawiania i przechowywania danych oraz do obsługi zapytań semantycznych. Implementacją takiego modelu grafowego jest np. struktura hierarchiczna w firmie. Rozwiązanie można oprzeć na takiej bazie danych jakNeo4J, FlockDB.

Podsumowanie

Czy NoSQL ma w ogóle sens? Wydaje mi się, że tak, ponieważ jest to zespół technologii oferujący konkretne rozwiązania. Nie zastąpią one tradycyjnych relacyjnych baz danych, bo te mają swoje dedykowane zastosowania – tak samo jest z zaprezentowanymi przeze mnie wcześniej przykładami. Ogólnie definicja skrótu NoSQL nie jest jednoznaczna i nie opisuje idealnie samego zjawiska. Nie ma żadnej przesłanki, która by mówiła, że bazy NoSQL nie mogą wykorzystywać języka zapytań SQL. Niektóre z baz przypisywanych do określenia „NoSQL” posiadają język zapytań, i logiczne jest to, że będzie on dosyć podobny do SQL – dzięki takiemu zabiegowi ich nauka staje się łatwiejsza. Co zatem może oznaczać i do czego odnosić się ten termin? Według wyjaśnienia spotykanego często w literaturze jest to „Not Only SQL”, ale w tym wypadku, czy do definicji „nie tylko SQL” nie pasowałaby również baza danych Oracle? Nasz dowód jest błędny, a postawione hipotezy nieprawdziwe, gdyż wyjaśniając definicję sami byśmy jej przeczyli. Co w związku z tym zrobić? Określenie jest dość nieścisłe, więc próba jego dokładnego wyjaśnienia może być bardzo trudna. Najlepiej przyjąć, że „NoSQL” to określony zestaw baz, zazwyczaj open source, które przeważnie nie wykorzystują języka zapytań SQL i zostały stworzone na przestrzeni kilku ostatnich lat.

Bazy danych są tematem, który można drążyć bez końca, niestety podróż do tego fascynującego świata musimy już zakończyć. Artykuł jest tylko małym skrawkiem ogromnej góry lodowej technologii przetwarzania danych, który jedynie przybliżył podstawowe aspekty takich systemów informatycznych.