NoSQL

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

NoSQL (зазвичай розшифровується як "non SQL", "non relational" or "not only SQL" - англ. не тільки SQL ) - база даних, що забезпечує інший механізм зберігання та видобування даних, ніж звичний підхід таблиць-відношень в реляційних базах даних. Подібні бази даних існували вже в другій половині 1960тих, але тоді вони ще не здобули гучне ім'я "NoSQL" , одержане після сплеску популярності на початку 21-ого століття, що був спричинений потребами Web 2.0 компаніями, такими як FacebookGoogle, та Amazon.com. NoSQL бази даних все більше і більше використовуються в задачах із застосуванням big data та real-time web застосунках. NoSQL системи також називають "Not only SQL" (англ. not only SQL — не тільки SQL) для підкреслення того, що вони можуть підтримувати SQL-подібну структуру та мову запитів.

Мотиви цього підходу включають: простоту дизайну схеми БД, значно спрощене горизонтальне масштабування на кластери машин (що є проблемою для реляційних баз даних), і тонкий контроль над доступністю. Структури даних, що використовуються в NoSQL (до прикладу ключ-значення, граф, документ) є відмінними від тих, що використовуються за замовчуванням в реляційних базах, що робить тим самим деякі операції над даними значно швидшими на NoSQL. Точна відповідність використання NoSQL бази даних залежить від проблем, які треба вирішити. Іноді структури даних, використовувані в NoSQL базах можуть розглядатись як більш гнучкі ніж таблиці реляційних моделей.

Багато NoSQL сховищ нехтують узгодженістю даних на противагу доступності, толерантності до партиціонування, та звісно швидкості. Бар'єрами прийняття парадигми NoSQL сховищ є використання низькорівневої мови запитів (замість добре розвиненого та стандартизованого SQL), брак стандартизованих інтерфейсів і значні інвестиції  в існуючі реляційні бази. Більшість NoSQL сховищ далеко не забезпечують добре знані ACID транзакції, однак декілька баз, такі як MarkLogicAerospike, FairCom c-treeACE, Google Spanner (що технічно теж NewSQL база даних), Symas LMDB, та OrientDB зробили на цьому додатковий акцент.

Натомість більшість NoSQL баз даних пропонують концепцію випадкового узгодження даних, в якому зміни в базі продубльованно на всі вузли "випадковим чином" (зазвичай така дія займає мілісекунди), що запити даних можуть не повернути оновлені дані моментально, або ж прочитані дані будуть не точними - давно знана проблема читання станів. На додаток, деякі NoSQL системи можуть містити дротову або іншої форми втрату даних. На щастя, деякі NoSQL забезпечують принцип write-ahead logging для уникнення втрати даних. Для розподіленої обробки транзакцій, поверх множинних баз даних, узгодженість даних, як наслідок, навіть більше завдання ніж воно постає при реляційному підході. навіть поточні реляційні бази  не гарантують цілісність посилань для розширених баз даних. Це всього декілька систем що підтримують як і ACID транзакції так і X/Open XA стандарти для підтримки обробки транзакцій на розподілених базах даних.

Історія[ред.ред. код]

Термін NoSQL було використано Карлом Строззі у 1998 як назву для його СУБД-легковаговика, Strozzi NoSQL open-source relational database що не слугувався стандартом Structured Query Language (SQL) інтерфейсу, проте все ще залишався реляційним. 

Джоан Оскарссон на Last.fm перепридставив термін NoSQL на початку 2009 року, коли він організував подію-обговорення розподілнених, з відкритим кодом, нерелційних баз даних. Ім'я здійснило спробу ознаменувати несподіваний ріст нереляційних, розподілених сховищ даних, що включає відкрите клонування та доступ до коду. Більшість ранніх NoSQL систем не пробували акцентувати увагу на atomicity, consistency, isolation and durability гарантії, всупереч усталеній практиці серед реляційних систем управління базами даних

