Развитие ядра субд

Современные традиционные СУБД чрезвычайно сложные программные системы. Проблема современных СУБД в их архитектуре, которая не меняется уже 30 лет, операции наподобие Join при большом объеме данных выполняются крайне неэффективно. А реализация блокировок на уровне полей съедает до 95% ресурсов сервера [28]. Недостатками существующих СУБД являются усложнение поиска данных, увеличение времени их извлечения, выполнения резервного копирования при росте объемов данных, слишком длительных сроков восстановления систем и данных в случае сбоев, чрезвычайная сложность в управлении, дороговизна, не гибкость с точки зрения оперативности адаптации.

Медлительность реляционных баз данных объясняется следующими факторами. Они обслуживают буферный пул, ведут журналы операций для нужд восстановления, а также управляют блокировками полей данных, предотвращающими их перезапись конкурирующими операциями. Все эти задачи отнимают более 90% системных ресурсов [9]. Реляционные базы данных не обладают необходимой гибкостью. Их архитектура, разработанная еще в эпоху перфокарт, реализует фиксированный подход к моделированию данных. Если организации нужно добавить новый столбец к таблице, приходится изменять схему базы, что может вызвать определенные трудности. При этом сама схема не всегда точно отражает исходную модель данных.

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

За последние 30 лет развитие СУБД происходило эволюционно в направлении расширения функциональности. Современные СУБД наделяются все более интеллектуальным функционалом, упрощающим процесс управления БД. Пользователям нужно, чтобы СУБД работала без сбоев, была эффективной и имела удобные интерфейсы, позволяла производить обмен данными на основе XML-технологий [20].

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

Требованиями к новым реализациям СУБД являются:

• способность функционировать в условиях информационной неоднородности и распределенности данных;

• интероперабельность, повторное использование данных и приложений в разнообразных применениях;

• возможность объединения БД в более сложные интегрированные образования, основанные на интероперабельном взаимодействии компонентов;

• реинженеринг, реконструкция как непрерывный процесс формирования, уточнения требований и конструирования БД;

• миграция унаследованных приложений в новые системы, соответствующие новым требованиям и технологиям.

Тенденциями развития современных универсальных коммерческих СУБД являются [1,2,8,11-15,18,24,25,26]:

• использование технологий параллельной обработки данных;

• создание программных средств для распределенной работы с данными;

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

Основные направления развития СУБД от главных разработчиков (IBM, Oracle, MS) во многом совпадают, это:

• уменьшение затрат на администрирование БД, за счет автоматизации задач администратора БД;

• снижение требований к аппаратным средствам серверов и систем хранения данных;

• использование технологии сжатия данных, в т.ч. для индексов и временных таблиц;

• упрощение конфигурирования и развертывания серверов БД;

• развитие средств обеспечения безопасности;

• реализация отказоустойчивой конфигурации;

• интеграция распределенных и неоднородных данных;

• поддержка хранения данных в формате XML (например, СУБД Oracle отображает XML-документ в реляционной структуре и хранит его в таблицах, в СУБД DB2 XML-данные никак предварительно не преобразуются и обрабатываются движком, функционирующим параллельно с реляционным);

• учет в БД полного жизненного цикла данных;

• использование СУБД для построения хранилищ данных;

• переносимость приложений из разных СУБД;

• включение в состав приложений СУБД аналитических функций.

Установка многих СУБД представляет собой не очень простую задачу, поэтому установку СУБД для промышленной эксплуатации необходимо поручать опытному администратору, иначе через какое-то время могут возникнуть проблемы с выделенной памятью, например, для хранения таблиц, обработки даны и т.п. Поэтому этот процесс должен выглядеть в стиле "plug and play" – подключай и работай. А СУБД должна самостоятельно подстраиваться под изменение внешних условий путем уточнения установочных и конфигурационных свойств СУБД, автоматического увеличения памяти, создания новых правил обеспечения целостности данных, настройка приложений на уточненные информационные потребности, распознавания внутренних неисправностей, нахождения поврежденных данных, обнаружения сбоев приложений и исправления неисправностей.

