Ivan Grishaev's blog

Совет дня №20

Sat, 31 Jan 2026 00:00:00 +0000

В прошлый раз мы говорили вот о чем. Когда мы изучаем план запроса, то смотрим, было ли попадание в индекс. Однако бывает подвох: индекс был, да не тот.

Скажем, есть запрос: показать топ-100 активных заказов по убыванию даты. Пожалуйста:

select * from orders
where status = 'active'
order by created_at desc
limit 100

Для поля status создан индекс idx_orders_status, для created_at — idx_orders_created_at (по убыванию).

Смотрим EXPLAIN, а там примерно такое:

limit: 100
  filter scan condition: status = 'active'
    index scan idx_orders_created_at: desc

Разработчик смотрит: index scan был? Был. Вот и ладушки.

На самом деле произошло вот что. Вместо того, чтобы взять только активные заказы и отсортировать их, Postgres сделал обратное. Он пошел по всей таблице (full scan), просто не в случайном порядке (как записи лежат на диске), а согласно индексу. При этом записи были отобраны вручную: для каждой из них выполнялась проверка status = ‘active’. Фактически это был full scan, только в другом порядке.

В идеале нам нужен другой план:

limit: 100
  in-memory sort, key: created_at (desc)
    index scan idx_orders_status condition: status = 'active'

Этот план читают так. Сначала Postgres выбирает активные заказы по индексу. Ожидается, что в таблице много завершенных заказов, поэтому у активных будет высокая селективность. Далее эти заказы сортируются в памяти по created_at (уже без всякого индекса) и берутся первые сто.

Почему был первый план, а не второй? Во-первых, индекса на status может не быть. Если он есть, у значения active низкая селективность: доля активных заказов высокая. Может быть, настало время обновить статистику командой analyze, и значение active уйдет из массива частых значений, которые нельзя брать в индекс. Наконец, можно признать, что тут ничего не поделаешь и мы согласы жить с первым планом, а не вторым. Возможны и другие варианты, их смотрят по ситуации.

Общий принцип такой. Часто фильтры и сортировка тянут одеяло на себя. Postgres должен решить, что выгоднее: отсортировать по индексу и пройтись вручную или наоборот: сначала отсечь по индексу и отсортировать в памяти. Второй вариант предпочтительней: когда выборка мала, любая операция над ней дешева: сортировка, группировка и так далее. Стремитесь к тому, чтобы WHERE отсекал как можно больше записей, и только потом вступали в действие другие операции.

Совет дня №19

Sat, 31 Jan 2026 00:00:00 +0000

Чтобы узнать план запроса, предварите его командой EXPLAIN:

explain select * from applications;

Seq Scan on applications
  (cost=0.00..359524.33 rows=965633 width=1745)

Эта команда НЕ выполнит запрос, а только вернет его план и приблизительные оценки.

План представляет дерево узлов; вложенность определяется пробелами слева. План читают от вложенных узлов к корню. Графические программы вроде PGAdmin показывают его в виде графа. У каждого узла как минимум три характеристики: стоимость (cost), число записей (rows) и средняя длина строки (width).

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

Число записей (rows) – ожидаемое число записей, которые произведет узел. Для них рассчитана средняя длина в байтах. Эти числа берутся из статистики и могут быть неточны.

Стоимость выражается двумя цифрами: X..Y. Первая цифра – столько усилий уйдет на то, чтобы произвести первую запись. Вторая – последнюю, то есть все остальное.

Зачем две цифры? Дело в том, что даже когда запрос производит много записей, важно знать, сколько усилий требует предварительная работа. Например, у обхода большой таблицы первый кост маленький, а второй – большой. Это нормально, потому что записи передаются следующему узлу без задержки. Если же добавить группировку, то следующий узел не получит данные, пока не выполнится группировка. Из-за этого первый кост будет большим. В идеале нужно держать его маленьким, чтобы клиент сразу начал получать строки.

У команды explain много параметров, чтобы собрать дополнительные метрики узлов. Например, время в секундах, число прочитанных страниц, попадание в буферный кэш. Самый важный параметр называется ANALYZE. С ним запрос будет выполнен, и метрики будут реальными, а не оценочными.

Модуль auto_explain автоматически логирует план запросов, которые выполнялись дольше порога, например одной секунды. Иногда его включают на проде.

Читать план тяжело, этот навык приходит с годами. Вы должны точно понимать, какую информацию ищете и почему ее там нет. В простом случае вас интересует, использовался ли индекс. Вы запускаете explain analyze и смотрите, был ли узел с типом “index scan”.

Узел “index only scan” означает, что данные получены из индекса без обращения к таблице. Это самый жир, лучше которого ничего не бывает. Узел “bitmap index scan” означает построение битовой карты, где каждый бит — номер блока. Такой обход используется для совмещения нескольких индексов, и он тоже хорош.

Узел “full seq scan” означает полный обход таблицы. Это нормально, если таблица мала или нужна ее большая часть. Если вы рассчитывали на индекс, это повод пересмотреть его.

Совет дня №18

Sat, 31 Jan 2026 00:00:00 +0000

Когда Postgres выполняет запрос, он строит план. Это сложная задача: сперва нужно распрасить запрос, построить дерево, проверить синтаксис. Затем строится логический план: здесь некоторые шаги разбиваются на подшаги, а другие, наоборот, группируются в один. На последнем этапе выводится физический план: в какую таблицу пойти, брать индекс или нет, в каком порядке выполнить джоины.

Парсинг запроса протекает достаточно быстро, потому что это чистая функция. Физический план, наоборот, дорогой. Вспомним: для того, чтобы определить, использовать индекс или нет, Postgres должен проверить, сколько в среднем строк в таблице; если она маленькая, проще сделать full scan. Далее нужно проверить, не является ли значение частым (с низкой селективностью). При анализе джоинов число комбинаций растет факториалом, поэтому Postgres применяет разные эвристики.

Подготовленное выражение – это запрос, который прошел этапы выше, и для него построен план. Далее его можно выполнить с разными параметрами, и (в идеале) план будет переиспользоваться. В идеале – потому что даже когда подготовленное выражение готово, оно не гарантирует применения плана. Если параметров нет, Postgres использует план. Если выражение вызывается с разными параметрами, Postgres ведет хеш-таблицу: параметры -> план -> время. Для одинаковых параметров план будет один и тот же. Накопив пять вызовов с разными параметрами, Postgres наконец-то определится с планом (с минимальным временем), и далее он используется всегда.

Некоторые клиенты к Postgres ведут свой кэш вида SQL -> preparedStatement. Каждый раз когда выполняется запрос, клиент ищет айди подготовленного выражения во внутреннем кэше. Если он есть, вызывается команда “выполни выражение foobar с такими-то параметрами” (аналог execute). Если Postgres ругнулся, что такого выражения нет, эта ошибка перехватывается, и посылается команда “тогда подготовь этот SQL и назначь ему имя foobar”. Далее все повторяется.

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

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

Совет дня №17

Sat, 31 Jan 2026 00:00:00 +0000

Наверное, вы много слышали про UUID версии 7. Дело в том, что недавно его утвердили окончательно, и он появился в Postgres 18. До этого люди писали свой UUID на коленке, но теперь все официально.

В целом UUID – это контейнер из 128 бит. Первые несколько содержат информацию о версии, остальное заполняется в зависимости от нее. Самый популярный стандарт сегодня – UUID 4, который полностью случаен. Есть и другие алгоритмы: например, 1 и 2 использовали MAC-адрес машины, на которой генерировались, и таким образом раскрывали системную инфу.

Чем хороша версия 7? Ее первые 48 битов содержат время Unix в миллисекундах. Это значит, такие ключи сохраняют порядок в разрезе тысячной секунды. Кроме того, из него можно извлечь дату и время, а также получить UUID из времени, зная, как заполнить хвост. Уникальность плюс время, два в одном.

Существует три подмножества UUID v7. Они различаются тем, как заполняется хвост. Версия a) хвост заполняется рандомом. Версия b) используется возрастающий счетчик из 12 бит, остальное – рандом. Версия c) используется два счетчика: 12 и 10 бит (могу быть неточным, читал спеку давно).

Счетчики в хвосте важны для супер-точных систем, например трейдинга. Лично я не сталкивался с ситуацией, когда порядка в рамках тысячной секунды недостаточно.

Как я уже рассказывал, UUID v7 отлично подходит на роль первичного ключа. Во-первых, если у вас числовые айдишки, вы становитесь заложником базы. Только она назначает айдишки сущностям. Это становится проблемой в распределенных системах, очередях задач. Пока сущность не вставилась в базу, можно наначить ей временный айди, но это лишнее усложнение.

Наоборот, в случае UUID можно присвоить сущности ключ до вставки в базу, например:

# python
user_id = generate_uuid()
profile_id = generate_uuid()

# sql
insert into users (id) values (user_id)

insert into profiles (id, user_id)
values (profile_id, user_id)

Оба запроса можно выполнить, не обращаясь к полю generated_id результата.

Говорят: UUID длиней числовой айдишки, это раздувание таблицы. Вспомним, что UUIDv7 = id + created_at. Так или иначе нужно хранить время создания сущности. Типы timestamp(tz) занимают 8 байт, тип biginteger/bigserial – тоже 8 байт. В сумме 16, а это столько же, сколько занимает UUID. Все сходится.

Главное: UUIDv4 (полностью случайный) не очень подходит для индексов btree. Если добавлять в него значения возрастанию, они будут наполнять бакеты последовательно. Примерно как фигурки в Тетрисе, когда профессиональные игроки укладывают их слева направо. Если данные случайны, фигурки падают в разные бакеты. Из-за этого выше фрагментация, а кроме того, часто срабатывает перераспределение узлов.

Похожая беда с обходом индекса. Когда мы обходим btree-индекс с числами, то порядок блоков почти совпадает с порядком ключей, например:

id   block
-> 1001
-> 1001
-> 1002

Если у нас уиды, маппинг будет такой:

id                           block
b7b0547b-...-148889ec0602 -> 51451
d1897a03-...-520566c5c9a7 -> 13
ef0093d3-...-26e923a66fe4 -> 7232

Будет много случайного доступа к файлу, и обход такого индекса медленней, чем с числовыми айдишками.

К счастью, седьмой уид сводит проблему на нет, так что пользуйтесь!

Совет дня №16

Sat, 31 Jan 2026 00:00:00 +0000

Разберем ситуацию, когда индекс есть, но не используется.

Предположим, в системе есть пользователи, и каждый указывает город:

create table users (
  id uuid primary key,
  name text,
  city text
)

В реальности поле city ссылается на таблицу городов, но сейчас это не важно – оставим текст. Разработчик создал индекс на город:

create index idx_user_city
using btree on users(city);

Выполняет запрос, чтобы найти пользователей из Москвы:

select * from users where city = 'Moscow'

Смотрит план, а там full scan. Почему?

