NoSQL

Записаться

Переходим к следующей части. Что же такое NoSQL, как оно связано со всем предыдущим, о чём мы говорили? Первое понимание, которое приходит в голову человеку, столкнувшемуся с этим термином, это не SQL или некоторое отрицание SQL. И сразу же говорят, что «нет», это неправильное понимание данного термина. Правильное понимание данного термина это «Not Only SQL» . Справедливости ради нужно сказать, что вначале подразумевалось всё-таки «No SQL» и только потом, когда появились ярые противники и критики данного подхода, расшифровали, как «Not Only». И под SQL мы понимаем, конечно же, не «SQL», не в том смысле, не в смысле языка запросов строчках language, а в смысле реляционных баз данных или еще уже, или еще шире – ACID. То есть не только системы, выполняющие требования ACID. И здесь мы понимаем, что у нас определение в таком виде от противного, то, практически, все решения, которые не удовлетворяют ACID, можно отнести к классу NoSQL.

И да, NoSQL это не технология, как говорит Википедия это «всего лишь ряд подходов, направленных на реализацию хранилищ баз данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом через SQL и реализующий принцип ACID. В общем виде мы говорим, что хранилище реализующие принцип BASE, вместо ACID могут быть отнесены к классу NoSQL решений.

Какие бывают типы NoSQL решений? Самый простой тип - это хранилище в виде «ключ-значение». Действительно, ключи уже плотно, скажем так, существуют в головах аналитиков и всех профессионалов, которые работают с данными. Это аналог идентификаторов и в некоторых случаях - аналог типов данных в реляционных базах данных. То есть это, скажем так, пересечение функционала идентификаторов, индексов и типов данных, в зависимости от реализации в конкретном решении. Но интуитивно, думаю, понятно, что такое «ключ-значение». Это когда мы храним просто пару: название параметра, значение параметра. Каждая запись является такой атомарной записью. Более продвинутый подход это, когда мы говорим, что само значение у нас может тоже являться парой «ключ-значение».

Дальше колоночные базы данных. Это самый распространенный тип NoSQL. Как раз он возник на таких задачах, когда мы получаем данные в больших количествах из различных источников. Как раз тот раз, когда мы говорила, что из одного источника мы получаем один набор атрибутов, из другого - другой набор атрибутов. В этом смысле нам удобнее хранить не строки с объединением данных атрибутов, а столбцы из одного источника, из другого источника, и они между собой как-то завязаны через ключевые значения.

Документоориентированные хранилища - это такие хранилища, которые хранят данные в виде структур. Проще всего представить себе XML или JSON структуру. Для таких структур в общем случае или чаще всего можно сказать о том, что они имеют нестабильную или нестандартную структуру, но при этом мы чаще всего хотим получить информацию для анализа, мы используем информацию из всего документа, то есть о всей структуре. То есть у нас есть большое количество документов, каждый из них может обладать своей структурой, но при обработке нам важно получать весь блог об этой структуре.

Графовые базы ориентированы на узкий класс задач обработки графов, мы будем об этом говорить подробнее. И нужно сказать, что других типов огромное количество, то есть на данный момент рынок растет вширь, и само количество, и скорость возникновения решений NoSQL говорит о том, что идет поиск. Еще буквально несколько лет и, скорее всего, из всего представляемого многообразия останется несколько самых живучих и самых выживших, сильных решений. В этом смысле нет никакого смысла сейчас знакомиться со всем разнообразием или давать их учить этому студенту.

Итак, чуть подробнее. Базы «ключ-значение» - это отсутствие схем, кроме единственной логики, что мы храним пару ключа и значения, это у нас изменяющаяся структура данных, это у нас отсутствие целостности, согласованности в жестком понимание этого смысла, то есть слабая согласованность может быть. Это у нас очень легкое масштабирование, обычно через схему «Master-Slave», через репликацию. Это очень высокая доступность как на чтение, так и на запись, но при этом у нас из-за отсутствия схемы, у нас нет сложности запросов, сложности обработки, то есть нет этой сложности на уровне самих систем управления такими данными, мы должны реализовывать всю обработку и всю логику, какой бы сложной она была в своих приложениях.

Возможны транзакции за простой схемы. И типичное применение - это логии, каширование, промежуточные результаты анализа и так далее. Я буду показывать слайды с некоторыми, возможно, уже даже не на более распространенными, но на слуху, реализациями различных типов вас. Но здесь нам нужно отметить Redis, на нём остановимся чуть подробнее.

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

Снова набор реализаций такого типа баз. Здесь мы говорим о реализации Hbase от Apache и платформы Hadoop. И распространенная реализация Cassandra, которую тоже использует много лидеров отрасли именно больших систем, в частности «одноклассники» реализованы на Cassandra. «Документоориентированые», как я уже говорил, это данные тоже с нестандартной структурой. На типичной задачи это именно хранения и быстрая обработка, а именно таких структур. Реализации, которые у многих на слуху: MongoDB и CouchDB.

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

Вот, ну и здесь я отсылаю на страничку, где классов больше, чем три или четыре. Вот, а мы еще говорим, что объектные, многомодельные базы данных на Grid и облаках, XML базы данных и так далее. И классов много, и реализаций очень много.

Ну и конечно же, мы должны сказать, что и SQL не остался в прошлом, то есть реляционные базы данных шагают вперед, они поняли, что масштабируемость нужна всем, и без этого они, действительно, останутся в прошлом, поэтому сейчас идет активный поиск, как правильно масштабировать с исполнением требований ACID. Ну, и мы не произнесли вслух, но на слайде это было, что «CAP-теорема» у нас все еще теорема, и она строгим доказательством пока не обладает, обладает только мистическими доказательствами. Возможно, что будет найдено решение, которое её опровергнет, и выполнятся все требования ACID в масштабируемой системе. Утверждается, что такие решения появляются. Мы с ним дела не имели.