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

Определения и обозначения

Нереляционная база данных (NoSQL) — база, в которой данные не обязательно организованы в связанные таблицы. В отличие от реляционной модели, она может использовать документы, пары «ключ—значение» или графы. Название не означает полного отсутствия связей: способы представления отношений зависят от выбранной модели. Поэтому NoSQL — общее название для разных подходов к хранению данных.

База данных «ключ—значение» хранит записи как пары: ключ однозначно указывает на соответствующее значение. Например, ключом может быть идентификатор пользователя, а значением — его настройки. Чтобы получить запись, системе достаточно обратиться по ключу. Такая модель полезна, когда заранее известно, по какому идентификатору ищут данные.

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

Графовая база данных представляет объекты вершинами, а связи между объектами — рёбрами. Например, вершинами могут быть люди, а ребро между ними означает дружбу. Такая модель помогает не только хранить объекты, но и отвечать на вопросы о связях: кто знаком с кем и как пройти от одного человека к другому.

Как это устроено

В реляционной базе столбцы таблицы обычно задают заранее, поэтому новые записи должны соответствовать общей схеме. Нереляционная база может разрешать документам одного типа иметь разный набор полей. Это удобно, если данные меняются или объекты изначально описываются неодинаково: не приходится заполнять отсутствующие характеристики пустыми значениями. Однако гибкость не отменяет правил — приложение всё равно должно понимать, как читать поля и значения.

Модель хранения определяет, каким способом система находит нужную запись. В базе «ключ—значение» запрос содержит ключ, поэтому получение значения похоже на поиск по адресу. В документной базе можно выбирать документы по одному или нескольким полям, например искать товары заданного цвета. В графовой базе запрос проходит по связям от вершины к вершине, что удобно для поиска соседей и цепочек отношений.

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

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

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

Основные модели нереляционных баз данных

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

Разбор задач

Для хранения настроек пользователей нужно подобрать модель: каждой настройке соответствует идентификатор пользователя и значение. Важно понять, как приложение будет получать запись: если оно заранее знает идентификатор и хочет быстро найти связанные с ним данные, сложные связи и выборки по множеству полей не нужны. Поэтому достаточно сопоставить ключ с сохранённым значением.

1. Определяем, что идентификатор пользователя позволяет однозначно обратиться к записи.
2. Рассматриваем пару: ключ — идентификатор, значение — настройка или набор настроек.
3. Сопоставляем это устройство с моделью, которая хранит пары и находит значение по ключу.

Ответ: подходит модель «ключ—значение». Если для одного пользователя нужно хранить несколько настроек, их можно объединить в значении или использовать отдельные ключи; конкретный вариант зависит от того, как приложение запрашивает настройки.

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

1. Отмечаем, что товары не имеют общего неизменного набора характеристик.
2. Представляем каждый товар отдельным документом с названием, категорией и подходящими ей свойствами.
3. Для поиска указываем поле и требуемое значение, например категорию или материал.

Ответ: используем документную базу данных и выполняем выборку по полям. Перед проектированием нужно определить, какие поля будут частыми условиями поиска, чтобы база могла эффективно выполнять такие запросы.

Нужно хранить пользователей, их дружеские связи и находить кратчайшую цепочку знакомств между двумя людьми. Здесь главное — не только сведения о каждом пользователе, но и отношения между пользователями. В графовой модели путь от одного человека к другому можно искать, переходя по рёбрам. В таблицах такую сеть тоже можно представить, но для обхода цепочек может потребоваться многократно соединять данные о связях.

1. Представляем каждого пользователя отдельной вершиной.
2. Каждую дружескую связь записываем как ребро между соответствующими вершинами.
3. Ищем путь между вершинами двух пользователей и среди путей выбираем путь с наименьшим числом рёбер.

Ответ: подходит графовая модель. Она делает отношения частью структуры данных и упрощает запросы о цепочках знакомств, особенно если таких запросов много.

Типичные ошибки

Ошибка — считать, что NoSQL означает «данные без структуры». Так можно подумать из-за того, что для некоторых баз не требуется заранее описывать единый набор столбцов. Но данные всё равно организованы по правилам модели: как пары, документы или вершины со связями. Проверь себя: можешь ли ты объяснить, как устроена запись и по чему её находят? Если да, структура есть.

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

Ошибка — считать любую нереляционную базу более быстрой или лучшей. Такое впечатление появляется из-за примеров, где NoSQL хорошо справляется с конкретной нагрузкой. Но скорость зависит от операций: решение, удобное для поиска по ключу, может быть неудобно для других запросов. Проверяй выбор по типичным запросам и требованиям системы, а не по названию технологии.

Ошибка — описывать графовые связи только парами «ключ—значение». Это может казаться простым способом сохранить данные, однако пары сами по себе не показывают удобную сеть отношений и затрудняют поиск цепочек. Сверь модель с задачей: если нужно многократно переходить от объекта к связанным объектам, граф обычно выразительнее. Для отдельного быстрого доступа по ключу, напротив, пары подходят хорошо.

Связь с другими темами

Для понимания NoSQL полезно знать реляционную модель: таблицы, строки, столбцы и назначение ключей. Эти знания помогают сравнить, как разные базы организуют записи и находят их. Ключ в нереляционной модели тоже помогает обратиться к данным, но его роль зависит от устройства базы.

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

Что запомнить

• Нереляционная база данных хранит данные не обязательно в виде связанных таблиц.
• NoSQL — общее название для разных моделей хранения, а не одной конкретной технологии.
• В модели «ключ—значение» доступ к значению выполняется по ключу.
• Документная база хранит записи в виде документов с полями и значениями.
• Графовая база представляет объекты вершинами, а отношения между ними — связями.
• Модель базы данных выбирают под структуру данных и типичные запросы.
• Нереляционные базы данных не являются безусловной заменой реляционным.