Самое важное: Postgres никогда не использует индекс просто потому, что он есть. Индекс берется в работу, только если а) по нему собрана статистика и б) она показывает, что индекс дешевле full scan.

Разберем оба условия. Статистика по каждой таблице, ее колонке и индексу хранится в каталоге pg_statistics. Это очень низкоуровневые данные. В них записаны наиболее частые значения колонок, их гистограмма, приблизительные диапазоны значений. Поверх pg_statistics создана вьюха pg_stats, которая удобнее в работе и проверяет права на таблицы.

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

analyze users

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

Итак, статистика есть, но индекс “мигает” – то используется, то нет. Например, ищем пользователей из Читы, попадаем в индекс:

explain
select * from users where city = 'Chita'
/* index scan on idx_user_city ... */

А если из Москвы, будет full scan:

explain
select * from users where city = 'Moscow'
/* full seq scan on users ... */

В чем дело? Ответ – селективность, она же избирательность. Так называют долю найденных записей относительно их общего числа. С селективностью есть путаница: разные учебники по-разному трактуют этот показатель. Одни говорят: если процент малый (1-5%), то селективность высокая, а если большой (30 и выше) – то низкая. Другие наоборот: малый процент – низкая селективность, высокий — большая. Я предпочитаю первый (обратный) вариант: чем меньше записей охватывает условие, тем точнее (выше) селективность.

Если проверить, сколько в базе пользователей из какого города, то окажется следующее. Из Читы – три человека (высокая селективность), а из Москвы – триста тысяч (крайне низкая). Москва окажется в каталоге pg_statistics в колонке “частые значения” – сигнал к тому, чтобы не брать индекс в работу. При анализе запроса Postgres это проверит и возьмет full scan. Москвичи пролетают!

Какова должна быть селективность значения? Реальность такова, что Postgres берет в работу индекс, если селективность условия не превышает 5-10 процентов. Это довольно мало! Именно поэтому нет смысла создавать индексы на логические флаги (true/false), статусы (active, pending, done) и другие значения с малым разбросом. Их селективность слишком низкая (высокая доля выборки).

Для таких значений используйте частичные индексы (см. прошлый совет). Например, только активные заказы, только москвичи и так далее. И потом ищите уже внутри этого подмножества.

Почему Postgres предпочитает full scan для условия, которое покрывает 30% таблицы? Ведь прочитать треть таблицы быстрее, чем всю? Дело в том, что обход индекса возвращает не сами строки, а номера блоков, где они находятся. Блоки идут не один за другим, а разбросаны по всему файлу. Даже если отсортировать номера по возрастанию, между ними могут быть большие промежутки. В результате будет много дисковых операций. На крутящихся жестких дисках это приводило к частому переносу головки.

Напротив, чтение всех блоков подряд относительно дешево. При таком методе Postgres читает сразу много блоков, а не по одному.

Итого: выполняйте analyze, проверяйте селективность условия.

Глава 1. Введение в документы

Sun, 25 Jan 2026 00:00:00 +0000

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

Табличное мышление

Если вы бэкенд-разработчик, то скорее всего работали с реляционными базами данных. Наиболее известные их представители — это MySQL, ее форк MariaDB, PostgreSQL, Microsoft SQL Server, Oracle DB. Реляционные базы называются так из-за лежащей в их основе реляционной алгебры (она же алгебра отношений). Это математический аппарат, который строится на отношениях (множествах кортежей) и операций над ними (проекция, объединение, пересечение и другие).

Чтобы работать с базой на прикладном уровне, реляционная алгебра не требуется. Гораздо важнее следствия математической модели:

любой массив данных является таблицей;
любая операция над таблицей порождает таблицу.

В каждой базе найдется техника, которая не подходит под эти правила. Однако общую картину это не меняет: в основе реляционных баз лежат таблицы и операции над ними.

Предположим, имеется таблица users с тремя полями: id, name и age:

create table users (
    id integer,
    name text,
    age integer
);

Добавим трех пользователей:

insert into users values
    (1, 'Ivan', 14),
    (2, 'John', 34),
    (3, 'Juan', 51);

Выборка всех полей без условий вернет таблицу (отношение):

select id, name, age from users;

┌────┬──────┬─────┐
│ id │ name │ age │
├────┼──────┼─────┤
│  1 │ Ivan │  14 │
│  2 │ John │  34 │
│  3 │ Juan │  51 │
└────┴──────┴─────┘

Если выбрать только два столбца, получим таблицу, усеченную по горизонтали. В реляционной алгебре это называется проекцией:

select id, age from users;

┌────┬─────┐
│ id │ age │
├────┼─────┤
│  1 │  14 │
│  2 │  34 │
│  3 │  51 │
└────┴─────┘

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

select id, name from users
where age between 18 and 49

Операторы SELECT и WHERE срезали данные с разных сторон, но итоговый результат — таблица:

┌────┬──────┐
│ id │ name │
├────┼──────┤
│  2 │ John │
└────┴──────┘

Оператор JOIN (соединение), напротив, расширяет таблицу по горизонтали. Ниже мы соединяем пользователей с их профилями по ссылочному полю.

create table profiles (
    user_id integer,
    job text,
    is_open boolean
);

insert into profiles values
    (1, 'teacher', true),
    (2, 'programmer', false),
    (3, 'tester', true);

select * from users u
join profiles p on u.id = p.user_id;

Итоговая таблица содержит поля обеих таблиц:

┌────┬──────┬─────┬─────────┬────────────┬─────────┐
│ id │ name │ age │ user_id │    job     │ is_open │
├────┼──────┼─────┼─────────┼────────────┼─────────┤
│  1 │ Ivan │  14 │       1 │ teacher    │ t       │
│  2 │ John │  34 │       2 │ programmer │ f       │
│  3 │ Juan │  51 │       3 │ tester     │ t       │
└────┴──────┴─────┴─────────┴────────────┴─────────┘

Даже такой примитивный запрос как select 1 as x возвращает таблицу. В ней одна колонка с именем x и одна запись с кортежем (1, ):

select 1 as x;

┌───┐
│ x │
├───┤
│ 1 │
└───┘

Возможно, кому-то этот подход напомнил Matlab, где любое значение считается матрицей, пусть даже размера 1x1.

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

В прикладных языках вроде Python или Java мы работаем не с таблицами, а коллекциями. Чаще всего это списки и словари, в случае строгой типизации – структуры, записи. Следующий тезис прозвучит странно, но все-таки: в обработке данных коллекции уступают таблицам. Если выразить проекцию и фильтр на прикладном языке, код окажется многословным, а иной раз – запутанным.

Причина в том, что Python, Java и аналоги – языки общего назначения. Их задача – быть удобными во всем, не вдаваясь слишком глубоко в какую-то область. При работе с коллекциями они удобны, но уступают специальному решению – SQL.

Предположим, имеется список пользователей. Каждый элемент – словарь с полями id, name и age. Нужно выбрать пользователей старше 18 лет, оставив при этом код и имя. Выразим это на разных языках, например императивном Python. Нам понадобится функция subset, которая вернет подмножество словаря:

dеf subset(d, *keys):
    return {k: d[k] for k in keys}

users = [
    {"id": 1, "name": "Ivan", "age": 14},
    {"id": 2, "name": "John", "age": 34},
    {"id": 3, "name": "Juan", "age": 51},
]

new_users = [
    subset(user, "id", "name") for user in users
    if user["age"] > 18
]

[{'id': 2, 'name': 'John'},
 {'id': 3, 'name': 'Juan'}]

То же самое на Clоjure, функциональном диалекте Лиспа:

(dеf users
  [{:id 1 :name "Ivan" :age 14}
   {:id 2 :name "John" :age 34}
   {:id 3 :name "Juan" :age 51}])

(->> users
     (filter (fn [user]
               (-> user :age (> 18))))
     (map (fn [user]
            (select-keys user [:id :name]))))

({:id 2 :name "John"}
 {:id 3 :name "Juan"})

В каждом языке это можно проделать разными способами, но мы выбрали самые очевидные: list comprehension в Python и map/filter Clоjure. Теперь запишем то же самое на SQL:

select id, name from users where age > 18;

┌────┬──────┐
│ id │ name │
├────┼──────┤
│  2 │ John │
│  3 │ Juan │
└────┴──────┘

Решение на SQL короче, однако мы усложним пример. Предположим, к пользователям прилагаются профили. Вдобавок к отбору по возрасту нужно оставить тех пользователей, в профиле которых указано “открыт к предложениям” (логическое поле is_open).

Вот какие трудности это влечет. Во-первых, чтобы найти профиль по номеру пользователя, нужно составить словарь user_id => profile. Во-вторых, на каждом шаге проверять, есть ли профиль, и если нет, отбрасывать пользователя, даже если ему больше 18 лет. В-третьих, при наличии профиля проверять флаг is_open. Код на Python:

profiles = [
    {"user_id": 1, "job": "teacher", "is_open": True},
    {"user_id": 2, "job": "programmer", "is_open": False},
    {"user_id": 3, "job": "tester", "is_open": True},
]

dеf index_by(field, rows):
    return {row[field]: row for row in rows}

profile_index = index_by("user_id", profiles);

result = []
for user in users:
    user_id = user["id"]
    profile = profile_index[user_id]
    if user["age"] > 18 and profile["is_open"]:
        row = {**user, **profile}
        result.append(row)

[{'id': 3,
  'name': 'Juan',
  'age': 51,
  'user_id': 3,
  'job': 'tester',
  'is_open': True}]

Версия на Clоjure:

(dеf profiles
  [{:user-id 1 :job "teacher" :is-open true}
   {:user-id 2 :job "programmer" :is-open false}
   {:user-id 3 :job "tester" :is-open true}])

(dеfn index-by [kw rows]
  (->> rows
       (map (juxt kw identity))
       (into {})))

(dеf profile-index
  (index-by :user-id profiles))

(->> users
     (filter (fn [user]
               (-> user :age (> 18))))
     (map (fn [user]
            (let [profile (get profile-index (:id user))]
              (merge user profile))))
     (filter (fn [row]
               (-> row :is-open))))

({:id 3,
  :name "Juan",
  :age 51,
  :user-id 3,
  :job "tester",
  :is-open true})

Решение на SQL:

select * from users u
join profiles p on u.id = p.user_id
where u.age > 18 and p.is_open;

┌────┬──────┬─────┬─────────┬────────┬─────────┐
│ id │ name │ age │ user_id │ job    │ is_open │
├────┼──────┼─────┼─────────┼────────┼─────────┤
│  3 │ Juan │  51 │       3 │ tester │ t       │
└────┴──────┴─────┴─────────┴────────┴─────────┘

Третий вариант — снова самый короткий, но преимущество не только в этом. SQL декларативен: он не указывает порядок обхода таблиц, не требует циклов и проверок if/else. Для его исполнения не нужен интерпретатор, установленный локально. Код на SQL выполнит сервер, а мы получим результат.