Средства диагностирования состояния технических, программных и информационных средств предназначены для выявления соответствующих проблем (получение справок о загрузке процессора, оперативной и дисковой памяти; состоянии информационных ресурсов, БД; работоспособности программных средств). При возникновении отклонений в функционировании системы, подсистема мониторинга на основе анализа состояния системы и ее элементов выявляет первоисточник проблемы, о котором сообщается ответственному администратору. Это позволяет повысить эффективность эксплуатации БД. Например, для диагностики работ аппаратно-программных средств 20 распределенных центров ЕСИМО используется IBM Tivoli мониторинг.

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

Администраторы баз данных должны тратить свое время на сложные задачи, а не на рутинные. Пользователи должны получать исчерпывающую информацию о текущем состоянии всех компонентов БД. СУБД должна выполнять действия, направленные на диагностику запуска программы, восстановление работоспособности компонент. БД и ее компоненты будут в будущем автоматическими, самонастраиваемыми, автоинсталлируемыми, автоуправляемыми, авторемонтируемыми, автопрограммируемыми, самокорректирующимися, самооптимизирующимися и самозащищаемыми. Эта идея реализована в СУБД DB2 UDB 8.2 (Stinger).

Следующая задача — это упрощение управления очень сложными системами. Чем сложнее система, тем больше необходимость в ее упрощении. При этом процесс упрощения еще более усложняет эти системы. При этом увеличивается сложность во внутреннем исполнении, а система упрощается во внешнем использовании. То есть система будет сообщать и советовать администратору, что может произойти и что надо делать.

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

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

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

Создатели многих облачных систем отвергают SQL как интерфейс, не пригодный для таких задач, и идут по одному из двух путей. В одних случаях проектировщики берут на вооружение уже существующую парадигму, зачастую копируя интерфейс Google Bigtable для СУБД или модель MapReduce для аналитических систем. В других случаях разработчики создают крайне минималистичный интерфейс, реализующий только операции создания, чтения, обновления, удаления.

В облачных СУБД в целях улучшения масштабируемости и управляемости приоритет обычно отдается каким-то простейшим наборам возможностей. Чем больше ветвлений кода содержит облачная система, тем больше вероятность появления узких мест, труднонастраиваемых конфигурационных параметров или ошибок, нарушающих работу сервиса. Облачные СУБД представляют собой гибкие, масштабируемые платформы, способные упростить создание разнообразных Web-приложений, работающих с большими объемами данных — от социальных сетей и позиционно-ориентированных сервисов до сайтов доставки новостей.

Элементы Not Only SQL (NoSQL) уже встраиваются в существующие СУБД общеизвестных поставщиков. Так, версия MySQL 5.6 предлагает принципиально новые возможности: полнотекствый поиск, ускоренную репликацию, поддержку многопоточности, автовосстановление, обработка условий WHERE непосредственно в низкоуровневом движке, интеграционный BinLog API, NoSQL/Memcached - интерфейс, позволяющий обращаться с запросами к движку InnoDB "в обход" SQL-нотации.

Разработчики веб-сервисов, ориентированных на конечного потребителя, и поставщики больших наборов данных заняты поиском возможностей распределения своих данных между множеством серверов. Управление БД посредством традиционных механизмов SQL в этом случае требует очень серьезных усилий.

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

• уровень постоянного хранения (на основе одной из существующих СУБД MySQL);

• высокопроизводительный серверный компонент (на основе web-сервера Apache);

• высокопроизводительный маршрутизатор запросов;

• надежную систему обмена сообщениями между центрами обработки данных для тиражирования (специально написанную нами);

• механизмы управления кластерными системами и их мониторинга (большей частью состоящие из специально разработанного кода);

• системы безопасности для управления сертификатами и аутентификации (специально разработанный код);

• собственную логику СУБД для выполнения операций чтения и записи (специально разработанный код).

Традиционные устройства хранения ничего не знают о размещенных в них БД, не имеют сведений, которые помогли бы определить конкретные столбцы и строки, содержавшиеся в запросе. Компания Oracle совместно с Sun Microsystems выпустила специализированную машину Exadata 2, адаптированную для работы с гибридными СУБД, способными работать и со строками, и с колонками. Компания Teradata создала аналитическое облако Enterprise Analytics Cloud и специализированную машину для работы с хранилищами данных Extreme Performance Appliance. В этих реализациях серверы хранения предоставляют данные, но сами они «ничего не знают» о серверах БД, на которых они работают. Эта технология обеспечивает десятикратное улучшение по времени отклика по сравнению с обычными дисками. Программное обеспечение Exadata совместно с Oracle Database анализирует запрашиваемые данные и знает, когда и какие данные следует кэшировать, чтобы избежать «замусоривания» памяти.

