Обзор существующих нереляционных СУБД

––––––––––––––––––––––––––––––––––––

Санкт-Петербургский  государственный

электротехнический  университет «ЛЭТИ»

––––––––––––––––––––––––––––––––––––

 

 

 

 

 

 

Реферат по дисциплине «Нереляционные системы»

Тема  реферата: «Обзор существующих нереляционных СУБД».

 

 

 

 

 

 

 

 

 

 

 

 

 

 

       

Содержание
Введение	3
Типы современных нереляционных СУБД	3
Документо-ориентированные СУБД	4
CouchDB	5
MongoDB	8
IBM Lotus Notes	10
Хранилища типа «ключ–значение»	12
Azure Table Storage	13
MEMBASE	13
Redis	14
Riak	15
Колоночно-ориентированные СУБД	17
Cassandra	18
Hypertable	19
Граф-ориентированные СУБД	21
OrientDB	22
Заключение	23
Список литературы	24

 

 

 

 

 

 

 

 

 

 

 

Введение.

Современные нереляционные СУБД в литературе принято называть NoSQL. Понятие NoSQL (Not Only SQL или No SQL) получило известность с 2009 года. Именно тогда развитие web-технологий и социальных сервисов дало толчок множеству новых подходов к хранению и обработке данных.

Выделим основные концептуальные отличия NoSQL систем от РСУБД:

– NoSql системы не являются реляционными;

– NoSql системы являются распределенными;

– Доступ к данным в NoSql системах как правило осуществляется по средствам простого API.

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

Достоинства NoSQL :

• Масштабируемость. Горизонтальное масштабирование существующих традиционных СУБД обычно является трудоемкой, дорогостоящей и эффективной только до определенного уровня задачей. В то же время многие NoSQL-решения проектировались исходя из необходимости масштабироваться горизонтально и делать это «на лету». Поэтому эта процедура обычно проще и прозрачнее в NoSQL, чем в РСУБД.
• Производительность БД на одном узле, а не в кластере также является немаловажным параметром. Для многих задач такие свойства традиционных СУБД, как транзакционность, изолированность изменений, надежность в пределах одного узла или даже сама реляционная модель, не всегда нужны в полном объеме. Поэтому отказ от этих свойств (всех или некоторых) позволяет NoSQL иногда добиваться большей производительности на одном узле, чем традиционным решениям.
• Надежная работа в условиях, когда отказ железа или сетевая недоступность – обычное дело, является одним из свойств многих решений NoSQL. Основной способ ее обеспечения – это репликация. Сама по себе репликация отнюдь не является уникальной особенностью NoSQL, но здесь, как и при масштабировании, важную роль играют эффективность и легкость внесения изменений в существующую инсталляцию. Переход БД к работе в режиме репликации – это простая задача для большинства NoSQL-решений.
• Простота разработки и администрирования – также важный аргумент в пользу NoSQL-технологий. Целый ряд задач, связанных с масштабированием и репликацией, представляющих значительную сложность и требующих обширной специальной экспертизы на традиционных СУБД, у NoSQL занимает считанные минуты. Задачи установки и настройки, само использование NoSQL-решений обычно существенно проще и менее трудоемки, чем в случае с РСУБД.

 

Типы современных  нереляционных СУБД

NoSQL системы принято различать по моделям хранения данных:

• ключ-значение,
• документно-ориентированная модель,
• колоночно-ориентированная модель,
• графовая модель.

 

 

 

 

 

 

 

 

 

 

 

 

 

Документо-ориентированные СУБД

Документо-ориентированные СУБД хранят данные в виде коллекций документов, состоящих из набора полей. Этот набор может различаться в документах одной коллекции благодаря «бессхемности» таких СУБД. В некоторых реализациях допускаются вложенные документы и сложные типы значений полей (массивы, ссылки и т.п.). Идеальный вариант их применения – это хранение более-менее независимых документов, не требующих поддержания ссылочной целостности между ними или коллекциями (форумы или социальные сети, каталоги товаров или изделий).

