NOSQL

NoSQL (англ. not only SQL, не только SQL) Обозначает ряд подходов, проектов, направленных на реализацию моделей баз данных, имеющих существенные отличия от используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL. Описание схемы данных в случае использования NoSQL-решений может осуществляться через использование различных структур данных: хеш-таблиц, деревьев и других. Основная идея при разработке такого типа систем предоставление разработчикам более гибких средств по модификации схемы данных на этапе эксплуатации, отказе от транзакционного контроля в пользу более естественной поддержки распределённых вычислений.

NoSQL и SQL Сторонниками концепции NoSQL подчёркивается, что она не является полным отрицанием языка SQL и реляционной модели, проект исходит из того, что SQL это важный и весьма полезный инструмент, но при этом он не может считаться универсальным. Одной из проблем, которую указывают для классических реляционных БД, являются проблемы при работе с данными очень большого объема и в проектах с высокой нагрузкой. Основная цель подхода расширить возможности БД там, где SQL недостаточно гибок, и не вытеснять его там, где он справляется со своими задачами.

Методологические основы В основе идеи NoSQL лежит следующее: Нереляционная модель данных Открытый исходный код Хорошая горизонтальная масштабируемость. В качестве одного из методологических обоснований подхода NoSQL используется эвристический принцип, известный как теорема CAP, утверждающий, что в распределённой системе невозможно одновременно обеспечить согласованность данных, доступность (англ. availability, в смысле корректность отклика по любому запросу) и устойчивость к расщеплению распределённой системы на изолированные части. Таким образом, при необходимости достижения высокой доступности и устойчивости к разделению предполагается не фокусироваться на средствах обеспечения согласованности данных, обеспечиваемых традиционными SQL-ориентированными СУБД с транзакционными механизмами на принципах ACID.

Тренды в развитии технологий хранения данных В последнее время мы можем наблюдать 4 тренда в развитии технологий хранения данных.

Первый тренд Увеличение объемов хранимых данных. Сегодня хранилища достигли таких невероятных размеров, что даже трудно себе представить. Только за 2009 и 2010 годы в базах было сохранено больше информации, чем за всю предыдущую историю человечества.

Второй тренд Взаимосвязанность данных. Информация перестала быть изолированной. Каждый кусочек знаний как-то связан с данными в других хранилищах информации. Страницы в интернете ссылаются на другие страницы. Тэги связывают помеченную информацию из разных источников. Онтологии устанавливают взаимосвязи между различными терминами, и т.д. и т.п.

Третий тренд Использование слабоструктурированной информации. Возьмем простой пример: описание товара в магазине. Если раньше было достаточно 5-6 полей, чтобы описать мужскую сорочку (размер, цвет, материал, фотография товара,...), то теперь количество параметров может доходить до нескольких десятков. Причем, для разных сорочек будет использован разный набор параметров. В таких условиях становится крайне сложно заранее определить структуру таблицы, в которой хранится описание товара.

Четвертый тренд Архитектура. В 80-х годах прошлого века типичная архитектура использовала один большой компьютер (mainframe) и одну базу данных. В 90-х, распространение получила клиент-серверная архитектура. В новом веке активно используются web-сервисы, каждый со своим backend-ом (грубо говоря, со своей базой данных) и другие распределенные решения. Оказалось, что в таких условиях у реляционных баз данных резко падает производительность. И если для большинства web-сайтов производительности еще хватает, то для таких приложений как современные социальные сети или поисковые сервисы SQL базы данных оказались несостоятельны.

Категории NoSQL баз Существует четыре категории NoSQL баз данных.

Первая категория Key-Value (Ключ-Значение) базы данных. Это очень простые по своей идее хранилища. Фактически это очень большие хэш- таблицы, где каждому ключу поставлено в соответствие значение. Такие базы могут очень быстро оперировать колоссальными объемами информации, но они имеют серьезные ограничения в языке запросов. В качестве примеров Key-Value баз данных можно привести Dynomite, Voldemort, Tokyo, Redis.DynomiteVoldemortTokyoRedis

Вторая категория клоны BigTable. BigTable это база данных разработанная компанией Google для собственных нужд. Эта база представляет собой большую таблицу с тремя измерениями: колонки, строки и временны'е метки. Такая архитектура позволяет добиться очень высокой производительности, кроме того, она хорошо масштабируется на множество компьютеров. Но это не реляционная база, и она не поддерживает многие возможности реляционных баз. В частности в BigTable нет join-ов, нет сложных запросов и т.д. Компания Google не распространяет BigTable, поэтому на рынке появилось несколько независимо разработанных клонов этой базы. В частности это такие проекты как: Hadoop, Hypertable иCassandra.BigTableHadoopHypertableCassandra

Третья категория Документо-ориентированные базы данных. Такие базы немного напоминают Key-Value базы, но в данном случае, база данных знает, что из себя представляют значения. Обычно, значением является некоторый документ или объект, к структуре которого можно делать запросы. Примерами таких баз являются CouchDB и MongoDB.CouchDBMongoDB

Четвертая категория Это базы данных построенные на графах. Такие базы ориентированы на поддержку сложных взаимосвязей между объектами, и основываются на теории графов. Структура данных в таких базах представляет собой набор узлов, связанных между собой ссылками. При этом и узлы и ссылки могут обладать некоторым количеством атрибутов. В качестве примера можно привести такие базы данных как: Neo4j, AllegroGraph, Sones graphDB.Neo4jAllegroGraphSones graphDB

Механизмы для доступа к данным в NoSQL БД Существует несколько механизмов для доступа к данным в NoSQL БД.

RESTful интерфейсы Это интерфейс похожий на основной протокол интернета HTTP. В рамках данного подхода предполагается, что каждый объект, которым мы можем манипулировать имеет свой уникальный адрес. Обращаясь по этому адресу мы можем запрашивать, создавать, редактировать или удалять указанный объект. При этом на сервере не сохраняется никакого состояния, то есть каждый запрос обрабатывается независимо от других запросов.

Языки запросов отличные от SQL GQL SQL-подобный язык для Google BigTable SPARQL язык запросов Семантического Веба Gremlin язык обхода графов Sones Graph Query Language язык запросов к Sones Graph

API запросов Google BigTable DataStore API Neo4j Traversal API

Почему базы данных используют RESTful API? Потому что гиперссылки легко позволяют ссылаться на данные расположенные на других серверах. RESTful в данном случае наиболее подходящее решение.

Манипулирование данными RESTful API позволяет выполнять операции создания, редактирования и удаления данных. Другой подход предполагает использование специального API для манипулирования данными. Например, Google BigTable использует DataStore API, а Neo4j GraphDatabase API. Кроме того, NoSQL базы данных поддерживают сериализацию данных в разные форматы, такие как: JSON javascript object notation Thrift ProtoBuffers RDF

Структура информации Структуру данных в реляционных системах на примере MySQL мы можем представить в виде следующей иерархии: База данных -> Таблица -> Строка -> Поле + Значение. Как это все выглядит в MongoDB: База данных -> Коллекция -> Документ -> ключ + значение.

Структура информации Таблицы в реляционных БД должны быть жестко структурированы, в то время как в MongoDB можно создавать документы произвольной структуры.

Пример документа в формате JSON

Как можно заметить у нас полная свобода во вложенности данных документа, что избавляет нас от необходимости разносить одну сущность в разные документы. Как и в SQL в MongoDB есть индексы, причем полная их поддержка. Мы можем стоить индекс по любому ключу приведенного выше документа, в том числе по вложенному country или по массиву tags. Можно делать составные индексы по нескольким ключам документа.

Выборка Предположим нам надо выбрать все документы из определенной коллекции у которых значение city равно "Moscow".

SQL SELECT docs.title, loc.city FROM documents docs INNER JOIN doc_location d_loc ON d_loc.doc_id = docs.doc_id INNER JOIN location loc ON loc.loc_id = d_loc.loc_idJOIN

MongoDB db.find({additional.location.city: "Moscow"});

Запись В SQL есть оператор INSERT для добавления и UPDATE для обновления записей. Запись в MongoDB Выполняется при помощи трех функций: insert - добавление, save и update - для обновление и добавление.

Запись // $doc - произвольный документ // Вставить документ db.insert($doc); // Обновить документ или добавить новый //если его не существует, 2 варианта db.save($doc); // или db.update({name: "Joe"}, $doc, true); // первый аргумент - условие, второй - новый документ, //третий - вставка если исходный документ не найден // //Атомарная операция. Увеличить параметр counter на //единицу db.update({name: "Joe"}, {$inc : {counter : 1}});

Агрегация Допустим, перед нами стоит задача: мы имеем таблицу с комментариями, надо выбрать суммарное количество голосов за каждого автора. В SQL это решается довольно просто, как-то так: SELECT author, SUM(votes) FROM comments GROUP BY author;