БД NoSQL не имеют строго определенных схем построения. Чтобы сформировать запрос, все значения в БД NoSQL необходимо предварительно описать. Каждое значение сопровождается именем, которое относит данные к определенному атрибуту. Таким образом, схема определяется самими данными.

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

Главными требованиями к таким СУБД являются доступность системы для пользователей; масштабируемость (гарантированное удовлетворение требований всех пользователей и клиентов, возможность быстрой установки в новых условиях эксплуатации); последовательность или целостность (если данные изменяются, то изменяются повсеместно, так что все пользователи системы в один и тот же момент времени могли видеть те же самые данные). Традиционные реляционные СУБД обеспечивают доступность и последовательность за счет масштабируемости. Новые СУБД типа NoSQL решают в первую очередь проблемы доступности и масштабируемости [3,27,29].

Элементы Not Only SQL (NoSQL) уже встраиваются в существующие СУБД общеизвестных поставщиков. Так, версия MySQL 5.6 предлагает принципиально новые возможности: полнотекствый поиск, ускоренную репликацию, поддержку многопоточности, автовосстановление, обработка условий WHERE непосредственно в низкоуровневом движке, интеграционный BinLog API, NoSQL/Memcached - интерфейс, позволяющий обращаться с запросами к движку InnoDB "в обход" SQL-нотации.

Разработчики веб-сервисов, ориентированных на конечного потребителя, и поставщики больших наборов данных заняты поиском возможностей распределения своих данных между множеством серверов. Управление БД посредством традиционных механизмов SQL в этом случае требует очень серьезных усилий.

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

• уровень постоянного хранения на основе одной из существующих СУБД MySQL;

• высокопроизводительный серверный компонент, на основе web-сервера Apache;

• высокопроизводительный маршрутизатор запросов;

• надежную систему обмена сообщениями между центрами обработки данных для тиражирования;

• механизмы управления кластерными системами и их мониторинга;

• системы безопасности для управления сертификатами и аутентификации;

• собственную логику СУБД для выполнения операций чтения и записи.

Традиционные устройства хранения ничего не знают о размещенных в них БД, не имеют сведений, которые помогли бы определить конкретные столбцы и строки, содержавшиеся в запросе. Компания Oracle совместно с Sun Microsystems выпустила специализированную машину Exadata 2, адаптированную для работы с гибридными СУБД, способными работать и со строками, и с колонками.

Компания Teradata создала аналитическое облако Enterprise Analytics Cloud и специализированную машину для работы с хранилищами данных Extreme Performance Appliance. В этих реализациях серверы хранения предоставляют данные, но сами они «ничего не знают» о серверах БД, на которых они работают. Эта технология обеспечивает десятикратное улучшение по времени отклика по сравнению с обычными дисками. Программное обеспечение Exadata совместно с Oracle Database анализирует запрашиваемые данные и знает, когда и какие данные следует кэшировать, чтобы избежать «замусоривания» памяти.

Аналитическая СУБД Aster компании Teradata подобно системам Oracle Exadata, EMC Greenplum и SAP HANA предлагается как программный продукт для локальной инсталляции и облачного развертывания. СУБД основана на той же аппаратной платформе, что и хранилища данных Teradata. В СУБД Aster реализован фреймворк распределенной обработки данных MapReduce, позволяющей вызывать функции системы при помощи стандартных SQL-запросов. Добавлены также механизмы анализа поведения пользователей на сайтах, результативности маркетинговых кампаний и дерева принятия решений, а также другие аналитические функции. Остальные усовершенствования касаются управления рабочими нагрузками и скорости исполнения SQL-запросов.

Создаются NoSQL СУБД Apache Hadoop, Cassandra, Amazon SimpleDB и Microsoft Windows Azure Table Services, Oracle NoSQL Database, предназначенные для преодоления ограниченности реляционной модели.