Также они хорошо подходят для работы с данными нестрогой структуры. Такого рода данные часто встречаются  при решении задач логирования и сбора статистики: существует множество типов событий, относящихся к одной категории, но с различными атрибутами. В традиционных СУБД хранение такого рода данных осуществляют двумя способами. Либо записывают основные параметры событий в одну таблицу, а дополнительные поля – в множество связанных таблиц, либо осуществляют сериализацию дополнительных полей в строки, бинарные данные и т.п. Такой подход сильно усложняет логику приложения и затрудняет дальнейшую работу с данными.

Примеры документо-ориентированных СУБД:

• CouchDB
• MongoDB
• IBM Lotus Notes
• Terrastore
• ThruDB
• OrientDB
• RavenDB
• BaseX
• Citrusleaf
• SisoDB

 

 

 

 

 

CouchDB

CouchDB — документо-ориентированная система управления базами данных, не требующая описания схемы данных, распространяется свободно, написана на языке Erlang.

CouchDB можно рассматривать как сервер веб-приложений; для реализации этой идеи в CouchDB встроен производительный веб-сервер, а программный код, как и данные, сохраняется в той же базе данных. Для автоматизации работы с приложениями CouchDB используется утилита CouchApp.

Особенности:

• данные сохраняются не в строках и колонках, а в виде JSON-подобных документов, моделью которых является не таблицы, адеревья;
• типизация элементов данных, то есть сопоставление отдельным полям документов типов INTEGER, DATE и пр., не поддерживается — вместо этого пользователь может написать функцию-валидатор;
• целостность базы данных обеспечивается исключительно на уровне отдельных записей (но не на уровне связей между ними);
• связи между таблицами или записями принципиально не поддерживаются, соответственно операция объединения (JOIN) между таблицами не определена;
• для построения индексов и выполнения запросов используются функции представления (view);
• функции-валидаторы, функции-представления, функции-фильтры сохраняются в текстовом виде в самой базе данных;
• каждой базе данных в системе CouchDB соответствует единственное B-дерево (не путать с двоичным деревом);
• каждое B-дерево хранится в виде отдельного файла на диске;
• одновременно может быть запущено несколько потоков для чтения базы данных и только один — для записи;
• целостность базы данных обеспечивается только при записи данных на диск;
• представления хранятся в БД и их индексы обновляются непрерывно, однако при каждом обновлении функций представления или отображения обновляется всё B-дерево целиком;
• при обработке данных с помощью функций-представлений используется упрощённая модель технологии MapReduce, что позволяет производить параллельные вычисления, в том числе и на многоядерном процессоре;
• распределение вычислений на несколько узлов не поддерживается — вместо этого используется механизм репликации;
• обработка данных с помощью цепочки последовательных функций MapReduce не поддерживается;
• поддерживается вертикальная масштабируемость, что означает поддержку не только огромных кластеров, но и портативных устройств (нетбуки, смартфоны и пр.);
• внешний интерфейс (API) к данной СУБД построен на основе архитектуры REST, то есть сама база данных, отдельные записи, отображения и запросы — суть ресурсы, которые имеют уникальный адрес (URL) и поддерживают операции GET, PUT, POST, DELETE;
• поэтому для взаимодействия с базой данных было написано много клиентских библиотек, в том числе на таких языках JavaScript, PHP, Ruby, Python и Erlang;
• взаимодействие между отдельными компонентами СУБД, то есть с серверами представлений осуществляется опять-таки с помощью текстового протокола, а данные передаются в формате JSON; это позволило использовать различные языки программирования для написания этих компонентов —Java,  JavaScript,  Python  и пр.

 

 

 

 

 

 

 

 

 

 

 

 

 

MongoDB

MongoDB — документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++.

