KosciaKowy blog

Dotychczas wydawało się, że rozwiązaniem wszystkich problemów tego świata jest Cloud Computing. Niestety, gdy już przeniesiono do chmury wszystko co tylko się dało (oraz kilka rzeczy, których się nie dało) okazało się, że część problemów pozostała nierozwiązana. Tak oto nastała moda na NoSQL. Chyba każda rozsądnie myśląca osoba przyzna, że relacyjne bazy danych są takie wczorajsze, a nowe czasy wymagają nowych rozwiązań. Czy aby jednak na pewno? Bawiąc się trochę BigTable na Google AppEngine mam pewne wątpliwości.

Szybkość i skalowalność

Jeśli wierzyć zapewnieniom ewangelistów NoSQL użycie nierelacyjnej bazy danych sprawi, że nasza aplikacja znacząco przyśpieszy, problem skalowalności zostanie na zawsze rozwiązany i nie straszne nam będą miliony użytkowników. Niestety w rzeczywistości przeciętny startup o milionach, czy nawet tysiącach użytkowników może tylko sobie pomarzyć. Nie czarujmy się, problem skalowalności jest na początku problemem całkowicie abstrakcyjnym. Na pewno jest o wiele więcej poważniejszych spraw, którymi należy się zająć zamiast zastanawiać się, czy nasza aplikacja podoła obciążeniu rzędu tysiąca żądań na sekundę.

Warto też dodać, że nie każda aplikacja skorzysta na bazie nierelacyjnej. Z moich doświadczeń z BigTable wynika, że o ile odczyty z bazy są dosyć szybkie, tak zapis już niekoniecznie. Jeśli aplikacja wykonuje bardzo dużo zapisów do bazy danych zysk może być niewielki. W dodatku mogą się pojawić problemy ze spójnością danych, jeśli wystąpią problemy z replikacją danych pomiędzy serwerami (uroki działania w chmurze). A nawet w przypadku aplikacji głównie odczytujących dane z bazy często lepszy efekt daje intensywne cache'owanie wyników zapytań. Rodzaj bazy danych schodzi więc wtedy na drugi plan.

Baza wiedzy

Kolejna sprawa, o której wiele osób zapomina to fakt, że właściwy schemat bazy danych i optymalne zapytania same się nie napiszą. Pracując z SQLem wystarczy otworzyć dowolną książkę, pogadać ze znajomym fachowcem od baz danych i już wszystko wiemy. Cała, wypracowana przez lata wiedza jest w zasięgu ręki. W przypadku NoSQL musimy wyrzucić do kosza sporą część dotychczasowej wiedzy. Zmuszeni jesteśmy do poruszania się trochę po omacku, eksperymentując na każdym kroku. Nagle okazuje się, że to co działało znakomicie w świecie relacyjnym tu nie ma zastosowania lub jest bardzo niewydajne. Wiele z nowych rozwiązań dla osoby myślącej SQLem nie będzie wcale takie oczywiste, a część wyda się wręcz odrobinę szalona. Na przykład denormalizacja danych - w świecie baz nierelacyjnych nie jest niczym niezwykłym.

Ograniczenia, ograniczenia

No dobra, korzystając z baz NoSQL zyskujemy lepszą skalowalność, brak sztywnego schematu bazy danych, sporą elastyczność, mniej problemów z mapowaniem danych w bazie do obiektów zdefiniowanych w kodzie i pewnie jeszcze kilka rzeczy, o których nie mam pojęcia. Ale pojawiają się ograniczenia. Czasem bardzo istotne. Po pierwsze bazy NoSQL nie są relacyjne. Może i jest to oczywiste, ale chyba nie wszyscy tak do końca zdają sobie sprawę, co to tak na prawdę oznacza. Całą obsługę relacyjności pomiędzy danymi (jeśli jest nam potrzebna) trzeba emulować w kodzie aplikacji, na wbudowane w bazę danych rozwiązania nie ma co liczyć. Po drugie często brak JOINów. Oczywiście, można się obejść bez JOINów w zapytaniach ale wymaga to odpowiedniego przygotowania modeli danych. Po trzecie ograniczenia w składni zapytań. W przypadku BigTable na Google AppEngine mamy dosyć ograniczoną możliwość sortowania i filtrowania danych. Potrafi to bardzo utrudnić pisanie wydajnych zapytań, a przecież rozliczany jestem z każdej milisekundy pracy procesora.

Dojrzałość rozwiązania

Na koniec warto wspomnieć, że bazy NoSQL są najczęściej rozwiązaniami stosunkowo młodymi. Co za tym idzie daleko im do dojrzałości, a więc i niezawodności, rozwijanych od lat baz relacyjnych. Trzeba być gotowym na odkrywania nowych błędów, napotykanie się na problemy, z którymi nikt wcześniej się nie zetknął.

NoSQL - czy warto?

Wszystko zależy od tego co tak na prawdę nasza aplikacja ma robić. Nie wszystko nadaje się do działania w chmurze z nierelacyjną bazą danych. Trzeba też zadać sobie pytanie czy koszt nauki nowych nierelacyjnych rozwiązań, oraz sposobów na obejście ograniczeń, nie przewyższy zysków jakie bazy NoSQL mogą nam dać.