ВНЕДРЕНИЕ ИНТЕЛЛЕКТУАЛЬНЫХ БАЗ ДАННЫХ. РЫНОК ИНСТРУМЕНТОВ

Обзор NOSQL систем

В последние годы появилась целая серия решений альтернативных реляционным БД. Эти технологии известны как «NoSQL базы данных».

Основная проблема реляционных БД заключается в том, что они не могут справляться с быстрым анализом и поиском для Big data. Можно выделить три конкретные проблемные области:

• •горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом);
• • производительность каждого отдельного сервера;
• • негибкий дизайн логической структуры.

Многие компании нуждаются в нахождении новых путей для хранения и масштабирования огромных массивов данных. Рассмотрим так называемые NoSQL базы данных подробнее.

Термин NoSQL был придуман Эриком Эвансом (Eric Evan / Racker), когда Джоан Оскарсон (Johan Oskarsson) из Last.fm хотел организовать мероприятие для обсуждения распределенных баз данных с открытым исходным кодом.

Под термином NoSQL скрывается большое количество продуктов с абсолютно разными дизайнами. Однако используются три основных параметра для сравнения этих систем: масштабируемость; модель данных и запросов; система хранения данных. Проанализируем некоторые NoSQL БД.

Масштабируемость - автоматическое распределение данных между несколькими серверами (распределенные базы данных). К ним относятся СУБД Cassandra, HBase, Riak, Scalaris и Voldemort.

Особенности распределенных БД: поддержка нескольких датацентров и возможность добавления новых машин в работающий кластер прозрачно для приложений пользователей.

Нераспределенные базы данных включают в себя CouchDB, MongoDB, Neo4j, Redis и Tokyo Cabinet. Эти системы могут служить прослойкой для хранения данных для распределенных систем; MongoDB предоставляет ограниченную поддержку шардинга (sharding), так же как и Lounge для CouchDB, и Tokyo Cabinet может использоваться как система хранения файлов для Voldemort.

Модель данных и запросов. Существует огромное многообразие моделей данных и API запросов в NoSQL базах данных.

Система семейства столбцов (columnfamily) используется в Cassandra и HBase, и ее идея была привнесена в них из документов, описывающих устройство Google Bigtable. В обеих системах в БД есть строки и столбцы, как обычно, но количество строк невелико: каждая строка имеет больше или меньше столбцов, в зависимости от необходимости, и столбцы не должны быть определены заранее.

Система ключ/значения проста и несложна для реализации, но неэффективна, если вы заинтересованы только в запросе или обновлении части данных. Также трудно реализовать сложные структуры поверх распределенных систем.

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

Neo4J обладает уникальной моделью данных, храня объекты и связи в качестве узлов и ребер графа. Для запросов, которые соответствуют этой модели (например, иерархических данных), они могут быть в тысячу раз быстрее, чем альтернативные варианты.

Scalaris использует распределенные транзакции между несколькими ключами. При этом необходимо учитывать компромисс между последовательностью и наличием свободных мест при оценке в распределенных системах.

Система хранения данных - способ хранения данных внутри системы. Обеспечивает возможность «выдерживания» высоких нагрузок хранилищем.

Базы данных хранящие данные в памяти, являются очень быстрыми (Redis может выполнять до 100 000 операций в секунду), но не могут работать с данными, превышающими размер доступной оперативной памяти. Долговечность (сохранение данных в случае сбоя на сервере или отключения питания) также может быть проблемой (в новых версиях будет поддержка append-only log). Количество данных, которые могут ожидать записи на диск, потенциально велико. Другая система с хранением данных в оперативной памяти — Scalaris, решает проблему долговечности с помощью репликации, но она не поддерживает масштабирования на несколько датацентров, так что потеря данных вероятна и тут — в случае отключения питания.

Memtables и SSTables буферизируют запросы на запись в памяти (memtable), после записи в commit лог для сохранности (см.подробнее http://wiki.apache.org/cassandra/ArchitectureOverview). После накопления достаточного количества записей, Memtable сортируется и записывается на диск, уже как SSTable. Это дает производительность, близкую к производительности памяти, в то же время система лишена проблем, актуальных при хранении только в памяти.

В-деревья используются в БД уже очень давно. Они обеспечивают надежную поддержку индексирования, но производительность очень низкая при использовании на машинах с жесткими дисками на магнитных дисках (которые по-прежнему наиболее экономически эффективны), так как происходит большое количество позиционирований головки при записи или чтении данных.

В CouchDB используют В-деревья с функцией добавления (append-only B-Trees — бинарное дерево, которое не нужно перестраивать при добавлении элементов), что позволяет получить неплохую производительность при записи данных на диск.