Разместить заказ
Вы будете перенаправлены на Автор24

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

8-800-775-03-30 support@author24.ru
Все предметы / Базы данных / Нереляционные базы данных

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

Определение 1

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

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

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

Готовые работы на аналогичную тему

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

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

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

Замечание 3

Из рассмотренных выше наиболее распространенной на данный момент является модель ключ = значение.

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

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