Автор видел примеры того, как целые экраны кода можно было заменить небольшим запросом. Единственное ограничение в том, что данные не всегда находятся в базе: в эпоху микросервисов их все чаще извлекают по сети. Сущности получают из разных источников и соединяют в приложении: строят индексы id => entity, обходят их и отбрасывают часть данных. Эти действия легко заменить шагами:

загрузить данные в реляционные таблицы;
выполнить запросы с нужными WHERE, JOIN, GROUP BY и так далее.

Недостаток в том, что данные нужно загрузить в базу – а ведь мы уже потратили время на обращение к сервисам. Это увеличивает трафик и замедляет обработку. Однако сегодня для каждого языка найдется in-memory SQL engine – движок SQL, который работает в одном процессе с приложением. Прежде всего это SQLite и DuckDB: они написаны на C/C++ и вызываются через внешний интерфейс (foreign function call). В Java доступны библиотеки H2 и HyperSQL, написанные на ней самой. Поэтому работа с данными сводится к шагам:

собрать ингредиенты из сетевых сервисов;
перенести их в SQL-движок, запущенный в памяти;
выполнить запросы и прочитать результат.

Часто разработчики выступают против SQL и заменяют абстракцией: ORM (Object Relational Mapping) или потоками (LinQ в C#, Streams в Java). Однако практика показывает: на долгой дистанции SQL проще и удобней. Реляционная модель позволяет строить любые проекции данных и при этом:

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

Не нужна машина, на которой установлены Python, Java и другие языки. Если данные хранятся в базе, для работы с ними хватит минимального клиента вроде psql.

Подход NoSQL

На рубеже нулевых и десятых годов возникли другие подходы к хранению данных. Их ключевая черта – отказ от таблиц и языка SQL. Совокупно эти решения назвали NoSQL, причем No означает не английское “нет”, а not only — не только SQL. Некоторые NoSQL-базы все-таки предлагают похожий на SQL язык и концепцию таблиц (например, Cassandra).

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

Некоторые базы рассчитаны на хранение документов. От хранилищ “ключ-значение” они отличаются тем, что значение, во-первых, объемно (занимает килобайты и мегабайты), а во-вторых – структурировано. Документ хранится не строкой, а в виде дерева или набора “путь-значение”. Рассмотрим следующий документ:

{
  "id": "123456",
  "title": "Some Document",
  "attrs": {
    "code": 662234,
    "created_at": "2025-01-22",
    "users": [
      {
        "id": 1,
        "email": "user1@test.com"
      },
      {
        "id": 2,
        "email": "user2@test.com"
      }
    ]
  }
}

При вставке он раскладывается на пары “путь->значение”:

id                  -> "123456"
title               -> "Some Document"
attrs.code          -> 662234
attrs.created_at    -> 2025-01-22
attrs.users.0.id    -> 1
attrs.users.0.email -> user1@test.com
attrs.users.1.id    -> 2
attrs.users.1.email -> user2@test.com

Чтобы найти документы по атрибутам, для некоторых путей строят индекс. В запросах используется либо доменный язык (DSL), либо выражение пути, аналог XPath для XML. Все это мы рассмотрим в последующих главах.

База данных Datomic и аналоги (например, XTDB) хранят документы в виде кортежей EAV – entity, attribute, value, что означает “сущность”, “атрибут”, “значение”. В реляционной модели мы бы выразили EAV таблицей:

create table eav (
    e integer,
    a text,
    v text
);

Достоинство модели EAV в том, ей можно описать что угодно: пользователей, профили, товары, заказчиков и так далее. Все это поместиться в одной таблице! Подобно двоичной системе счисления, EAV — своего рода рубеж: далее упростить модель невозможно.

Именно в минимализме EAV проявляется красота этой тройки. Ниже мы заполняем таблицу данными: это пользователи и профили из задачи выше. Каждая группа кортежей относятся к одной сущности:

insert into eav values

    (10001, 'user/name', 'Ivan'),
    (10001, 'user/age', '14'),

    (10002, 'user/name', 'John'),
    (10002, 'user/age', '34'),

    (10003, 'user/name', 'Juan'),
    (10003, 'user/age', '51'),

    (10004, 'profile/user-ref', '10001'),
    (10004, 'profile/job', 'teacher'),
    (10004, 'profile/is-open', 'true'),

    (10005, 'profile/user-ref', '10002'),
    (10005, 'profile/job', 'programmer'),
    (10005, 'profile/is-open', 'false'),

    (10006, 'profile/user-ref', '10003'),
    (10006, 'profile/job', 'tester'),
    (10006, 'profile/is-open', 'true');

Пользователи и профили хранятся в одной таблице и не конфликтуют друг с другом. Однако для SQL подобный минимализм неудобен: он усложняет запросы. Чтобы выбрать пользователей старше 18 лет, открытых к предложениям, понадобится каскад подзапросов и соединений. Маловероятно, что запрос ниже понятен без погружения в контекст:

select *
    from eav
where e in (
    select v::integer
    from eav
    where a = 'profile/user-ref'
        and e in (
            select e from eav where a = 'profile/is-open' and v = 'true'
    )
    intersect
    select e
    from eav
    where a = 'user/age' and v::integer > 18
);

Напротив, в реляционной модели он удивительно прост:

select * from users u
join profiles p on u.id = p.user_id
where u.age > 18 and p.is_open;

Для работы с EAV служит особый язык запросов, основанный на Datalog. В свою очередь Datalog – подмножество языка Prolog, созданного для логических задач. Язык опирается на сопоставления и правила. Приведем код на Clоjure, где мы работаем с Datomic. Для начала запишем пользователей с профилями:

(dеf data
  [{:db/id "user1" :user/name "Ivan" :user/age 14}
   {:db/id "user2" :user/name "John" :user/age 34}
   {:db/id "user3" :user/name "Juan" :user/age 51}
   {:profile/user-ref "user1" :profile/job "teacher"    :profile/is-open true}
   {:profile/user-ref "user2" :profile/job "programmer" :profile/is-open false}
   {:profile/user-ref "user3" :profile/job "tester"     :profile/is-open true}])

(d/transact conn {:tx-data data})

Выберем пользователей старше 18 лет, открытых к предложениям:

(dеf query
  '[:find (pull ?u [*])
	:in $
	:where
	[?u :user/age ?age]
	[(> ?age 18)]
	[?p :profile/user-ref ?u]
	[?p :profile/is-open true]])

(d/q query (d/db conn))

[[{:db/id 96757023244368, :user/name "Juan", :user/age 51}]]

Как и в случае с SQL, запрос на Datalog занял меньше строк, чем код на Clоjure. Специализированное решение – всегда более емкое.

Переход с SQL на EAV требует серьезной перестройки мышления. И хотя Datomic не стал популярен как реляционные базы, он вызывал своего рода ренессанс Datalog. Появились его различные клоны: XTDB, Datascript, Datalevin и другие, каждый со своими особенностями.

Некоторые решения NoSQL абстрагируются от хранения данных. Скажем, Datomic использует Postgres или MySQL для чтения и записи EAV (наряду с этой тройкой он хранит два других атрибута, которые нас не интересуют). Упрощая, можно сказать, что Datomic — это огромное Btree-дерево, части которого хранятся в реляционной таблице. Также Datomic использует кластер Memcached, а его облачная версия — хранилище S3. Похоже устроена база XTDB: данные могут хранится в реляционных базах, файлах S3 и даже кластере Kafka.

Из всего разнообразия NoSQL нас интересуют базы, ориентированные на документы. Перечислим те, которые пользователь может установить на свой сервер (т.н. self-hosted решения):

MongoDB: производительная база данных, написанная на C++. Известна своей масштабируемостью и репликацией. Очень популярна в мире Node.js.
CouchDB: хранилище документов, написанное на Erlang. CouchDB интересен концепцией представлений (view). Последние устроены как комбинация шагов Map и Reduce — первичная выборка и ее свертка. Разработка CouchDB опирается на публикации Google о технологиях BigTable и MapReduce.
Cassandra: распределенная колоночная база на языке Java. Изначально нацелена на работу в кластере. Предлагает таблицы и SQL-подобный язык, хотя и более ограниченный, чем в реляционных аналогах.

К облачным решениям относятся:

DynamoDB: один из главных сервисов AWS, хранилище документов по ключу. Отличается высокой скоростью и масштабированием. Работает по протоколу REST JSON, что позволяет общаться с ней через обычный HTTP-клиент.
OpenSearch: еще одно решение AWS для индексации документов. Создан на базе ElasticSearch после того, как последний сменил лицензию. Формально OpenSearch не является облачным сервисом, но сложность его развертки столь высока, что в основном им пользуются как услугой облачных провайдеров.
YandexDB (YDB): база данных, созданная в Яндексе. Изначально использовалась для внутренних нужд, в настоящее время доступна как платный сервис. Работает по протоколу gRPC, а также поддерживает API DynamoDB. Последний фактор облегчает переезд из AWS в Яндекс.

Это неполный список, однако мы не ставим цель перечислить все решения для хранения документов. Важнее другое: что представляют собой документы? Где они встречаются и почему их выбирают вместо реляционных таблиц?

Знакомство с документами

Документ — это набор фактов о сущности. Договор с поставщиком, заявка на кредит, история болезни – все это документы. Приведем пример в формате JSON:

{
  "id": "123456",
  "title": "Some Document",
  "attrs": {
    "code": 662234,
    "created_at": "2025-01-22",
    "users": [
      {
        "id": 1,
        "email": "user1@test.com"
      },
      {
        "id": 2,
        "email": "user2@test.com"
      }
    ]
  }
}

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

Предположим, мы знаем номер документа — 123. Этого недостаточно, чтобы его извлечь. Нужно знать сущность: users, orders и так далее. Ключ документа становится парой (users, 123), и эту пару нужно где-то хранить. По своей природе пара сложнее, чем один элемент.

Другой довод в пользу UUID в том, что его производят разные участники. Когда вы создаете документ, UUID может произвести Postgres, приложение (Java, Python и так далее), очередь задач или другой узел инфраструктуры. Нужно лишь, чтобы везде использовался одинаковый алгоритм, например UUID4 или UUID7. Особенности последнего мы обсудим чуть позже.

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

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

историческая: документы перенесли из реляционной базы данных, где у них были числовые ключи – “айдишники”. В системе остался API, который до сих пор обращается к данным по этому полю, например GET /users/123. В этом случае мы поддерживаем совместимость с API.
прикладная: в финансах и бухгалтерии приняты свои системы нумерации документов. Менеджеру удобно, когда у заявок на кредит числовые номера, уникальные в рамках года. Мы согласны поддерживать такой атрибут обеспечить его уникальность; однако это именно атрибут, а не первичный ключ.

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

Тело документа содержит атрибуты – пары “путь -> значение”. Значения могут быть вложенными, например словарем внутри словаря или списком словарей, в каждом из которых другой список.

