Ostateczny przewodnik po bazach danych NoSQL

Nie ma wątpliwości, że sposób, w jaki aplikacje internetowe radzą sobie z danymi, zmienił się znacząco w ciągu ostatniej dekady. Zbieranych jest więcej danych i więcej użytkowników uzyskuje do nich dostęp jednocześnie niż kiedykolwiek wcześniej. Oznacza to, że skalowalność i wydajność są większym wyzwaniem niż kiedykolwiek w przypadku relacyjnych baz danych opartych na schemacie, a zatem mogą być trudniejsze do skalowania.

Ewolucja NoSQL

Problem skalowalności SQL został dostrzeżony przez firmy Web 2.0 z ogromnymi, rosnącymi potrzebami w zakresie danych i infrastruktury, takie jak Google, Amazon i Facebook. Wymyślili własne rozwiązania problemu – technologie takie jak BigTable, DynamoDB i Cassandra.

To rosnące zainteresowanie zaowocowało powstaniem wielu systemów zarządzania bazami danych NoSQL (DBMS), z naciskiem na wydajność, niezawodność i spójność. Wiele istniejących struktur indeksowania zostało ponownie wykorzystanych i ulepszonych w celu zwiększenia wydajności wyszukiwania i odczytu.

Po pierwsze, istniały zastrzeżone (zamknięte) typy baz danych NoSQL opracowane przez duże firmy w celu zaspokojenia ich specyficznych potrzeb, takie jak BigTable Google, który uważany jest za pierwszy system NoSQL, oraz DynamoDB firmy Amazon.

Sukces tych zastrzeżonych systemów zapoczątkował rozwój wielu podobnych open-source i zastrzeżonych systemów baz danych, z których najpopularniejsze to Hypertable, Cassandra, MongoDB, DynamoDB, HBase i Redis.

Co wyróżnia NoSQL?

Jedną z kluczowych różnic między bazami danych NoSQL a tradycyjnymi relacyjnymi bazami danych jest fakt, że NoSQL jest formą nieustrukturyzowanej pamięci masowej .

Oznacza to, że bazy danych NoSQL nie mają ustalonej struktury tabel, jak te, które można znaleźć w relacyjnych bazach danych.

Zalety i wady baz danych NoSQL

Zalety

Bazy danych NoSQL mają wiele zalet w porównaniu z tradycyjnymi, relacyjnymi bazami danych.

Jedną z głównych podstawowych różnic jest to, że bazy danych NoSQL mają prostą i elastyczną strukturę. Są wolne od schematów.

W przeciwieństwie do relacyjnych baz danych bazy danych NoSQL są oparte na parach klucz-wartość.

Niektóre typy magazynów baz danych NoSQL obejmują magazyn kolumn, magazyn dokumentów, magazyn wartości kluczy, magazyn wykresów, magazyn obiektów, magazyn XML i inne tryby magazynu danych.

Zwykle każda wartość w bazie danych ma klucz. Niektóre magazyny baz danych NoSQL umożliwiają również programistom przechowywanie w bazie danych serializowanych obiektów, a nie tylko prostych wartości ciągów.

Bazy danych typu open source NoSQL nie wymagają kosztownych opłat licencyjnych i mogą działać na niedrogim sprzęcie, dzięki czemu ich wdrażanie jest opłacalne.

Ponadto podczas pracy z bazami danych NoSQL, niezależnie od tego, czy są one otwarte, czy zastrzeżone, rozbudowa jest łatwiejsza i tańsza niż w przypadku pracy z relacyjnymi bazami danych. Dzieje się tak, ponieważ odbywa się to poprzez skalowanie poziome i dystrybucję obciążenia na wszystkie węzły, a nie przez skalowanie pionowe, które zwykle ma miejsce w przypadku relacyjnych systemów baz danych, które polega na zastąpieniu głównego hosta bardziej wydajnym.

Niedogodności

Oczywiście bazy danych NoSQL nie są idealne i nie zawsze są właściwym wyborem.

Po pierwsze, większość baz danych NoSQL nie obsługuje funkcji niezawodności, które są natywnie obsługiwane przez relacyjne systemy baz danych. Te cechy niezawodności można podsumować jako atomowość, spójność, izolację i trwałość. Oznacza to również, że bazy danych NoSQL, które nie obsługują tych funkcji, wymieniają spójność na wydajność i skalowalność.

Aby obsługiwać funkcje niezawodności i spójności, programiści muszą wdrożyć własny, zastrzeżony kod, co zwiększa złożoność systemu.

Może to ograniczyć liczbę aplikacji, które mogą polegać na bazach danych NoSQL w celu zapewnienia bezpiecznych i niezawodnych transakcji, takich jak systemy bankowe.

Inne formy złożoności występujące w większości baz danych NoSQL obejmują niezgodność z zapytaniami SQL. Oznacza to, że potrzebny jest ręczny lub zastrzeżony język zapytań, dodając jeszcze więcej czasu i złożoności.

NoSQL a relacyjne bazy danych

Ta tabela zawiera krótkie porównanie funkcji między NoSQL a relacyjnymi bazami danych:

Należy zauważyć, że tabela przedstawia porównanie na poziomie bazy danych , a nie różne systemy zarządzania bazami danych, które implementują oba modele. Systemy te zapewniają własne, zastrzeżone techniki, które pozwalają przezwyciężyć niektóre problemy i niedociągnięcia w obu systemach, aw niektórych przypadkach znacznie poprawiają wydajność i niezawodność.

Typy magazynów danych NoSQL

Magazyn wartości klucza

W typie magazynu wartości klucza używana jest tabela skrótów, w której unikalny klucz wskazuje na element.

Klucze można organizować w logiczne grupy kluczy, wymagając jedynie, aby klucze były unikatowe w ramach własnej grupy. Pozwala to na identyczne klucze w różnych grupach logicznych. W poniższej tabeli przedstawiono przykład magazynu klucz-wartość, w którym kluczem jest nazwa miasta, a wartością jest adres Uniwersytetu Ulster w tym mieście.

Niektóre implementacje magazynu wartości klucza udostępniają mechanizmy buforowania, które znacznie poprawiają ich wydajność.

Wszystko, co jest potrzebne, aby poradzić sobie z elementami przechowywanymi w bazie danych, to klucz. Dane są przechowywane w postaci ciągu, JSON lub BLOB (Binary Large OBject).

Jedną z największych wad tej formy bazy danych jest brak spójności na poziomie bazy danych. Może to zostać dodane przez programistów za pomocą własnego kodu, ale jak wspomniano wcześniej, zwiększa to wysiłek, złożoność i czas.

Najbardziej znaną bazą danych NoSQL, która jest zbudowana na magazynie kluczowych wartości, jest DynamoDB firmy Amazon.

Magazyn dokumentów

Magazyny dokumentów są podobne do magazynów klucz-wartość, ponieważ są pozbawione schematu i oparte na modelu klucz-wartość. Oba mają zatem wiele zalet i wad. W obu przypadkach brakuje spójności na poziomie bazy danych, co umożliwia aplikacjom zapewnienie większej niezawodności i spójności.

Istnieją jednak kluczowe różnice między nimi.

W magazynach dokumentów wartości (dokumenty) zapewniają kodowanie przechowywanych danych. Mogą to być kodowania XML, JSON lub BSON (JSON zakodowany binarnie).

Można również wykonywać zapytania na podstawie danych.

Najpopularniejszą aplikacją bazodanową, która opiera się na magazynie dokumentów, jest MongoDB.

Sklep kolumn

W bazie danych magazynu kolumn dane są przechowywane w kolumnach, a nie w wierszach, jak ma to miejsce w większości relacyjnych systemów zarządzania bazami danych.

Magazyn kolumn składa się z jednej lub więcej rodzin kolumn, które logicznie grupują określone kolumny w bazie danych. Klucz służy do identyfikowania i wskazywania wielu kolumn w bazie danych z atrybutem keyspace, który definiuje zakres tego klucza. Każda kolumna zawiera krotki nazw i wartości, uporządkowane i oddzielone przecinkami.

Magazyny kolumn mają szybki dostęp do odczytu/zapisu do przechowywanych danych. W magazynie kolumn wiersze odpowiadające jednej kolumnie są przechowywane jako pojedynczy wpis na dysku. Zapewnia to szybszy dostęp podczas operacji odczytu/zapisu.

Najpopularniejsze bazy danych korzystające z magazynu kolumn to BigTable firmy Google, HBase i Cassandra.

Baza wykresu

W bazie danych NoSQL w bazie wykresów do reprezentowania danych używana jest ukierunkowana struktura wykresu. Wykres składa się z krawędzi i węzłów.

Formalnie graf jest reprezentacją zbioru obiektów, w którym niektóre pary obiektów są połączone łączami. Połączone obiekty są reprezentowane przez abstrakcje matematyczne, zwane wierzchołkami, a połączenia łączące niektóre pary wierzchołków nazywane są krawędziami. Mówi się, że zbiór wierzchołków i krawędzi, które je łączą, jest grafem.

Ilustruje to strukturę bazy danych wykresów, która wykorzystuje krawędzie i węzły do ​​reprezentowania i przechowywania danych. Węzły te są zorganizowane według pewnych relacji między sobą, co jest reprezentowane przez krawędzie między węzłami. Zarówno węzły, jak i relacje mają określone właściwości.

Grafowe bazy danych są najczęściej używane w aplikacjach społecznościowych. Grafowe bazy danych pozwalają programistom skupić się bardziej na relacjach między obiektami niż na samych obiektach. W tym kontekście rzeczywiście pozwalają na skalowalne i łatwe w użyciu środowisko.

Obecnie najpopularniejszymi grafowymi bazami danych są InfoGrid i InfiniteGraph.

Systemy zarządzania bazami danych NoSQL

Aby uzyskać krótkie porównanie baz danych, poniższa tabela zawiera krótkie porównanie różnych systemów zarządzania bazami danych NoSQL.

MongoDB ma elastyczne przechowywanie schematów, co oznacza, że ​​przechowywane obiekty niekoniecznie muszą mieć taką samą strukturę lub pola. MongoDB ma również kilka funkcji optymalizacji, które rozdzielają gromadzone dane, co skutkuje ogólną poprawą wydajności i bardziej zrównoważonym systemem.

Inne systemy baz danych NoSQL, takie jak Apache CouchDB, są również bazą danych typu magazynu dokumentów i dzielą wiele funkcji z MongoDB, z wyjątkiem tego, że dostęp do bazy danych można uzyskać za pomocą interfejsów API RESTful.

REST to styl architektoniczny składający się ze skoordynowanego zestawu ograniczeń architektonicznych zastosowanych do komponentów, łączników i elementów danych w sieci WWW. Opiera się na bezstanowym protokole komunikacyjnym klient-serwer, który można buforować (np. protokół HTTP).

Aplikacje RESTful używają żądań HTTP do publikowania, odczytywania danych i usuwania danych.

Jeśli chodzi o bazy danych z kolumnami, Hypertable to baza danych NoSQL napisana w C++ i oparta na BigTable firmy Google.

Hypertable obsługuje dystrybucję magazynów danych między węzłami, aby zmaksymalizować skalowalność, podobnie jak MongoDB i CouchDB.

Jedną z najczęściej używanych baz danych NoSQL jest Cassandra, opracowana przez Facebooka.

Cassandra to baza danych magazynu kolumn, która zawiera wiele funkcji mających na celu niezawodność i odporność na błędy.

Zamiast szczegółowego przyjrzenia się każdemu DBMS NoSQL, Cassandra i MongoDB, dwa z najczęściej używanych systemów zarządzania bazami danych NoSQL, zostaną omówione w następnych podrozdziałach.

Kasandra

Cassandra to system zarządzania bazą danych opracowany przez Facebook.

Celem Cassandry było stworzenie systemu DBMS, który nie ma pojedynczego punktu awarii i zapewnia maksymalną dostępność.

Cassandra to głównie baza danych magazynu kolumn. Niektóre badania określały Cassandrę jako system hybrydowy, inspirowany BigTable firmy Google, która jest bazą danych magazynu kolumn, oraz DynamoDB firmy Amazon, która jest bazą danych klucz-wartość.

Osiąga się to poprzez zapewnienie systemu klucz-wartość, ale klucze w Cassandrze wskazują na zestaw rodzin kolumn, w oparciu o rozproszony system plików BigTable firmy Google i funkcje dostępności Dynamo (rozproszona tabela mieszająca).

Cassandra została zaprojektowana do przechowywania ogromnych ilości danych rozproszonych w różnych węzłach. Cassandra to DBMS zaprojektowany do obsługi ogromnych ilości danych rozmieszczonych na wielu serwerach, zapewniając jednocześnie wysoce dostępną usługę bez pojedynczego punktu awarii, co jest niezbędne w przypadku dużych usług, takich jak Facebook.

Główne cechy Cassandry to:

