Нереляционные базы данных

Причины и предусловия применения не реляционных БД

Но, помимо достоинств модель имеет и некоторые недостатки, к которым можно отнести:

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

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

Типы нереляционных БД

Для решения этой проблемы стали применять хранилища типа NoSQL (Not Only SQL) или постреляционные базы данных. Этот новый термин объединяет в себе нереляционные хранилища данных, не подчиняющихся привычным правилам хранения данных (ACID). Обычно в таких системах нет жесткой структуры и не используется пересечение таблиц, по большому счету они вообще не имеют таблиц. Нереляционные базы данных разделяют на несколько типов, которые определяются зависимостью от их масштабируемости, моделями данных и запросов, а также системой хранения данных. Единую классификацию ещё не разработали. Однако различают следующие модели данных:

1. Ключ - Значение.

   В последнее время стали появляться БД нового типа, которые получили название «ключ — значение» (от англ. «key-value» database), показавшие себя хорошо в распределенных системах, имеющих большую нагрузку, в том числе в поисковых системах Интернета.

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

   Замечание 1

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

   Ключи представляют собой кэш-коды хранящихся данных (значений). Ключи объединены в группы таким образом, что все данные одной группы, которые с ними связаны, хранятся на одном сервере. Следовательно, по ключу возможно определить сервер и напрямую получить от него данные. Этим обеспечивается масштабируемость. Когда один сервер не будет справляться с нагрузкой, к нему добавят еще один и разделят данную группу ключей на 2 части.

   Базы данных типа «ключ — значение» обладают достоинствами и недостатками, которые принципиально важны при решении определенных задач.

   К достоинствам можно отнести:

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

   Недостатками являются:

   • отсутствие поддержки связи между данными, обеспечения целостности данных;
   • отсутствие стандарта языка описания и управления данными (у реляционных БД стандартом является язык SQL);
   • основной вид запросов, представляющий поиск значения по ключу, что приводит к ряду сложностей (например, выполнения сортировки данных).
   Замечание 2

   Как правило, базы данных «ключ — значение» применяют в «облачных» вычислениях: в поисковой системе Google (система хранения данных BigTable), интернет-магазине Amazon ( база данных SimpleDB), энциклопедии Википедия, социальной сети Facebook.

   Представленная модель характеризуется наиболее эффективной производительностью, минимальной стоимостью внедрения и масштабирования. Является самой простой формой, как для организации данных так и для их реализации, но одновременно и одной из самых быстрых. С помощью таких хранилищ можно сохранять в памяти по определенному ключу любые данные, представленные как простым числом или текстом, так и сериализованным объектом. Представители данной схемы - популярный в настоящее время memcached и менее популярные: CouchDB, Redis, Scalaris, BerkeleyDB , Tokyo Cabinet, Voldemort.

2. Документно-ориентированная.

   В данной модели каждая запись хранится в виде отдельного документа, имеющего собственный набор полей, отличающийся от документа к документу. Популярные представителями этой модели являются Lotus Notes, CouchDB, MongoDB.

3. Колоночно-ориентированная.

   Эта модель данные хранит в столбцах вместо привычного хранения в строках, что является выгодным для различного рода архивов информации и каталогов, в которых большая часть вычислений происходит над подобными выборками данных. Представителями данной модели являются BigTable, HyperTable и HBase, а также Cassandra.

4. Графовая.

   В данной модели для представления информации используются вершины и ребра графа. Подобная модель наиболее производительно работает с данными, которые представлены в виде графов (например социальные графы). Наиболее популярными системами хранилища данных этого типа являются neo4j, AllegroGraph, ActiveRDF.

На протяжении последних лет прослеживается тенденция перехода к построению БД на основе не реляционных моделей. Причиной тому является выявление у реляционных моделей недостатков в построении структуры БД, что делает ее более уязвимой. В связи с этим выбирают объектно-ориентированные базы данных. Причинами их выбора являются:

1. Высокая степень документной ориентированности.
2. Сильная объектная ориентированность.
3. Хранилище данных легко интегрируется с веб-сервисами вендора.
4. Главная решаемая проблема заключается в масштабируемости при поисковых запросах.