Приведем несколько документов. В первом метаданные и атрибуты собраны вместе, и не совсем ясно, что есть что:

{
  "id": "c2a44fe0-6840-4916-b6dd-b401f34f9c2a",
  "type": "contract",
  "number": 523552,
  "created_at": "2025-01-01",
  "created_by": {
    "id": "099f2886-9772-4128-a5cd-b648369ce3f0",
    "email": "some.user@test.com"
  },
  "tags": [
    "risk",
    "contract",
    "acme"
  ],
  "expires_at": "2027-12-31",
  "amount": 100000000
}

Вариант, где метаданные собраны в отдельный словарь, выглядит удобнее:

{
  "id": "c2a44fe0-6840-4916-b6dd-b401f34f9c2a",
  "meta": {
    "type": "contract",
    "created_at": "2025-01-01",
    "created_by": {
      "id": "099f2886-9772-4128-a5cd-b648369ce3f0",
      "email": "some.user@test.com"
    },
    "tags": [
      "risk",
      "contract",
      "acme"
    ]
  },
  "number": 523552,
  "expires_at": "2027-12-31",
  "amount": 100000000
}

Иногда атрибуты выносят в отдельный словарь. На вершине документа остаются поля id, meta и attrs:

{
  "id": "c2a44fe0-6840-4916-b6dd-b401f34f9c2a",
  "meta": {
    "type": "contract",
    "created_at": "2025-01-01",
    "created_by": {
      "id": "099f2886-9772-4128-a5cd-b648369ce3f0",
      "email": "some.user@test.com"
    },
    "tags": [
      "risk",
      "contract",
      "acme"
    ]
  },
  "attrs": {
    "number": 523552,
    "expires_at": "2027-12-31",
    "amount": 100000000
  }
}

Перейдем к другому вопросу: чем документ отличается от реляционных таблиц? Для этого рассмотрим документ: договор со ссылкой на контрагента:

{
  "id": "c2a44fe0-6840-4916-b6dd-b401f34f9c2a",
  "number": 523552,
  "created_at": "2025-01-01",
  "expires_at": "2027-12-31",
  "contractor": {
    "id": "bd6a0da9-fe35-4a37-846c-dff3f32cf0ac",
    "title": "Acme Inc"
  },
  "amount": 100000000,
  "currency": "EUR"
}

Разложим его на две таблицы: контрагенты и договоры:

create table contractors (
    id uuid primary key,
    title text
);

create table contract (
    id uuid primary key,
    number integer,
    created_at date,
    expires_at date,
    contractor uuid references contractors(id),
    amount integer,
    currency text
);

insert into contractors values (
    'bd6a0da9-fe35-4a37-846c-dff3f32cf0ac',
    'Acme Inc'
);

insert into contract values (
    'c2a44fe0-6840-4916-b6dd-b401f34f9c2a',
    523552,
    '2025-01-01',
    '2027-12-31',
    'bd6a0da9-fe35-4a37-846c-dff3f32cf0ac',
    100000000,
    'EUR'
);

Одним запросом мы получим обе сущности:

select * from contract c, contractors cs
where c.contractor = cs.id;

┌──────────────────────────────────────┬────────┬────────────┬────────────┬──────────────────────────────────────┬───────────┬──────────┬──────────────────────────────────────┬──────────┐
│                  id                  │ number │ created_at │ expires_at │              contractor              │  amount   │ currency │                  id                  │  title   │
├──────────────────────────────────────┼────────┼────────────┼────────────┼──────────────────────────────────────┼───────────┼──────────┼──────────────────────────────────────┼──────────┤
│ c2a44fe0-6840-4916-b6dd-b401f34f9c2a │ 523552 │ 2025-01-01 │ 2027-12-31 │ bd6a0da9-fe35-4a37-846c-dff3f32cf0ac │ 100000000 │ EUR      │ bd6a0da9-fe35-4a37-846c-dff3f32cf0ac │ Acme Inc │
└──────────────────────────────────────┴────────┴────────────┴────────────┴──────────────────────────────────────┴───────────┴──────────┴──────────────────────────────────────┴──────────┘

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

Доводы в пользу документов

Преимущества документов очевидны, если выдвинуть следующие требования.

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

Покажем это на примере. Предположим, система ведет договоры между участниками. Бухгалтерские реалии таковы, что в зависимости от типа участников структура договора меняется. Договоры между двумя обществами, обществом и ИП, ИП и самозанятым различаются кардинально. Часть полей будет общей, но будет и немало других, особых для каждого случая.

В приложении строят каскад схем. Сперва определяют базовую схему, которой соответствует любой документ. В ней содержатся поля id, meta и attrs. Запишем ее на псевдокоде:

Type = Enum(user, profile, contract, ...)

Meta = {
    type: Type,
    created_at: Date,
    created_by: UserRef,
    tags: List<String>
}

Attrs = Dict<String, Any>

Document = {
    id: UUID,
    meta: Meta,
    attrs: Attrs
}

На ее основе определяют договор. Считаем, что условная функция merge рекурсивно объединяет две схемы:

ContractBase = merge(Document, {
    attrs: {
        amount: Integer,
        currency: EnumCurrency,
        contractor: ContractorRef
    }
})

От общего договора наследуют конкретный случай: договор между организацией и индивидуальным предпринимателем:

ContractOrgIp = merge(ContractBase, {
    attrs: {
        ip: IPRef,
        tenor: TenorSpec,
        departments: List<DepartmentRef>
    }
})

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

ContractOrgOrg = merge(ContractBase, {
    attrs: {
        org: OrgRef,
        risks: List<RiskTable>,
        risk_taker: RiskTakerRef
    }
})

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

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

{
  "id": "6e394e79-2d71-47ae-a314-534fd9a10719",
  "amount": 10000,
  "currency": "USD",
  "users": [
    {
      "id": "418d4488-507f-4ad4-86a3-f1c1e43f4b69",
      "email": "ivan@test.com"
    },
    {
      "id": "9f3d6c5a-02b3-45cf-b256-699fe91aab59",
      "email": "anna@test.com"
    },
    {
      "id": "66250983-1a11-421d-86b8-753384bf4845",
      "email": "elena@test.com"
    }
  ]
}

Хранить вложенный массив в плоской таблице неудобно. Обычно поступают так: таблица application хранит скалярные (отличные от коллекций) атрибуты. Коллекции выносят в смежные таблицы и связывают их таблицами-мостами:

┌────────────────────────────────────────────────────────────────────────────────────────────┐
│┌──────────────────────────┐                        ┌──────────────────────────────────────┐│
││       applications       │                        │                users                 ││
│├────────┬────────┬────────┤                        ├────────┬───────────────┬─────────────┤│
││   id   │ amount │currency│                        │   id   │     email     │  full_name  ││
│├────────┼────────┼────────┤                        ├────────┼───────────────┼─────────────┤│
││...10719│   10000│     USD│                     ┌─▶│...3f4b6│  ivan@test.com│  Ivan Testov││
│└────────┴────────┴────────┘                     │  ├────────┼───────────────┼─────────────┤│
│     ▲                                           │ ▲│...aab59│  anna@test.com│ Anna Testova││
│     │                  ┌─────────────────────┐  │ │├────────┼───────────────┼─────────────┤│
│     │                  │  application_users  │  │ ││...f4845│ elena@test.com│Elena Testova││
│     │                  ├────────────┬────────┤  │ │└────────┴───────────────┴─────────────┘│
│     │                  │document_id │user_id │──┘ │     ▲                                  │
│     │                  ├────────────┼────────┤    │     │                                  │
│     ├──────────────────│    ...10719│...3f4b6│────┘     │                                  │
│     │                  ├────────────┼────────┤          │                                  │
│     ├──────────────────│    ...10719│...aab59│          │                                  │
│     │                  ├────────────┼────────┤          │                                  │
│     └──────────────────│    ...10719│...f4845│──────────┘                                  │
│                        └────────────┴────────┘                                             │
└────────────────────────────────────────────────────────────────────────────────────────────┘

Проблема в том, что у пользователя тоже могут быть вложенные поля, например список ролей или отделов, которым он принадлежит. Понадобится таблица application_users_roles или application_users_departments. Структура базы усложняется: чем больше вложенность документа, тем сложнее каскад таблиц. Если на каком-то уровне возникнет ошибка, ее тяжело расследовать.

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

{
  "id": "...",
  "amount": 10000,
  "contractor": "e093c3c8-54c8-4375-a964-4a5de09ef3d0",
  "currency": "RUB"
}

и после:

{
  "id": "...",
  "amount": 10000,
  "contractor": {
    "ref": "e093c3c8-54c8-4375-a964-4a5de09ef3d0",
    "entity": "contractor"
  },
  "currency": "RUB"
}

Чтобы работа с документами не превратилась в хаос, вводят версии схем. Версию хранят в метаданных и используют в операторах if или case при работе с полем. В примере ниже функция принимает документ и возвращает ссылку на контрагента:

(dеfn contractor-ref [doc]
  (let [version (-> doc :meta :version)]
    (cond
      (>= version 2)
      (-> doc :contractor :ref)

      :else
      (-> doc :contractor))))

Логика сводится к оператору cond: он находит первое истинное условие и возвращает следующую за ним форму. Если версия документа больше или равна двум, путь к ссылке учитывает :ref. В противном случае сработает форма :else.

Предположим, с версии 5 структура ссылки опять поменялась:

{
   "meta":{
      "version":5
   },
   "contractor":{
      "ref":{
         "id":"...",
         "type":":contractor"
      }
   }
}

Чтобы это учесть, добавим в cond новую пару:

(dеfn contractor-ref [doc]
  (let [version (-> doc :meta :version)]
    (cond
      (>= version 5)
      (-> doc :contractor :ref :id)

      (>= version 2)
      (-> doc :contractor :ref)

      :else
      (-> doc :contractor))))

Реляционные базы не позволяют делать то же самое на уровне колонок. Если ссылка хранится в поле с типом uuid, в нее нельзя записать лишние данные: понадобится новая колонка.

Еще одно удобство документных баз в том, что, как правило, они предлагает удобные CRUD-операции. Реляционные базы, напротив, перекладывают их на ваши плечи.

Когда вы подключаетесь к документной базе из приложения, вам доступен объект Connection или Client. Он предлагает методы .create, .update, get_by_id, delete_by_id и другие. Вот как выглядит жизненный цикл документа на псевдокоде:

client = Client.connect(host, port, ...)

doc = {
    meta: {
        created_at: now(),
        created_by: user.id
    },
    attrs: {
        amount: 10000,
        currency: "USD"
    }
}

client.save(doc)
doc.update({"attrs": {"amount": 10550}})
doc.delete()

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

Реляционные базы не предлагают таких удобств. Разработчику доступен метод .execute, который ожидает запрос и параметры. Что именно в этом запросе — остается на ваше усмотрение. Чтобы извлечь платеж по ID, мы пишем SELECT:

