Беспрецедентные объемы данных заставляют разработчиков и бизнес приглядываться к альтернативам реляционных баз данных, используемым вот уже более тридцати лет. В совокупности все эти технологии известны как «NoSQL базы данных».
Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим оhigh-load проектах). Есть три конкретные проблемных области:
Термин NoSQL был придуман Эриком Эвансом (Eric Evan / Racker), когда Джоан Оскарсон (Johan Oskarsson) из Last.fm хотел организовать мероприятие для обсуждения распределенных баз данных с открытым исходным кодом.
Некоторые люди относятся неодобрительно к термину NoSQL так как он звучит как основанный на том что мы не хотим делать, а не на том кем мы являемся. Движение NoSQL это не движение против реляционных баз данных. NoSQL — это «Не только SQL» (Not Only SQL), а не «Нет SQL» (No SQL at all).
Под термином NoSQL скрывается большое количество продуктов с абсолютно разными дизайнами и иногда при обсуждении разговор может идти о разных системах. Так что я предлагаю использовать три оси для сравнения этих систем: масштабируемость, модель данных и запросов, система хранения данных.
Я выбрал 10 NoSQL баз данных для примеров. Это не весь список, но их достаточно для оценки.
Под масштабируемостью, некоторые могут подразумевать репликацию, так что когда мы говорим о масштабируемости в данном контексте — мы имеем в виду автоматическое распределение данных между несколькими серверами. Такие системы мы называем распределенные базы данных. В них входят Cassandra, HBase, Riak, Scalaris и Voldemort. Это ваш единственный выбор, если вы используете объем данных который не может быть обработан на одной машине или если вы не хотите управлять распределением вручную.
Есть две вещи, на которые нужно смотреть в распределенной базе данных: поддержка нескольких датацентров и возможность добавления новых машин в работающий кластер прозрачно для ваших приложений.
Не распределенные базы данных включают в себя CouchDB, MongoDB, Neo4j, Redis и Tokyo Cabinet. Данные системы могут служить прослойкой для хранения данных для распределенных систем; MongoDB предоставляет ограниченную поддержку шардинга (sharding), так же как и отдельный проект Lounge для CouchDB, и Tokyo Cabinet может использоваться как система хранения файлов для Voldemort.
Существует огромное многообразие моделей данных и API запросов в NoSQL базах данных.
(Соответствующие ссылки Thrift, Map/Reduce, Thrift, Cursor, Graph, Collection, Nested hashes, get/put, get/put, get/put)
Система семейства столбцов (columnfamily) используется в Cassandra и HBase и ее идея была привнесена в них из документов описывающих устройство Google Bigtable (Cassandra правда немного ушла от идей Bigtable и ввела supercolumns). В обеих системах, у вас есть строки и столбцы, как вы привыкли видеть, но количество строк не велико: каждая строка имеет больше или меньше столбцов, в зависимости от необходимости и столбцы не должны быть определены заранее.
Система ключ/значения сама по себе простая, и не сложная для реализации, но не эффективна, если вы заинтересованы только в запросе или обновлении части данных. Так же трудно реализовать сложные структуры поверх распределенных систем.
Документо-ориентированные базы данных это по существу следующий уровень систем ключ/значение, позволяющие связывать вложенные данные с каждым ключом. Поддержка таких запросов более эффективна, чем просто возвращение всего BLOB каждый раз.
Neo4J обладает поистине уникальной моделью данных, храня объекты и связи в качестве узлов и ребер графа. Для запросов, которые соответствуют этой модели (например, иерархических данных) они могут быть в тысячу раз быстрее, чем альтернативные варианты.
Scalaris уникальна в использовании распределенных транзакций между несколькими ключами. Обсуждение компромиссов между последовательностью и наличием свободных мест выходит за рамками этого поста, но это другой аспект, который необходимо учитывать при оценке в распределенных системах.
Под системой хранения данных я имею в виду, как данные хранятся внутри системы.
Система хранения данных может сказать нам многое о том, какие нагрузки база может нормально выдерживать.
Базы данных хранящие данные в памяти очень, очень быстрые (Redis может выполнять до 100,000 операций в секунду), но не могут работать с данными превышающими размер доступной оперативной памяти. Долговечность (сохранение данных в случае сбоя на сервере или отключения питания) так же может быть проблемой (в новых версиях будет поддержка append-only log). Количество данных которые могут ожидать записи на диск потенциально велико. Другая система с хранением данных в оперативной памяти — Scalaris, решает проблему долговечности с помощью репликации, но она не поддерживает масштабирования на несколько датацентров, так что потеря данных вероятна и тут — в случае отключения питания.
Memtables и SSTables буферизируют запросы на запись в памяти (memtable), после записи в commit лог для сохранности данных (объяснить это трудно, но можно подробнее почитать в wiki Cassandra — http://wiki.apache.org/cassandra/ArchitectureOverview). После накопления достаточного количества записей, Memtable сортируется и записывается на диск, уже как SSTable. Это дает производительность близкую к производительности памяти, в тоже время система лишена проблем актуальных при хранении только в памяти. (Эта процедура описана более подробно в разделах 5.3 и 5.4, так же как слияние деревьев на основе лога — Thelog-structured merge-tree )
B-деревья используются в базах данных уже очень давно. Они обеспечивают надежную поддержку индексирования, но производительность очень низкая при использовании на машинах с жесткими дисками на магнитных дисках (которые по-прежнему наиболее экономически эффективны), так как происходит большое количество позиционирований головки при записи или чтении данных.
Интересным вариантом является использование в CouchDBB-деревьев , только с функцией добавления (append-only B-Trees — бинарное дерево которое не нужно перестраивать при добавлении элементов), что позволяет получить не плохую производительность при записи данных на диск.
Движение NoSQL резко выросло в 2009 году, благодаря увлечению количества компаний связанных с использованием больших объемов данных. Появляется все больше систем позволяющих организовывать и прозрачно поддерживать огромные массивы данных, обрабатывать и контролировать эти данные. Я надеюсь благодаря этой небольшой статье, вы узнаете о некоторых сильных сторонах NoSQL систем и возможно внесете свой вклад в развитие данного движения.
Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о
- горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
- производительность каждого отдельного сервера
- не гибкий дизайн логической структуры.
Термин NoSQL был придуман Эриком Эвансом (Eric Evan / Racker), когда Джоан Оскарсон (Johan Oskarsson) из Last.fm хотел организовать мероприятие для обсуждения распределенных баз данных с открытым исходным кодом.
Некоторые люди относятся неодобрительно к термину NoSQL так как он звучит как основанный на том что мы не хотим делать, а не на том кем мы являемся. Движение NoSQL это не движение против реляционных баз данных. NoSQL — это «Не только SQL» (Not Only SQL), а не «Нет SQL» (No SQL at all).
Под термином NoSQL скрывается большое количество продуктов с абсолютно разными дизайнами и иногда при обсуждении разговор может идти о разных системах. Так что я предлагаю использовать три оси для сравнения этих систем: масштабируемость, модель данных и запросов, система хранения данных.
Я выбрал 10 NoSQL баз данных для примеров. Это не весь список, но их достаточно для оценки.
Масштабируемость
Под масштабируемостью, некоторые могут подразумевать репликацию, так что когда мы говорим о масштабируемости в данном контексте — мы имеем в виду автоматическое распределение данных между несколькими серверами. Такие системы мы называем распределенные базы данных. В них входят Cassandra, HBase, Riak, Scalaris и Voldemort. Это ваш единственный выбор, если вы используете объем данных который не может быть обработан на одной машине или если вы не хотите управлять распределением вручную.
Есть две вещи, на которые нужно смотреть в распределенной базе данных: поддержка нескольких датацентров и возможность добавления новых машин в работающий кластер прозрачно для ваших приложений.
Не распределенные базы данных включают в себя CouchDB, MongoDB, Neo4j, Redis и Tokyo Cabinet. Данные системы могут служить прослойкой для хранения данных для распределенных систем; MongoDB предоставляет ограниченную поддержку шардинга (sharding), так же как и отдельный проект Lounge для CouchDB, и Tokyo Cabinet может использоваться как система хранения файлов для Voldemort.
Модель данных и запросов
Существует огромное многообразие моделей данных и API запросов в NoSQL базах данных.
(Соответствующие ссылки Thrift, Map/Reduce, Thrift, Cursor, Graph, Collection, Nested hashes, get/put, get/put, get/put)
Система семейства столбцов (columnfamily) используется в Cassandra и HBase и ее идея была привнесена в них из документов описывающих устройство Google Bigtable (Cassandra правда немного ушла от идей Bigtable и ввела supercolumns). В обеих системах, у вас есть строки и столбцы, как вы привыкли видеть, но количество строк не велико: каждая строка имеет больше или меньше столбцов, в зависимости от необходимости и столбцы не должны быть определены заранее.
Система ключ/значения сама по себе простая, и не сложная для реализации, но не эффективна, если вы заинтересованы только в запросе или обновлении части данных. Так же трудно реализовать сложные структуры поверх распределенных систем.
Neo4J обладает поистине уникальной моделью данных, храня объекты и связи в качестве узлов и ребер графа. Для запросов, которые соответствуют этой модели (например, иерархических данных) они могут быть в тысячу раз быстрее, чем альтернативные варианты.
Scalaris уникальна в использовании распределенных транзакций между несколькими ключами. Обсуждение компромиссов между последовательностью и наличием свободных мест выходит за рамками этого поста, но это другой аспект, который необходимо учитывать при оценке в распределенных системах.
Система хранения данных
Под системой хранения данных я имею в виду, как данные хранятся внутри системы.
Система хранения данных может сказать нам многое о том, какие нагрузки база может нормально выдерживать.
Базы данных хранящие данные в памяти очень, очень быстрые (Redis может выполнять до 100,000 операций в секунду), но не могут работать с данными превышающими размер доступной оперативной памяти. Долговечность (сохранение данных в случае сбоя на сервере или отключения питания) так же может быть проблемой (в новых версиях будет поддержка append-only log). Количество данных которые могут ожидать записи на диск потенциально велико. Другая система с хранением данных в оперативной памяти — Scalaris, решает проблему долговечности с помощью репликации, но она не поддерживает масштабирования на несколько датацентров, так что потеря данных вероятна и тут — в случае отключения питания.
Memtables и SSTables буферизируют запросы на запись в памяти (memtable), после записи в commit лог для сохранности данных (объяснить это трудно, но можно подробнее почитать в wiki Cassandra — http://wiki.apache.org/cassandra/ArchitectureOverview). После накопления достаточного количества записей, Memtable сортируется и записывается на диск, уже как SSTable. Это дает производительность близкую к производительности памяти, в тоже время система лишена проблем актуальных при хранении только в памяти. (Эта процедура описана более подробно в разделах 5.3 и 5.4, так же как слияние деревьев на основе лога — The
Интересным вариантом является использование в CouchDB
Заключение
Движение NoSQL резко выросло в 2009 году, благодаря увлечению количества компаний связанных с использованием больших объемов данных. Появляется все больше систем позволяющих организовывать и прозрачно поддерживать огромные массивы данных, обрабатывать и контролировать эти данные. Я надеюсь благодаря этой небольшой статье, вы узнаете о некоторых сильных сторонах NoSQL систем и возможно внесете свой вклад в развитие данного движения.