• Brak pojedynczego punktu awarii. Aby to osiągnąć, Cassandra musi działać na klastrze węzłów, a nie na pojedynczej maszynie. Nie oznacza to, że dane w każdym klastrze są takie same, ale oprogramowanie do zarządzania tak. W przypadku awarii jednego z węzłów dane w tym węźle będą niedostępne. Jednak inne węzły (i dane) będą nadal dostępne.
• Rozproszone mieszanie to schemat, który zapewnia funkcjonalność tablicy mieszającej w taki sposób, że dodanie lub usunięcie jednego gniazda nie zmienia znacząco mapowania kluczy do gniazd. Daje to możliwość rozłożenia obciążenia na serwery lub węzły zgodnie z ich pojemnością, a co za tym idzie, minimalizację przestojów.
• Stosunkowo łatwy w użyciu interfejs klienta . Cassandra używa Apache Thrift jako interfejsu klienta. Apache Thrift zapewnia wielojęzycznego klienta RPC, ale większość programistów preferuje alternatywy typu open source zbudowane na bazie Apple Thrift, takie jak Hector.
• Inne funkcje dostępności. Jedną z funkcji Cassandry jest replikacja danych. Zasadniczo odzwierciedla dane do innych węzłów w klastrze. Replikacja może być losowa lub specyficzna, aby zmaksymalizować ochronę danych, na przykład umieszczając ją w węźle w innym centrum danych. Inną cechą Cassandry jest polityka partycjonowania. Polityka partycjonowania decyduje, w którym węźle umieścić klucz. Może to być również losowe lub w kolejności. Korzystając z obu typów zasad partycjonowania, Cassandra może osiągnąć równowagę między równoważeniem obciążenia a optymalizacją wydajności zapytań.
• Spójność. Funkcje takie jak replikacja sprawiają, że spójność jest trudna. Wynika to z faktu, że wszystkie węzły muszą być zaktualizowane w dowolnym momencie z najnowszymi wartościami lub w momencie wyzwolenia operacji odczytu. Ostatecznie jednak Cassandra stara się zachować równowagę między akcjami replikacji a akcjami odczytu/zapisu, udostępniając tę ​​możliwość dostosowania programiście.
• Czynności odczytu/zapisu. Klient wysyła żądanie do pojedynczego węzła Cassandra. Węzeł, zgodnie z zasadami replikacji, przechowuje dane w klastrze. Każdy węzeł najpierw wykonuje zmianę danych w dzienniku zatwierdzania, a następnie aktualizuje strukturę tabeli o zmianę, obie wykonywane synchronicznie. Operacja odczytu jest również bardzo podobna, żądanie odczytu jest wysyłane do pojedynczego węzła, a ten pojedynczy węzeł określa, który węzeł przechowuje dane, zgodnie z polityką partycjonowania/umieszczania.

MongoDB

MongoDB to wolna od schematów, zorientowana na dokumenty baza danych napisana w C++. Baza danych jest oparta na magazynie dokumentów, co oznacza, że ​​przechowuje wartości (nazywane dokumentami) w postaci zaszyfrowanych danych.

Wybór formatu zakodowanego w MongoDB to JSON. Jest to potężne, ponieważ nawet jeśli dane są zagnieżdżone w dokumentach JSON, nadal będą dostępne do przeszukiwania i indeksowania .

Poniższe podrozdziały opisują niektóre z kluczowych funkcji dostępnych w MongoDB.

Odłamki

Sharding to partycjonowanie i dystrybucja danych na wielu komputerach (węzłach). Fragment to zbiór węzłów MongoDB, w przeciwieństwie do Cassandry, w której węzły są symetrycznie rozmieszczone. Korzystanie z fragmentów oznacza również możliwość skalowania w poziomie w wielu węzłach. W przypadku, gdy istnieje aplikacja korzystająca z pojedynczego serwera bazy danych, można ją przekonwertować na klaster shardowany z niewielką ilością zmian w oryginalnym kodzie aplikacji, ponieważ sposób shardowania jest wykonywany przez MongoDB. oftware jest prawie całkowicie oddzielone od publicznych interfejsów API udostępnianych po stronie klienta.

Język zapytań Mongo

Jak wspomniano wcześniej, MongoDB używa interfejsu API RESTful. Aby pobrać określone dokumenty z kolekcji bazy danych, tworzony jest dokument zapytania zawierający pola, do których powinny pasować żądane dokumenty.

działania

W MongoDB istnieje grupa serwerów zwanych routerami. Każdy z nich działa jako serwer dla jednego lub więcej klientów. Podobnie klaster zawiera grupę serwerów zwanych serwerami konfiguracji. Każdy z nich przechowuje kopię metadanych wskazującą, który fragment zawiera jakie dane. Akcje odczytu lub zapisu są wysyłane od klientów do jednego z serwerów routerów w klastrze i są automatycznie kierowane przez ten serwer do odpowiednich fragmentów zawierających dane za pomocą serwerów konfiguracyjnych.

Podobnie jak Cassandra, fragment w MongoDB ma schemat replikacji danych, który tworzy zestaw replik każdego fragmentu, który zawiera dokładnie te same dane. W MongoDB istnieją dwa typy schematów replik: replikacja Master-Slave i Replica-Set. Replica-Set zapewnia większą automatyzację i lepszą obsługę awarii, podczas gdy Master-Slave wymaga czasami interwencji administratora. Niezależnie od schematu replikacji, w dowolnym momencie w zestawie replik tylko jeden fragment działa jako fragment podstawowy, wszystkie pozostałe fragmenty replik są fragmentami pomocniczymi. Wszystkie operacje zapisu i odczytu trafiają do fragmentu podstawowego, a następnie są równomiernie (w razie potrzeby) dystrybuowane do innych fragmentów pomocniczych w zestawie.

Na poniższej grafice widzimy opisaną powyżej architekturę MongoDB, pokazującą serwery routerów na zielono, serwery konfiguracyjne na niebiesko i fragmenty zawierające węzły MongoDB.

Należy zauważyć, że sharding (lub udostępnianie danych między shardami) w MongoDB jest całkowicie automatyczny, co zmniejsza wskaźnik niepowodzeń i czyni MongoDB wysoce skalowalnym systemem zarządzania bazą danych.

Indeksowanie struktur dla baz danych NoSQL

Indeksowanie to proces kojarzenia klucza z lokalizacją odpowiedniego rekordu danych w DBMS. W bazach danych NoSQL jest używanych wiele struktur indeksowania danych. Poniższe sekcje krótko omówią niektóre z bardziej powszechnych metod; mianowicie indeksowanie B-Tree, indeksowanie T-Tree i indeksowanie O2-Tree.

Indeksowanie B-drzewa

B-Tree jest jedną z najpopularniejszych struktur indeksowych w DBMS.

W B-drzewa, węzły wewnętrzne mogą mieć zmienną liczbę węzłów potomnych w pewnym predefiniowanym zakresie.

Jedną z głównych różnic w stosunku do innych struktur drzewa, takich jak AVL, jest to, że B-Tree pozwala węzłom mieć zmienną liczbę węzłów podrzędnych, co oznacza mniej równoważenia drzewa, ale więcej marnowanej przestrzeni.

B+-Tree to jeden z najpopularniejszych wariantów B-Tree. B+-Tree to ulepszenie w stosunku do B-Tree, które wymaga, aby wszystkie klucze znajdowały się w liściach.

Indeksowanie drzewa T

Struktura danych T-Trees została zaprojektowana przez połączenie funkcji AVL-Trees i B-Trees.

Drzewa AVL to rodzaj samobalansujących się drzew binarnych, podczas gdy drzewa B są niezrównoważone, a każdy węzeł może mieć inną liczbę dzieci.

W T-Tree struktura jest bardzo podobna do AVL-Tree i B-Tree.

Każdy węzeł przechowuje więcej niż jedną krotkę {klucz-wartość, wskaźnik}. Ponadto wyszukiwanie binarne jest wykorzystywane w połączeniu z węzłami z wieloma krotkami, aby zapewnić lepszą pamięć i wydajność.

T-Tree ma trzy typy węzłów: T-Node, który ma prawe i lewe dziecko, węzeł liścia bez dzieci i węzeł pół-liścia z tylko jednym dzieckiem.

Uważa się, że T-Trees mają lepszą ogólną wydajność niż AVL-Trees.

Indeksowanie drzewa O2

Drzewo O2- jest zasadniczo ulepszeniem w stosunku do drzew czerwono-czarnych, formy drzewa wyszukiwania binarnego, w którym węzły liści zawierają krotki {wartość klucza, wskaźnik}.

Zaproponowano O2-Tree w celu zwiększenia wydajności obecnych metod indeksowania. Drzewo O2 rzędu m (m ≥ 2), gdzie m jest minimalnym stopniem drzewa, spełnia następujące właściwości:

