NoSQL (nierelacyjna baza danych SQL, pierwotnie „non SQL” lub „non relational”)[1]baza danych zapewniająca mechanizm do przechowywania i wyszukiwania danych modelowanych w inny sposób niż relacje tabelaryczne używane w relacjach baz danych SQL.

Takie bazy danych istniały od końca lat 60. XX wieku, ale nie używano nazwy „NoSQL”. NoSQL umożliwia tworzenie prostych projektów, horyzontalne skalowanie do klastrów maszyny (co jest problemem dla relacyjnych baz danych)[2] i lepszą kontrolę nad dostępnością. Bazy NoSQL wykorzystywane są coraz częściej w big data działających w czasie rzeczywistym[3]. Inne cechy wspólne baz NoSQL to open source, budowa na potrzeby firm Web 2.0, brak schematu danych oraz możliwość wyboru sposobu przechowywania danych w zależności od ich specyfiki[4].

NoSQL stworzony został z potrzeby obsługiwania większych wolumenów danych, która wymusiła przejście na model budowania platform na klastrach mniej wydajnych serwerów. Ta zmiana wzbudziła także wątpliwości w sprawie łatwości tworzenia kodu dobrze współpracującego z bazami relacyjnymi[4]. Struktury danych używane przez NoSQL (np. klucz–wartość, graf, dokument, szerokokolumnowe) różnią się od tych używanych domyślnie w relacyjnych bazach danych, dzięki czemu niektóre operacje NoSQL są szybsze. Wybór konkretnej bazy danych pod względem formy przechowywania danych zależy od problemu, który musi rozwiązać. Czasami struktury danych używane przez bazy danych NoSQL są również postrzegane jako „bardziej elastyczne” niż relacyjne bazy danych[5]. Wiele baz danych w celu osiągnięcia wysokiej dostępności danych (przepustowości) rezygnuje całkowicie lub częściowo ze spójności (twierdzenie CAP Erica Brewera). NoSQL nie posiada jednego standardowego języka zapytań i interfejsu[6][7].

Bazy danych NoSQL nie spełniają ACID i co najwyżej mogą osiągnąć kompromis określany BASE (Basically Available, Soft state, Eventual consistency)[7]. Chociaż niektóre bazy danych takie jak: MarkLogic, Aerospike, FairCom c-treeACE, Google Spanner (NewSQL), Symas LMDB i OrientDB uczyniły je centralnym elementem swoich projektów. Istnieje niewiele systemów, które obsługują zarówno transakcje ACID, jak i standardy X/Open XA w przypadku rozproszonego przetwarzania transakcji.

Historia edytuj

Nazwa edytuj

Termin NoSQL po raz pierwszy został użyty przez Carlo Strozziego w 1998 roku jako nazwa dla lekkiej relacyjnej bazy open source Strozzi NoSQL[4][8]. RDBMS NoSQL różni się od ogólnej koncepcji NoSQL z 2009 roku. Strozzi sugeruje, że ponieważ obecny ruch NoSQL „całkowicie odchodzi od modelu relacyjnego, powinien zatem zostać nazwany bardziej stosownie – NoREL”[9].

W 2009 roku Johan Oskarsson szukał dla spotkania Hadoop w San Francisco nazwy, która stanowiłaby jednocześnie dobry hashtag Twittera; krótkiej, łatwej do zapamiętania i takiej, dla której Google nie wyświetlałby zbyt wielu wyników, tak aby wyszukiwanie po nazwie pozwalało łatwo znaleźć spotkanie. Poprosił o sugestie na kanale IRC #cassandra i spośród propozycji wybrał nazwę NoSQL, którą zgłosił Eric Evans z RackSpace. Spotkanie dotyczyło otwartych, rozproszonych, nierelacyjnych systemów baz danych. Nazwa NoSQL była negatywna i nie do końca pasowała do opisywanych systemów jednak termin ten rozpowszechnił się na ogólnoświatową sieć i stał się de facto nazwą trendu w IT[4][10][11].

