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

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

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

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

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

Срочно нужна работа?
Мы готовы помочь!

Найти эксперта

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

Для решения этой проблемы стали применять хранилища типа 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. Главная решаемая проблема заключается в масштабируемости при поисковых запросах.

Срочно нужна работа?
Мы готовы помочь!

Найти эксперта