Co to jest NoSQL? Bazy danych dla przyszłości w chmurze

Jedną z najbardziej podstawowych decyzji, jakich należy dokonać podczas tworzenia aplikacji, jest użycie bazy danych SQL lub NoSQL do przechowywania danych. Konwencjonalne bazy danych SQL (tj. Relacyjne) są wynikiem dziesięcioleci ewolucji technologii, dobrych praktyk i testów warunków skrajnych w świecie rzeczywistym. Zostały zaprojektowane z myślą o niezawodnych transakcjach i zapytaniach ad hoc, które są podstawą aplikacji biznesowych. Ale są też obarczone ograniczeniami - takimi jak sztywny schemat - co sprawia, że ​​są mniej odpowiednie dla innych rodzajów aplikacji.

Bazy danych NoSQL powstały w odpowiedzi na te ograniczenia. Systemy NoSQL przechowują dane i zarządzają nimi w sposób, który zapewnia dużą szybkość działania i dużą elastyczność ze strony programistów. Wiele z nich zostało opracowanych przez firmy takie jak Google, Amazon, Yahoo i Facebook, które szukały lepszych sposobów przechowywania treści lub przetwarzania danych dla masowych witryn internetowych. W przeciwieństwie do baz danych SQL wiele baz danych NoSQL można skalować w poziomie na setki lub tysiące serwerów.

Zalety NoSQL nie są jednak pozbawione kosztów. Systemy NoSQL zazwyczaj nie zapewniają takiego samego poziomu spójności danych jak bazy danych SQL. W rzeczywistości, podczas gdy bazy danych SQL tradycyjnie poświęcały wydajność i skalowalność na rzecz właściwości ACID stojących za niezawodnymi transakcjami, bazy danych NoSQL w dużej mierze porzuciły te gwarancje ACID dotyczące szybkości i skalowalności.

Krótko mówiąc, bazy danych SQL i NoSQL oferują różne kompromisy. Chociaż mogą one konkurować w kontekście konkretnego projektu, jak w, co wybrać do tego wniosku lub tej aplikacji, są komplementarne w większy obraz. Każdy jest dostosowany do różnych przypadków użycia. Decyzja jest nie tyle kwestią „albo / albo”, ale jest to kwestia tego, które narzędzie jest odpowiednie do pracy.

NoSQL kontra SQL

Podstawowa różnica między SQL i NoSQL nie jest aż tak skomplikowana. Każdy ma inną filozofię dotyczącą sposobu przechowywania i pobierania danych.

W przypadku baz danych SQL wszystkie dane mają własną strukturę. Konwencjonalna baza danych, taka jak Microsoft SQL Server, MySQL lub Oracle Database, używa schematu - formalnej definicji sposobu, w jaki będą składane dane wstawiane do bazy danych. Na przykład dana kolumna w tabeli może być ograniczona tylko do liczb całkowitych. W efekcie dane zapisane w kolumnie będą miały wysoki stopień normalizacji. Sztywny schemat bazy danych SQL ułatwia również wykonywanie agregacji danych, na przykład za pomocą funkcji JOIN.

Dzięki NoSQL dane mogą być przechowywane bez schematu lub w dowolnej formie. W każdym rekordzie można przechowywać dowolne dane. Wśród baz danych NoSQL znajdziesz cztery popularne modele przechowywania danych, które prowadzą do czterech popularnych typów systemów NoSQL:

  1. Bazy danych dokumentów (np. CouchDB, MongoDB). Wstawione dane są przechowywane w postaci dowolnych struktur JSON lub „dokumentów”, w których dane mogą być dowolnymi liczbami, od liczb całkowitych po ciągi tekstowe. Nie ma nieodłącznej potrzeby określania, jakie pola, jeśli w ogóle, będzie zawierał dokument.
  2. Sklepy klucz-wartość (np. Redis, Riak). Dostęp do dowolnych wartości - od prostych liczb całkowitych lub ciągów po złożone dokumenty JSON - uzyskuje się w bazie danych za pomocą kluczy.
  3. Magazyny z szerokimi kolumnami (np. HBase, Cassandra). Dane są przechowywane w kolumnach zamiast w wierszach, jak w konwencjonalnym systemie SQL. Dowolną liczbę kolumn (a tym samym wiele różnych typów danych) można grupować lub agregować w zależności od potrzeb w przypadku zapytań lub widoków danych.
  4. Grafowe bazy danych (np. Neo4j). Dane są przedstawiane jako sieć lub wykres jednostek i ich relacji, przy czym każdy węzeł na wykresie jest porcją danych o dowolnej formie.