Базуючись на даних доходу у 2014 році, лідерами NoSQL ринку є MarkLogicMongoDB та Datastax. Базуючись на 2015 році - найпопулярнішими є NoSQL бази даних, такі як MongoDBApache Cassandra, та Redis.

Типи та приклади NoSQL баз даних[ред.ред. код]

Відомо декілька способів класифікації NoSQL баз даних, кожен зі своїм набором категорій, деякі з них частково збігаються. Розглянемо базову класифікацію за моделями даних:

  • Колонка: Accumulo, Cassandra, Druid, HBase, Vertica
  • Документ: Apache CouchDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB
  • Ключ-значення: Aerospike, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB
  • Граф: AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog
  • Мульти-модель: Alchemy Database, ArangoDB, CortexDB, Couchbase, FoundationDB, MarkLogic, OrientDB

Більш деталізована версія

Оригінальна назва Тип Приклад
Key-Value Cache Ключ-значення: кеш CoherenceeXtreme ScaleGigaSpaces, GemFire, HazelcastInfinispan, JBoss Cache, Memcached, Repcached, TerracottaVelocity
Key-Value Store Ключ-значення: сховище Flare, Keyspace, RAMCloud, SchemaFree, HyperdexAerospike
Key-Value Store (Eventually-Consistent) Ключ-значення: сховище (випадково-узгоджене) DovetailDB, Oracle NoSQL DatabaseDynamoRiak, Dynomite, MotionDb, Voldemort, SubRecord
Key-Value Store (Ordered) Ключ-значення: сховище (впорядковане) Actord, FoundationDB, Lightcloud, LMDB, Luxio, MemcacheDB, NMDB, Scalaris, TokyoTyrant
Data-Structures Server Сервер структурованих даних Redis
Tuple Store Кортеж: сховище Apache River, Coord, GigaSpaces
Object Database Об'єктна база даних DB4O, Objectivity/DBPerst, Shoal, ZopeDB
Document Store Документ: сховище ClusterpointCouchbaseCouchDBDocumentDBIBM DominoMarkLogicMongoDBQizxRethinkDBXML-databases
Wide Column Store Широко-колонкове сховише BigTableCassandraDruidHBaseHypertable, KAI, KDI, OpenNeptune, Qbase

Ключ-значення[ред.ред. код]

Ключ-значення (від англ. Key-value (KV)) сховище використовує асоціативний масив (знаний як карта або словник) я основну модель даних. В цій моделі дані представляються як колекція з пар типу ключ-значення, при тому що кожен можливий ключ з'являється в колекціях не більше одного разу.

Модель такого типу є однією із найпростіших, і багатші моделі зазвичай реалізовані як їх розширення. Модель типу ключ-значення може бути розширена до скінченно впорядкованої, що підтримує ключі в лексикографічному порядку. Це розширення є обчислювально потужним, в тому, що він може ефективно видобувати селективні діапазони ключів.

Моделі типу ключ-значення можуть використовувати різні рівні узгодженості, починаючи від випадкової і завершуючи серіалізованими даними. Деякі бази даних підтримують впорядковані ключі. Існують різні реалізації апаратного забезпечення, і деякі користувачі підтримують дані в пам'яті (RAM), в той час як інші використовують HDD накопичувачі або класичні обертові диски.

Приклад: Oracle NoSQL DatabaseRedis, and dbm.

Документні сховища[ред.ред. код]

Центральним поняттям такої моделі даних є "документ". У той час кожна документно-орієнтована реалізація бази даних відрізняється від деталей цього визначення, в загальному, всі вони припускають, що документи і інкапсулюють та шифрують збережені дані в деяких стандартних форматах або кодуваннях. Кодування на практиці включає XML, YAML і JSON, а також бінарні форми, як BSON. Документи адресуються в базі даних за допомогою унікального ключа.

Різноманітні способи реалізації пропонують різноманітні підходи і (або) способи групування документів:

  • Колекції
  • Теги
  • Невидимі мета-дані
  • Ієрархія директорій