select * from payments where id = ?

Чтобы удалить — DELETE:

delete from payments where id = ?

Разработчик должен помнить об инъекциях, избегать конкатенации строк для построения SQL, помнить операторы и многое другое.

Выше таблица не может быть параметром. Выражения select * from users и select * from orders – это разные запросы. Если разработчик хочет универсальную функцию, которая принимает имя таблицы и ID, ее пишут отдельно с учетом небезопасных символов (экранирования). Некоторые таблицы квалифицированы, то есть включают схему: не просто payments, а prod_analytics.payments. В этом случае обе части экранируются отдельно:

select * from "prod_analytics"."payments" ...

Документные базы используют словари для фильтрации. Чтобы выбрать документы по нескольким признакам, передают словарь атрибут => значение (по умолчанию они объединяются оператором AND). Если нужен еще один критерий отбора, в словарь добавляют поле, и задача решена:

client.find("payments", {
    amount: 10000,
    currency: "USD",
    created_by: 153523
})

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

select * from payments where amount = 10000
select * from payments where amount = 10000 and currency = 'USD'

В итоге, даже скачав библиотеку для Postgres, разработчик не может приступить к работе. Требуется некий “обвес”, вспомогательный код, который берет на себя вставку данных, выборку, удаление и остальное. Поэтому так популярны ORM: они служат посредником между базой и приложением. ORM действительно помогает на старте: легче начать проект, новички быстрее пишут код. У этой медали другая сторона: иногда ORM посылает неоптимальные или излишние запросы, но разработчик не в курсе этого.

Задачи, которые решают документы

Разберем теперь, как фирмы приходят к документо-ориентированным базам данных: какие факторы подталкивают их к тому, чтобы платить за кластер MongoDB или облачный сервис DynamoDB. Речь пойдет о реальных, а не выдуманных случаях.

Проблема типов. Некоторые данные с трудом ложаться на реляционную модель из-за разнообразия типов. Следующий пример это иллюстрирует.

Предположим, мы храним товары в Postgresql или MySQL. У товара есть код, название, цена, ссылка на продавца и другие поля, свойственные всем товарам. Но как быть с полями, которые относятся к особым видам товаров? Для ноутбука это диагональ экрана, наличие портов и частота памяти. Для одежды — материалы, длина рукава, обхват талии. Для спортивного питания — калорийность, доля жиров, белков, углеводов, масса одной порции, число порций в упаковке и так далее.

Приведем характеристики случайных товаров с маркетплейсов. Игровой ноутбук:

Процессор..................Intel Core 7 240H
Частота процессора.........2500
Ядер процессора............10
Тип памяти.................DDR5
Частота памяти.............5600
Наличие микрофона..........да
Беспроводные интерфейсы....Bluetooth, Wi-Fi
Интерфейсы.................Ethernet, USB 3.2 Gen2 Type A x 2

Футболка:

Цвет товара.........черный
Стиль...............повседневный
Декор...............отсутствует
Размер..............L/XL

Спортивное питание:

Количество в упаковке.....12 штук
Объем.....................1400
Общий вес.................800
Диетические особенности...без глютена, без сахара

Проблема характеристик в том, что их много. Если вынести каждую их них в колонку, мы упремся в ограничение базы на их число. (В скобках отметим, что максимальное число колонок в Postgres — 1600, но на самом деле эта цифра зависит от состава типов. Если точнее, длина записи не может превышать 8 килобайт – максимальный размер страницы. Ограничение можно обойти, собрав Postgresql из исходного кода с заменой константы blocksize, однако маловероятно, что читатель пойдет на эти меры.)

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

|   id | title            | laptop.cpu_count | laptop.mem_freq | cloth.color | cloth.size | food.box_mass | food.diet_note |
|------+------------------+------------------+-----------------+-------------+------------+---------------+----------------|
| 1001 | Razor Flare 18   |               10 |            5600 |             |            |               |                |
| 1002 | MSI Katana 13 XH |               12 |            3200 |             |            |               |                |
| 2001 | T-Shirt White    |                  |                 | white       | L,X,XL     |               |                |
| 2002 | Shirt Pop Blue   |                  |                 | blue        | XXL,S      |               |                |
| 3001 | Mega Snack Plus  |                  |                 |             |            |          1400 | no gluten      |
| 3002 | Protein Bomb     |                  |                 |             |            |          1200 | no sugar       |

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

Поскольку рост по горизонтали нам закрыт, пойдем по вертикали. Мы уже знакомы с моделью EAV, и здесь она весьма кстати. Добавим таблицу item_props с колонками item_id, property и value. В них записаны ссылки на товары, имена характеристик и значения:

create table items(
    id integer primary key,
    title text
);

create table item_props(
    item_id integer references items(id),
    property text,
    value text
);

Подготовим товары: два ноутбука, две футболки и два батончика:

insert into items values
    (1001, 'Razor Flare 18'),
    (1002, 'MSI Katana 13 XH'),
    (2001, 'T-Shirt White'),
    (2002, 'Shirt Pop Blue'),
    (3001, 'Mega Snack Plus'),
    (3002, 'Protein Bomb');

Назначим характеристики:

insert into item_props values
    (1001, 'laptop.cpu_count', '10'),
    (1002, 'laptop.mem_freq', '5600'),
    (1002, 'laptop.cpu_count', '12'),
    (1002, 'laptop.mem_freq', '3200'),
    (2001, 'cloth.color', 'white'),
    (2001, 'cloth.size', 'L,X,XL'),
    (2002, 'cloth.color', 'blue'),
    (2002, 'cloth.size', 'XXL,S'),
    (3001, 'food.box_mass', '1400'),
    (3001, 'food.diet_note', 'no gluten'),
    (3002, 'food.box_mass', '1200'),
    (3002, 'food.diet_note', 'no sugar');

Чтобы выбрать товары с характеристиками, соединим таблицы оператором JOIN:

select * from items, item_props
where items.id = item_props.item_id;

┌──────┬──────────────────┬─────────┬──────────────────┬───────────┐
│  id  │      title       │ item_id │     property     │   value   │
├──────┼──────────────────┼─────────┼──────────────────┼───────────┤
│ 1001 │ Razor Flare 18   │    1001 │ laptop.cpu_count │ 10        │
│ 1002 │ MSI Katana 13 XH │    1002 │ laptop.mem_freq  │ 5600      │
│ 1002 │ MSI Katana 13 XH │    1002 │ laptop.cpu_count │ 12        │
│ 1002 │ MSI Katana 13 XH │    1002 │ laptop.mem_freq  │ 3200      │
│ 2001 │ T-Shirt White    │    2001 │ cloth.color      │ white     │
│ 2001 │ T-Shirt White    │    2001 │ cloth.size       │ L,X,XL    │
│ 2002 │ Shirt Pop Blue   │    2002 │ cloth.color      │ blue      │
│ 2002 │ Shirt Pop Blue   │    2002 │ cloth.size       │ XXL,S     │
│ 3001 │ Mega Snack Plus  │    3001 │ food.box_mass    │ 1400      │
│ 3001 │ Mega Snack Plus  │    3001 │ food.diet_note   │ no gluten │
│ 3002 │ Protein Bomb     │    3002 │ food.box_mass    │ 1200      │
│ 3002 │ Protein Bomb     │    3002 │ food.diet_note   │ no sugar  │
└──────┴──────────────────┴─────────┴──────────────────┴───────────┘

Таблицу item_props можно заполнять бесконечно, не беспокоясь о числе характеристик. Если ноутбуку понадобится новое свойство (объем видеопамяти), это будет очередная строка в таблице:

insert into item_props values
    (1001, 'laptop.video_mem', '8 Gb');

Наш дизайн не учитывает, что у характеристик разные типы. Частота памяти — это число (2666 герц), размер одежды — перечисление (L, XL), наличие bluetooth — логический флаг (есть или нет). Иные значения могут быть коллекциями, например версии кодеков или протоколы — это списки строк или чисел.

В таблице item_props колонка value носит строковый тип. Это компромисс, на который мы пошли, чтобы хранить в ней любое значение. В целом это неудобно, особенно если требуется поиск по характеристикам: придется приводить текст к числу, булеву и другим типам.

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

create table item_props_json(
    item_id integer references items(id),
    property text,
    value jsonb
);

insert into item_props_json values
    (1001, 'laptop.cpu_count', '10'),
    (1002, 'laptop.mem_freq', '5600'),
    (1002, 'laptop.cpu_count', '12'),
    (1002, 'laptop.mem_freq', '3200'),
    (2001, 'cloth.color', '"white"'),
    (2001, 'cloth.size', '["L","X","XL"]'),
    (2002, 'cloth.color', '"blue"'),
    (2002, 'cloth.size', '["XXL","S"]'),
    (3001, 'food.box_mass', '1400'),
    (3001, 'food.diet_note', '"no gluten"'),
    (3002, 'food.box_mass', '1200'),
    (3002, 'food.diet_note', '"no sugar"');

Обратите внимание, что строки заключаются в двойные кавычки, потому что этого требует стандарт JSON. Выберем данные еще раз:

select * from items, item_props_json
where items.id = item_props_json.item_id;

┌──────┬──────────────────┬─────────┬──────────────────┬──────────────────┐
│  id  │      title       │ item_id │     property     │      value       │
├──────┼──────────────────┼─────────┼──────────────────┼──────────────────┤
│ 1001 │ Razor Flare 18   │    1001 │ laptop.cpu_count │ 10               │
│ 1002 │ MSI Katana 13 XH │    1002 │ laptop.mem_freq  │ 5600             │
│ 1002 │ MSI Katana 13 XH │    1002 │ laptop.cpu_count │ 12               │
│ 1002 │ MSI Katana 13 XH │    1002 │ laptop.mem_freq  │ 3200             │
│ 2001 │ T-Shirt White    │    2001 │ cloth.color      │ "white"          │
│ 2001 │ T-Shirt White    │    2001 │ cloth.size       │ ["L", "X", "XL"] │
│ 2002 │ Shirt Pop Blue   │    2002 │ cloth.color      │ "blue"           │
│ 2002 │ Shirt Pop Blue   │    2002 │ cloth.size       │ ["XXL", "S"]     │
│ 3001 │ Mega Snack Plus  │    3001 │ food.box_mass    │ 1400             │
│ 3001 │ Mega Snack Plus  │    3001 │ food.diet_note   │ "no gluten"      │
│ 3002 │ Protein Bomb     │    3002 │ food.box_mass    │ 1200             │
│ 3002 │ Protein Bomb     │    3002 │ food.diet_note   │ "no sugar"       │
└──────┴──────────────────┴─────────┴──────────────────┴──────────────────┘

Так выглядят данные в терминале, однако в приложении результат может отличаться. Библиотеки для работы с базой автоматически парсят значения json(b), и они становятся нативными типами приложения: числами, строками, словарями и так далее.

