Typowo dla siebie, prócz pracy zawodowej, pracy prywatnej nad projektami, a także szkolenia się w ramach np. Sekurak Academy czy przygotowań pod certyfikacje, rozwijam się również pasywnie, przeszukując źródła takie jak LinkedIn, blogi czy YouTube.

Ostatnio natrafiłem na materiał dotyczący pułapki NoSQL, w którą wpada większość niedoświadczonych programistów, bądź nawet całe zespoły. W związku z tym chciałem poruszyć ten temat w oparciu o przykłady z własnego „podwórka”.

NoSQL i pułapki?

Biorąc pod uwagę trendy sprzed jeszcze 10 lat, zestawienie NoSQL — w ogólności baz tego typu — i pułapek wydaje się być nieporozumieniem.

Faktem jest, że istnieje cała paleta zastosowań, w ramach których należy użyć właśnie tego typu bazy danych. Natomiast niejednokrotnie napotykałem zespoły, które używały tego typu baz bez konkretnego uzasadnienia.

Przejmowałem projekty, które nie miały żadnego uzasadnienia ani w ramach logiki biznesowej, ani charakterystyki wydajnościowej. Nie istniała realna potrzeba typowo infrastrukturalna.

A więc, skoro tak, to jakie to są „pułapki”?

Przede wszystkim: brak schemy, czyli schematu. Co do zasady jest to główna zaleta tych baz — nie wymuszają go i nie posiadają narzutu wynikającego ze schemy. Natomiast nie wszystko, co jest łatwe lub coś upraszcza, jest automatycznie dobre.

O ile w systemie prostym brak schematu, który byłby jawny i zarządzany z pojedynczego miejsca, może kompletnie nie mieć znaczenia i nie mieć żadnego impactu na to, jak dany system będzie się zachowywał w trakcie dalszego rozwoju, tak system rozproszony, rozbudowany czy po prostu modularny będzie już podatny na tego typu problemy. Brak schematu widocznego z perspektywy jednego miejsca — bazy danych — powoduje rozmycie pojęcia logiki biznesowej.

Można też przytoczyć starsze podejście: Database First. W starszych systemach organizowano całość wokół tego, jak zorganizowana była baza. Sama schema natomiast była zamodelowana wokół logiki biznesowej. To powodowało, że migrowanie baz było trudniejsze, a całość była zamodelowana względem jednego źródła prawdy i jednego typu takiego źródła — SQL-owej bazy danych.

Moje podejrzenie jest takie, że to spowodowało odwrotny efekt i ucieczkę od tego podejścia, bo „winą było to, że musi być schemat”, a nie sama próba rozwiązania problemu. O ile sam zamysł jest w porządku, tak nie chodzi o ucieczkę od tworzenia schematu, a o rozważne użycie go jako atutu w danych zastosowaniach.

Przechowywanie tymczasowych danych, takich jak sesja, czy cache’owanie „luźnych” struktur danych w tzw. międzyczasie jest trudne w bazie o usztywnionej schemie. Bazy NoSQL, takie jak Redis, Mongo czy CosmosDB, pozwalają wrzucić tego typu dane jak do „worka”, a następnie je wyciągnąć i usunąć. I to zazwyczaj niskim kosztem czasu procesora na odczyt.

Dodatkowym problemem jest zazwyczaj niedopasowanie wybranego narzędzia do konkretnego zastosowania. Konkretne bazy, takie jak Mongo czy CosmosDB, posiadają swoje mocne strony, np. niższy czas odczytu czy niższe obciążenie procesora przy zapisie lub odczycie — zależnie od tego, jak dany silnik został zaimplementowany.

Łącząc te dwie kwestie, można wywnioskować, że używanie NoSQL jako core dla swojej logiki biznesowej będzie zwyczajnie pułapką. Nie zawsze tak będzie. Istnieją przypadki, w których można przyjąć, że to się nie wydarzy, np. systemy rozproszone, w których logika biznesowa znajduje się wyłącznie w ramach jednego, odrębnego mikro- lub makroserwisu. Wtedy modelowanie „schemy” na wierzchu bazy NoSQL pozostaje w obszarze pojedynczego systemu, a reszta infrastruktury widzi dane przez pryzmat systemu, nie zaś z perspektywy bezpośredniego dostępu do samych danych, które bez zduplikowanej wiedzy o schemie po prostu będą „bełkotem”.

Moje podejście SQL vs NoSQL

W przypadku Pika Cloud podejście jest proste. Najważniejsze „biznesowo” encje są w SQL-owej bazie w ramach EventStore’u zaimplementowanego na NoSQL-like nakładce na PostgreSQL, czyli MartenDB, lub są zwyczajnymi relacjami z powiązaniami albo bez powiązań.

System oczywiście użytkuje bazy dokumentowe w sensie stricte, czyli CosmosDB, a także bazy typu Key-Value, czyli Redis.

Z tą różnicą, że w przypadku CosmosDB chodziło głównie o odczyt. Według Microsoftu jest ona stworzona głównie pod odczyt, a nie pod zapis. PikaNote na Azure odczytuje po sieci LAN, wewnątrz Azure’a, „deskryptory” notatek. Deskryptory pozwalają elastycznie modelować listę widocznych notatek, budować paginowaną listę itd., same jednak nie zawierają treści notatki — tekstowej czy sheet.

Zawartość jest w pliku PCN przechowywana w kategorii „Różne”, pod tagiem „notes”, w Pika Core.

A więc mamy dwie bazy dla jednego flow tak naprawdę: dokumentową i obiektową — CosmosDB i S3. Jednocześnie część danych pozwalających lokalizować pliki wewnątrz S3, stanowiących „listing” plików, to indeks przechowywany wewnątrz Redisa.

Redis faktycznie ma ustawiony backup, co nie zmienia faktu, że odtworzenie tego konkretnego zestawu danych to kwestia uruchomienia zestawu workerów w tle z użyciem konsoli administratora systemu.

Tutaj widać uzależnienie tego, co i gdzie jest przechowywane, od tego, jak trwałe i jak łatwe do odtworzenia są konkretne dane. Im bardziej trwałe i nastawione na przechowywanie są dane, tym bardziej powinniśmy być skłonni do użycia bazy SQL.

Wyjątkiem od tej reguły będzie NoSQL-owa baza, jaką jest Elasticsearch, przy czym Elasticsearch powinien być interpretowany jako usługa, a nie baza danych, mimo że pełni taką rolę.