В СУБД Sherpa [22] имеется схема секционирования данных, инфраструктура маршрутизации запросов, механизм тиражирования и т.д. с расчетом на упорядоченные данные. Для выполнения запроса необходимо проверить права клиента и затем переадресовать запрос модулю хранения, содержащему нужный блок данных. Контроллер табличных фрагментов управляет конфигурацией кластера Sherpa. В Sherpa спроектирован простой интерфейс наподобие REST (Representational State Transfer, протокол для Web-сервисов, основанный на HTTP), реализующий всего несколько операций. В Sherpa нет сложных транзакций, сложных запросов (например, на соединение таблиц и агрегацию) и целого ряда других «стандартных» возможностей СУБД.

СУБД Drizzle создана в 2008 г., является ответвлением СУБД MySQL. Эта СУБД предназначена для облачных сервисов и веб-приложений. Чтобы повысить быстродействие СУБД, авторы удалили из кода все функции, не требуемые для этих задач, преобразовали архитектуру системы в микроядро и переписали код на C++.

СУБД Greenplum Database отличает возможность масштабирования до петабайтных значений с линейным ростом затрат, распараллеливание запросов, ускоряющее скорость работы на один-два порядка. С технологической точки зрения эту СУБД отличает использование программы MapReduce, разработанной в Google, которая обеспечивает не только высокую производительность за счет применения большого числа процессоров, а в перспективе и ядер, но и высокую надежность, а также технологии компрессии, от 3 до 10 раз сокращающей объемы передаваемых и хранимых данных. СУБД Greenplum Database имеет встроенные возможности для аналитики и статистической обработки средствами специализированного языка программирования R.

В нереляционной СУБД с открытым кодом MongoDB (компании 10gen) в случае сбоя сервер СУБД восстановится до последнего рабочего состояния. Также реализована возможность добавления новых данных к имеющемуся набору, полученному в результате фильтрации с помощью программы MapReduce. Кроме того, усовершенствована функция тиражирования и механизм секционирования данных. СУБД MangoDB представляет собой документно-ориентированную СУБД, хранящую информацию в последовательном формате, подобном JSON. Базы MongoDB лишены табличных структур и схем и позволяют вносить новые атрибуты по мере необходимости. Запросы выполняются с помощью синтаксиса, напоминающего JavaScript. СУБД MongoDB способна извлекать информацию быстрее, чем реляционные СУБД, особенно при запросах на получение несложных наборов данных.

Отличие архитектуры СУБД Компании Greenplum в том, что каждый отдельный компонент СУБД играет роль законченной мини-СУБД, которая сама владеет и оперирует отдельной порцией доверенных ей данных [21]. Эта СУБД автоматически распределяет данные и нагрузку по обработке запросов с помощью программы MapReduce. Продукты Greenplum ориентированы на системы с массовым параллелизмом, в них используется элементы модернизированной версии PostgreSQL. СУБД Greenplum является реализацией конструкции MapReduce, обеспечивающей работу с большими документами в разных форматах, и классической СУБД, ориентированной на работу с реляционными таблицами. Такого рода универсальность достигается за счет машины для работы с параллельными потоками данных – СУБД может не только независимо работать с каждым из двух источников, но и совмещать работу с двумя одновременно. В частности, средствами MapReduce можно оптимизировать доступ к большим СУБД, либо обеспечить выполнение SQL-запросов к таблицам и к файлам. Ядро Greenplum Database – Parallel Dataflow Engine для обработки параллельных потоков данных задумана так, что в перспективе может поддерживать процессоры, состоящие из многих тысяч ядер и при этом поддерживать SQL в характерной для нее параллельной манере.

Компания Couchbase выпустила бета-версию нереляционной СУБД Mobile Couchbase для ОС iOS, используемой в iPhone. Разработчики могут встраивать СУБД в приложения для iPhone и iPad. Mobile Couchbase создана на основе нереляционной СУБД Apache CouchDB. СУБД Mobile Couchbase отличают возможности синхронизации: при минимальном написании кода можно реализовать автоматическую синхронизацию данных по сети с экземпляром CouchDB, работающим в облаке или в ЦОД. СУБД экономно расходует оперативную память и требует относительно немного пространства хранения: приложение с внедренной БД можно легко уместить в 20 Мбайт. Протоколы передачи сообщений, используемые в СУБД, не слишком трафикоемки.

Компания Oracle выпустила NoSQL Database. Эта СУБД предназначена для комплекса Oracle Big Data Appliance. Основой Oracle NoSQL Database является Java-версия СУБД с открытым кодом Berkeley DB, широко применяемая во встроенных системах. В новой СУБД используется простая модель «ключ-значение», то есть нужный элемент данных можно получить по его числовому ключу-идентификатору. Система позволяет делать структурированные запросы, но не требует фиксированной схемы данных. Фирма Oracle построила кластер NoSQL Database из 300 узлов.