У порівнянні з реляційними, колекції, до прикладу, можна розглядати як аналоги таблиць а документи - аналоги до записів. Однак існує відмінність: кожен запис в таблиці має сталу послідовність атрибутів, в той час як документні бази можуть містити в колекції набори з абсолютно відмінними атрибутами

Графи[ред.ред. код]

Цей тип баз даних розроблений для даних, де дані можуть бути представлені у вигляді складових вершин графу, об'єднаних скінченним числом зв'язків між ними. Таким типом даних можуть бути соціальні мережі, мережі гормадського транспорту, карти доріг тощо.

Графові бази даних та їх мови запитів
База даних (назва) Мова(и) Примітки
AllegroGraph SPARQL RDF кортеж
DEX/Sparksee C++Java.NETPython Графова база даних
FlockDB Scala Графова база даних
IBM DB2 SPARQL RDF кортеж, доданий в DB2 10
InfiniteGraph Java Графова база даних
MarkLogic JavaJavaScriptSPARQLXQuery Мульти модельна документна база та RDF кортеж
Neo4j Cypher Графова база даних
OWLIM JavaSPARQL 1.1 RDF кортеж
Oracle SPARQL 1.1 RDF кортеж 11g
OrientDB Java Мульти-модельна документна база і графова база даних
Sqrrl Enterprise Java Графова база даних
OpenLink Virtuoso C++C#JavaSPARQL Гібрид Middleware та database engine 
Stardog JavaSPARQL Графова база даних

Продуктивність[ред.ред. код]

Бен Скотфілд оцінив різні категорії NoSQL баз даних:

Модель даних Продуктивність Масштабованість Гнучкість Складність Функціональність
Key–Value Store high high high none variable (none)
Column-Oriented Store high high moderate low minimal
Document-Oriented Store high variable (high) high low variable (low)
Graph Database variable variable high high graph theory
Relational Database variable variable low moderate relational algebra

Обробка реляційних даних[ред.ред. код]

Оскільки у більшості NoSQL баз даних відсутня можливість для операцій з'єднання в запитах, схема БД повинна бут спроектована іншим чином. Виділяють три техніки обробки реляційних даних в NoSQL базах:

Множинні запити[ред.ред. код]

Підхід розбиття складних запитів на підмножину простих. NoSQL запити зазвичай простіші за традиційні SQL запити, тож можливість запуску додаткових запитів є доцільною з точки зору сумарного часу виконання. У випадку потреби запуску значної кількості запитів, варто розглянути наступні два підходи.

Кешування/Реплікація/Ненормалізовані дані[ред.ред. код]

На відміну від зберігання вийнятково зовнішніх ключів, звичний підхід зберігати зовнішні значення заразом з даними моделі. До прикладу, кожен коментар блогу може включати ім'я користувача окрім його id, забезпечуючи тим самим легкий доступ до імені користувача, не вимагаючи іншого пошуку. Однак, коли ім'я користувача було змінено - це тепер вимагатиме змін в багатьох місцях. Таким чином, цей підхід працює краще, при частому читанні даних, ніж їх модифікації.

Вкладені дані[ред.ред. код]

В документних базах, таких як MongoDB це цілком звично розміщувати більше даних в меншу кількість колекцій. До прикладу, застосунок типу блог може зберігати коментарі до певного посту як один запис. При цьому підході один документ міститиме всі необхідні дані для певного типу завдань.

Підримка ACID та JOIN[ред.ред. код]

Якщо база даних відзначена як така, що підтримує ACID чи joins, це означає що це підтверджено в її документації. Ступінь підтримки в тій чи іншій мірі відповідає потребам конкретного застосування.

Database ACID Joins
Aerospike Yes No
ArangoDB Yes Yes
CouchDB Yes Yes
c-treeACE Yes Yes
HyperDex Yes Yes
InfinityDB Yes No
LMDB Yes No
MarkLogic Yes Yes
OrientDB Yes Yes

Посилання[ред.ред. код]