Niektórzy zwolennicy systemów NoSQL twierdzą, że nazwa NoSQL nie oznacza „nie” dla SQL a raczej oznacza „Not Only SQL” (z ang. nie tylko SQL), podkreślając możliwość obsługi języka zapytań SQL[12][13].

Początki edytuj

Pomysł nierelacyjnych baz danych nie jest nowy, a wykorzystanie nierelacyjnych repozytoriów rozpoczęło się w czasach pierwszych komputerów. Nierelacyjne bazy danych rozkwitały w latach 60. XX wieku, w czasach komputerów mainframe, a później, w momencie dominacji relacyjnych baz danych DBMS, znalazły zastosowanie w wyspecjalizowanych repozytoriach, na przykład w hierarchicznych usługach katalogowych. Pojawienie się nierelatywnego systemu DBMS nowej generacji wynikało z potrzeby stworzenia równoległych systemów rozproszonych dla wysoce skalowalnych aplikacji internetowych, takich jak wyszukiwarki internetowe[14].

NoSQL zyskał popularność na początku XXI wieku[2], gdy pojawiły się nowe potrzeby firm Web 2.0, takich jak Facebook, Google i Amazon.com, Netflix, Yahoo!, eBay, Hulu, IBM i wiele innych[15][16][17].

Na początku 2000 roku Google Inc. zbudował swoją wysoce skalowalną wyszukiwarkę i aplikacje: Gmail, mapy Google, Google Earth, Google Finance i Google Aplikacje – rozwiązując problemy związane ze skalowalnością i równoległym przetwarzaniem dużych ilości danych. W rezultacie utworzono rozproszony system plików, column-family-oriented data store, distributed coordination system, środowisko uruchomieniowe oparte na algorytmie MapReduce. Publikacja przez Google opisów tych technologii spowodowała wzrost zainteresowania programistów oprogramowaniem open source, w wyniku czego powstał Hadoop i powiązane projekty mające na celu stworzenie podobnych technologii. Pojawienie się Hadoop położyło podwaliny pod szybki wzrost NoSQL. Rok później w 2007 r. Amazon postanowił podzielić się informacjami o swoim systemie Dynamo[17][18][19][20].

Modele danych i przykładowe bazy danych edytuj

Każde rozwiązanie NoSQL wykorzystuje inny model. Istnieją różne podejścia do klasyfikacji baz danych NoSQL, każda z różnymi kategoriami i podkategoriami.

  • Podstawowa klasyfikacja baz danych ze względu na ich model danych z przykładami:
Model danych Przykładowe bazy danych
Klucz – wartość Aerospike, Apache Ignite, ArangoDB, BerkeleyDB, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, InfinityDB, LevelDB, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Project Voldemort, Redis, Riak, SDBM/Flat File dbm, ZooKeeper
Dokument Apache CouchDB, ArangoDB, BaseX, Clusterpoint, Couchbase, Cosmos DB, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB
Rodzina kolumn Amazon SimpleDB, Accumulo, Cassandra, Druid, HBase, Hypertable, Vertica.
Graf AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso
Multi-model Apache Ignite, ArangoDB, Couchbase, FoundationDB, InfinityDB, MarkLogic, OrientDB

Wiele baz danych nie pasuje jednoznacznie do żadnej z kategorii, np. OrientDB określa się jako bazę dokumentów i bazę grafową[7].

  • Bardziej szczegółowa klasyfikacja oparta na klasyfikacji Stephena Yena[21][22]:
