5 pułapek NoSQL

nosql-pitfalls

Nagrałem film, w którym mówię o zaletach baz NoSQL. Odzew był ciekawy, ale momentami miałem wrażenie, że nie wszyscy widzą dwie strony medalu. Fakty są takie, że na bazach NoSQL można się nieźle przejechać ?.

Wersja wideo

Zarządzanie schematem

Każda baza NoSQL podchodzi do schematu na swój sposób. W niektórych schematu nie ma (MongoDB), w niektórych może być dynamiczny (Elasticsearch), a w niektórych przypomina ten z baz relacyjnych (Cassandra). W modelu konceptualnym dane ZAWSZE mają jakiś schemat. Encje, pola, nazwy, typy, relacje. Niezależnie od typu bazy, fizyczny model to odwzorowanie modelu konceptualnego.

Bazy NoSQL dają nam większą lub mniejszą swobodę działania w zakresie schematu. W MongoDB możemy dodać dwa różne dokumenty o tych samych nazwach pól ale innych typach. Czy ma to sens? Raczej nie. Czy może tak się zdarzyć? Oczywiście, że tak. Prosty błąd ludzki i nasza aplikacja leży.

Kolejna kwestia to relacje między encjami. Nawet jeśli schemat jako taki jest, to musimy mieć gdzieś udokumentowane zależności między danymi. Na podstawie bazy relacyjnej możemy wygenerować diagram ERD. W przypadku baz NoSQL może to się nie udać.

Stosując bazy NoSQL musimy pamiętać o kwestiach zarządzania schematem i walidacji danych. Bez tego dane mogą nam “eksplodować”. Ciekawostka: Niejedna firma porzuciła MongoDB i wybrała PostgreSQL.

Mniej wybacza

Szybkość baz NoSQL to efekt odpowiedniego modelowania, indeksowania i partycjonowania danych. W relacyjnej bazie danych możemy dodawać kolumny, przekształcać tabele, przerzucać dane z jednej tabeli do drugiej, dodawać indeks jeśli wcześniej o nim zapomnieliśmy. W przypadku baz NoSQL nie koniecznie będzie to możliwe. Możliwe, że będziemy musieli wspomóc się jakimiś zewnętrznymi narzędziami jak Apache Spark.

W Elasticsearch jeśli nie trafimy ze schematem/mappingiem indeksu, musimy wykorzystać np. Reindex API, czyli ponownie zaindeksować dane do innego indeksu.

W Cassandrze możemy wykonywać zapytania tylko filtrując po partiton key i clustering key. Jeśli zapomnieliśmy dodać którejś z kolumn do klucza, jest możliwość poratowania się dodatkowym indeksem, ale może to zabić wydajność, jeśli zbiór ten ma dużą liczność.

Brak ACID

Właściwości ACID gwarantowane po stronie bazy upraszczają pisanie kodu. Nie musimy obsługiwać błędów związanych z tym, że dane w tabeli X już są, a w tabeli Y jeszcze nie (o ile w ogóle). Z twierdzenia CAP wiemy, że są bazy spójne jak i “ostatecznie spójne“. Najbardziej popularną bazą danych tego typu jest Apache Cassandra. Eventual consistency wymaga innego podejścia do modelowania danych jak i logiki aplikacji. Kod powinien być napisany w bardziej defensywny sposób, ponieważ nie ma pewności, że zmieniony przed chwilą rekord jest już dostępny z poziomu innej części aplikacji. Przykładem spójnej bazy danych jest HBase, ale nawet Cloudera uważa, że nie zastąpi on relacyjnej bazy danych. Niektóre bazy reklamują się jako spójne, a spójność mają zapewnioną tylko w pewnym zakresie. Np. MongoDB oferuje transakcje, ale dopiero od wersji 4.0 zapewnia transakcje wielu dokumentów.

Brak SQL

Wadą baz NoSQL jest brak… SQL ?. Może się nam to podobać lub nie, ale SQL to podstawa jeśli chodzi o dane. Wielu analityków korzysta na co dzień z SQL i nauka kolejnego języka może zniechęcić do korzystania z bazy. Nie bez powodu powstał Spark SQL lub Beam SQL.

Ograniczona analityka i/lub brak JOINów

Jest to trochę dyskusja różnic między systemami OLTP i OLAP. Przyzwyczajeni jesteśmy do operowania klauzulami GROUP BY lub JOIN, jednak nie każda baza będzie oferować takie możliwości. Agregacje i złączenia mogą być bardzo ograniczone (o ile możliwe) w związku z charakterem danej bazy. Aby uzyskać możliwości analityczne w Apache Cassandra, obok stawia się klaster Apache Spark. O tym jak połączyć jedno z drugim dowiesz się z tego wpisu.

Podsumowanie

Czy w takim razie warto używać baz NoSQL? Oczywiście, że tak. Musimy pamiętać, że każda baza została utworzona z myślą o rozwiązaniu pewnej klasy problemów. Naginanie “przeznaczenia” jest możliwe, ale wiążą się z tym konsekwencje. Śrubki łatwiej wkręcać śrubokrętem, Gwoździe wbijać młotkiem, a malować ściany wałkiem.

Ciekawą alternatywą są bazy NewSQL. Przykładem takiej bazy jest np. CockroachDb i Spanner. Rozwiązują problemy tradycyjnych baz relacyjnych (głównie kwestia skalowania), jednocześnie zachowując właściwości ACID.

3 komentarze do “5 pułapek NoSQL”

    1. Ciekawe. Nie miałem okazji korzystać na poważnie z Cosmos DB. Zastanawiam się jak z utrzymaniem i testowaniem takiego kodu. Nie mam zbyt dobrych wspomnień z procedurami w MSSQL. Prawie zawsze były stare, za długie i najlepszym wyjściem było przepisać je do C# 😁

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *