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

3. Репликация

4. Быстрая разработка (RAD) и развёртывание приложений.

Среда разработки приложений Domino Designer предоставляет разработчикам развитые базовые сервисы для разработки документоориентированных приложений.

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

5. Автономное выполнение приложений

Клиент Lotus Notes позволяет локально (на компьютере пользователя) хранить базы данных Lotus Notes, реплицировать их с сервером Domino, работать с локальными базами данных при отсутствии подключения к серверу Domino, исполнять программный код сервера в локальных базах данных.

Данная функциональность поддерживает полнофункциональную  работу пользователя в отключенном  от сервера состоянии (например, на ноутбуке). Изменения на локальном (для  пользователя) компьютере и на сервере  взаимно синхронизируются посредством  репликации.

6. Инфраструктура управления открытыми ключами (PKI)

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

• Электронная цифровая подпись используется при аутентификации сервером пользователя и/или сервера, при определении уровня доверия выполняемому коду, при проверке достоверности почтовых сообщений, документов (записей в БД) и отдельных полей.
• Шифрование применяется для почтовых сообщений, целиком баз данных, отдельных документов (записей в БД), отдельных полей и сетевого трафика между двумя серверами Lotus Domino, а также между сервером и клиентом Lotus Notes.

Хранилища типа «ключ–значение».

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

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

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

Примеры реализации:

• Azure Table Storage
• MEMBASE
• Redis
• Chordless
• LevelDB

 

 

 

 

 

 

 

 

 

 

 

 Azure Table Storage

Windows Azure Table Storage — гибкое хранилище сущностей ключ-значение, которое позволяет быстро создать облачное приложение без замыкания модели данных приложения на конкретный набор схем. Этот сервис не является хранилищем реляционных данных и не даёт таких возможностей по управлению реляционными данными, как SQL Database (например, join-ов и хранимых процедур). Windows Azure Table Storage имеет ограниченную поддержку запросов на стороне сервера, но имеет функции транзакций. Кроме этого, разные записи внутри одной таблицы могут иметь разную структуру, и такой подход в Windows Azure Table Storage позволяет эффективно хранить и оперировать простыми реляционными данными.

Возможности:

• Географическая репликация
• Вертикальное масштабирование
• Поддержка REST
• поддерживает логирование, позволяя вам видеть все выполняемые запросы. Логирование также предоставляет агрегированные метрики для запросов.
• Для обеспечения высокого уровня отказоустойчивости хранимые данные реплицируются в три копии внутри региона и еще в три копии в другой датацентр в этом же регионе

MemBase

MemBase — открытое, распределенное персистентное хранилище ключ-значение оптимизированное для хранения данных веб-приложений. 

Ключевые характеристики системы: 
 
Скорость. MemBase автоматически распределяет и данные и запросы на манипуляцию ими между серверами кластера. Данные реплицируются для обеспечения высокой доступности даже в случае выхода части серверов из строя, а также автоматически перемещаются внутри хранилища в память с соответствующим временем доступа (часто используемые данные при этом попадают в самую быструю память, а наименее часто — на медленные диски). Вся архитектура системы оптимизирована для высочайшей скорости работы. 
 
Гибкость. MemBase масштабируется линейно. Серверы можно добавлять / удалять из кластера прямо в процессе работы.  
 
Надежность. Любое количество серверов системы (вплоть до значения replication count, которое можно изменять) может отказать в любой момент времени, но кластер все равно будет продолжать свою работу. Даже в случае, если сервер-лидер кластера выйдет из строя, его замена будет подобрана автоматически без вмешательства пользователя. 
 
Полная совместимость с memcached по протоколу. Для общения с membase приложения используют библиотеку memcached и memcached протокол.

 

Redis

Redis — сетевое журналируемое хранилище данных типа «ключ — значение» с открытым исходным кодом.

Хранит базу данных в оперативной  памяти, снабжена механизмами снимков и журналирования для обеспечения постоянного хранения. Основной особенностью является поддержка значений следующих типов: строка (данный тип позволяет хранить произвольный сериализованный объект либо число, поддерживаются специальные операции трактующие строку как целое число), связный список, множество, сортированное множество, хеш таблица, операции над которыми выполняются атомарно. Также предоставляет операции для реализации механизма обмена сообщениями в паттерне publish — subscribe.

Для обеспечения надежности в рамках нескольких узлов Redis использует репликацию, а одного узла – журналирование операций с диском.

Имеет библиотеки для работы со многими существующими языками  программирования, такими как C, C++, C#, Clojure, Common Lisp, Erlang,Java, JavaScript, Haskell, Lua, Perl, PHP, Python, Ruby, Scala, Go, Tcl.

 

 

 

 

 

 

 

Riak

Riak — распределенная opensource база данных, разработанная на Erlang и спроектированная в расчете на:

• Высокую доступность и устойчивость к сбоям;
• Все данные в кластере реплицируются по принципу соседей на хэш кольце (см. логотип для иллюстрации) и даже в случае сбоев доступны посредством интеллектуального перенаправления запросов внутри кластера.
• В случае возникновения коллизий из-за разрыва сетевого соединения или просто одновременной записи, на запрос получения данных может вернуться несколько версий и приложение само может решить как их объединить или какую версию использовать.
• Масштабируемость и простоту обслуживания;
• Добавление нового сервера тривиально путем копирования конфига и одной команды.
• Перераспределение данных и все остальное прозрачно происходит за сценой.
• Минимальный рекомендуемый размер Riak кластера — 5 серверов, меньшее количество не дает раскрыть весь потенциал.
• Одинаково легко обслуживать как маленький, так и большой кластер.
• Есть коммерческая Enterprise версия с поддержкой от Basho, компании-разработчика Riak (изначально выходцы из Akamai), равноправной зашифрованной репликацией между датацентрами и поддержкой SNMP.
• Есть встроенный веб-интерфейс для мониторинга и управления кластером, у меня правда так и не дошли руки его освоить:
• Универсальность.
• Схема отсутствует, ключи и данные — произвольные бинарные строки. Ключи располагаются в пространствах имен (bucket).
• Сериализация — на усмотрение разработчика, популярные варианты — Erlang'овскийBERT, JSON для других платформ, можно использовать просто как файловую систему.
• Модульная система хранилищ данных, альтернатив много, основная — GoogleLevelDB; еще интересный вариант с хранением полностью в оперативной памяти — получается продвинутый распределенный кэш с репликацией, поиском и пр.
• Гибко настраиваемое количество узлов кластера, которые должны подтвердить успешность операции, чтобы она считалась успешной: можно указывать для всего кластера, пространства имен и даже конкретного запроса. Riak в любом случае остается eventually consistent базой данных (AP из CAP теоремы), но с возможностью управлять балансом производительности операций и надежностью выполнения запросов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Колоночно-ориентированные СУБД

В отличие от традиционных, колоночные СУБД хранят данные в виде последовательности столбцов, а не строк. Благодаря этому достигаются некоторые преимущества в хранении и обработке больших объемов информации.

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

Примеры реализации: Hadoop / HBase Cassandra Hypertable Cloudata Cloudera SciDB

 

 

 

 

 

 

 

 

 

 

 

 

 

Apache Cassandra 

Apache Cassandra — распределённая система управления базами данных, относящаяся к классу noSQL-систем и рассчитанная на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных, представленных в виде хэша.

СУБД Cassandra написана на языке Java и включает в себя полностью распределённую hash-систему Dynamo, что обеспечивает практически линейную масштабируемость при увеличении объёма данных. Cassandra использует модель хранения данных на базе семейства столбцов (ColumnFamily), что отличается от систем, подобных memcachedb, которые хранят данные только в связке ключ/значение, возможностью организовать хранение хэшей с несколькими уровнями вложенности. Cassandra относится к категории хранилищ, повышенно устойчивых к сбоям: помещённые в БД данные автоматически реплицируются на несколько узлов распредёленной сети или даже равномерно распределяются в нескольких дата-центрах. При сбое узла, его функции на лету подхватываются другими узлами. Добавление новых узлов в кластер и обновление версии Cassandra производится на лету, без дополнительного ручного вмешательства и переконфигурации других узлов. Тем не менее настоятельно рекомендуется заново сгенерировать токены для каждого узла, включая существующие, чтобы не испортить распределение нагрузки. Генерации ключей для существующих узлов можно избежать в случае кратного увеличения количества узлов (в 2 раза, в 3 раза и т.д.).

Для упрощения взаимодействия с БД поддерживается язык формирования структурированных запросов CQL (Cassandra Query Language), который на первый взгляд напоминает SQL, но существенно урезан в функциональности. Например, можно выполнять только простейшие запросы SELECT с выборкой по определённому условию. Добавление и обновление осуществляется через единое выражение UPDATE, операция INSERT отсутствует (если записи нет, при выполнении UPDATE она создаётся). Из возможностей можно отметить поддержку пространств имён и семейств столбцов, создание индексов через выражение «CREATE INDEX». Драйверы с поддержкой CQL подготовлены для языков Python, Java (JDBC/DBAPI2), Ruby (gem cassandra-cql), PHP (Trift, cassandra-pdo, Cassandra-PHP-Client-Library) и JavaScript (Node.js).

 

 

 

 

 

Hypertable

Hypertable является opensource проектом, направленным на воспроизведение функционала BigTable от Google. Поставленная перед проектом цель заключается в реализации системы хранения данных на базе распределенной файловой системы, позволяющей перейти на новый уровень производительности при работе с гигантскими объемами данных. 
Принцип работы:

• Hypertable хранит данные в табличном формате, сортируя записи по основному ключу;
• для хранимых данных не используются какие-либо типы данных, любая ячейка интерпретируется как байтовая строка;
• масштабируемость достигается путем разбиения таблиц на смежные интервалы строк и хранения их на разных физических машинах;
• в системе используется два типа серверов:

Master Server

– как и во многих других подобных системах мастер-сервер выполняет обязанности скорее административного характера: он управляет работой Range серверов, работает с метаданными (которые хранятся просто в отдельной таблице, наравне с остальными).

Range Server

– их задача стоит в собственно в хранении диапазонов строк из различных  таблиц. Каждый сервер может хранить несколько несмежных диапазонов строк, если диапазон превышает по объему определенный лимит (по-умолчанию — 200 MB), то он разбивается на пополам и одна половина обычно перемещяется на другой сервер. Если же на одном из серверов подходит к концу дисковое пространство, то под руководством мастер-сервера часть диапазонов с него перераспределяется на менее загруженные Range серверы.

• Еще одним компонентом системы является Hyperspace, этот сервер предоставляет указатель на основную таблицу с метаданными, а также пространство имен. Помимо этого этот сервис выступает в роли lock-механизма для клиентов системы.

В качестве основы для этой системы может использоваться как  входящая в состав Hadoopфайловая система HDFS, так и KosmosFS.

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

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