Model danych Przykładowe bazy danych
Key-Value Cache Apache Ignite, Coherence, eXtreme Scale, Hazelcast, Infinispan, JBoss Cache, Memcached, Repcached, Velocity
Key-Value Store ArangoDB, Flare, Keyspace, RAMCloud, SchemaFree, Aerospike, quasardb
Key-Value Store (Eventually-Consistent) DovetailDB, Oracle NoSQL Database, Dynamo, Riak, Dynomite, Voldemort, SubRecord
Key-Value Store (Ordered) Actord, FoundationDB, InfinityDB, Lightcloud, LMDB, Luxio, MemcacheDB, NMDB, TokyoTyrant
Data-Structures Server Redis
Tuple Store Apache River, Coord, GigaSpaces
Object Database (Obiektowe) DB4O, Objectivity/DB, Perst, Shoal, ZopeDB
Document Store (Dokument) ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, IBM Domino, MarkLogic, MongoDB, Qizx, RethinkDB
Wide Column Store

(Szerokokolumnowe)

Amazon DynamoDB, Bigtable, Cassandra, Druid, HBase, Hypertable, KAI, KDI, OpenNeptune, Qbase
  • Klasyfikacja i ocena Bena Scofielda[22][23]
Wydajność Skalowalność Elastyczność Złożoność Funkcjonalność
Key-Value Stores wysoka wysoka wysoka żadna zmienna (żadna)
Column stores wysoka wysoka umiarkowana niska minimalna
Document stores wysoka zmienna(wysoka) wysoka niska zmienna(niska)
Graph databases zmienna zmienna wysoka wysoka teoria grafów
Relational databases zmienna zmienna niska umiarkowana rachunek relacyjny

Bazy klucz–wartość edytuj

Magazyn klucz–wartość korzysta z asocjacyjnej tablicy (znanej również jako mapa lub słownik) jako podstawowego modelu danych. W tym modelu dane są reprezentowane jako zbiór par klucz–wartość, tak że każdy możliwy klucz pojawia się najwyżej jeden raz w kolekcji[24][25]. Wykorzystywana jest do: przechowywania obrazów, przechowywania danych sesji, koszyka zakupów, tworzenia wyspecjalizowanych systemów plików, jako pamięci podręcznych obiektów, a także w systemach zaprojektowanych pod kątem skalowalności.

Model klucz–wartość jest jednym z najprostszych nietrywialnych modeli danych, a bogatsze modele danych są często implementowane jako jego rozszerzenie. Model klucz–wartość może zostać rozszerzony na dyskretnie uporządkowany model, który utrzymuje klucze w porządku leksykograficznym. Ponieważ magazyny klucz–wartość zawsze wykorzystują klucz główny, przeważnie cechują się wysoką wydajnością i są łatwo skalowalne. Magazyn klucz–wartość należy odpytywać po kluczu[4][26].

Magazyny klucz–wartość mogą wykorzystywać modele spójności od spójności ostatecznej (wartość zreplikowana na inne serwery) do możliwości serializacji. Niektóre bazy danych obsługują porządkowanie kluczy. Sposobem na rozwiązanie konfliktu aktualizacji może być faworyzowanie najnowszego wpisu lub zwrócenie wszystkich wartości w celu dokonania wyboru. Istnieją różne implementacje sprzętowe, a niektórzy użytkownicy przechowują dane w pamięci RAM, SSD, HDD.

Dokument edytuj

Dokument jest głównym pojęciem baz dokumentów. Ogólnie zakłada się, że dokumenty zawierają i kodują dane (lub informacje) w niektórych standardowych formatach lub kodowaniach tj.: XML, JSON, YAML, a także formy binarne tj. BSON. Dokumenty są adresowane w bazie danych za pomocą unikalnego klucza, który reprezentuje ten dokument. Jedną z innych cech charakterystycznych bazy danych zorientowanej na dokumenty jest to, że oprócz wyszukiwania klucza przeprowadzanego przez magazyn klucz–wartość, baza danych oferuje również interfejs API lub język zapytań, który pobiera dokumenty na podstawie ich zawartości. Dokument jest używany do logowania zdarzeń, analizy stron internetowych lub analizy w czasie rzeczywistym, aplikacjach e-commerce[4][27][28].