В некоторых языках, например в Java, нет встроенного JSON-парсера. Драйвер JDBC не преобразует колонку jsonb в значение JVM. Вместо этого он вернет объект PGObject с JSON-строкой, и как с ней работать – остается на ваше усмотрение. Различные ORM предлагают JSONField – класс, который кодирует и декодирует данные, используя стороннюю библиотеку. В других языках, например Clоjure, можно расширить типы протоколом – соглашением о том, как упаковать их в JSON и прочитать обратно.

Решение с характеристиками можно улучшить. Вместо того, чтобы хранить их по отдельности, построим словарь вида характеристика -> значение. В этом случае таблица item_props не понадобится: словарь хранится в самом товаре. Пример:

drop table item_props;
drop table item_props_json;

alter table items add column props jsonb;

update items set props = $$
    {"laptop.cpu_count": 10, "laptop.mem_freq": 5600}
$$ where id = 1001;

update items set props = $$
    {"cloth.color": "white", "cloth.size": ["L","X","XL"]}
$$ where id = 2001;

Мы удалили таблицы характеристик, добавили товару колонку props и записали в нее свойства двух товаров. На практике такие изменения автоматизируют: пишут запрос, который “схлопывает” характеристики и значения в словари и переносит в товары. В следующих главах мы рассмотрим эту технику.

Попутно решается еще одна деталь: объект JSON исключает повторы ключей, поэтому не получится хранить две характеристики с одинаковым именем. В таблице item_props мы бы создали уникальный индекс для комбинации (item_id, property).

Словарь характеристик, хоть и ослабляет структуру базы, оказывается удачным решением. Да, поле JSON – черный ящик, который хранит что угодно. Да, перед записью вы обязаны проверить, что props – словарь, а не число или список. Да, тип jsonb нарушает нормальные формы, которым учат в университетах. Однако упрощение, которое дает jsonb, в конечном счете перевешивает недостатки. Мы получили меньше таблиц и меньше кода. Задача решена простым и понятным способом.

Сложная структура. Иногда сервис получает уведомления платежных систем: Paypal, Stripe, App Store. Чтобы проверить покупку, из уведомления берут коды пользователя и товара, сумму, номер транзакции. Эти поля записывают в базу и показывают в личном кабинете. Перед обработкой уведомления проверяют, что транзакция с таким номером еще не встречалась.

На практике уведомления содержат больше четырех полей. Так, служба Paypal IPN (Instant Payment Notification, мгновенные уведомления о платежах) передает почти сорок полей, среди которых:

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

То же самое относится к App Store: сервера Apple присылают огромные документы, структура которых описана в документации.

Чаще всего разработчики читают только те поля, что необходимы для проверки платежа. Остальное отбрасывают за ненадобностью: у разработчика нет времени, чтобы адаптировать базу данных. В самом деле: чтобы хранить уведомления Paypal в таблице, понадобится 40 колонок. Много времени уйдет на то, чтобы разложить документ на поля и правильно записать их. Позже формат уведомлений может измениться, и мы получим ошибку из-за несовместимых типов. Досадно, когда уведомление пришло, но не обработалось по нашей вине.

Решение в том, чтобы выбрать из уведомления только главные поля, а остальные сохранить в поле jsonb. Этот вариант устойчив к ситуации, когда структура уведомления меняется.

Зачем хранить уведомления? Одна из причин в том, что они полезны для отчетов и аналитики. Например, руководитель хочет знать, какую услугу чаще всего покупали в такой-то стране в определенный период. Менеджер запросит отчет продаж в разрезе категорий товаров. Имея данные в базе, пусть даже в виде jsonb, эти потребности легко удовлетворить.

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

Локальные данные решают эту проблему. Разумеется, время от времени проводят сверку с платежным сервисом, чтобы выявить расхождения. Однако в плане отчетности вы не зависите от него: не нужно вызывать API, чтобы показать историю платежей или продажи в определенной стране за месяц. Технически это решается хранением документов в поле jsonb.

Стандарты. Иногда бизнес опирается на стандарты — соглашения о том, как обмениваться данными. Одним из примеров служит FHIR (Fast Healthcare Interoperability Resources) — стандарт обмена медицинской информацией в США и других странах. FHIR определяет сущности, принятые в медицинской сфере: пациент, клиника, анализы, история болезни. Также он описывает спецификацию REST-сервера, который их хранит и обрабатывает.

Сущности выглядят как огромные JSON-документы. Приведем пример пациента с официального сайта:

{
  "resourceType" : "Patient",
  "id" : "example",
  "identifier" : [{
    "use" : "usual",
    "type" : {
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
        "code" : "MR"
      }]
    },
    "system" : "urn:oid:1.2.36.146.595.217.0.1",
    "value" : "12345",
    "period" : {
      "start" : "2001-05-06"
    },
    "assigner" : {
      "display" : "Acme Healthcare"
    }
  }],
  "active" : true,
  "name" : [{
    "use" : "official",
    "family" : "Chalmers",
    "given" : ["Peter",
    "James"]
  },
  {
    "use" : "usual",
    "given" : ["Jim"]
  },
  {
    "use" : "maiden",
    "family" : "Windsor",
    "given" : ["Peter",
    "James"],
    "period" : {
      "end" : "2002"
    }
  }],
  "telecom" : [{
    "use" : "home"
  },
  {
    "system" : "phone",
    "value" : "(03) 5555 6473",
    "use" : "work",
    "rank" : 1
  },
  {
    "system" : "phone",
    "value" : "(03) 3410 5613",
    "use" : "mobile",
    "rank" : 2
  },
  {
    "system" : "phone",
    "value" : "(03) 5555 8834",
    "use" : "old",
    "period" : {
      "end" : "2014"
    }
  }],
  "gender" : "male",
  "birthDate" : "1974-12-25",
  "_birthDate" : {
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDеfinition/patient-birthTime",
      "valueDateTime" : "1974-12-25T14:35:45-05:00"
    }]
  },
  "deceasedBoolean" : false,
  "address" : [{
    "use" : "home",
    "type" : "both",
    "text" : "534 Erewhon St\nPeasantVille, Rainbow, Vic  3999",
    "line" : ["534 Erewhon St"],
    "city" : "PleasantVille",
    "district" : "Rainbow",
    "state" : "Vic",
    "postalCode" : "3999",
    "period" : {
      "start" : "1974-12-25"
    }
  }],
  "contact" : [{
    "relationship" : [{
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v2-0131",
        "code" : "N"
      }]
    }],
    "name" : {
      "family" : "du Marché",
      "_family" : {
        "extension" : [{
          "url" : "http://hl7.org/fhir/StructureDеfinition/humanname-own-prefix",
          "valueString" : "VV"
        }]
      },
      "given" : ["Bénédicte"]
    },
    "additionalName" : [{
      "use" : "nickname",
      "given" : ["Béné"]
    }],
    "telecom" : [{
      "system" : "phone",
      "value" : "+33 (237) 998327"
    }],
    "address" : {
      "use" : "home",
      "type" : "both",
      "line" : ["534 Erewhon St"],
      "city" : "PleasantVille",
      "district" : "Rainbow",
      "state" : "Vic",
      "postalCode" : "3999",
      "period" : {
        "start" : "1974-12-25"
      }
    },
    "additionalAddress" : [{
      "use" : "work",
      "line" : ["123 Smart St"],
      "city" : "PleasantVille",
      "state" : "Vic",
      "postalCode" : "3999"
    }],
    "gender" : "female",
    "period" : {
      "start" : "2012"
    }
  }],
  "managingOrganization" : {
    "reference" : "Organization/1"
  }
}

Опытный разработчик скажет, что документ можно разбить на таблицы. Технически это возможно; скорее всего, найдется ORM, которая поделит документ на таблицы patient, address, phone и другие, а при чтении – соберет обратно. Проблема в том, что подобных сущностей — полторы сотни (на момент написания книги — 157), и если допустить, что на каждую понадобятся три таблицы…

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

create table patients (
    id uuid primary key dеfault uuid_generate_v4(),
    entity jsonb not null,
    created_at timestamptz not null dеfault current_timestamp,
    updated_at timestamptz
);

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

Другая область, где используют документы — это игры. В пошаговых стратегиях, где ходы делают по очереди, состояние игры описано документом. Он содержит сведения об игроках, юнитах, их здоровье, статусах, предметах, очередности хода и многое другое. Состояние игры хранится в одном месте и читается одним запросом. Когда игрок делает ход, состояние извлекают из поля jsonb. К нему применяют накопленные ходы, записывают в базу новое состояние и рассылают игрокам события.

По такому принципу работала Глобальная Карта компании Wargaming, где когда-то работал автор. Состояние Карты хранилось в Postgresql в поле jsonb; от игроков принимались ходы. Каждый час запускалась задача, которая применяла ходы к состоянию, и таким образом шла игра.

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

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

Слабые стороны документов

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

Перечислим слабые стороны документов, которые заметны в сравнении с реляционной моделью.

Первая и самая значимая особенность — отсутствие оператора JOIN. В SQL им соединяют таблицы по горизонтали. Скажем, если профиль ссылается на пользователя, можно извлечь обе сущности разом, соединив по ключам (первичному и внешнему). Это полезно в отчетах, выгрузке данных, а также когда мы работаем не с одним пользователем, а с тысячами.

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

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

Иные документные базы не имеют оператора JOIN в принципе. К ним относится Cassandra – распределенная база, написанная на Java. Проблему соединения в ней решают денормализацией. Если нужно соединение таблиц users и profiles, заводят таблицу users_profiles и пишут в нее те же данные. Поскольку данные обновляются в двух местах, это чревато расхождением и как следствие – странными результатами.

В MongoDB аналог JOIN называется $lookup. Этот оператор выбирает сущности из смежной коллекции. Предположим, в MongoDB хранятся статьи и комментарии. Ниже мы выбираем статьи, при этом к каждой из них подтягиваются комментарии по условию post._id = comment.post_id (поле id предваряется подчеркиванием, потому что оно системное).

db.posts.aggregate([
  {
    $lookup: {
      from: "comments",
      localField: "_id",
      foreignField: "post_id",
      as: "comments"
    }
  },
  {
    $limit: 100
  }
])

В результате у каждой статьи поле comments с массивом комментариев.

Определенно, оператор $lookup — лучше, чем ничего. С ним задача упрощается: не нужно соединять данные в приложении. Однако $lookup покрывает только левое соединение (LEFT JOIN). Чтобы сделать его внутренним (исключить статьи без комментариев), добавляют условие, что собранный массив не пуст:

{$match: {comments: {$ne: []}}}

Для правого, полного, анти- и других соединений операторов нет. Это расстроит любителей реляционных баз, поскольку они знают: семейство операторов JOIN — мощный инструмент, которым решают целый пласт задач.