• Każdy węzeł jest albo czerwony albo czarny. Korzeń jest czarny.
• Każdy węzeł liścia jest pomalowany na czarno i składa się z bloku lub strony, która zawiera pary „kluczowa wartość, rekord-wskaźnik”.
• Jeśli węzeł jest czerwony, to oba jego dzieci są czarne.
• Dla każdego węzła wewnętrznego wszystkie proste ścieżki od węzła do potomnych węzłów-liści zawierają tę samą liczbę czarnych węzłów. Każdy węzeł wewnętrzny przechowuje pojedynczą wartość klucza.
• Węzły-liścia to bloki zawierające od ⌈m/2⌉ do m par „klucz-wartość, wskaźnik-rekord”.
• Jeśli drzewo ma pojedynczy węzeł, musi to być liść, który jest korzeniem drzewa i może zawierać od 1 do m kluczowych elementów danych.
• Węzły liściowe są podwójnie połączone w kierunku do przodu i do tyłu.

Tutaj widzimy proste porównanie wydajności między O2-Tree, T-Tree, B+-Tree, AVL-Tree i Red-Black Tree:

Kolejność użytego drzewa T, drzewa B+ i drzewa O2 wynosiła m = 512.

Czas jest rejestrowany dla operacji wyszukiwania, wstawiania i usuwania ze współczynnikami aktualizacji wahającymi się między 0%-100% dla indeksu 50M rekordów, z operacjami powodującymi dodanie kolejnych 50M rekordów do indeksu.

Oczywiste jest, że przy współczynniku aktualizacji 0-10%, B-Tree i T-Tree radzą sobie lepiej niż O2-Tree. Jednak wraz ze wzrostem współczynnika aktualizacji, indeks O2-Tree działa znacznie lepiej niż większość innych struktur danych, przy czym najbardziej cierpią struktury B-Tree i Red-Black Tree.

Sprawa dla NoSQL?

Krótkie wprowadzenie do baz danych NoSQL, podkreślające kluczowe obszary, w których tradycyjne relacyjne bazy danych zawodzą, prowadzi do pierwszego wniosku:

Chociaż relacyjne bazy danych zapewniają spójność, nie są zoptymalizowane pod kątem wysokiej wydajności w aplikacjach, w których często przechowywane i przetwarzane są ogromne ilości danych.

Bazy danych NoSQL zyskały dużą popularność ze względu na wysoką wydajność, dużą skalowalność i łatwość dostępu; jednak nadal brakuje im funkcji zapewniających spójność i niezawodność.

Na szczęście wiele baz danych NoSQL stawia czoła tym wyzwaniom, oferując nowe funkcje zwiększające skalowalność i niezawodność.

Nie wszystkie systemy baz danych NoSQL działają lepiej niż relacyjne bazy danych.

MongoDB i Cassandra mają podobną, aw większości przypadków lepszą, wydajność niż relacyjne bazy danych w operacjach zapisu i usuwania.

Nie ma bezpośredniej korelacji między typem sklepu a wydajnością systemu DBMS NoSQL. Implementacje NoSQL ulegają zmianom, więc wydajność może się różnić.

Dlatego pomiary wydajności w różnych typach baz danych w różnych badaniach należy zawsze aktualizować najnowszymi wersjami oprogramowania bazy danych, aby te liczby były dokładne.

Chociaż nie mogę wydać ostatecznego werdyktu na temat wydajności, oto kilka punktów, o których należy pamiętać:

• Tradycyjne indeksowanie B-Tree i T-Tree jest powszechnie stosowane w tradycyjnych bazach danych.
• Jedno z badań zaoferowało ulepszenia i ulepszenia poprzez połączenie cech wielu struktur indeksujących w celu uzyskania drzewa O2.
• O2-Tree przewyższało inne struktury w większości testów, zwłaszcza przy ogromnych zestawach danych i wysokim współczynniku aktualizacji.
• Struktura B-Tree zapewniła najgorszą wydajność ze wszystkich struktur indeksujących omówionych w tym artykule.

Dalsza praca może i powinna być wykonana w celu zwiększenia spójności baz danych NoSQL. Integracja obu systemów, NoSQL i relacyjnych baz danych, to obszar do dalszego zbadania.

Na koniec należy zauważyć, że NoSQL jest dobrym dodatkiem do istniejących standardów baz danych, ale z kilkoma ważnymi zastrzeżeniami. NoSQL zamienia funkcje niezawodności i spójności na czystą wydajność i skalowalność. To sprawia, że ​​jest to wyspecjalizowane rozwiązanie, ponieważ liczba aplikacji, które mogą polegać na bazach danych NoSQL, pozostaje ograniczona.

Plusy? Specjalizacja może nie zapewniać dużej elastyczności, ale jeśli chcesz wykonać specjalistyczną pracę tak szybko i wydajnie, jak to możliwe, nie potrzebujesz szwajcarskiego scyzoryka. Potrzebujesz NoSQL.