Różne implementacje oferują różne sposoby organizowania lub grupowania dokumentów: kolekcje, tagi, niewidoczne metadane, hierarchie katalogów, wiadra[28].

W tabelarycznych relacyjnych bazach danych każda kolumna musi zawierać taką samą sekwencję pól definiowana przez wartość lub oznaczona jako null; podczas gdy dokumenty w kolekcji mogą mieć zupełnie inne pola[4].

Rodzina kolumn edytuj

Analogicznie do relacyjnych baz danych, rodzina kolumn jest „tabelą”, a każda para klucz–wartość jest „rzędem”. Każda kolumna to krotka (triplet) składająca się z nazwy kolumny, wartości i stempla czasu. Stempel czasu jest odpowiedzą na problem aktualizacji. Istnieją dwa typy rodzin kolumn: standardowa rodzina kolumn i super rodzina kolumn. Rodzina kolumn jest używana do logowania zdarzeń, zarządzania treścią, jako liczniki, do wygasających danych[4][29].

Graf edytuj

Ten rodzaj bazy danych jest przeznaczony dla danych, których relacje są dobrze reprezentowane jako wykres składający się z elementów powiązanych ze skończoną liczbą relacji między nimi. Rodzajem danych mogą być relacje społeczne, połączenia transportu publicznego, mapy drogowe, topologie sieci itp. Baza grafów jest oparta na węzłach (encje), krawędziach (relacje), właściwościach, teorii grafów. Grafy są używane w sieciach społecznościowych, do wytyczania tras[4][29].

Obsługa danych relacyjnych edytuj

Ponieważ większość baz danych NoSQL nie ma możliwości dołączania zapytań, schemat bazy danych zasadniczo musi być różnie zaprojektowany. Istnieją trzy główne techniki obsługi danych relacyjnych w bazie danych NoSQL[30][31].

Wiele zapytań (Multiple queries) edytuj

Zamiast odzyskiwać wszystkie dane za pomocą jednego zapytania, często wykonuje się kilka zapytań w celu uzyskania pożądanych danych. Zapytania NoSQL są często szybsze niż tradycyjne zapytania SQL, więc koszt konieczności wykonania dodatkowych zapytań może być akceptowalny[30][31].

Buforowanie, replikacja i nienormalizowane dane (Caching, replication and non-normalized data) edytuj

Zamiast tylko przechowywać klucze obce, często zachowuje się rzeczywiste obce wartości wraz z danymi modelu. Na przykład każdy komentarz do bloga może zawierać oprócz identyfikatora użytkownika także nazwę użytkownika, zapewniając w ten sposób łatwy dostęp do nazwy użytkownika bez konieczności ponownego wyszukiwania. Kiedy jednak zmieni się nazwa użytkownika, będzie ona musiała zostać zmieniona w wielu miejscach w bazie danych. Tak więc to podejście działa lepiej, gdy odczyty są znacznie częstsze niż zapisy[30][31].

Zagnieżdżanie danych (Nesting data) edytuj

W bazach danych dokumentów, takich jak MongoDB, często umieszcza się więcej danych w mniejszej liczbie zbiorów. Na przykład w aplikacji do blogowania można wybrać przechowywanie komentarzy w dokumencie posta na blogu, tak aby po pojedynczym pobieraniu otrzymywano wszystkie komentarze. Tak więc w tym podejściu pojedynczy dokument zawiera wszystkie dane potrzebne do określonego zadania[30][31].