Стоунбрейкер предложил воплощенную в VoltDB концепцию NewSQL - новое поколение СУБД, которые выполнены в архитектуре NoSQL, но поддерживают SQL и реализуют атомарность, согласованность, изолированность, долговечность.

MarkLogic Server – это СУБД для работы с неструктурированной информацией, метаданными, включает развитый поисковый механизм.

Создаются также графо-ориентированные СУБД для поддержки масштабных социальных сетей (InfiniteGraph - Java-СУБД; FlockDB от создателей Twitter).

СУБД HBase V0.19.3 (Apache Software Foundation) и Bigtable (Google) предлагают новый способ последовательной обработки данных. На смену SQL- подобным процессам извлечения и преобразования данных в монолитных системах приходит подход, в котором БД поддерживают операции создания, чтения, изменения, удаления, а сложные преобразования передаются внешним компонентам, рассчитанным на параллельные вычисления. Параллельные вычисления можно выполнять, например, при помощи приложений MapReduce, а высокая пропускная способность достигается при помощи распределенной и реплицируемой файловой системы, такой как Hadoop Distributed File System (HDFS) или Google File System. В СУБД HBase для хранения связанной информации в одной таблице часто используется денормализация. СУБД HBase представляет собой масштабируемую, распределенную, построенную на основе столбцов БД с динамической схемой для структурированных данных. Она обеспечивает надежное и эффективное управление большими объемами информации (несколько петабайт и более), распределенных среди тысяч серверов. Данные СУБД HBase представляют собой многомерный массив, значения которого (ячейки таблицы) обозначаются четырьмя ключами:

value = Map(TableName, RowKey, ColumnKey, Timestamp)

где:

• TableName – строка;

• RowKey (Ключ строки) и ColumnKey – двоичные значения (тип byte[]);

• Timestamp (Метка времени) – 64-разрядное число (тип long);

• value (значение) – необрабатываемый массив байтов (тип byte[]).

СУБД HBase является распределенным хранилищем данных с колоночной организацией информации. Модель данных СУБД HBase во многом копирует модель данных Bigtable. Ключ строки является первичным ключом таблицы и обычно представляет собой строковые данные. Строки сортируются по ключам строки в лексикографическом порядке. Информация, хранящаяся в таблице, структурирована в наборы столбцов, которые можно считать категориями. Каждое семейство столбцов может содержать произвольное количество элементов, обозначаемых метками (или квалификаторами). Ключ столбца column состоит из названия набора, двоеточия (:) и метки. Например, для элементаdate и набора info ключ столбца имеет значение info:date. Некоторые наборы столбцов определены в схеме таблицы HBase, но приложения могут на лету создавать новые элементы, добавляя строки в таблицу. В наборе столбцов разные строки таблицы могут иметь разное количество элементов. СУБД HBase поддерживает модель динамической схемы.

Индексируется по строке, ключу колонки и временной метке. Ключи являются произвольными строками в СУБД HBase. Каждая операция чтения или записи над строкой является атомарной вне зависимости от количества затронутых колонок.

В таблице 1 приведен простой пример таблицы HBase Persons с двумя наборами столбцов name и contact [21].

Таблица 1 - Таблица Persons с двумя наборами столбцов

Ключ строки	Метка времени	Набор столбцов
		name	contact
000001	t3		contact:http research.google.com/people/jeff/
	t2	name:first Jeffrey
	t1	name:last Dean
000002	t5	name:first Gabriel
	t4	name:last Mateescu