При разработке авторы исходили из необходимости специализации  баз данных, благодаря чему им удалось  отойти от принципа «один размер подо всё». За счёт минимизации семантики  для работы с транзакциями появляется возможность решения целого ряда проблем, связанных с недостатком  производительности, причём горизонтальное масштабирование становится проще. Используемая модель документов хранения данных проще кодируется, проще управляется (в том числе за счёт применения т. н. «бессхемного стиля» (англ. schemaless style)), а внутренняя группировка релевантных данных обеспечивает дополнительный выигрыш в быстродействии. Нереляционный подход весьма удобен для создания баз данных, у которых горизонтальное масштабирование подразумевает разворачивание на множестве машин. Возможность обеспечивать наилучшую производительность должна существовать параллельно с поддержкой более обширной функциональности, чем это позволяет использование пар «ключ-значение» (в чистом виде). Технология баз данных должна работать везде, начиная с серверов пользователя ивиртуальных машин и заканчивая облачными технологиями.

Основные возможности  данной СУБД:

• Документо-ориентированное хранилище (простая и мощная JSON-подобная схема данных)
• Достаточно гибкий язык для формирования запросов
• Динамические запросы
• Полная поддержка индексов
• Профилирование запросов
• Быстрые обновления «на месте»
• Эффективное хранение двоичных данных больших объёмов, напр., фото и видео
• Журналирование операций, модифицирующих данные в БД
• Поддержка отказоустойчивости и масштабируемости: асинхронная репликация, набор реплик и шардинг
• Может работать в соответствии с парадигмой MapReduce
• Полнотекстовый поиск, в том числе на русском языке, с поддержкой морфологии

 

СУБД управляет наборами JSON -подобных документов, хранимых в двоичном виде в формате BSON. Хранение и поиск файлов в MongoDB происходит благодаря вызовам протокола GridFS. Подобно другим документо-ориентированным СУБД , MongoDB не является реляционной СУБД. Среди других отличий от традиционных реляционных СУБД:

• Отсутствует оператор «join». Обычно данные могут быть организованы более денормализованным способом, но на разработчиков ложится дополнительная нагрузка по обеспечениюнепротиворечивости данных.
• Нет такого понятия, как «транзакция». Атомарность гарантируется только на уровне целого документа, т.е. частичного обновления документа произойти не может.
• Отсутствует понятие «изоляции». Любые данные, которые считываются одним клиентом, могут параллельно изменяться другим клиентом.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IBM Lotus Notes 

IBM Lotus Notes — программный продукт, платформа для автоматизации совместной деятельности рабочих групп, содержащий в себе средства электронной почты, персональных и групповых электронных календарей, службы мгновенных сообщений и среду исполнения приложений делового взаимодействия.

Особенности:

1. Кроссплатформенность.

Значимой особенностью является кроссплатформенность Lotus Notes. Текущая версия сертифицирована IBM для работы со следующими операционными системами:

• сервер Lotus Domino — Windows (32 и 64-бит), Linux, Solaris, i5/OS (OS/400), AIX, z/OS (OS/390)
• клиент Lotus Notes — Windows (32 и 64-бит), Mac OS X, Linux

2. Масштабируемость

Вертикальная масштабируемость обеспечивается следующими возможностями:

• Увеличение производительности аппаратной платформы, на которой установлен сервер.
• Достаточно простая замена аппаратной и даже программной платформы (операционной системы) сервера на более производительную. Перенос данных может быть осуществлён даже обычным копированием.

Горизонтальная масштабируемость обеспечивается следующими возможностями:

• Распределение нагрузки достигается путём распределения по разным серверам Lotus Domino клиентов, приложений и функций (задач сервера Domino). Перераспределить нагрузку сравнительно просто на уже работающей инфраструктуре сети Lotus Domino, запуская и останавливая задачи сервера Domino или назначая «домашние» сервера пользователям и перенося приложения с сервера на сервер прямо на работающих серверах.
• Кластеризация серверов Lotus Domino. Организация и переконфигурация кластеров Domino возможна на работающей инфраструктуре серверов Domino (для включения сервера в кластер даже не требуется его перезагрузка).