Похожая проблема встречается в Datomic. Эта база, наоборот, сильна во внутренних соединениях (INNER JOIN), при котором записи без совпадений отбрасываются. Левые соединения частично возможны при помощи функции get-else. Полные и правые, увы, приходится делать в приложении.

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

В плане транзакций документные базы тоже уступают реляционным. Например, в Datomic транзакции выполняются строго одна за другой. Так устроен транзактор – процесс, который отвечает за изменения в базе. Если транзакция займет длительное время, она заблокирует другие операции на запись (на чтении это не скажется). Подобных ситуаций избегают, разбивая крупные изменения на группу мелких.

Изначально MongoDB предлагала транзакции в рамках одного документа. Гарантировалось, что либо все изменения увенчаются успехом, либо не сработает ни одно. В 2018 году появились ACID-транзакции в разрезе нескольких документов. MongoDB по-прежнему разделяет эти понятия: легкие транзакции для одного документа и тяжелые для нескольких. Последние доступны лишь в случае, когда сервер запущен с поддержкой реплики (флаг --replset). Это усложняет локальную разработку, когда MongoDB запущен в Docker и нужно отладить транзакцию в нескольких документах.

В Postgres транзакции занимают центральное место. Существуют их разные уровни, точки сохранения и отката. Многие сущности и переменные живут строго в рамках транзакции. За счет механизма MVCC (multi-version concurrency control, мульти-версионный контроль параллельного доступа) многие транзакции выполняются параллельно и не мешают друг другу. В критических случаях применяют двухфазные транзакции, известные как XA или 2 phase commits. С ними атомарные изменения возможны даже на разных физических серверах.

Работая с документной базой, обратите внимание на протокол обмена. Если данные передаются в двоичном виде, это хороший признак: сервер может вернуть большой объем данных, что необходимо в ряде задач.

Иные базы общаются с клиентами по REST и JSON (например, OpenSearch). На первый взгляд это удобно: нужен только HTTP-клиент и JSON-парсер. Как правило, то и другое есть в поставке языка. Работа с базой становится делом тривиальным: нужно отправить JSON, проверить статус и прочитать результат. Многие задачи легко автоматизировать утилитами curl и jq.

Протокол HTTP позволяет обращаться к базе из браузера при помощи XMLHttpRequest и Fetch API. Это снижает нагрузку на приложение, потому что оно не служит посредником между браузером и базой. С другой стороны, это небезопасно: обращение к базе из браузера означает, что последний хранит ключ доступа. Подобный доступ используют в закрытых системах, например внутренних приложениях фирмы, где база доступна только из локальной сети.

Недостаток JSON том, что он плохо подходит для ленивого чтения. Парсеры читают его целиком, и на больших данных это проблематично. Растет потребление памяти; нельзя обработать первую сущность, пока не прочитаны все. Текстовый формат избыточен: числа записаны неплотно (один байт – один десятичный разряд), строки экранированы (содержат символы \n, \t, \uXXXX и другие). Неоднозначная ситуация с числами с плавающей запятой. JSON не сообщает, как их читать (Float, Double, BigDecimal), и выбор остается за вами. Также в JSON нет дат и времени: эти поля приводят к нужным типам вручную.

Двоичный формат решает эти проблемы. Числа в нем записаны плотно: скажем, 2 147 483 647 умещается в четыре байта, а не десять. Строки не экранируются, и парсер не бежит по ним в поисках обратной косой черты. Длина значений известна заранее. Каждое значение предваряется кодом типа, так что мы отличим Double от BigDecimal и строку от времени. Двоичный формат удобен для ленивого чтения.

Читатель возразит: проблемы форматов решаются библиотеками. Хорошо написанный клиент скрывает эти шероховатости, и разработчику не важно, как передаются даты, сколько выделено памяти и так далее. Но практика показывает: чем дольше вы работаете с базой, тем вероятней эти детали коснутся вас.

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

Не все документные базы столь легко делятся данными. Например, OpenSearch возвращает не более 10 тысяч документов за один запрос. Если в базе миллион документов, потребуется сто обращений. При этом ваша задача – следить, чтобы результат каждого запроса не превышал 2 147 483 647 байтов, иначе переполнится объект ByteArrayOutputStream.

OpenSearch поддерживает API под названием scroll (аналог курсора в Postgres). Он гарантирует, что в рамках скролла мы не увидим изменений, сделанных другими клиентами. Однако scroll подразумевает запросы в цикле и проброс nextToken. Это влечет написание кода и его отладку. В плане удобства scroll бесконечно далек от COPY.

Наконец, документные базы часто дороги в развертке и эксплуатации. Причина в том, что многие из них устроены как абстракции над другими хранилищами данных. Выше мы упоминали: Datomic хранит индексы в Postgresql, MySQL или DynamoDB. Желательно иметь кластер Memcache для снижения нагрузки. XTDB работает поверх RocksDB, кластера Kafka или сервиса S3. OpenSearch состоит из компонентов с разной функциональностью: ведущий узел (master node), хранилище (data node), прием данных (ingest node) и другие.

Когда в системе много узлов, их трудно развернуть локально. В том числе поэтому документные базы почти всегда работают в облаке. Для локальной разработки доступны их упрощенные dev-версии. В случае Datomic это библиотека com.datomic/local, в которой нет серверного узла: база работает в приложении и использует файлы или память для хранения.

Считается очевидным, что такие системы дешевле развернуть в облаке. На первых порах это действительно так: запуск OpenSearch или Datomic в AWS занимает минуту с момента нажатия на кнопку. Если купить виртуальный сервер и поручить то же самое devops-инженеру, он потратит на это дни.

Однако за все нужно платить, и часто это понимают, когда увязли в облачных решениях. Автор наблюдал эту ситуацию в стартапах и крупных фирмах. На ранних этапах команда ни в чем себе не отказывает: внедряет одно облачное решение, второе, третье. Бдительность усыпляют trial-периоды, когда счета выставляются со скидкой. Но вот они кончились, и счет за облако съедает почти всю прибыль. Инвесторы требуют урезать расходы, и разработчикам ставят задачи на оптимизацию. Теперь они заняты техническими вещами, а не развитием продукта.

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

Замечание о переоценке

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

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

На конференции PGConf сотрудник OpenAI рассказал о роли Postgres в компании. С его слов, OpenAI использует один узел Postgres в облаке Azure. Из особых техник применяется только репликация, чтобы разгрузить чтение. Запись обслуживает один узел, при этом не используется даже шардирование. А тем временем аудитория OpenAI приближается к миллиарду пользователей! Согласно опросам, каждый десятый человек в мире пользуется их услугами – и все это обслуживает один узел Postgres с несколькими репликами. Подробности доклада и слайды вы найдете на странице PGConf Dev 2025.

При всем скепсисе автора к AI нельзя не признать: продукты OpenAI совершили поворот в индустрии. Появился пример того, как компания с одним узлом Postgres вышла на уровень гигантов. Выбирая технический стек, помните об этом факте.

Почему Postgres

В этой книге мы решаем следующую задачу: адаптируем Postgres для хранения документов. На первый взгляд это бессмысленно: зачем Postgres, если существуют специальные решения? Многие из них мы упоминали: это MongoDB, OpenSearch, DynamoDB и другие.

Причина в том, что пока развивались NoSQL-решения, Postgres тоже не стоял на месте. На смену json пришел jsonb, и с каждой версией его возможности улучшаются. Мы узнаем, как читать подмножество jsonb, обновлять его отдельные поля, переводить jsonb в таблицу и обратно, использовать язык JSON Path и другие техники. Вместе они не уступают возможностям документных баз.

Кроме типов json(b), Postgres силен в других направлениях. Прежде всего это операторы JOIN. С их помощью строят отчеты и сложные выборки, сравнивают массивы данных на предмет совпадений. JOIN развивает табличное мышление, о котором мы говорили в начале главы. Со временем вы увидите, что почти любая задача решается соединением: внутренним, левым, полным и другими.

Транзакции в Postgres раскрываются в полной мере. Они дают гранулярный контроль над изменениями, управляют параллельным доступом к данным.

Расширение pg_trgm (триграммы) предлагает поиск на вхождение строки, сопоставление с регулярным выражением, проверку схожести строк.

Расширение pg_cron выполняет запросы по расписанию, что снимает вопрос о внешнем планировщике.

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

Postgres открыт и бесплатен в использовании. Он умерен в требованиях и работает на самом скромном оборудовании. Вы найдете Postgres во всех менеджерах пакетов: apt, yaml, brew и других. Легко запустить Postgres на виртуальном сервере ценой в несколько долларов. Это будет настоящий Postgres, а не муляж для локальной разработки.

Если вы арендуете базу в облаке, но исчерпали бюджет, возможны десятки вариантов переезда. Каждый провайдер предлагает услугу забора данных у конкурента. Предоставьте доступ к базе, и другой провайдер клонирует ее себе. Так выживают стартапы: первый год они арендуют Postgres в AWS со льготным периодом. Как только он заканчивается, переезжают со скидкой в Google Cloud, потом – в Azure и так далее.

Для Postgres написано множество утилит и расширений. Ваш лучший друг – утилита psql, интерактивная оболочка для базы данных. Ее возможности крайне обширны: запросы, импорт и экспорт таблиц, просмотр метаданных, переменные и псевдонимы. Программы PGAdmin, DBeaver, DataGrip и другие предлагают графический интерфейс. PGAdmin запускается в браузере и не требует локальной установки.

Postgresql — база данных с большим объемом учебных материалов. На этом поле с ней конкурирует разве что MySQL. Документация на 3000 страниц охватывает все тонкости Postgresql, в том числе низкоуровневые. Компания Postgres Pro выпускает книги на русском языке для читателей разного уровня. Все материалы доступны бесплатно и без регистрации. К книгам прилагаются файлы с запросами, чтобы не набирать их вручную. В вашем распоряжении учебная база в нескольких вариантах (малого, среднего, большого, гигантского).

Тайное преимущество SQL

Выбирая хранилище данных, имейте в виду: SQL знают не только программисты.

Сегодня почти любая должность, связанная с цифрами и финансами, подразумевает знание SQL. Сотрудники банков и телекомов работают в OLAP-системах, которые агрегируют данные из многих источников. Каждая из этих программ предлагает свой диалект SQL, и сотрудники изучают их на внутренних курсах. PostgreSQL становится еще одним диалектом, который учится в короткое время.

Автор проводил внутренние вебинары на тему как пользоваться Postgres и PGAdmin. Вопреки ожиданиям, у сотрудников было мало вопросов, и всем было все понятно. Позже автор видел, как сотрудники писали сложные запросы и передавали знания друг другу.

В крупных фирмах SQL становится связующим звеном между бизнесом и программистами. Он помогает перевести бизнес-жаргон в технические термины. Например, если аналитик понимает SQL, он объяснит, что значит “дейли лимиты с апрувом без кепэсити” – какие таблицы и фильтры имеются в виду. Иногда аналитики пишут сложные запросы, не привлекая программистов, и тем самым берегут их время.

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