Przypisy edytuj

  1. Prof. Dr.Stefan Edlich, NOSQL Databases [online], nosql-database.org [dostęp 2018-02-26].
  2. a b http://www.leavcom.com/pdf/NoSQL.pdf.
  3. RDBMS dominate the database market, but NoSQL systems are catching up [online], db-engines.com [dostęp 2018-02-26] (ang.).
  4. a b c d e f g h i 1.5. Pojawienie się baz NoSQL, [w:] Martin Fowler, Pramod J. Sadalage, Jakub Hubisz, NoSQL. Kompendium wiedzy, 1 grudnia 2014, ISBN 978-83-246-9908-7.
  5. Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications – All Things Distributed [online], www.allthingsdistributed.com [dostęp 2018-02-27] (ang.).
  6. http://www.journalofcloudcomputing.com/content/pdf/2192-113X-2-22.pdf.
  7. a b c Wprowadzenie do NoSQL, część I [online], msdn.microsoft.com [dostęp 2018-02-27] (pol.).
  8. http://publications.lib.chalmers.se/records/fulltext/123839.pdf.
  9. NoSQL Relational Database Management System: Home Page [online], www.strozzi.it [dostęp 2018-02-27] (ang.).
  10. Alexey Vasiliev, World of the NoSQL databases [online], leopard.in.ua [dostęp 2018-02-26] (ang.).
  11. Knut Haugen, A Brief History of NoSQL – All About the Code [online], blog.knuthaugen.no [dostęp 2018-02-26] (ang.).
  12. What is NoSQL (Not Only SQL database)? – Definition from WhatIs.com, „SearchDataManagement” [dostęp 2018-02-26] (ang.).
  13. bliki: NosqlDefinition, „martinfowler.com” [dostęp 2018-02-26].
  14. Shashank. Tiwari, Professional NoSQL, Indianapolis, IN: Wiley, 2011, Rozdział 1., ISBN 978-0-470-94224-6, OCLC 757856904.
  15. http://openproceedings.eu/2013/conf/edbt/Mohan13.pdf.
  16. NOSQL meetup [online], Eventbrite [dostęp 2018-02-26] [zarchiwizowane z adresu 2017-08-03] (ang.).
  17. a b Amazon Goes Back to the Future With ‘NoSQL’ Database, „WIRED”, ISBN 978-0-470-94224-6 [dostęp 2018-02-26] (ang.).
  18. https://static.googleusercontent.com/media/research.google.com/pl//archive/bigtable-osdi06.pdf.
  19. https://static.googleusercontent.com/media/research.google.com/pl//archive/mapreduce-osdi04.pdf.
  20. Amazon’s Dynamo – All Things Distributed [online], www.allthingsdistributed.com [dostęp 2018-02-27] (ang.).
  21. https://dl.dropboxusercontent.com/u/2075876/nosql-steve-yen.pdf.
  22. a b http://www.christof-strauch.de/nosqldbs.pdf.
  23. Ben Scofield, NoSQL @ CodeMash 2010 [online], 15 stycznia 2010 [dostęp 2018-03-01].
  24. What is a Key/Value store database? [online], dba.stackexchange.com [dostęp 2018-02-27].
  25. Marc Seeger, Key Value Stores: A Practical Overview – Marc’s Blog [online], blog.marc-seeger.de [dostęp 2018-02-27] (ang.).
  26. NoSQL Data Modeling Techniques, „Highly Scalable Blog”, 1 marca 2012 [dostęp 2018-02-28] (ang.).
  27. 11 OPEN NoSQL Document-Oriented Databases – DZone Database [online], dzone.com [dostęp 2018-02-28] (ang.).
  28. a b NoSQL, „Big Data Technologies”, 11 stycznia 2016 [dostęp 2018-02-28] (ang.).
  29. a b The Different Types of NoSQL Databases – open source for you, „Open Source For You”, 16 maja 2017 [dostęp 2018-02-28] (ang.).
  30. a b c d Overview of NoSQL in BIG-DATA – Bista Solutions, „Bista Solutions: Best Odoo Implementation Company | Odoo Gold Partners”, 26 października 2015 [dostęp 2018-03-21] (ang.).
  31. a b c d How To Choose A Nosql Database Like A Pro [online], Nexus Web Development Company [dostęp 2018-03-21] (ang.).