Magazyn danych bez schematu jest przydatny w następujących scenariuszach:

  1. Chcesz szybkiego dostępu do danych i bardziej zależy Ci na szybkości i prostocie dostępu niż niezawodnych transakcjach lub spójności.
  2. Przechowujesz duże ilości danych i nie chcesz zamknąć się w schemacie, ponieważ późniejsza zmiana schematu może być powolna i bolesna.
  3. Pobierasz nieustrukturyzowane dane z jednego lub kilku źródeł, które je tworzą i chcesz zachować dane w ich oryginalnej postaci, aby zapewnić maksymalną elastyczność.
  4. Chcesz przechowywać dane w strukturze hierarchicznej, ale chcesz, aby te hierarchie były opisywane przez same dane, a nie przez zewnętrzny schemat. NoSQL pozwala na przypadkowe odwoływanie się do danych w sposób bardziej złożony dla baz danych SQL do emulacji.

Zapytania do baz danych NoSQL

Structured Query Language używany w tradycyjnych bazach danych zapewnia jednolity sposób komunikacji z serwerem podczas przechowywania i pobierania danych. Składnia SQL jest w dużym stopniu ustandaryzowana, więc chociaż poszczególne bazy danych mogą różnie obsługiwać pewne operacje (np. Funkcje okien), podstawy pozostają takie same.

Z kolei każda baza danych NoSQL ma zwykle własną składnię do wykonywania zapytań i zarządzania danymi. Na przykład CouchDB wykorzystuje zapytania w postaci JSON, wysyłane przez HTTP, do tworzenia lub pobierania dokumentów ze swojej bazy danych. MongoDB wysyła obiekty JSON za pomocą protokołu binarnego, za pośrednictwem interfejsu wiersza poleceń lub biblioteki językowej.

Niektóre produkty NoSQL mogą używać składni podobnej do SQL do pracy z danymi, ale tylko w ograniczonym zakresie. Na przykład Apache Cassandra, baza danych magazynu kolumn, ma własny język podobny do SQL, Cassandra Query Language lub CQL. Część składni języka CQL pochodzi prosto z podręcznika SQL, na przykład słowa kluczowe SELECT lub INSERT. Ale nie ma możliwości wykonania JOIN lub podzapytania w Cassandrze, dlatego powiązane słowa kluczowe nie istnieją w CQL.

Architektura bez współdzielenia

Wybór projektu wspólny dla systemów NoSQL to architektura „nic wspólnego”. W projekcie „nic nie współdzielonego” każdy węzeł serwera w klastrze działa niezależnie od każdego innego węzła. System nie musi uzyskiwać konsensusu z każdego węzła, aby zwrócić część danych do klienta. Zapytania są szybkie, ponieważ można je zwracać z dowolnego węzła znajdującego się najbliżej lub najwygodniejszego.

Kolejną zaletą „nic wspólnego” jest odporność i skalowalność. Skalowanie klastra w poziomie jest tak proste, jak rozpędzanie nowych węzłów w klastrze i czekanie, aż zsynchronizują się z innymi. Jeśli węzeł NoSQL ulegnie awarii, inne serwery w klastrze będą nadal pracować. Wszystkie dane pozostają dostępne, nawet jeśli dostępnych jest mniej węzłów do obsługi żądań.

Należy zauważyć, że projekt „nic nie współdzielonego” nie dotyczy wyłącznie baz danych NoSQL. Wiele konwencjonalnych systemów SQL można skonfigurować bez współdzielenia, chociaż zazwyczaj wiąże się to z poświęceniem spójności w całym klastrze na rzecz wydajności.

Ograniczenia NoSQL

Jeśli NoSQL zapewnia tak dużą swobodę i elastyczność, dlaczego nie zrezygnować całkowicie z SQL? Prosta odpowiedź: wiele aplikacji wciąż wymaga tego rodzaju ograniczeń, spójności i zabezpieczeń, jakie zapewniają bazy danych SQL. W takich przypadkach niektóre „zalety” NoSQL mogą zmienić się w wady. Inne ograniczenia wynikają z faktu, że systemy NoSQL są stosunkowo nowe. 

Brak schematu

Nawet jeśli pobierasz dane w dowolnym formacie, prawie zawsze musisz nałożyć na nie ograniczenia, aby były przydatne. W przypadku NoSQL nakładanie ograniczeń wiąże się z przeniesieniem odpowiedzialności z bazy danych na twórcę aplikacji. Na przykład programista może narzucić strukturę za pomocą systemu mapowania relacyjnego obiektu lub ORM. Ale jeśli chcesz, aby schemat działał z samymi danymi , NoSQL zazwyczaj tego nie robi.

Niektóre rozwiązania NoSQL zapewniają opcjonalne mechanizmy typowania i walidacji danych. Na przykład Apache Cassandra ma mnóstwo natywnych typów danych, które przypominają te, które można znaleźć w konwencjonalnym języku SQL.

Ostateczna spójność

Systemy NoSQL oferują silną lub natychmiastową spójność dla lepszej dostępności i wydajności. Konwencjonalne bazy danych zapewniają, że operacje są niepodzielne (wszystkie części transakcji kończą się powodzeniem lub żadna), spójne (wszyscy użytkownicy mają ten sam widok danych), izolowane (transakcje nie konkurują) i trwałe (po ich zakończeniu przetrwają) awaria serwera).