В некоторых NoSQL-базах наблюдается интересная вещь: их заказчики продавливают SQL. Например, в Datomic, основанный на языке Datalog, со временем добавили диалект SQL – пусть не такой мощный, как в Postgres, но удобный для аналитиков. Базу XTDB сделали совместимой с протоколом PG Wire, чтобы к ней можно было обратиться из любого клиента для Postgres.

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

Теперь когда со вступлениями окончено, перейдем к практической части: познакомимся с возможностями JSON в Postgres.

Совет дня №15

Fri, 23 Jan 2026 00:00:00 +0000

Пагинация, продолжение.

Вернемся к случаю, когда нужна пагинация по убыванию времени (created_at, updated_at) и так далее. Этот критерий встречается так часто, что для него есть лазейка.

В прошлый раз мы использовали кортеж (created_at, id). Идея в том, что поскольку created_at не уникален, он не дает точного положения в таблице. Но так как id уникален, их комбинация – тоже уникальна.

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

точно попадать в границы;
использовать btree индекс.

Итак, если у вас API и нужна пагинация, ваши варианты:

limit и offset; убедитесь, что offset не превышает какого-то разумного числа, например тысячи. Иначе вас будут парсить.
keyset: комбинация полей (some_field + id) для уникальности. Требует отдельного индекса.
UUIDv7 – если требуется пагинация по created_at. Это частый случай, поэтому рассмотрите его.

Перейдем к пагинации, которая используется не в API, а для служебных нужд. Например, в миграциях, переносе данных и так далее. Нужно обойти огромную таблицу, при этом выгрузить ее в память нельзя – слишком большая (например, 100 миллионов записей).

Один из способов – использовать курсор и FETCH API. Апишка у него довольно простая:

BEGIN;

DECLARE cur_foo CURSOR FOR SELECT * FROM items;

FETCH FORWARD 100 FROM cur_foo;
FETCH FORWARD 100 FROM cur_foo;
FETCH FORWARD 100 FROM cur_foo;
...
CLOSE cur_foo;
COMMIT;

Объявляем курсор, затем в цикле вытягиваем по 100 записей, пока результат не пустой. В конце закрываем курсор.

Казалось бы, вот он – святой Грааль. Но беда в том, что курсор требует транзакции. В момент открытия он запоминает текущий снимок (номер транзакции) и просматривает записи, версия которых не превышает его. Чтобы пользоваться курсором, нужно держать транзакцию в течение всего цикла. Для больших таблиц это дорого, поэтому подходит только для всяких ночных скриптов.

Кроме того, курсор привязан к конкретному соединению с БД. Использовать их в HTTP API невозможно.

Другой способ обойти большую таблицу – сдампить ее в файл при помощи COPY (см. прошлый совет). Чтобы таблица не заняла весь диск, ее сжимают в gzip. В результате у вас оказывается файл my_table.gzip, вы отрываете его и спокойно парсите. Идея в том, чтобы забрать данные из базы как можно скорее и потом не мучить ее пагинацией. Если скрипт упадет, не придется насиловать базу снова – у вас уже есть файл.

Третий способ – использовать драйвер, который позволяет обрабатывать записи в полете. Например, мой pg2. Функция execute принимает запрос и всякие опции. Среди прочих можно передать редьюсер – функцию трех тел:

(fn
  ([]
   (make-acc ...))
  ([acc row]
   (conj acc row))
  ([acc]
   (finalize acc)))

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

Полагаю, это все, что можно сказать про пагинацию.

Совет дня №14

Fri, 23 Jan 2026 00:00:00 +0000

Итак, пагинация. Прежде всего, совет такой: если можете избежать пагинации, сделайте это. Пагинация — это состояние и его проброс. Лишние заморочки, пространство для багов.

Пример, когда пагинации можно избежать — поиск. Как правило, релевантность поиска резко снижается с продвижением по выдаче. Условно, первые 10 позиций точные, еще десять — более-менее, остальное — просто чтобы заполнить выдачу. Вспомните, как давно вы были на пятой странице Гугла? Если нужной информации нет, лучше отправить другой запрос, чем скроллить страницы. Поэтому договоритесь: в поиске выдаем 50-100 позиций и никаких пагинаций. Живые люди не будут ей пользоваться, а вы только откроете ворота различным ботам и парсерам.

Конечно, иногда пагинация необходима. Простой способ ее добавить — это выражения LIMIT и OFFSET. Дешево и сердито, но с недостатками. Во-первых, на больших смещениях выборка линейно замедляется. Это все равно что перематывать аудиокассету каждый раз с начала. В моей таблице миллион документов, и выражение

select * from table limit 1 offset 500000

занимает 7 секунд. Целая вечность!

Второй минус — LIMIT-OFFSET неконсистентны. В перерывах между запросами может добавиться новая запись, и произойдет наслоение. Я видел такое много раз: листаешь первую страницу, переходишь на вторую и видишь наверху заголовок, который был внизу первой страницы.

Дело в том, что пока я мотал первую страницу, добавили новую статью, и окно сместилось. Для новостного сайта это не страшно, но представьте, что у нас аналог Твиттера. Пока мы читали первые 20 твитов, кто-то наспамил еще двадцать. В результате вторая страница может полностью состоять из твитов, которые мы только что видели на первой! Это никуда не годится.

Чтобы этого избежать, используют пагинацию по уникальному btree-индексу. Такой индекс однозначно определяет позицию в таблице: новые записи не сместят окно. У каждой таблицы есть такой индекс — это первичный ключ (id). Если логика позволяет листать по id, этим нужно воспользоваться. Пример:

select * from items where id < ?
order by id (desc)
limit 100

Id последней записи запоминается и передается в следующий запрос. Продолжаем до тех пор, пока выборка не пустая.

Как быть, если id случаен, и требуется сортировка по дате создания? Задача усложняется, потому что дата не уникальна. Записи могут быть вставлены импортом и поэтому иметь одну дату. Граница окна пагинации может попасть на серию записей с одинаковой датой. Если запомнить дату последней записи и выполнить запрос

select * from items
where created_at < ?
order by created_at desc
limit 100

, мы пропустим записи, которые не показали.

Решение в следующем: уникальный атрибут + неуникальный дают уникальное комбо. В самом деле: если поле created_at не уникальное, то пара (created_at, id) — уникальная. Поэтому заводим составной индекс на пару (created_at desc, id desc) и листаем по нему:

select * from items
where (created_at, id) < (?, ?)
order by created_at desc, id desc
limit 100

Обратите внимание, мы сравниваем кортежи (они сравниваются поэлементно). Общий принцип такой, что создается уникальный индекс на пару (поле, id). Он называется keyset, потому что “набор ключей”.

Каждая сотрировка (возраст, имя, зарплата) требует своей пары, поэтому договоритесь о них заранее.

Совет дня №13

Fri, 23 Jan 2026 00:00:00 +0000

Работая с ORM, избегайте проблемы 1 + N. Это когда вы обращаетесь к ссылочным полям, и база подтягивает сущности штучно, а не разом.

Пример: магазин товаров, сущность Order ссылается на User (кто заказал) и Item (что заказали). Модель выглядит так:

class Order(model.Model):
  status = EnunField(active, cancelled, pending...)
  created_at = DateTimeFiled(now=True)
  user = ForeignField(class=User)
  item = ForeignField(class=Item)

Типичная задача — вывести активные заказы с информацией о клиенте и товаре. Разработчик делает так:

orders = Orders.filter(status=active) \
  .order_by(created_at, desc).all()

Затем он строит таблицу:

for order in orders:
  print order.id, order.user.name, order.item.title

Что произойдет под капотом? Сначала выполнится запрос:

select * from orders where status = 'active'
order by created_at desc;

Тут все в порядке. Однако в цикле, когда происходит обращение к полям user и item, выполняются запросы get-by-id:

select * from users where id = 1
select * from users where id = 2
...
select * from items where id = 100
select * from items where id = 200
...

В среднем запросов будет 1 + 2N. На практике в одном заказе может быть много товаров, а кроме того, возможны подгрузки других сущностей. Скажем, товар хранит ссылку на продавца. Если в таблице должен быть продавец, это будет еще +N запросов.

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

Проблема 1 + N лечится разными способами. Первый — ORM может джойнить сущности, то есть выполнить запрос:

select * from orders
left join users on orders.user_id = user.id
left join items on order.item_id = item.id
where status = 'active'
order by created_at desc;

Такой джоин может нарушить пагинацию по limit/offset, но это страшно. Можно либо не использовать ее вообще, либо взять пагинацию по keyset, либо заменить limit выражением fetch.

Другой способ — вытянуть записи по слоям на уровне приложения. Первый слой — это orders. Как только происходит обращение к user, ORM собирает все user_id и выполнят запрос

select * from users where id in (?, ?, ? ...)

То же самое с items — выгребаются уникальные item_id, и по ним делается запрос с IN.

Некоторые ORM действуют тоньше. Если айдишников много, они выгребают смежные сущности кусками по 10-30. Таким образом, если нужно пройти 100 заказов, мы совершим 4-10 запросов, что не так страшно.

Проблема 1 + N — настоящий бич ORM. Сколько подобных ошибок я исправил — затрудняюсь припомнить (и конечно, совершил сам).

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

Совет дня №12

Fri, 23 Jan 2026 00:00:00 +0000

Дополнение вчерашней заметки насчет запросов в базу. Смотреть запросы, которые выполняются во время тестов – это хорошо, можно поймать много кривых вещей. Но есть еще одна техника: считать запросы и проверять их количество. Этим вы защищаете код от ситуации, когда небольшое изменение накинуло +20 запросов. В ORM подобные вещи случаются часто. В основном они вызваны проблемой 1 + N, о которой будет следующий совет.

Фреймворки-гиганты предлагают встроенный метод подсчета запросов. Например, в Django, если тестовый класс унаследован от TransactionTestCase, доступен метод assertNumQueries. В целом подобный тест выглядит так:

class TestSomeFunc(TestCase):
    dеf test_func(self):
        with self.assertNumQueries(4, using="db1"):
            some_func()

Если кто-то поправит логику, число запросов изменится, и тест не пройдет.

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

# 1 auth
# 2 permission check
# 4 fetch data
# 2 update data
# 2 send notifications

В одном проекте выяснилось: удаление сущности порождало 400 с лишним запросов. Разумеется, почти все они удалялись поштучно, потому что разработчики не дружили с БД.

Для Django написаны в том числе сторонние сборщики запросов, их легко нагуглить. Полагаю, то же самое есть в Руби, Spring Boot и прочих комбайнах. Подсчет легко сделать в Кложе: достаточно динамической переменной и макроса.

Не обязательно считать запросы во всех апишках: скажем, для get-by-id подсчет избыточен. Но удаление сущностей, сложные перемещения из одной таблицы в другую – очень желательно. Все для этого есть, просто воспользуйтесь.