Пустые ячейки не имеют значений, связанных с ключами этих ячеек. СУБД HBase не хранит пустые ячейки: чтение пустых ячеек подобно извлечению из массива значения при помощи несуществующего ключа. Для каждой строки одновременно можно получить доступ только к одному элементу группы столбцов (в отличие от реляционных БД, где при помощи одного запроса можно получить доступ к ячейкам строки из многих столбцов). Под строками подразумеваются произвольные наборы байт, т.к. СУБД HBase не интерпретирует данные. Элементы группы столбцов отображаются в строке как подстроки. Таблицы разделены на регионы, соответствующие таблетам Bigtable. Регион содержит строки определенного диапазона. Разделение таблиц на регионы является ключевым механизмом для эффективного обслуживания больших таблиц. Диапазон строк таблицы динамически разбивается на набор регионов. Регион HR отвечает подмножеству строк в таблице [startkey(HR), endkey(HR).

Ключ колонки выглядит следующим образом: key = family_id:column_qualifier, он включает в себя идентификатор семейства колонок family_id и идентификатор колонки внутри семейства column_qualifier. Семейство колонок описывается во время создания или изменения таблицы, тогда как квалификатор колонки внутри семейства может быть произвольным набором байт, таким образом, разные строки могут обладать разным набором колонок. Данные хранятся в файловой системе по семействам колонок. При описании колонки для неё доступно множество опций, таких как максимальное количество версий, есть ли необходимость хранить семейство колонок всегда в оперативной памяти или оно может быть записано на диск, а также необходимо ли сжатие при записи на диск.

Версии объекта доступны по временной метке. При записи объекта в хранилище данных приложение может указать его временную метку. Приложения, которым необходимо избежать коллизий, должны самостоятельно генерировать уникальные временные метки. Версии объектов в СУБД HBase представляются объектами класса KeyValue. KeyValue является неизменяемым объектом (immutable). KeyValue содержит ссылку на массив из байтов, сдвиг в этом массиве, начиная с которого начинаются байты, принадлежащие KeyValue, и длину, которую KeyValue занимает в массиве.

СУБД Cassandra (Apache Software Foundation, http://cassandra.apache.org/download/) - это высоко-масштабируемое, автоматически восстанавливающее согласованность данных, распределенное, основанное тоже на колончатой модели данных ключ-значение хранилище. Основными единицами модели данных для этой СУБД являются:

• Column (колонка) - это наименьшая единица данных - кортеж, который содержит название, значение и временная метка, все значения устанавливаются клиентом, включая timestamp;

• Column Family (семейство колонок) - это контейнер для колонок, аналог таблицы из реляционных систем, в семействе колонок устанавливается механизм сортировки;

• Row (ряд) - это ключ и связанные с ним наборы колонок, каждое семейство колонок сохраняется в отдельном файле, и этот файл отсортирован в row порядке; связанные колонки это те, к которым обращаются вместе (они хранятся в одном семействе колонок);

• Keyspace (пространcтво ключей) - это первое измерение, оно содержит семейство колонок; пространство ключей это тоже самое, что и схема в реляционной СУБД;

• Super Column (супер колонка) - это колонка контейнер, которая содержит другие колонки.

СУБД Cassandra позволяет размещать в каждой строке до 2 млрд. столбцов. Размеры строк имеют предельный размер около 2 Гбайт. СУБД поддерживает вторичные индексы, что обеспечивает несложный механизм опроса данных, и возможность изменять схему БД, не перезапуская весь кластер. Можно произвести компрессию данных в фоновом режиме, имеются методы оптимизации использования рабочей памяти серверов. СУБД подходит для сред, работающих на нескольких узлах.

БД NoSQL будут говорить на одном языке. Стремясь объединить растущий, но разобщенный рынок СУБД категории NoSQL, создатели СУБД CouchDB и SQLite представили новый язык запросов формата UnQL (Unstructured data Query Language). Он во многом совместим с классическим SQL, предназначен для использования в веб-сервисах, как единый механизм доступа к SQL и NoSQL-базам данных. UnQL использует формат JSON.

Развитие UnQL создало условия для унификации NoSQL. Язык UnQL можно рассматривать в качестве «надмножества» SQL. В этом случае будет реализован анализ всех операторов языка SQL и обеспечена поддержка ряда новых операторов и выражений. Если язык UnQL получит признание достаточно большого числа разработчиков, он может сыграть для рынка NoSQL примерно ту же роль, какую четыре десятилетия назад сыграл для рынка реляционных БД язык SQL, то есть стать общим интерфейсом, который объединит фрагментированный рынок СУБД нового поколения [9].

Язык UnQL создавался для того, чтобы обеспечить единый интерфейс для широкого диапазона архитектур БД, имеющих природу как SQL, так и NoSQL. Язык UnQL, как и SQL, построен на основе реляционной алгебры. Это гарантирует получение предсказуемых и повторяемых результатов.

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

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