Документные, ключ-значение и графовые базы: когда и когда не стоит

NoSQL — базы не на таблицах: документные (MongoDB), ключ-значение (Redis) и графовые (Neo4j). У каждой своя задача, а по умолчанию хватает реляционной.

Таблицы не единственный способ

До сих пор мы хранили данные в таблицах. Это самый распространённый способ, но не единственный. Примерно с 2009 года вошло в обиход слово NoSQL. Его чаще читают как «не только SQL»: базы, в которых данные устроены иначе, чем в таблицах. Они появились не из-за моды, а из-за конкретных задач. Крупные сайты упирались в то, что одна реляционная база не успевала записывать, а данные у разных страниц были разной формы. Тогда пошли пробовать другие формы.

Началась пора увлечения: «таблицы устарели, всё в MongoDB». Через несколько лет волна схлынула. Реляционные базы научились хранить JSON и масштабироваться, а многие новые базы, наоборот, добавили SQL и транзакции. Разумный вывод: у каждой формы данных есть задача, где она лучше всех, и почти всегда этих задач меньше, чем кажется.

Посмотрите на одни и те же данные из вашего брифа в четырёх формах и задайте им разные вопросы. Для каждого вопроса схема оценивает, как удобно его решает выбранная форма.

ТаблицыДокументКлюч — значениеГраф

id	title	category_id
1	Первая услуга	1
2	Вторая услуга	1
3	Третья услуга	2

Одна таблица на вид «вещей», связи через ключи (category_id).

Вопрос к данным: Все услуги одной категорииКто связан с кем через общие услуги, и через два, три шагаНайти сессию вошедшего посетителя по токену из cookieСчётчик посетителей за сегодня: +1 при каждом заходеКаждая услуга со своим набором полей, читается целиком одним кускомЗаявки со ссылкой на услугу и контактами, плюс отчёт за месяц

Таблицы: Естественно. Это WHERE category_id = … Для такого вопроса таблицы и созданы.

Форма	Оценка
Таблицы	Естественно
Документ	Можно
Ключ — значение	Неудобно
Граф	Можно

Текстовая альтернатива: для каждого из шести вопросов (отбор по категории, связи через несколько шагов, сессия по токену, счётчик, документ с произвольными полями, заявки с отчётом) схема называет, какая форма хранения подходит естественно, какая терпимо, а какая неудобно. Оценки это суждение автора урока, а не замер.

Документные базы

Документная база (MongoDB, CouchDB, Firestore) хранит документы: обычно это JSON-объекты с вложенностью, у каждого свой набор полей. Услуга может быть одним документом, в который сразу вложены подтверждения и ведущие.

Это хорошо, когда:

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

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

Важная оговорка: PostgreSQL умеет документы. Тип jsonb хранит JSON в столбце, по нему можно искать и строить индексы. Поэтому часто достаточно таблицы с одним столбцом JSON для «кусков с любыми полями», а отдельная база не нужна.

Ключ-значение

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

Для чего его берут:

• сессии: ключ это токен из cookie, значение это сведения о человеке, а запись сама исчезает через полчаса;
• кэш: готовая страница или результат тяжёлого запроса;
• счётчики и лимиты: «не больше пяти попыток входа в минуту с этого адреса»;
• очереди коротких задач.

Цена: по значению искать нельзя (только по ключу), связей нет, а данные в памяти при сбое могут пропасть (это настраивается, но тогда теряется скорость). Поэтому Redis чаще всего помощник к основной базе, а не её замена.

Графовые базы

Когда в данных главное связи, подходит граф: вершины (люди, услуги) и рёбра между ними (ведёт, знает, купил). Самая известная графовая база это Neo4j. Запрос читается как путь: «найди людей, которые ведут услуги, которые ведут мои знакомые».

Это сила при задачах вроде «друзья друзей друзей», рекомендаций («те, кто купил это, купили и…»), поиска мошеннических цепочек, маршрутов. Но у обычного сайта связи на один шаг: услуга относится к категории, заявка к услуге. Их решает обычный JOIN, и графовая база здесь не нужна. Знать о ней стоит, чтобы узнать «свою» задачу, если она когда-нибудь появится.

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

Как выбирать

Вопросы, которые стоит задать до выбора.

1. Какие вопросы будут задавать данным? Найти по ключу, пройтись по связям, собрать отчёт, показать целиком? Форма хранения должна следовать из вопросов, а не из названия модной базы.
2. Нужны ли транзакции и целостность? Для заявок, заказов и денег нужны. Для счётчика посетителей нет.
3. Сколько данных и нагрузки? На сайте-визитке с сотней заявок в год эти вопросы вообще не стоят.
4. Кто всё это будет обслуживать? Каждая новая база это ещё один сервер: запустить, обновить, защитить, копировать, наблюдать. Это и есть настоящая цена.

Из этого получается рабочее правило: по умолчанию берите одну реляционную базу (PostgreSQL, а для самого маленького проекта SQLite) и добавляйте другую, когда измерили, что без неё не обойтись. Инженер Дэн Маккинли назвал это «выбирать скучные технологии»: у каждой команды есть всего несколько «токенов новизны», и тратить один из них на экзотическое хранилище разумно, только если именно в нём ваше отличие от других. Для сайта это почти никогда не так.

Проверьте себя: для заявок с контактами и отчётом за месяц вы бы выбрали документную базу?

Нет. Заявка ссылается на услугу, отчёт это группировка по датам и услугам, а ещё нужны транзакции. Всё это сильная сторона реляционной базы. Документная заставила бы дублировать услугу в каждой заявке.

Где лежат данные и кто может их читать

У каждой нереляционной базы свои настройки доступа, и это место, где ошибаются чаще всего. Годами в интернете находили тысячи экземпляров MongoDB и Redis, открытых без пароля прямо наружу, потому что при установке для удобства разработки доступ не закрыли. Данные из них копировали, а иногда стирали и требовали выкуп. Правило простое: база не должна быть видна из интернета (порт закрыт файрволом, слушает только свой сервер), у неё есть пароль, а в брифе для каждой функции записано, кто читает данные и где они лежат. Про последнее (в какой стране) будет урок 7: для персональных данных это не прихоть, а закон.

Практика

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

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

Что было не так с 2010 годом

В начале десятых «NoSQL» стало знаменем: многие стартапы брали MongoDB для всего подряд, потому что она не требовала описывать схему и обещала бесконечный рост. Рост приходил не у всех, а вот цена («схема» в голове у кода, дублирующиеся данные, отчёты вручную) приходила ко всем. К середине десятилетия многие вернулись к реляционным базам и принесли с собой урок: выбирают по задаче, а не по моде.