Te cztery właściwości, łącznie określane jako ACID, są obsługiwane inaczej w większości systemów NoSQL. Zamiast natychmiastowej spójności w całym klastrze uzyskuje się spójność ostateczną ze względu na czas potrzebny do skopiowania aktualizacji do innych węzłów w klastrze. Dane wstawione do klastra są ostatecznie dostępne wszędzie, ale nie możesz zagwarantować, kiedy.

Semantyka transakcji, która w systemie SQL gwarantuje, że wszystkie etapy transakcji (np. Wykonanie sprzedaży i zmniejszenie zapasów) są zakończone lub wycofane, zazwyczaj nie są dostępne w NoSQL. W przypadku każdego systemu, w którym musi istnieć „jedno źródło prawdy”, takiego jak bank, podejście NoSQL nie będzie działać dobrze. Nie chcesz, aby saldo Twojego banku różniło się w zależności od tego, do którego bankomatu idziesz; chcesz, aby wszędzie zgłaszano to samo.

Niektóre bazy danych NoSQL mają częściowe mechanizmy obejścia tego problemu. Na przykład MongoDB ma gwarancje spójności dla poszczególnych operacji, ale nie dla całej bazy danych. Microsoft Azure CosmosDB umożliwia wybranie poziomu spójności na żądanie, dzięki czemu można wybrać zachowanie, które pasuje do Twojego przypadku użycia. Ale w przypadku NoSQL oczekuj spójności ostatecznej jako zachowania domyślnego.

Blokada NoSQL

Większość systemów NoSQL jest koncepcyjnie podobnych, ale są implementowane bardzo różnie. Każdy ma zwykle swoje własne metafory i mechanizmy wyszukiwania i zarządzania danymi.

Jednym z efektów ubocznych jest potencjalnie wysoki stopień sprzężenia między logiką aplikacji a bazą danych. Nie jest to takie złe, jeśli wybierzesz system NoSQL i trzymasz się go, ale może stać się przeszkodą, jeśli zmienisz systemy w przyszłości.

Jeśli przeprowadzasz migrację z, powiedzmy, MongoDB do CouchDB (lub odwrotnie), musisz zrobić coś więcej niż tylko migrację danych. Musisz także przejrzeć różnice w dostępie do danych i metaforach programistycznych - innymi słowy, musisz przepisać części aplikacji, które mają dostęp do bazy danych.

Umiejętności NoSQL

Kolejną wadą NoSQL jest względny brak wiedzy. Tam, gdzie rynek konwencjonalnych talentów SQL jest wciąż dość duży, rynek umiejętności NoSQL dopiero się rodzi.

Dla porównania, Indeed.com informuje, że na koniec 2017 r. Liczba ofert pracy dla konwencjonalnych baz danych SQL - MySQL, Microsoft SQL Server, Oracle Database itd. - pozostaje wyższa w ciągu ostatnich trzech lat niż liczba zleceń dla MongoDB, Couchbase i Cassandra. Zapotrzebowanie na wiedzę specjalistyczną NoSQL rośnie, ale wciąż stanowi ułamek rynku konwencjonalnego SQL.

Łączenie SQL i NoSQL

Możemy spodziewać się, że niektóre różnice między systemami SQL i NoSQL znikną z czasem. Już wiele baz danych SQL akceptuje dokumenty JSON jako rodzimy typ danych i może wykonywać zapytania dotyczące tych danych. Niektóre mają nawet natywne sposoby narzucania ograniczeń na dane JSON, dzięki czemu są obsługiwane z tymi samymi rygorami, co konwencjonalne dane wierszowo-kolumnowe.

Z drugiej strony bazy danych NoSQL nie tylko dodają języki zapytań podobne do SQL, ale także inne możliwości tradycyjnych baz danych SQL. Na przykład co najmniej dwie bazy danych dokumentów - MarkLogic i RavenDB - obiecują zgodność z ACID.

Tu i ówdzie pojawiają się oznaki, że przyszłe generacje baz danych przekroczą te paradygmaty i będą oferować zarówno funkcjonalność NoSQL, jak i SQL. Na przykład usługa Azure Cosmos DB firmy Microsoft używa zestawu prymitywów pod maską, aby zamiennie odtwarzać zachowania obu rodzajów systemów. Google Cloud Spanner to baza danych SQL, która łączy silną spójność z poziomą skalowalnością systemów NoSQL.

Jednak czyste systemy SQL i czyste systemy NoSQL będą miały swoje miejsce przez wiele lat. Szukaj NoSQL, aby uzyskać szybki, wysoce skalowalny dostęp do danych w dowolnym formacie. Wiąże się to z kilkoma kosztami, takimi jak spójność odczytów i inne zabezpieczenia wspólne dla baz danych SQL. Ale w przypadku wielu aplikacji te zabezpieczenia mogą być warte wymiany za to, co oferuje NoSQL.