§22

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

Проблемы реляционных БД

Несмотря на то что реляционные (табличные) БД хорошо себя зарекомендовали и составляют подавляющее большинство реаль​но используемых баз данных, они не универсальны и в некоторых задачах их применение приводит к серьёзным проблемам.

Во-первых, для того чтобы построить надёжно работающую реляционную БД, необходимо представить исходные данные как набор взаимосвязанных таблиц. Это требует серьёзных усилий, кроме того, данные становятся менее понятными для человека, потому что он мыслит не таблицами, а объектами, которые имеют определённый набор свойств.

Во-вторых, данные, связанные с одним объектом, разбросаны по разным таблицам, поэтому при поиске их приходится «вытас​кивать» с помощью сложных запросов, которые выполняются сравнительно медленно при больших объёмах данных.

В-третьих, во всех реляционных базах данных структура дан​ных чётко определена, причем она задаётся разработчиком при со​здании базы, и изменить её весьма непросто. Теперь представим себе, что нам нужно хранить документы, которые могут иметь раз​ное количество свойств с разными названиями и типами данных, причём эти свойства заранее не определены и могут меняться со временем. В этом случае использовать реляционные БД, по край​ней мере, очень сложно, поскольку они для этой цели не предна​значены.

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

Базы данных «ключ — значение»

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

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

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

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

Многие базы типа «ключ — значение» хранят документы — объекты, которые имеют произвольный набор полей-свойств, на​пример:

{

    ключ: 1231239786234762394769237

    автор: "А.С. Пушкин"

    название: "Евгений Онегин"

}

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

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

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

В то же время у них есть и недостатки:

• СУБД не поддерживают связи между данными, не обеспечивает целостность данных;
• нет стандарта на язык описания и управления данными (для реляционных БД таким стандартом стал язык SQL);
• основной вид запросов — поиск значения по ключу, поэто​му очень сложно, например, выполнить сортировку данных.​

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

Кроме того, есть бесплатные СУБД этого класса, например MongoDB (www.mongodb.org) или  CouchDB (couchdb.apache, org).

Вопросы и задания

1.​ Назовите недостатки реляционных БД. В каких задачах они проявляются?

2.​ Что такое распределённые базы данных?

3.​ Что такое масштабируемость? Почему реляционные БД плохо масштабируются?

4.​ Как вы понимаете выражение «ключ — значение»?

5.​ Как обеспечиваются связи между объектами в таких БД? Как обеспечивается целостность данных?

6.​ Вспомните, что такое хэширование и хэш-коды. Как можно выпол​нить масштабирование на основе хэш-кодов?

7. Что такое документоориентированные базы данных?

8. Назовите достоинства и недостатки баз данных типа «ключ — значение». В каких задачах их имеет смысл использовать?

9. Что вы думаете о дальнейшей судьбе реляционных БД в связи с появлением новых принципов хранения данных? Проведите исследование.

Подготовьте сообщение

«Нереляционные базы данных: за и против»

Задача

*Попробуйте поработать с какой-нибудь документоориентированной СУБД.