1. Классика всех времен: страница NSM

Традиционная и самая распространённая архитектура в OLTP-СУБД (PostgreSQL, Oracle) — слотированная страница, относящаяся к семейству NSM (N-ary Storage Model). Страница, как правило, имеет фиксированный размер, чаще всего 8 или 16 КБ (может настраиваться параметром БД), и делится на три логические области:

· Заголовок страницы — содержит метаданные: размер страницы, количество слотов, смещение до свободного пространства и флаги.

· Таблица слотов — массив записей фиксированной длины, каждая из которых хранит смещение (offset) до начала соответствующей строки. Слоты упорядочены по позиции строки в таблице.

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

Особенности работы с изменениями на уровне страницы:

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

При удалении строки соответствующий слот помечается как недействительный (например, устанавливается флаг deleted или смещение становится отрицательным). Физическое освобождение места происходит позже — при сборке мусора (VACUUM в PostgreSQL) или при перестройке страницы.

Главный недостаток:

Для запросов, которые читают миллионы строк, но выбирают лишь 2–3 атрибута из 20, NSM необходимо просканировать всю страницу целиком. В результате в кэш CPU загружаются все атрибуты, включая ненужные. Это не только увеличивает время I/O, но и порождает промахи кэша (cache misses), поскольку полезные данные перемешиваются с не нужными.

2. Колоночная страница DSM:

Научная работа Джорджа П. Коупленда и Сетрага Н. Хошафяна «A Decomposition Storage Model» (ACM SIGMOD) [1] предложила кардинально иной подход к организации данных на странице, получивший название DSM (Decomposition Storage Model).

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

Преимущества на уровне страниц:

· Страница заполняется данными одного типа — это даёт значительный прирост в сжатии (RLE, дельта-кодирование, битовые карты) по сравнению с NSM-архитектурой.

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

Обратная сторона:

Вставка или обновление строки требуют записи в страницы всех атрибутов, что превращается в доступ к множеству файлов и их соединение. Запрос SELECT * для ограниченного числа строк также вынужден выполнять дорогостоящее соединение страниц разных столбцов, что делает DSM неэффективной для OLTP.

Первоначально модель не получила широкого распространения именно из-за высокой стоимости сборки строк. Однако с ростом мощностей процессоров и объёмов оперативной памяти она стала основой для колоночных СУБД (Vertica, Greenplum, ClickHouse), где основная нагрузка — аналитические запросы.

3. PAX: гибридная модель данных

В 2001 году на конференции VLDB была представлена работа Анастасии Аламаки, Дэвида ДеВитта, Марка Хилла и Муниратнама Сивакумара «Weaving Relations for Cache Performance» [2], в которой авторы предложили комбинированный подход — PAX (Partition Attributes Crosswise).

Ключевая идея модели:

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

Как происходит выборка данных:

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

Обновление всей строки не требует записи в отдельные файлы (как в DSM) — достаточно перезаписать соответствующие мини-блоки внутри одной страницы.

4. Современные реализации на основе PAX

Apache Parquet

Прямой наследник PAX. Файл разбивается на Row Groups (группы строк, типично 128 МБ – 1 ГБ), каждая из которых действует как крупная «страница» PAX. Внутри Row Group данные организованы по Column Chunks — это и есть мини-блоки разных атрибутов, только теперь они могут быть сжаты независимо друг от друга. Parquet также добавляет индексы и статистику на уровне Column Chunk (min, max, null count), что позволяет при сканировании пропускать целые блоки без разжатия.

Apache ORC (Optimized Row Columnar)

Аналог Parquet, используемый в Hive, Presto и Trino. Внутри ORC-файла выделяются Stripes (полосы), которые выполняют ту же роль, что и Row Groups в Parquet. Внутри Stripe данные хранятся по колонкам с добавлением индексов и словарей. По сути, это тоже PAX, но с более агрессивным сжатием и встроенной фильтрацией.

5. FastLanes — PAX, оптимизированный под SIMD и GPU

PAX-архитектура значительно улучшила предыдущие модели хранения данных, но она не учитывала характеристики процессора. Именно в этом направлении происходит дальнейшее развитие архитектуры хранения данных. Петер Бонч, учёный из исследовательского центра CWI (Нидерланды), предложил новый формат FastLanes, который оптимизирует хранение данных под возможности современных процессоров.

Файл FastLanes состоит из двух главных компонентов: Footer (футер) и Data (данные). Футер содержит метаданные, описание данных и их местонахождение в файле и может храниться отдельно от блока «Данные».

На верхнем уровне блок «Данные» повторяет архитектуру PAX: данные делятся на группы строк и атрибуты. В отличие от существующих типов файлов, в FastLanes группы строк содержат количество записей, кратное 1024. Это позволяет избежать материализации данных в основной памяти и выполнять всю работу на уровне процессора. Следующим важным нововведением является использование сжатия LWC (Light-Weight-Compression). Вместо тяжеловесных алгоритмов по типу Zstd, которые не позволяют распараллелить обработку данных, применяются FSST, DICT, ALP при каскадном (рекурсивном) применении которых достигается уровень сжатия Snappy за более короткий промежуток времени [3]. Кроме этого, для каждой колонки данных могут применяться разные операторы кодирования. Сжатые данные хранятся в сегментах, в которых кроме самих данных хранятся смещения на отдельные вектора, что позволяет читать данные на уровне одного вектора вместо целого блока, как в старых форматах.

Когда данные читаются из оперативной памяти в процессор, закодированный вектор, содержащий 1024 значения, разжимается и полностью помещается в кэш процессора. Напротив, старые форматы файлов не только используют непараллельные алгоритмы сжатия, но и применяют их к целым Row Group, что влечёт за собой использование основной памяти и уменьшение скорости обработки [3].

Использованные источники:

1. Copeland G.P., Khoshafian S.N. A Decomposition Storage Model. Proceedings of ACM SIGMOD, 1985.
2. Ailamaki A., DeWitt D., Hill M., Sivakumar M. Weaving Relations for Cache Performance. Proceedings of VLDB, 2001.
3. Boncz P., Afroozech A., et al. The FastLanes File Format: specification.

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

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

Когда воспроизвести дефект синтетически нельзя, остаётся пассивная телеметрия в продакшене и последовательное отсечение гипотез данными.

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

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

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

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

Управляющий слой Tailscale разбит на шарды, у каждого своя база SQLite, и обращается к ней ровно один процесс. Такой однописательный режим — именно то, для чего SQLite и предназначен, что делает дальнейшее особенно неприятным.

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

Первый случай сочли единичным. Базу починили, причину не нашли. Потом это повторилось. И ещё раз. Всего до устранения первопричины набралось 19 отдельных инцидентов за полгода, и каждый означал простой: процесс на шарде останавливался, пока базу чинили или восстанавливали. На ранних инцидентах простой превышал час, и всё это время у клиентов на шарде не работали консоль администратора и API.

Почему он не поддавался обычным приёмам

Дефект сопротивлялся всем стандартным подходам сразу:

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

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

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

Улика: транзакция, которой не стало

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

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

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

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

Шестнадцатилетняя гонка

SQLite с журналом предзаписи работает с двумя файлами. База — это набор страниц; при изменении данных новые страницы пишутся не в основной файл, а сначала в журнал. Позже контрольная точка переносит их в базу. Обычно момент переноса SQLite выбирает сам, но Tailscale управляла контрольными точками вручную, чтобы снимать быстрые согласованные копии. Именно этот нестандартный, хотя и полностью документированный выбор и вывел их на дефект.

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

Журналы показали редкую гонку данных (race condition) между контрольной точкой и пишущей транзакцией. Если запись происходит в определённый момент работы контрольной точки, та сбивается: считает часть страниц перенесёнными в основной файл, хотя перенос не состоялся. Данные теряются навсегда, а страницы, которые на них ссылаются, например индексные, записываются как ни в чём не бывало. Файл становится структурно повреждённым, что проверка целостности всё это время и фиксировала.

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

Ложная тревога, чуть не сорвавшая исправление

Исправление вышло в версии 3.52.0, и Tailscale раскатывала его осторожно, начав с нескольких канареечных шардов. После общей раскатки монитор резервных копий немедленно покраснел, сообщив о повреждении в тринадцати базах.

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

Разбирали это с трёх сторон сразу. Разработчики SQLite отозвали версию целиком и выпустили 3.51.3, содержавшую только исправление гонки. Tailscale перешла на хранение меток времени целыми секундами, поскольку перевод текста в целое число однозначен. А в 3.53.0 появилось автоматическое восстановление таких индексов, чтобы проблема не возникала впредь.

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

Как доказали, что дефект действительно исправлен

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

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

Случай второй: три процента, терявшиеся только на чистой машине

Второй сюжет проще по масштабу и полезнее в быту. Сервис представлял собой небольшой пересыльщик TCP: принять соединение, читать текстовые строки, передавать дальше. На тестовом стенде входило 97 004 строки, а выходило 94 183. Ни ошибок, ни исключений, просто пропавшие сообщения.

На ноутбуке автора всё воспроизводилось идеально: сто тысяч строк на входе, сто тысяч на выходе. Это расхождение и было первой уликой — тест проверял не то, что делает продакшен.

Сменить машину раньше, чем код

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

Считать, а не логировать

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

Сервер разобрал всё до последней строки, а ответов отправил меньше, чем разобрал. Это отпечаток пальца конкретного дефекта, и дальше оставалось найти его в коде ответа.

read() ничего не обещает про сообщения

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

TCP — это поток байтов, а не очередь сообщений. Вызов чтения не имеет понятия о том, что такое одно сообщение в вашем протоколе. Ядро вправе слить десяток сообщений в один сегмент, и одно чтение заберёт все десять, а ответ уйдёт один.

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

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

Вывод автора расследования:
Локальный тест это не нагрузочный тест, ноутбук это не сервер, а одно чтение из сокета это не одно сообщение.

Третий сюжет: гонки, которые видит только поддержка

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

Классический двойной расход

Наивная версия, которую пишут первой:

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

Инвариант переезжает в условие запроса

Общее решение — сделать проверку и запись одним оператором, перенеся условие корректности в WHERE:

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

Вебхук, доставленный дважды

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

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

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

Что из этого складывается

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

Что забрать с собой

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

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

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

Три постмортема, на которых строится разбор: разбор Tailscale о поиске шестнадцатилетнего бага в SQLite, ретроспектива потери трёх процентов сообщений и четыре гонки в биллинге на бессерверном Postgres.

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

Виноват тут не шлюз. Виноват сервер, который исходил из того, что каждый запрос приходит ровно один раз. В сети, где теряются ответы, это допущение неверно всегда.

Идемпотентность — свойство операции, при котором повторное выполнение приводит к тому же состоянию, что и однократное. Сам ответ при этом может отличаться: повторный DELETE вернёт 404 вместо 200, и метод от этого идемпотентным быть не перестаёт. У HTTP это закреплено на уровне методов: RFC 9110 относит к идемпотентным PUT, DELETE и безопасные методы, а POST идемпотентным по своей природе не является. Бизнес-операции почти всегда отправляют именно через POST.

Клиент не может отличить «сервер не получил запрос» от «сервер выполнил операцию, но ответ потерялся», поэтому повтор придёт в любом случае.

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

Проверка «посмотреть и вставить» неатомарна: два одновременных повтора оба увидят отсутствие ключа. Нужен уникальный индекс или условная запись.

Запись в базу и отправка в очередь в одну транзакцию не помещаются. Обёртывать сетевой вызов в BEGIN и COMMIT вредно вдвойне: корректности не даёт, а пул соединений выедает.

Transactional outbox решает это одной таблицей: событие пишется в той же транзакции, что и бизнес-запись, а отдельный процесс доставляет его в очередь.

Почему повтор неизбежен

Сеть отказывает так, что установить факт доставки невозможно в принципе. Есть три типовых сценария, и внешне они неразличимы:

• Сервер обработал запрос, но ответ потерялся по дороге назад.
• Сервер всё ещё считает, а у клиента уже сработал таймаут.
• Балансировщик повторил запрос сам, никого об этом не уведомив.

Для GET повтор безвреден. Для POST /payments это второе списание. Отсюда и правило: одна логическая операция должна приводить к одному записанному итоговому состоянию, сколько бы раз её ни отправили. Осознанно новая операция обязана прийти с новым ключом.

Два способа сделать ручку идемпотентной и один в довесок

Способ первый: ключ идемпотентности

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

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

И последнее: повтор должен получить тот же самый ответ. Если первая попытка вернула 201 с идентификатором платежа, то и повтор возвращает те же 201 и тот же идентификатор, а не 409 и не пустую двухсотку. Иначе клиент решит, что операция не прошла, и попробует ещё раз.

Способ второй: сделать операцию идемпотентной по смыслу

Иногда ключ не нужен вовсе, потому что семантику можно спроектировать идемпотентной с самого начала. Классический пример — PUT /users/42, который задаёт полное представление ресурса: отправьте его дважды, и состояние будет одним и тем же.

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

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

Довесок: оптимистичная блокировка

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

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

Где наивная реализация ключа разваливается

Гонка в проверке

Последовательность «проверить наличие ключа, потом вставить» содержит зазор, в который помещаются оба одновременных повтора: обе стороны видят, что ключа нет, и обе выполняют работу. Резервировать ключ нужно атомарно, через уникальное ограничение базы, условную запись или транзакционный compare-and-set (атомарное сравнение с записью).

Это же относится и к примеру с платежом выше: замена словаря в памяти на Redis гонку не закрывает, пока проверка и вставка остаются двумя отдельными командами. Нужен атомарный примитив резервирования, вроде SET key value NX или INSERT ... ON CONFLICT DO NOTHING.

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

Слепок запроса, а не только ключ

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

Когда тот же ключ приходит с другим слепком, это ошибка на стороне клиента, и отдавать ему старый результат нельзя. Разбор проектирования идемпотентных ручек предлагает отвечать 409 Conflict; автор практического руководства в этом случае возвращает 422. Важно, чтобы выбранный код был задокументирован и никогда не подменяется молчаливой отдачей чужого ответа.

Состояния и коды ответа

Минимальная модель состояний записи выглядит так: PROCESSING, SUCCEEDED, FAILED_RETRYABLE и FAILED_FINAL. Рядом хранятся ключ операции, слепок, отметки времени, идентификатор решения, снимок ответа и версия политики. Клиенту нужна детерминированная карта из состояния в код ответа:

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

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

Вторая половина задачи: база и очередь

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

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

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

Почему обернуть это в транзакцию нельзя

Соблазнительный и заведомо неверный вариант выглядит так:

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

Есть и вторая беда, чисто эксплуатационная. Такой код держит открытое соединение и блокировки строк всё время сетевого вызова. Обычно очередь отвечает быстро, но под нагрузкой, ретраями или деградацией вызов растягивается на секунды, и все запросы к тем же строкам стоят в очереди. Это надёжный способ исчерпать пул соединений и уронить заодно ни в чём не повинные части сервиса.

Outbox: событие как строка в той же транзакции

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

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

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

Этот SELECT и последующая простановка статуса выполняются в одной транзакции: блокировка живёт до фиксации. Благодаря SKIP LOCKED доставщик масштабируется горизонтально из коробки, каждый экземпляр берёт свой набор строк. А если он упадёт посреди пачки, вся пачка откатится и уйдёт повторно, что даёт ещё один довод в пользу идемпотентного потребителя.

Может показаться, что здесь мы делаем ровно то, что осудили выше: держим блокировку на время сетевого вызова. Разница в том, что блокируется не бизнес-таблица и соединение берётся не из пула, обслуживающего пользовательские запросы, а SKIP LOCKED не даёт одной медленной строке задержать остальные.

Потребитель обязан быть идемпотентным

Если доставщик упал посреди прохода, на следующем он переотправит те же строки. Очереди вроде SQS и Kafka в типовой конфигурации гарантируют доставку «хотя бы один раз», поэтому дедупликация на приёмной стороне обязательна, и уникальным ключом служит идентификатор события или решения.

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

Настройки продюсера и подтверждения брокера снижают количество повторов, но не снимают с приложения ответственность за однократность бизнес-эффекта.

Что добавить перед продакшеном

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

Когда задержка опроса становится критичной, полагающийся на периодический опрос доставщик заменяют захватом изменений: инструменты вроде Debezium читают журнал предзаписи PostgreSQL и публикуют изменения без паузы на опрос. Таблица outbox и потребитель при этом не меняются. Но это заметно более тяжёлое эксплуатационное обязательство, поэтому начинать почти всегда стоит с опроса.

Что забрать с собой

Обе части задачи выглядят избыточными ровно до первого инцидента. Тридцать строк кода с ключом идемпотентности стоят дешевле одного тикета с заголовком «вы списали дважды», а таблица outbox дешевле расследования, почему заказ есть у клиента и отсутствует на складе.

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

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

Материалы, на которых основан разбор: три паттерна идемпотентности с рабочим кодом, проектирование ручек, переживающих реальные повторы и пошаговая сборка outbox на Node.js.

Откройте самый денежный обработчик в своём сервисе и попробуйте отправить в него один и тот же запрос дважды. Если во второй раз что-то произошло, вы уже знаете, с чего начать понедельник.

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

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

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

Сравнение = NULL не почти верно, а отвечает на другой вопрос. Для проверки на отсутствие есть отдельные операторы, которые сравнением не являются.

Одно значение NULL в списке для NOT IN обнуляет всю выдачу целиком, а не сужает её.

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

Запрос, который отработал, прошёл только проверку грамматики. Число становится верным, когда с вопросом совпали строки, фильтры и знаменатель.

Три логических исхода вместо двух

Начнём с простого случая. В таблице клиентов у одного из них не заполнен телефон, и это прямо видно глазами. Запрос находит ноль строк:

Условие phone = NULL спрашивает: «равно ли это неизвестное значение тому неизвестному значению?» Ответить на такое нельзя, поэтому для каждой строки возвращается неизвестность, включая ту самую строку с пустым телефоном. А отбор оставляет только строки, где условие истинно. Неизвестность не проходит ровно так же, как не прошла бы ложь.

Правило действует единообразно: NULL = NULL тоже не истина, а неизвестность. Отсюда и главный вывод — оператор равенства нельзя «подправить», чтобы он здесь заработал. Он не почти прав, он отвечает на другой вопрос.

В Postgres это проверяется одной строкой. Что вернёт такое выражение?

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

Как ведут себя И, ИЛИ и НЕ

Логические связки тоже работают в трёх значениях, и запомнить стоит два исключения:

То есть ИЛИ всё ещё истинно, если истинна вторая сторона, а И всё ещё ложно, если ложна вторая сторона. Всё остальное с участием неизвестности схлопывается в неизвестность.

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

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

Операторы, которые никогда не возвращают неизвестность

Лечится это выходом из трёхзначной логики. Сначала решите, что NULL означает в вашей предметной области, а потом скажите это явно:

Проверки IS TRUE, IS NOT TRUE, IS FALSE, IS NOT FALSE и IS UNKNOWN никогда не возвращают неизвестность, поэтому строку не потеряют.

Аналог того же для равенства — IS NOT DISTINCT FROM. Обычное равенство спрашивает, известно ли, что значения совпадают. Этот оператор спрашивает, одно ли это значение, обращаясь с отсутствием как с полноценным состоянием. Две неизвестности неразличимы, поэтому предикат истинен.

Где это пригодится:
Соединение по условию равенства отбрасывает строки, где ключ отсутствует с обеих сторон. Если два отсутствующих ключа должны считаться совпадением, замените равенство на IS NOT DISTINCT FROM. То же касается проверок уникальности и условий отбора, где «отсутствует» должно означать «отсутствует», а не «неизвестно».

Ловушка NOT IN, из-за которой пропадает вся выдача

Это самый дорогой из всех эффектов, потому что он не сужает результат, а стирает его целиком. Операторы IN и NOT IN разворачиваются в цепочки сравнений, а NOT IN — в цепочку через И:

Разберём оба исхода. Если значение совпало с одним из перечисленных, срабатывает то самое правило «И спасает ложь справа», и выражение честно ложно. Если не совпало ни с одним, множитель со сравнением с пустым значением делает всё выражение неизвестным.

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

Обычный IN ведёт себя мягче, поскольку разворачивается в цепочку через ИЛИ: совпадение остаётся истиной независимо от того, что ещё есть в списке. В простом условии отбора пустое значение в списке вообще ничего не меняет: несовпавшая строка отсеется что при неизвестности, что при лжи. Разница вылезает там, где результат сравнения используется дальше: под отрицанием, в выражении CASE или в ограничении целостности.

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

Вычистить отсутствующие значения из подзапроса тоже можно, но это помогает, только если вы уверены, что их следует игнорировать. Вариант с NOT EXISTS делает это намерение явным, а не подразумеваемым.

Арифметика: одно значение NULL обнуляет строку

Любая арифметическая операция с участием отсутствующего значения даёт отсутствующее значение. Сложение, умножение, деление, модуль, возведение в степень — результат один.

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

Подставлять значение по умолчанию нужно в той точке, где вам известно правило предметной области, а не механически везде. В разборе Кристофера Уинслетта из Crunchy Data приводится удачная иллюстрация: отсутствующее количество почти всегда означает ноль, отсутствующая ставка налога тоже, а вот отсутствующая цена нулём не является и должна оставаться неизвестной, пока её кто-нибудь не заполнит.

Агрегаты и оконные функции считают не то, что кажется

Здесь отсутствующие значения ведут себя иначе, чем везде: агрегаты их пропускают. Функция COUNT(*) считает строки, а COUNT(колонка) — только непустые значения; SUM, AVG, MIN и MAX пропускают пустые входы.

У товара с двумя незаполненными оценками среднее и сумма пусты, а число строк равно двум. Отсюда практическое правило, которое экономит часы разбирательств с аналитикой: среднее — это сумма, делённая на количество непустых значений, а не на количество строк. Смешивать SUM(x) / COUNT(*) и ожидать совпадения со средним нельзя.

Оговорка про типы тоже важна: если сумма и счётчик целочисленные, деление усечёт дробную часть. Шесть, делённое на два, случайно даст ровно три, а оценки 5, 1 и 2 дадут при целочисленном делении двойку вместо 2,67.

Где ломаются оконные функции

Суммирование и усреднение в окне пропускают отсутствующие значения так же, как при группировке, а ROW_NUMBER считает строку в любом случае. Расхождение начинается у функций, которые смотрят в конкретную позицию окна: LAG, LEAD, FIRST_VALUE, LAST_VALUE и NTH_VALUE.

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

Проверка чужого запроса, включая сгенерированный

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

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

Проверка первая: посчитайте строки до того, как поверите сумме

Задача звучала как «чистая выручка по завершённым заказам». Полученный запрос:

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

Виновато соединение. Два заказа возвращались частями, по две записи на каждый, поэтому одиннадцать строк превращаются в тринадцать, а сумма по заказам считает эти два заказа дважды: 2105 вместо 1605. Лишние 500 — это ровно стоимость задвоенных заказов. Явление называется размножением строк: соединение множит строки всякий раз, когда ключ на другой стороне встречается больше одного раза.

Проверка стоит двух запросов:

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

Проверка вторая: ищите отсутствующие значения в каждом фильтре

Следующая просьба звучала как «та же выручка, но без служебных аккаунтов», и запрос получился такой:

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

Что забрать с собой

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

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

Материалы разбора: почему сравнение с NULL никогда не срабатывает, поведение NULL в вычислениях Postgres и проверка сгенерированного SQL до того, как поверить числу.

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

Если ваш прод стоит на Postgres Pro Enterprise, это тот случай, когда обновляться нужно не по плану, а сейчас: среди закрытых проблем четырнадцать с оценкой CVSS 8,8, и для одиннадцати из них upstream прямо пишет о выполнении произвольного кода, причём часть срабатывает через обычные SQL-функции вроде to_char() или через регулярные выражения. Если вы на ванильном PostgreSQL, те же исправления вышли ещё 13 августа в версиях 18.6, 17.11, 16.15, 15.19 и 14.24, и проверить стоит, что вы их уже накатили.

• «Нулевые» релизы Postgres Pro Enterprise содержат только исправления безопасности и ошибок, без новых функций; новые возможности придут в плановых минорных версиях вида 17.11.1.
• Закрыты 28 CVE и более 110 багов из обновления PostgreSQL от 13 августа 2026 года (18.6, 17.11, 16.15, 15.19, 14.24).
• Самые опасные: 14 CVE с оценкой 8,8, из них 11 на выполнение произвольного кода, включая переполнения буфера в regexp, to_char(), PL/Perl, pg_stat_statements и pg_dump.
• Обновление накопительное, pg_upgrade не нужен: остановить сервер и заменить бинарники; после этого проверить GIN-, btree_gist- и ltree-индексы.
• Компания связывает скорость выпуска с приказом ФСТЭК №117 для госорганов и ГИС: критические уязвимости устранять за 24 часа, высокие за 7 дней.

Что такое «нулевой» релиз

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

«Нулевой» релиз разрывает эту связку. Он собирается на базе предыдущего минорного релиза Postgres Pro Enterprise, в него переносятся только исправления из актуальной версии PostgreSQL, и никаких новых возможностей там нет. Доработки, отложенные ради скорости, выйдут позже в привычных минорных версиях по обычному циклу. Технический директор Postgres Professional Юлия Рыденкова объясняет это так: «Заказчик может установить необходимые исправления сразу, не дожидаясь следующего планового обновления и не внедряя одновременно с этим новые возможности продуктов».

Подход не новый для индустрии: примерно так устроены security-only ветки у дистрибутивов Linux. Для российского рынка СУБД, где заказчики часто сидят на сертифицированных редакциях с долгим циклом обновления, разделение потоков «безопасность» и «функции» снимает главный аргумент против быстрого патчинга.

Какие уязвимости закрыты

Все 28 CVE перечислены в анонсе PostgreSQL от 13 августа. Четырнадцать из них имеют максимальную в этом наборе оценку CVSS 8,8; Postgres Professional выделяет одиннадцать, где по описанию upstream возможно выполнение произвольного кода:

• CVE-2026-14664: переполнение буфера в обработке регулярных выражений.
• CVE-2026-14669: переполнение буфера в функции to_char().
• CVE-2026-14670: переполнение буфера в связанных (tied) объектах PL/Perl.
• CVE-2026-14671: путаница типов в кэше планов contrib/refint.
• CVE-2026-14676: переполнение буфера в pg_stat_statements.
• CVE-2026-14680: путаница типов через аргументы типа internal.
• CVE-2026-15741: SQL-инъекция через аргумент функции EXTRACT() при обратном разборе (deparse) выражений.
• CVE-2026-16238 и CVE-2026-16239: путаница типов в pg_restore_attribute_stats() и в связке CLOSE + DECLARE курсоров.
• CVE-2026-18408: команда psql \unrestrict позволяла суперпользователю сервера-источника pg_dump выполнить произвольный код в клиенте psql при восстановлении дампа.
• CVE-2026-19385: переполнение буфера в pg_dump.

Ещё две проблемы стоят отдельно. CVE-2026-6471 (CVSS 7,2): пользователь с правами на репликацию мог заставить логическое декодирование подгрузить произвольную библиотеку через dlopen. После исправления список разрешённых плагинов вывода ограничен новым параметром output_plugin_libraries, и если у вас работает логическая репликация с нестандартными плагинами, их нужно туда прописать. CVE-2026-6464 (CVSS 8,1) касается psql: при раннем сбое команды COPY FROM STDIN или \copy FROM STDIN строки данных могли быть разобраны как команды psql. Для эксплуатации нужен контроль и над серверной ошибкой, и над данными COPY; вариант COPY FROM с именем файла не затронут.

Ещё три уязвимости с оценкой 8,8 в этот список компания не включила: недоразмерные выделения памяти в tsvector и tsquery (CVE-2026-14662), в 32-битных pltcl и plperl (CVE-2026-14677) и запись по произвольным адресам в fuzzystrmatch (CVE-2026-15742). Остальные пункты списка, от раскрытия существования пользователя через нестандартное число итераций SCRAM (CVE-2026-14672, CVSS 5,3) до чтения за границей буфера в функции ascii() (CVE-2026-18024, CVSS 4,3), имеют оценки от 3,8 до 8,2. Компания отмечает, что несколько уязвимостей, в частности CVE-2026-16239 и CVE-2026-14680, найдены исследователями при участии ИИ-инструментов Claude и Codex Security.

Что делать после обновления

Обновления накопительные: выгружать и загружать базы или запускать pg_upgrade не нужно, достаточно штатно остановить сервер и заменить бинарные файлы. Но после этого Postgres Professional, как и upstream в своём анонсе, просит выполнить несколько проверок, потому что часть исправлений затрагивает индексы:

1. Проверить таблицы с GIN-индексами и выполнить ANALYZE, если значение reltuples выглядит некорректным (исправлена ошибка параллельной сборки GIN).
2. Переиндексировать btree_gist-индексы на столбцах типов float4, float8, bit и bit varying, если они есть.
3. Переиндексировать B-tree-индексы по столбцам ltree, если значения могут содержать больше 14 653 меток.
4. Проверить конфигурацию логического декодирования и добавить доверенные плагины в output_plugin_libraries.

Пользователям ванильного PostgreSQL стоит помнить ещё об одном: ветка 14 перестанет получать исправления 12 ноября 2026 года, а версии 18.4 и 18.5 не выходили вовсе, ветка 18 перескочила с 18.3 сразу на 18.6 из-за регрессии в 18.5.

Почему компания торопится

Postgres Professional прямо связывает формат «нулевых» релизов с регуляторикой. С 1 марта 2026 года действует приказ ФСТЭК России №117 от 11 апреля 2025 года о защите информации в государственных информационных системах и системах госорганов и госучреждений: уязвимости критического уровня нужно устранить или закрыть компенсирующими мерами за 24 часа, высокого уровня за 7 календарных дней, а если уязвимости нет в БДУ ФСТЭК, сведения о ней нужно направить в службу в течение 5 рабочих дней. На коммерческие компании приказ напрямую не распространяется, но именно госзаказчики составляют заметную часть пользователей сертифицированных редакций, и для них ждать плановый релиз вендора с патчем невозможно: сроки считаются с момента выявления.

Второй фактор, который называет компания: ИИ-инструменты резко ускорили поиск дефектов. В качестве примера Postgres Professional ссылается на программу координированного раскрытия уязвимостей Anthropic, в которой модель Claude нашла и передала мейнтейнерам сотни проблем в проектах с открытым кодом; две CVE из сегодняшнего списка тоже найдены с участием ИИ. Чем быстрее находят, тем важнее способность вендора быстро адаптировать и протестировать upstream-патч для своей редакции.

Чего в сообщении нет: точных номеров «нулевых» версий по веткам и ссылок на страницы загрузки. Не сказано и о сроках аналогичных релизов для редакции Postgres Pro Standard. Следующая точка на календаре для всех пользователей PostgreSQL, плановое квартальное обновление upstream в ноябре; будет ли к нему «нулевой» релиз и как быстро, компания не обещала.

Источники: Postgres Professional: новость на Хабре, PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released, PostgreSQL: Security Information

Изображение на обложке: Изображение: Postgres Professional

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

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

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

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

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

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

Представим старый монолит интернет-магазина. Внутри него есть каталог, корзина, заказы, платежи, скидки, личный кабинет и уведомления. Переписать всё сразу — рискованно. Но можно начать с относительно изолированного участка, например с уведомлений.

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

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

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

user_id передается явно, чтобы решение «попал ли пользователь в новый сегмент» было стабильным от запроса к запросу. Иначе один и тот же клиент будет получать разные ответы при обновлении страницы, и поведение системы станет непредсказуемым.

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

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

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

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

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

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

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

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

Этот подход также полезен там, где бизнес продолжает активно развивать продукт. Если фичи нельзя заморозить на полгода, модернизация должна идти параллельно с продуктовой разработкой.

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

Индекс в базе данных — это вспомогательная структура (чаще всего B-дерево; хеш-индексы, GiST, GIN и другие типы применяются в узких специфических сценариях), которая ускоряет выборку строк по заданным колонкам. По аналогии с оглавлением книги: вместо перелистывания всех страниц СУБД сразу переходит к нужной главе. Но если оглавление построено плохо, пользы от него нет — а вот накладные расходы на поддержку остаются.

В этой статье разберём семь самых разрушительных ошибок индексации в production-SaaS: от параноидального создания индексов «на всякий случай» до игнорирования раздутия и особенностей мультитенантных схем. Каждая ошибка — с примерами SQL, метриками и конкретным фиксом.

Индексы — это налог на запись: каждый INSERT, UPDATE и DELETE обновляет все индексы таблицы.

Индекс на колонке с низкой селективностью (boolean, статус) почти бесполезен — используйте частичные (partial) индексы.

В составном индексе порядок колонок критичен: PostgreSQL может использовать (a, b, c) только если условие начинается с a.

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

В мультитенантных системах индекс по tenant_id один часто недостаточен: добавляйте диапазон времени или тип события.

Внешние ключи в PostgreSQL не индексируются автоматически — после каждого FOREIGN KEY создавайте индекс вручную.

Без EXPLAIN ANALYZE индексы создаются вслепую. Проверяйте реальный план выполнения перед деплоем.

Ошибка 1. Индексировать всё подряд «на всякий случай»

Самая распространённая ошибка — не недостаток индексов, а их избыток из тревожности. Особенно часто в неё попадают junior-разработчики: добавляют индекс на каждую колонку, которая встречается в WHERE, «на всякий случай». Кажется ответственным, но на самом деле вредно.

Каждый индекс — это налог на запись. При INSERT, UPDATE и DELETE PostgreSQL (или MySQL) вынуждена обновлять все индексы таблицы. На таблице с 8 индексами каждая запись трогает 8 структур данных. При низкой нагрузке это невидимо, но при 10 000 записей в минуту это становится узким местом.

Аудит неиспользуемых индексов в PostgreSQL:
Запрос к pg_stat_user_indexes покажет, сколько раз каждый индекс применялся с момента сброса статистики. Если idx_scan = 0 — индекс кандидат на удаление.

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

Ошибка 2. Не понимать селективность

Индекс на булеву колонку — почти всегда бесполезен. Селективность измеряет, сколько различных значений содержится относительно общего числа строк. У boolean всего два значения. Если 95% строк имеют is_active = true, планировщик запросов проигнорирует индекс и сделает Seq Scan — и будет прав.

Правило большого пальца: если у колонки меньше 10–20 уникальных значений относительно размера таблицы, простой индекс по ней один не справится. Используйте частичные или составные индексы.

Ошибка 3. Неверный порядок колонок в составном индексе

Составные индексы мощны, но часто неправильно понимаются. PostgreSQL может использовать индекс (a, b, c) для фильтрации по a, a и b, a, b и c. Но не может эффективно использовать его, если запрос фильтрует только по b или c — ведущая колонка пропущена.

Решение: первыми ставьте колонки с equality-условиями, затем — по селективности, и проектируйте индексы вокруг реальных паттернов запросов, а не вокруг схемы таблицы. Также учитывайте ORDER BY и необходимость покрывающего индекса. Перед созданием обязательно запускайте EXPLAIN ANALYZE.

Ошибка 4. Игнорировать раздутие индексов

Индексы деградируют со временем. Многие инженеры воспринимают их как «поставил и забыл», но это заблуждение. В PostgreSQL при обновлении или удалении строки старые записи в индексе устаревают и накапливаются как раздутие (bloat); их физическое удаление происходит при выполнении VACUUM. На высокоизменяемых таблицах (заказы, события, логи, сессии) раздутие накапливается стремительно.

Таблица с 1 млн живых строк может иметь индекс, раздутый до размеров 8 млн записей. Каждый запрос через такой индекс делает в 8 раз больше работы, чем должен.

REINDEX CONCURRENTLY — ключевое слово. Обычный REINDEX блокирует таблицу, а в production-SaaS это прямой путь к инциденту. CONCURRENTLY перестраивает индекс без блокировок, хотя и медленнее.

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

Ошибка 5. Индексы на колонках с малым числом уникальных значений в мультитенантных системах

В мультитенантной архитектуре почти каждый запрос фильтрует по tenant_id. Естественное желание — проиндексировать эту колонку. Но для крупных тенантов индекс по tenant_id вернёт слишком много строк, и планировщик предпочтёт Seq Scan. Для маленьких тенантов отдельный индекс по tenant_id может быть полезен.

На серьёзном масштабе правильное решение — партиционирование таблиц по tenant_id, но это архитектурное решение. Практический первый шаг — составные индексы с временными диапазонами.

Ошибка 6. Не индексировать внешние ключи

В PostgreSQL внешние ключи не индексируются автоматически. При удалении родительской строки СУБД должна проверить все дочерние таблицы на наличие ссылающихся записей — и без индекса на внешнем ключе это Seq Scan по каждой дочерней таблице. На таблице orders с 50 млн строк удаление пользователя вызывает полное сканирование.

Сделайте это командным соглашением: в чек-листе миграций обязательный пункт «после каждого FOREIGN KEY — CREATE INDEX».

Ошибка 7. Не использовать EXPLAIN ANALYZE перед деплоем

Большинство решений об индексах принимаются интуитивно. Интуиция ошибается достаточно часто, чтобы это стало проблемой. EXPLAIN ANALYZE показывает, что именно делает планировщик: какие индексы использует, какие игнорирует, сколько строк реально прочитал против оценки, где тратится время.

На что обращать внимание:
• Seq Scan на большой таблице при выборке малой доли строк — возможно, пропущен индекс или планировщик не может использовать существующий индекс.
• Rows Removed by Filter в десятки тысяч — индекс есть, но неправильные колонки или низкая селективность.
• Buffers: shared hit=0 read=45000 — данные не закэшированы (cold cache), страницы читаются с диска. Для диагностики раздутия смотрите общее число буферов и сравнивайте размер индекса с ожидаемым.
• Высокое actual time — проверьте раздутие, актуальность статистики, количество буферов, дисковую подсистему и наличие блокировок. Запустите ANALYZE tablename, чтобы обновить статистику планировщика.

Чек-лист индексации для SaaS

• У каждой колонки внешнего ключа есть индекс?
• Составные индексы упорядочены по селективности, а не по удобству?
• Булевы и низкокардинальные фильтры используют частичные индексы вместо полных?
• Вы запускали EXPLAIN ANALYZE на 10 самых медленных запросов за неделю?
• Есть процесс поиска и удаления неиспользуемых индексов?
• Высокоизменяемые таблицы регулярно проходят REINDEX CONCURRENTLY?
• Autovacuum настроен под реальный объём записи, а не под значения по умолчанию PostgreSQL?
• В мультитенантных таблицах индексы начинаются с tenant_id и включают диапазон времени?

Выводы

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

База данных, которая быстра на 10 000 строках и быстра на 50 миллионах, — не случайность. Это результат того, что кто-то считал планирование запросов первоклассной инженерной задачей, а не рутинным дополнением.

Проверьте свои самые медленные запросы этой недели — возможно, одна из этих семи ошибок уже сидит в вашей production-базе.

Источник и материалы:
• Database Indexing Mistakes That Kill SaaS Performance at Scale — оригинальная статья OutworkTech
• PostgreSQL Index Types — официальная документация
• REINDEX — документация по перестроению индексов

В нашей системе две базы данных:

- Остатки по счетам - текущий остаток по каждому счёту

- Остатки по клиентам - агрегированный баланс клиента по всем его счетам.

При каждом изменении остатка по счёту нужно обновить Остатки по счетам и уведомить Остатки по клиентам через Kafka. Логика простая. Но в какой-то момент клиент звонит в поддержку: его баланс в приложении не совпадает с реальным. Вы смотрите в обе базы — данные разошлись. Когда именно это произошло — непонятно.

Причина почти всегда одна и та же:

Транзакция закоммичена, событие не ушло. Базы разошлись. Никто не узнал.

Почему очевидные решения не работают

Первая реакция разработчика — обернуть отправку в try-catch и повторить при ошибке:

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

Вторая идея — отправить событие до коммита:

Тоже не работает: если коммит упадёт, Kafka уже получила событие об изменении, которого нет в базе. Данные снова разошлись, но в другую сторону.

Третья идея — двухфазный коммит (2PC). Это протокол, который координирует атомарный коммит сразу в нескольких системах. Звучит как решение, но на практике Kafka его не поддерживает в классическом смысле, а реализации 2PC с брокерами сообщений крайне сложны в эксплуатации и плохо переносят сбои координатора.

Все три пути упираются в одну проблему: **невозможно атомарно закоммитить транзакцию в базе и отправить сообщение в Kafka** — это две разные системы без общего менеджера транзакций.

Принцип решения

Раз нельзя сделать две операции атомарными, нужно свести их к одной. Именно это делает паттерн **Transactional Outbox**.

Вместо того чтобы отправлять событие в Kafka напрямую, мы записываем его в таблицу `outbox` — в той же базе, в той же транзакции, что и изменение остатка. Одна транзакция, одна база, полная атомарность за счёт ACID.

Доставкой события из `outbox` в Kafka занимается отдельный процесс — уже без транзакционных рисков, с возможностью повторных попыток.

Это и есть весь паттерн. Дальше — вопрос реализации.

Два способа реализации

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

Способ 1: Polling Relay

Фоновый воркер периодически опрашивает 'outbox' и отправляет неотправленные события в Kafka.

Структура таблицы outbox:

Бизнес-транзакция:

Relay-процесс:

При нескольких экземплярах ретранслятора важно, чтобы одно событие забирал только один из них. Используем `FOR UPDATE SKIP LOCKED`:

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

Способ 2: CDC через Debezium

CDC (Change Data Capture) — подход, при котором события читаются не опросом таблицы, а напрямую из журнала транзакций базы данных (WAL в PostgreSQL). [Debezium](https://debezium.io/) подключается к PostgreSQL как репликационный слот и стримит каждое изменение в `outbox` в Kafka в реальном времени.

Relay-процесс при этом не нужен вообще.

Бизнес-транзакция остаётся той же — пишем в `accounts` и `outbox` атомарно. Debezium сам следит за WAL и публикует новые записи в Kafka с минимальной задержкой.

Когда выбирать: нужна задержка доставки в миллисекунды, команда готова к Debezium + Kafka Connect в инфраструктуре.

Что выбрать для синхронизации остатков

Для большинства задач с остатками по счетам polling relay достаточен. CDC имеет смысл, если бизнес требует обновления клиентского баланса быстрее чем за секунду.

Получатель: защита от дублей

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

Самый надёжный способ — inbox-таблица с уникальным constraint:

>Почему не `existsById` перед вставкой? При параллельной обработке два консюмера могут одновременно получить `false` и оба начать обработку. Уникальный constraint на уровне БД закрывает эту гонку.

Что сломается при небрежной реализации

Relay внутри API-сервиса. Если ретранслятор живёт в том же процессе, что и API, горизонтальное масштабирование до 10–30 реплик создаёт столько же потоков, опрашивающих `outbox`. База тратит CPU не на запросы, а на управление блокировками. Relay — отдельный деплоймент, который масштабируется по объёму событий, а не по HTTP-трафику.

Таблица outbox незаметно растёт. Без очистки запросы замедляются, индексы раздуваются. Настройте автоматическую очистку:

Отсутствие мониторинга outbox. Outbox — скрытая очередь внутри базы. Если relay начнёт отставать, вы узнаете об этом от клиентов, а не от алертов. Следите за количеством и возрастом необработанных событий — это главные сигналы проблемы.

Итог

Проблема потери событий при синхронизации баз — не баг конкретной реализации. Это фундаментальное ограничение: нельзя атомарно закоммитить транзакцию в базе и отправить сообщение в Kafka.

Transactional Outbox обходит это ограничение, сводя две операции к одной: событие пишется в `outbox` в той же транзакции, что и основные данные. Дальше — дело техники: polling relay, если нужна простота, CDC, если нужна скорость.

Остатки по счетам и клиентам будут согласованы — даже если между сервисами что-то пойдёт не так.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

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

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

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

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

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

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

pgBackRest — основной open-source инструмент резервного копирования и восстановления PostgreSQL последние ~10 лет: parallel backup, асинхронная архивация WAL, шифрование, поддержка S3/Azure/GCS-хранилищ, до десяти одновременно поддерживаемых major-версий Postgres (политика 5 supported + 5 EOL). Текущий стабильный релиз — v2.58.0, выпущен в январе 2026.

• Дата объявления: 27 апреля 2026 года
• Мейнтейнер: David Steele, 13 лет разработки
• Репозиторий помечен archived — release-веток и патчей больше не будет
• Текущий стабильный релиз: v2.58.0 (январь 2026)
• Главные альтернативы: wal-g, Barman
• Автор просит форки выбирать новое имя

Почему закрывают

Прямой повод — продажа компании Crunchy Data, в которой David Steele работал и которая корпоративно спонсировала разработку pgBackRest. После сделки автор искал позицию, которая позволила бы продолжить работу над проектом, и параллельно собирал спонсорство — но обе попытки оказались безуспешны.

pgBackRest 13 лет был моим личным проектом. После продажи Crunchy Data я искал позицию, позволяющую продолжать работу, и пытался собрать спонсорство — но усилий не хватило, чтобы сделать проект жизнеспособным. Как и всем остальным, мне нужно зарабатывать. Лучше сделать жёсткий стоп, чем тянуть проект кое-как.

Что это значит для пользователей

Существующие установки продолжат работать — релиз v2.58.0 не отзывают. Но дальше будет так:

• Security-патчей больше нет. Если в pgBackRest найдут CVE, никто не выпустит фикс — придётся либо мигрировать, либо патчить самим в форке.
• Поддержки следующих major-версий Postgres не будет. v2.58.0 уже поддерживает PG13–18, но когда выйдет PG19 (ожидается осенью 2026), pgBackRest не получит обновлённых WAL-форматов и сломается на новых кластерах.
• Открытые issues (68 на момент архивации) останутся без ответов. Pull-request-ы тоже.
• Документация на pgbackrest.org пока на месте, но судьба сайта после ухода автора неясна.

Альтернативы pgBackRest

wal-g

wal-g — продолжатель WAL-E, создан в Citus Data в 2017 (Daniel Farina + Katie Li). Активная разработка сейчас спонсируется Yandex Cloud, поддерживается распределённой командой и сообществом. Поддерживает PostgreSQL, MySQL/MariaDB, MS SQL Server, MongoDB и Redis (последние два — beta). Бэкап в S3/GCS/Azure/Swift, параллельная обработка, delta-копии. Релизы выходят регулярно.

Barman

Barman — инструмент от EDB (бывший 2ndQuadrant). Делает full и incremental бэкапы, point-in-time recovery, поддерживает streaming-репликацию и WAL-archiving. Сильнее других ориентирован на on-prem-сценарии и enterprise-сетапы. У EDB есть коммерческие подписки на Barman — это снижает риск похожего сценария.

pg_basebackup

pg_basebackup — встроенный инструмент Postgres. Подходит для небольших БД, простых сетапов, разовых снимков. С PG17 умеет page-level incremental backup (через summarize_wal и pg_combinebackup), но без удобной обвязки. Не покроет parallel backup, multi-repo retention и продвинутые retention-полиси.

Что делать прямо сейчас

1. Проверьте текущую версию pgBackRest на серверах: pgbackrest version
2. Подпишитесь на список рассылки pgsql-announce — туда придут уведомления о CVE Postgres, требующих внимания и от backup-tooling.
3. Запланируйте миграцию на wal-g или Barman в течение 6–12 месяцев. До PG19 (релиз ожидается осенью 2026) — окно есть, после — будет жать.
4. Если рассматриваете форк pgBackRest — David Steele явно просит дать форку новое имя. Это не хулиганство, а защита пользователей от путаницы между поддерживаемой и заброшенной кодовой базой.
5. Перед миграцией протестируйте новый инструмент на staging: восстановление до точки, retention-полиси, скорость parallel backup на ваших объёмах. У wal-g и Barman разная философия — на каких-то нагрузках различия в скорости в разы.

Выводы

История pgBackRest — это не «open-source умер», это про то, что donations и star-driven sponsorship не работают как модель устойчивости infrastructure-проектов. 13 лет работы, страница на GitHub Sponsors — и всё равно один человек на длинной дистанции не вытягивает. Backup-инструмент Postgres-уровня требует коммерческого стейкхолдера. У wal-g он есть (Yandex Cloud, исторически Citus Data), у Barman — EDB, у pgBackRest был Crunchy Data, и его не стало. Похожую модель устойчивости open-source проектов мы недавно разбирали на примере расширения honker для SQLite — где спонсорство сразу зашито в распределённую команду.

Для DBA практический вывод простой: ревизия инфры на «один человек = один мейнтейнер = single point of failure» и проверка, кто поддерживает критичные инструменты — продуктовая компания или энтузиаст в свободное время.

Джон Чартер в статье «Things you didn't know about indexes» разбирает не только базовые принципы B-tree, но и три типа индексов, о которых новичкам не рассказывают: функциональные, частичные и покрывающие. Переводим полностью, с примерами на таблице покемонов и объяснением, почему EXPLAIN — ваш лучший друг.

Индексы ускоряют чтение, но замедляют запись. INSERT, UPDATE и DELETE обновляют каждый индекс — восемь индексов на таблице значат восемь дополнительных обновлений.

Композитный индекс (type_1, type_2) работает для запросов на type_1 и на обе колонки вместе, но не для запросов только на type_2. Порядок колонок важен.

Функция над индексированной колонкой убивает индекс. WHERE lower(name) = 'pikachu' не использует индекс на name — нужен функциональный индекс на lower(name).

Частичный индекс с WHERE покрывает только нужные строки. Для soft-delete или редких флагов экономит место и ускоряет запись.

Покрывающий индекс с INCLUDE отвечает на запрос без похода в таблицу — в EXPLAIN это Index Only Scan.

Не угадывайте — используйте EXPLAIN ANALYZE. Он показывает реальный план запроса и реальное время выполнения.

Начнём с того, что вы, вероятно, уже знаете

Индекс в базе данных похож на алфавитный указатель в конце учебника. Хотите найти страницы про фосфор? Идёте в конец, находите тему и номера страниц рядом с ней:

Представим таблицу покемонов:

Без индекса поиск Пикачу означает, что база прочитает каждую строку, проверяя колонку name. На четырёх строках это мгновенно. На десяти миллионах — уже проблема. Такое чтение называется full table scan, и оно не медленное само по себе: современные базы легко прошивают миллионы строк в секунду. Проблема в линейной сложности — удваиваете число строк, удваиваете время. Индексный поиск этой разницы почти не замечает.

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

Данные отсортированы, поэтому база может сделать бинарный поиск по имени и найти нужную строку, а не сканировать всю таблицу. Под капотом Postgres хранит это как B-tree (сбалансированное дерево), но идея такая же, как в учебнике: отсортированные данные, по которым можно быстро искать.

Итак, индексируем всё подряд, верно? Не так быстро.

Цена индексации

Как бы ни хотелось проиндексировать всё, у индексов есть компромиссы. Главное правило:

Чтение ускоряется, запись замедляется.

С новым блестящим индексом каждый INSERT, UPDATE и DELETE должен обновить и индекс тоже. Когда мы добавляем нового покемона, база находит правильное место в отсортированном индексе имён и вставляет его туда. А индексов может быть несколько — умножайте эту работу на каждый из них.

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

И не забываем про планировщик (query planner) — компонент, который перед каждым запросом оценивает варианты доступа к данным и выбирает самый дешёвый. Чем больше индексов, тем больше вариантов он взвешивает, так что время планирования растёт и на быстрых выборках может даже превысить время выполнения.

Отдельный риск на проде. Обычный CREATE INDEX блокирует таблицу на запись до конца построения. На таблице в десятки миллионов строк это минуты недоступности. В production используйте CREATE INDEX CONCURRENTLY — он строит индекс без эксклюзивной блокировки, ценой чуть большего времени и того, что операция может быть прервана и оставить индекс в состоянии INVALID (который надо пересобрать).

Почему ваш индекс не работает

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

Композитные индексы и порядок колонок

Возвращаясь к таблице покемонов: вы могли решить, что хороший индекс — это индекс на type_1 и type_2. «Покажи всех покемонов типа Water и Flying» — вполне разумный запрос.

Этот индекс определённо поможет запросам вроде:

Но вот этому — уже нет:

Удивлены? Когда вы создаёте композитный индекс (type_1, type_2), вы просите базу построить структуру примерно такого вида:

Сначала сортировка по type_1, затем по type_2 внутри каждой группы. Для запросов по type_1 индекс отличный, для запросов по type_1 AND type_2 — ещё лучше, но для запросов только по type_2 он не будет использован так, как вы надеетесь. Посмотрите на Flying: он разбросан под Bug, Electric, Fire и Water — базе некуда прыгнуть.

Задайте себе вопрос: какие запросы будут частыми? Если по type_2 вы будете искать так же часто, как по type_1, создайте второй индекс на type_2.

Функции убивают индекс

Поиск без учёта регистра — частая фича. Пользователям всё равно, пишут ли они «Pikachu», «pikachu» или «PiKaChU» — они просто хотят результат. Поэтому можно написать так:

Я бы не обратил на такой запрос особого внимания. Выглядит нормально. У нас есть индекс на name, запрос должен летать. Но, конечно, он не летает.

Почему? Индекс на name, а не на lower(name). Для базы это две совершенно разные вещи. Ваш индекс — это отсортированный список значений вида Bulbasaur, Charmander, Squirtle, Pikachu, а не bulbasaur, charmander, squirtle, pikachu. Так что когда вы просите строки, где lower(name) = 'pikachu', у базы нет отсортированной структуры для этого — и она откатывается к сканированию всей таблицы, приводя каждое имя к нижнему регистру по ходу дела.

Это касается любой функции, оборачивающей колонку. Если база не видит индексированную колонку слева от сравнения, индекс выбывает из игры.

И вот настоящие грабли: неявные преобразования тоже считаются. Классический пример — колонка user_id типа bigint сравнивается со строкой (WHERE user_id = '42') или timestamp сравнивается со строковой датой. Postgres тихо добавит приведение типа — и индекс работать перестанет с тем же эффектом, что и явная обёртка функцией.

Как обойти это? К счастью, можно построить индекс на выражении. Индекс на lower(name) абсолютно валиден, и запрос выше будет использовать его без проблем. К этому мы ещё вернёмся.

Как избежать этих ловушек

Короткий ответ: не гадайте. Измеряйте. Как? Спросите базу.

В Postgres есть инструмент EXPLAIN, который показывает, как именно база собирается выполнить запрос. Поставьте его перед любым SELECT — и получите отчёт:

Index Scan — это то, что вы хотите видеть. Значит, база использует индекс. Сравните с проблемным запросом:

Seq Scan значит, что читается каждая строка. Никаких индексов.

Если хотите реальные тайминги вместо оценок планировщика, используйте EXPLAIN ANALYZE. Он действительно запускает запрос и сообщает, что произошло. Попробуйте на запросе, который, как вам кажется, вы понимаете — результаты часто удивляют. А если Postgres тормозит не из-за индексов — у нас есть 12 шагов диагностики, от pg_stat_activity до auto_explain.

Чего вам не рассказывали

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

Сначала оговоримся про типы индексов в целом. Всё, о чём мы пока говорили, — это B-tree, тип по умолчанию в Postgres. Но для нестандартных задач есть другие: GIN для jsonb и полнотекстового поиска, GiST для геоданных и диапазонов, BRIN для огромных таблиц с физически упорядоченными данными (логи, временные ряды), Hash для точного равенства. Ниже речь идёт именно о B-tree — но идеи функциональных, частичных и покрывающих индексов применимы и к другим типам.

Функциональные индексы

Мы затрагивали это в разделе про функции. Проблемный запрос был такой:

Индекс на name не помогает, потому что база ищет строки с lower(name) = ..., а отсортированной структуры для lower(name) у неё нет. Исправление — дать ей такую структуру:

Это функциональный индекс (его ещё называют индексом на выражении). Вместо того, чтобы индексировать сырую колонку, вы индексируете результат выражения, применённого к ней. Конечно, это не ограничивается lower(). Можно индексировать любое детерминированное выражение:

Годится любая функция с меткой IMMUTABLE — в Postgres это означает, что она возвращает одинаковый результат для одинаковых аргументов при любых условиях (в отличие от STABLE, которая детерминирована только в рамках одной транзакции, и VOLATILE).

Но осторожно. Если тянуться к функциональному индексу при первом же случае, это часто плохой запах. Если мы так часто ищем по имени в нижнем регистре, почему мы вообще не храним имя в нижнем регистре? Альтернативы: отдельная колонка name_lower, которую заполняете на вставке; тип citext (case-insensitive text) из одноимённого расширения; или COLLATE с регистронезависимой коллацией. Функциональный индекс — когда изменить хранение уже нельзя.

Частичные индексы

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

В нашей таблице покемонов есть колонка is_legendary. На момент написания существует около 1000 видов покемонов, из которых легендарными считаются всего 80 — меньше 10%.

Представьте приложение с опцией «показать всех легендарных». Изначально так и хочется создать составной индекс:

Это работает, но это перебор. Индекс теперь содержит запись для каждого покемона, а подавляющее большинство — не легендарные. Мы будем платить за хранение и запись 1000 строк, чтобы обслуживать запросы, которым интересны только 80. Более того, поскольку is_legendary — булево, получается структура, где сначала идёт разделение на False и True, и первая группа — это 920 записей мёртвого груза, оплачивающих свою долю каждой записи в таблицу ради запросов, которые их игнорируют.

Частичный индекс покрывает только строки, которые подходят под условие:

Теперь в индексе 80 записей вместо 1000. Он меньше, быстрее в запросах; а запросы вида WHERE is_legendary = true используют его без вопросов. Запросы, которые не подходят под условие (WHERE is_legendary = false), откатываются к full table scan — что вам и нужно. Эти запросы и так матчат почти каждую строку, так что индекс им не особо помог бы.

Любая колонка, где вы почти всегда запрашиваете одно значение, — кандидат на частичный индекс. Представьте индекс на колонке email в таблице users, где у вас реализован soft-delete:

Soft-deleted строки почти никогда не запрашиваются, но без фильтра всё равно раздували бы ваши индексы.

Покрывающие индексы

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

А что, если я скажу, что так делать необязательно?

Если в индексе уже есть все колонки, которые нужны запросу, база может ответить на запрос из одного только индекса. Это покрывающий индекс. В EXPLAIN вы увидите его как Index Only Scan — три самых сладких слова из возможного вывода EXPLAIN.

Одна важная оговорка. Даже при Index Only Scan Postgres всё же заглядывает в visibility map — битовую карту, которая для каждой страницы таблицы отмечает, видимы ли все её строки всем активным транзакциям. Если страница «грязная» (были недавние UPDATE/DELETE), Postgres всё равно пойдёт в heap за проверкой MVCC. Так что на интенсивно пишущих таблицах регулярный VACUUM (автовакуум обычно справляется) критичен для того, чтобы Index Only Scan оставался «онли».

Вот запрос:

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

Покрывающие индексы можно строить и специально. Postgres позволяет добавить к индексу дополнительные колонки через INCLUDE:

Теперь на такой запрос можно ответить прямо из индекса:

Почему не положить base_attack прямо в индексируемые колонки? Потому что база считает индексируемые колонки тем, по чему нужно сортировать и искать. Если добавить base_attack в ключевые колонки индекса, вы скажете базе сортировать индекс сначала по name, потом по base_attack — дополнительная работа, которая не нужна, если вы ищете только по name. INCLUDE говорит: «тащи эту колонку с собой, но не морочься сортировкой».

Правка автора: когда на самом деле нужен INCLUDE

В комментариях на Reddit автор получил поправку от u/therealgaxbo и обновил статью. Скорость записи — не главная причина использовать INCLUDE для покрывающих индексов: в обоих случаях (колонка в ключе или в INCLUDE) индекс обновляется при каждой записи, разница по нагрузке скромная.

Реальные причины использовать INCLUDE:

Можно включать колонки, у которых типы данных не имеют подходящего operator class для типа индекса (operator class — набор функций сравнения, по которым Postgres строит индекс для конкретного типа; для некоторых типов он просто не определён). Например, колонку box (геометрический прямоугольник) нельзя добавить в B-tree индекс как ключевую — нет оператора «меньше/больше». А через INCLUDE можно.

Можно добавить колонки в уникальный индекс без изменения его семантики уникальности:

Это обеспечивает уникальность только по email, но при этом покрывает запросы, которым нужен user_id.

Выводы

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

Хотите глубже? Сайт Use The Index, Luke научит вас всему, что только можно знать про индексы в разных СУБД. А если вы только начинаете с Postgres — загляните в наши основы PostgreSQL: от установки до первых запросов.

И не забудьте запустить EXPLAIN ANALYZE хотя бы на одном запросе сегодня — результаты могут вас удивить.

Источник: jon.chrt.dev — Things you didn't know about indexes

Сальваторе Дипьетро (Salvatore Dipietro) из AWS сообщил: на Linux 7.0 с планировщиком PREEMPT_LAZY throughput PostgreSQL упал до 0,51x по сравнению с Linux 6.x. То есть база данных стала работать почти вдвое медленнее — и виновата одна строка в ядре.

• Linux 7.0 убрал режим PREEMPT_NONE — остались только Full и Lazy preemption
• Throughput PostgreSQL на Linux 7.0 упал до 0,51x (50 751 tps против 98 565 tps на Linux 6.x)
• Причина: планировщик прерывает поток, держащий spinlock, — 55% CPU уходит на spinning в ожидании
• Revert-патч восстанавливает производительность до 1,94x
• Linux 7.0 stable выйдет примерно через 2 недели; Ubuntu 26.04 LTS будет на нём

Как обнаружили регрессию

Дипьетро тестировал на EC2 m8g.24xlarge с 96-vCPU процессором Graviton4. Стенд: PostgreSQL 17, утилита pgbench, 1024 клиента, 96 потоков, длительность теста — 1200 секунд. Это типичная нагрузка высоконагруженного OLTP-сервиса.

На Linux 6.x результат составил 98 565 tps. На Linux 7.0 с PREEMPT_LAZY — 50 751 tps, то есть падение до 0,51x. После применения revert-патча производительность выросла до 1,94x относительно Linux 6.x — и достигла 98 565 tps.

Почему ядро изменили и при чём здесь spinlocks

Виновен коммит 7dadeaa6e851 за авторством Питера Зийлстры (Peter Zijlstra) из Intel. В Linux 7.0 убрали режим PREEMPT_NONE: теперь доступны только Full и Lazy preemption. По умолчанию включён PREEMPT_LAZY.

Проблема в том, как PostgreSQL реализует spinlocks. Функция s_lock() в StrategyGetBuffer/GetVictimBuffer крутится в ожидании блокировки. При PREEMPT_LAZY планировщик может вытеснить поток прямо в тот момент, когда он держит spinlock. Все остальные потоки, ожидающие этот замок, начинают активно спиниться — и по замерам 55% CPU уходит именно на это бесполезное ожидание. Затронуты все основные архитектуры: arm64, x86, powerpc, riscv, s390, loongarch.

PREEMPT_NONE означает, что задача будет выполняться до явного вызова schedule() или возврата из системного вызова/прерывания. Это исторически использовалось для серверных нагрузок с активным ожиданием, но мы убираем этот режим — он маскирует проблемы с блокировками вместо того, чтобы их решать.

Патовая ситуация: кто должен чинить?

Разработчики ядра считают, что проблема на стороне PostgreSQL: база данных должна использовать механизм rseq (Restartable Sequences) — расширение Linux, позволяющее коду пространства пользователя эффективно работать с критическими секциями без spinlock-спиннинга.

Правильное решение — использовать rseq time slice extension. Spinlock-спиннинг в пространстве пользователя изначально является проблемным паттерном в вытесняющей многозадачной среде.

Но PostgreSQL rseq не поддерживает, и никаких сроков интеграции нет. Это классический тупик: ядро меняет поведение, опираясь на «правильную» архитектуру, а прикладное ПО годами использует привычные примитивы. В итоге пострадают администраторы баз данных, которые просто обновят ядро.

Что делать администраторам PostgreSQL

До тех пор, пока проблема не решена на уровне ядра или PostgreSQL, администраторам баз данных стоит учитывать следующее:

• Не обновляться на Linux 7.0 в production до появления официального патча или workaround
• Отслеживать параметр preemption model ядра при обновлении дистрибутива
• Ubuntu 26.04 LTS, выходящая примерно в конце апреля 2026, будет использовать Linux 7.0 — проверить совместимость заранее
• При необходимости использовать кастомное ядро с revert-патчем коммита 7dadeaa6e851
• Следить за обновлениями в PostgreSQL hackers mailing list и linux-kernel mailing list

Регрессия производительности PostgreSQL на Linux 7.0 — наглядный пример того, как изменение в ядре может затронуть критическую инфраструктуру. До появления официального решения (патч ядра или поддержка rseq в PostgreSQL) администраторам баз данных следует воздержаться от обновления ядра в production-окружениях. Отслеживать развитие ситуации можно на Phoronix.

• SQLCommenter — формат тегов в SQL-комментариях, по которым Traffic Control различает запросы
• Изоляция микросервисов через Postgres-роли и application_name
• Автоматическая маркировка запросов по HTTP-роутам через middleware
• Контроль новых деплоев и фича-флагов через теги feature
• Tier-based лимиты для мультитенантных SaaS-приложений
• Обработка ошибки SQLSTATE 53000 при блокировке запроса

Перевод статьи Patterns for Postgres Traffic Control Джоша Брауна из блога PlanetScale.

Настройка: SQLCommenter и передача тегов через контекст

Большинство паттернов опираются на пользовательские теги, прикреплённые к запросам. Traffic Control читает их в формате SQLCommenter — это SQL-комментарий с URL-кодированными парами ключ=значение, добавляемый в конец запроса:

Эти теги затем доступны для правил Traffic Control. Вот минимальный хелпер на Go, который добавляет теги в этом формате:

Если вы используете pgx с включённым PrepareThreshold, комментарий SQLCommenter станет частью ключа кэша prepared statement. Это может привести к разрастанию кэша планов. Решение — отключить PrepareThreshold для подключений с тегированием или использовать SimpleProtocol.

Примеры кода рассчитаны на Go 1.22+. В частности, r.Pattern (поле http.Request) и range по целому числу (for attempt := range maxRetries) появились именно в этой версии.

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

С этими двумя хелперами паттерны ниже просто устанавливают ключи и значения в контексте. Тегирование происходит автоматически при выполнении запроса.

Изоляция сервисов через Postgres-роли

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

Бюджет на username='pscale_api_123abc' изолирует весь трафик от этой роли. Это также помогает при инцидентах — можно мгновенно ограничить долю ресурсов сервиса без передеплоя.

Имя пользователя — это внутреннее Postgres-имя роли, а не имя роли в дашборде. Также можно целиться в кастомные роли, созданные через CREATE ROLE, если ваши микросервисы строго разделяют права на таблицы.

Также можно использовать application_name, добавив его к строке подключения:

Маркировка запросов по HTTP-роутам

Когда вы запускаете монолит или крупный API-сервис, проблема обычно не в целом сервисе — а в конкретных роутах. Эндпоинт /api/export, генерирующий CSV-отчёты, не должен убивать /api/checkout.

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

Оберните вызовы к базе данных, чтобы они автоматически подхватывали теги:

Теперь каждый запрос несёт информацию о роуте, из которого пришёл. Можно создать бюджет Traffic Control для route='/api-export' и задать ему консервативный лимит CPU.

Это также упрощает управление инцидентами. Если вы видите всплеск и не знаете, какой роут виноват — график нарушений в Traffic Control покажет, какой именно тег route достигает лимитов.

Фича-флаги и новые деплои

Выкатка новой фичи в production всегда несёт риск. Может, новый паттерн запросов нормально работает под тестовой нагрузкой, но становится дорогим на масштабе. Traffic Control позволяет ограничить радиус поражения до того, как ситуация превратится в инцидент.

Простейшая версия устанавливает тег из переменной окружения при старте:

Установите DEPLOYMENT_TAG=new_checkout_v2 при раскатке новых подов и оставьте переменную пустой на старых. Traffic Control может иметь бюджет на feature='new_checkout_v2' в режиме Warn с первого дня — так вы увидите, как новый код себя ведёт, прежде чем он вызовет проблемы.

Для фича-флагов, управляемых в рантайме, подход тот же, но определяется результатом проверки флага:

Tier-based лимиты для мультитенантных приложений

В SaaS-приложении пользователи бесплатного тарифа не должны деградировать работу enterprise-клиентов. Traffic Control позволяет обеспечить это на уровне базы данных, а не только на уровне приложения.

Инжектируйте тариф пользователя в SQL-теги сразу после аутентификации:

В middleware аутентификации:

Теперь создайте два бюджета Traffic Control:

• tier='free' — консервативные лимиты на долю сервера и максимальное число параллельных запросов
• tier='pro' — умеренные лимиты

Enterprise-трафик оставьте без бюджета или задайте высокий потолок. Когда пользователь бесплатного тарифа запускает тяжёлый дашборд или триггерит медленный запрос — бюджет сбросит этот трафик до того, как он затронет enterprise-нагрузки.

Паттерны можно комбинировать. Бюджет tier='free' AND route='api-export' будет строже, чем бюджет только на tier='free'. Enterprise-экспорты получат больше ресурсов, чем бесплатные.

Фоновые задачи и скрипты

Фоновые задачи — частая причина инцидентов с базой данных. Миграция, ночная синхронизация или одноразовый бэкфилл данных могут случайно насытить БД, если выполняются быстрее ожидаемого. Traffic Control — чистый способ задать потолок ресурсов без настройки таймаутов на уровне каждого запроса.

Для долгоживущих фоновых воркеров используйте выделенный пул подключений с отдельным application_name:

Функция newJobDB принимает DSN базы и устанавливает application_name в background-jobs перед подключением. Максимум подключений ограничен четырьмя, чтобы фоновая задача не занимала больше воркеров, чем положено.

Установка application_name на уровне строки подключения в коде гарантирует, что имя всегда задано для этого сервиса — независимо от конкретного запроса или переменных окружения. Это можно комбинировать с SQL-комментариями для ещё более гранулярного контроля.

Для одноразовых скриптов и миграций — аналогичный подход. Здесь идентичность скрипта кодируется прямо в строке подключения:

Создайте бюджет Traffic Control для application_name='background-jobs' в режиме Warn. Понаблюдайте, сколько ресурсов базы обычно потребляет фоновая работа. Затем переключите на Enforce, чтобы ограничить её на уровне, при котором она не сможет вытеснить интерактивный трафик.

Обработка заблокированных запросов

Когда Traffic Control в режиме Enforce и запрос превышает бюджет, Postgres возвращает SQLSTATE 53000 с сообщением, начинающимся с [PGINSIGHTS] Traffic Control:. Приложение должно обрабатывать это без падения.

С pgx/v5:

Правильная реакция зависит от роли запроса в приложении. Для некритичных нагрузок — аналитики, отчётов — возвращайте 503 или закэшированный результат:

Для критичных путей можно реализовать короткий retry с экспоненциальным backoff:

Наблюдение за Warn-режимом

Прежде чем переключить бюджет в Enforce, запустите его в режиме Warn. В этом режиме запросы выполняются успешно, но драйвер получает Postgres-notice. С pgx/v5 можно логировать их, чтобы понять, что именно будет заблокировано:

Соберите логи за несколько часов репрезентативного трафика. Паттерн срабатываний подскажет, нужно ли корректировать лимиты.

Собираем всё вместе

Паттерны компонуются. В реальном приложении можно наслоить несколько из них:

Traffic Control видит всё это как комбинацию тегов. Бюджет на tier='free' покрывает весь free-трафик независимо от роута. Бюджет на route='api-export' AND tier='free' — конкретную комбинацию. Несколько совпадающих бюджетов применяются одновременно, и запрос должен удовлетворять каждому из них.

Начните в режиме Warn, понаблюдайте, какие бюджеты срабатывают при нормальной нагрузке, ужесточайте лимиты, пока не будут триггериться только патологические случаи — затем переключите на Enforce.

Выводы

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

Полный текст оригинальной статьи — в блоге PlanetScale.

Автор блога Database Doctor провёл серию бенчмарков на DuckDB и PostgreSQL (подробнее о нём — в нашем гайде по PostgreSQL), сравнив классическую размерную модель (dimensional model) с подходом «One Big Table». Результаты оказались неожиданными для многих — JOIN не просто «не дорогой», он зачастую быстрее плоской таблицы.

— JOIN в колоночных СУБД (DuckDB) обходится дешевле, чем сканирование широкой OBT-таблицы, уже начиная с 4–6 колонок

— Стоимость сканирования OBT растёт нелинейно (примерно O(n log n)) с увеличением числа колонок

— В строковых хранилищах (PostgreSQL) JOIN тоже выигрывает на большинстве сценариев

— Ральф Кимбалл описал эти закономерности ещё в 1996 году в своей классической книге о размерном моделировании

— Даже при «бесконечном I/O» денормализация не экономит CPU — она его тратит

Постановка эксперимента

Рассмотрим два конкурирующих подхода к моделированию данных:

• Размерная модель (dimensional model) — атрибуты продуктов хранятся в отдельной таблице product, и мы делаем JOIN с таблицей sales каждый раз при чтении
• One Big Table (OBT) — все атрибуты продуктов заранее «вклеены» в таблицу sales_obt, и мы читаем данные через SELECT без JOIN

Очевидно, что вторую таблицу дороже строить в ETL-пайплайне. Но какая из них потребляет меньше CPU при чтении?

Размерная модель

Схема данных:

Здесь c01 ... c20 — строковые колонки с атрибутами продуктов. Кардинальности:

• product — 100 000 строк; каждая из колонок c01–c20 содержит ~100 уникальных значений (MD5-хеши)
• sales — 1 миллиард строк со случайным v и равномерно распределённым id_product

Эта модель, где сущность (product) хранится отдельно от фактов (sales), называется размерной моделью (dimensional model). Подробнее о ней — в конце статьи.

Генерация тестовых данных

Сначала создаём seed-таблицу — универсальный способ генерации последовательности чисел, который работает практически на всех SQL-платформах:

Примечание: да, можно было бы использовать INSERT ... VALUES с несколькими кортежами, но не каждая аналитическая БД поддерживает этот синтаксис. Зато UNION ALL работает, кажется, вообще везде.

С помощью seed-таблицы генерируем миллиард строк для sales:

Таблицу product заполняем MD5-хешами для получения строковых значений с контролируемой кардинальностью:

Примечание: да, можно было бы взять ровно 100 различных значений вместо ~101 для c01–c20, но с приведённым выше кодом проще.

Модель «One Big Table»

На другой стороне ринга — заранее объединённая широкая таблица:

Гипотеза: JOIN медленнее, чем плоская таблица

Итак, вопрос: что быстрее?

Размерная модель с JOIN:

Или OBT без JOIN:

Если «JOIN — это дорого», то размерная модель должна быть медленнее. Мы также должны увидеть более высокое потребление CPU.

Чтобы быть максимально нечестным по отношению к размерной модели, автор запускает тесты на системе, где вся база помещается в оперативную память. Так мы моделируем «бесконечный I/O» и не платим за дисковые операции.

Результаты DuckDB

Тестовая машина: ноутбук с 14 ядрами, 32 ГБ RAM, SSD на 3 ГБ/с. Размер базы — 45 ГБ, из которых sales_obt занимает ~40 ГБ. DuckDB отлично утилизирует ядра: CPU загружен на 100% во время выполнения запросов.

Для тестов автор использовал серию запросов с нарастающим числом колонок:

Примечание: DuckDB использует написание EXPLAIN ANALYZE (а не ANALYSE). В оригинале автор шутит, что DuckDB «правильно» использует британское написание — но на самом деле в DuckDB работает американский вариант.

Базовый замер (measurement 0) — просто чтение v: мы платим за JOIN, но не запрашиваем колонки из product. Читатели, которых интересует эта крайняя ситуация и способы оптимизации, могут изучить тему join elimination в планировщиках запросов. Каждый запрос выполняется трижды, берётся лучшее время.

Время выполнения (wall clock)

Выводы из графика:

• При запросе 1–2 колонок OBT незначительно быстрее
• С ростом числа колонок стоимость OBT взлетает — до 15 секунд при 20 колонках
• JOIN остаётся практически константным по времени (~1 секунда) независимо от числа колонок
• Рост OBT напоминает O(n log n) — нелинейная зависимость

Потребление CPU

DuckDB позволяет замерить CPU-время по каждому оператору в запросе:

Та же закономерность: OBT при 20 колонках потребляет ~200 секунд CPU, тогда как размерная модель — всего ~15 секунд (scan + join). Разница — на порядок.

Почему JOIN быстрее при масштабировании?

Казалось бы, мы читаем каждую строку. Почему не быстрее просто отдать её из плоской таблицы?

Ответ кроется в том, как работают колоночные хранилища (DuckDB, Parquet и другие):

1. Декомпрессия колонок. Сжатые строки хранятся в словаре (dictionary encoding). Чтобы получить данные, движок «соединяет» указатели в сегментах сжатия со словарём. Это по сути тоже своего рода JOIN — но уже внутри Storage Engine. В размерной модели строки уже «материализованы» в таблице product, и эта «декомпрессия» фактически заранее выполнена
2. Сборка строк из колонок. В колоночном формате данные каждой колонки хранятся отдельно. Чтобы собрать строку, нужно пройти по метаданным, найти местоположение каждой колонки и скопировать данные в финальный результат. Каждая колонка — это отдельная аллокация (и деаллокация) памяти. Именно этот механизм, вероятно, и даёт нелинейный рост стоимости сканирования широкой OBT-таблицы

А что насчёт строковых хранилищ?

Не все базы данных используют колоночное сжатие. Строковые хранилища (row stores) хранят данные в формате строк (аналогично AVRO в мире Data Lake).

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

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

Гипотеза автора

В пользу OBT в строковом хранилище:

• Данные можно отдать напрямую, без «сборки» строк из колонок
• Не нужна «неявная декомпрессия» сжатых строк
• JOIN на строковых форматах медленнее, чем на колоночных — нельзя векторизовать хеширование

В пользу JOIN:

• Если нужна часть колонок, проекция (отбрасывание ненужных) стоит CPU — это неявный memcpy
• Больший объём данных при сканировании — больше работы с буферами
• У JOIN лучше кеш-локальность для строк — меньше TLB-промахов

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

Тест на PostgreSQL 17

Для теста автор выбрал PostgreSQL 17 — классическое строковое хранилище. Датасет уменьшен до 1% (10 млн строк в sales, 10 000 строк в product), но и так sales_obt занимает 7 ГБ.

Чтобы убрать стоимость сериализации результата для клиента, вместо SELECT * используется:

Примечание: PostgreSQL сериализует результат в клиентский формат даже при EXPLAIN ANALYZE. Это дополнительная работа, которой лишены системы, использующие Arrow-буферы, — там промежуточная сериализация не нужна.

Чтобы убедиться, что PostgreSQL не «хитрит» с NULL-проверкой в COUNT, автор проверил план выполнения. Видно, что агрегат действительно работает со строкой, ширина которой пропорциональна числу входных колонок:

Выводы:

• Как и предполагалось, стоимость «проекции» (отбрасывания ненужных колонок) доминирует при малом числе колонок — OBT проигрывает
• Вопреки ожиданиям, даже в базовом случае (0 колонок из JOIN) размерная модель оказывается быстрее
• Красивая линейная зависимость: строковое хранилище масштабируется предсказуемо в обоих случаях
• JOIN выигрывает или проигрывает OBT с минимальной разницей — но тренд в пользу JOIN

Глубокое погружение: что именно тормозит PostgreSQL?

С помощью EXPLAIN (ANALYZE, BUFFERS) автор убедился, что запрос работает полностью в памяти:

shared hit=909120 означает, что все буферы были прочитаны из памяти (shared buffers), без обращения к диску. PostgreSQL форкает процесс на каждое соединение, поэтому профилировать конкретный запрос можно через SELECT pg_backend_pid().

Автор использовал Windows Performance Recorder для профилирования PostgreSQL на 16-колоночном запросе:

Два самых горячих вызова:

1. tts_buffer_heap_getsomeattrs (файл execTuples.c) — по сути, неоптимальный memcpy. Эта функция копирует данные из буферного пула в представление кортежа. Именно та «проекция», которую автор предсказывал — но реализованная неэффективно
2. ExecInterpExpr (файл execExprInterp.c) — интерпретатор выражений. Современные БД используют векторизованное или компилированное выполнение; PostgreSQL по умолчанию интерпретирует через гигантский switch-блок (JIT-компиляция через LLVM доступна с PG 11, но не используется на дефолтных настройках для дешёвых запросов). Основной вызывающий — ExecAgg: подсчёт COUNT обходится почти так же дорого, как само чтение данных

Важная оговорка: PostgreSQL — не идеальный представитель строковых хранилищ. Базы данных с компилируемыми запросами могут быть значительно быстрее при «сыром сканировании». Тем не менее, строковые хранилища, похоже, почти всегда выигрывают от использования JOIN — если только вы не планируете выбирать практически все колонки из OBT в каждом запросе. Даже денормализация одной колонки ради экономии CPU может оказаться ошибочной.

Как автор собирал PostgreSQL с отладочными символами

Для профилирования PostgreSQL нужны debug-символы. Ни пакет Chocolatey, ни установщик EnterpriseDB их не включают — пришлось собирать из исходников на Windows.

Необходимые пакеты:

Файл msvc.ini в корне репозитория PostgreSQL:

Сборка:

Размерная модель: уроки прошлого

Всё, что мы наблюдаем, не ново. Ещё в 1996 году Ральф Кимбалл опубликовал книгу «The Data Warehouse Toolkit», которая до сих пор переиздаётся и считается классикой.

Кимбалл аргументировал:

• Большие аналитические таблицы (факты) должны содержать только метрики (то, что агрегируется) и целочисленные ключи измерений (то, по чему делается JOIN)
• Все атрибуты сущностей хранятся в отдельных таблицах измерений (dimension tables), к которым присоединяются через foreign key
• Колонки с высокой кардинальностью и единственным значением лучше хранить прямо в таблице фактов — «вырожденные измерения» (degenerate dimensions). Это идеально соответствует нашему наблюдению: чтение одной колонки через JOIN действительно немного медленнее

Кимбалл также рекомендовал объединять связанные таблицы внутри самого измерения (делая таблицу измерения шире) — но только для измерений, не для фактов. И делал он это не ради производительности, а для упрощения работы оптимизатора запросов.

Итоги

Главный вывод:

«JOIN — НЕ дорогая операция по сравнению с альтернативами»

Что мы выяснили:

• Даже при чтении всех строк JOIN зачастую дешевле, чем сканирование One Big Table
• В колоночных хранилищах (DuckDB) преимущество JOIN проявляется начиная с 4–6 колонок и растёт нелинейно
• В строковых хранилищах (PostgreSQL) JOIN тоже выигрывает на большинстве сценариев
• «Жертвовать диском ради экономии CPU на JOIN» — это миф, который противоречит измерениям
• Размерное моделирование (Кимбалл, 1996) — не устаревшая методология, а эффективный инженерный подход

Важно помнить: мы тестировали JOIN большой таблицы (1 млрд строк) с маленькой (100 000 строк). Что произойдёт при JOIN двух больших таблиц — вопрос для отдельного исследования.

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

Перевод и адаптация статьи «Joins are NOT Expensive!» из блога Database Doctor. Если вы хотите глубже разобраться в SQL — рекомендуем нашу шпаргалку по SQL.

SQL (Structured Query Language) — это декларативный язык запросов для управления реляционными базами данных. С его помощью можно создавать таблицы, добавлять, изменять и удалять данные, а также делать выборки по заданным условиям. SQL стандартизирован организацией ISO и поддерживается всеми основными СУБД: PostgreSQL, MySQL, SQLite, Microsoft SQL Server и Oracle.

- SQL расшифровывается как Structured Query Language — язык структурированных запросов.

- Язык создан в 1973 году в IBM, стандарт ISO принят в 1987 году.

- SQL используют 51,5% профессиональных разработчиков по всему миру (Stack Overflow, 2023).

- Основные операции: SELECT, INSERT, UPDATE, DELETE — охватывают 90% повседневных задач.

- SQL работает с реляционными базами данных, где данные хранятся в связанных таблицах.

- Один SQL-запрос может обработать миллионы строк за доли секунды.

Зачем нужен SQL — где используется и кому пригодится

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

• Веб-разработка — интернет-магазины, блоги, социальные сети хранят пользователей, товары и записи в реляционных БД.
• Аналитика данных — аналитики используют SQL для агрегации, фильтрации и построения отчётов.
• Backend-разработка — серверные приложения взаимодействуют с PostgreSQL или MySQL через SQL-запросы.
• Data Science — учёные по данным выгружают датасеты из хранилищ (Redshift, BigQuery) с помощью SQL.
• DevOps и администрирование — DBA оптимизируют запросы, настраивают индексы, следят за производительностью.

SQL востребован как у начинающих разработчиков, так и у опытных инженеров. По данным Glassdoor, знание SQL входит в топ-3 навыков для вакансий Data Analyst и Backend Developer в 2024 году. Даже фронтендеры, которые редко работают напрямую с БД, рано или поздно сталкиваются с SQL при отладке или настройке.

Основные команды SQL

Все команды SQL делятся на группы. Самые важные — это DDL (Data Definition Language) для создания структур и DML (Data Manipulation Language) для работы с данными. Рассмотрим ключевые команды подробнее.

SELECT — выборка данных

SELECT — самая используемая команда SQL. Она позволяет извлекать данные из одной или нескольких таблиц. Базовый синтаксис:

Звёздочка * означает «все столбцы», но на практике лучше перечислять нужные явно — это ускоряет запрос и делает код читаемым. Чтобы отфильтровать дубликаты, используют SELECT DISTINCT.

Можно также ограничить количество строк в результате:

INSERT, UPDATE, DELETE — изменение данных

Три команды, отвечающие за создание, изменение и удаление записей:

Важно: Всегда используйте WHERE в командах UPDATE и DELETE. Без условия изменения применятся ко всем строкам таблицы, и восстановить данные без бэкапа не получится.

CREATE TABLE — создание таблиц

Прежде чем работать с данными, нужно создать таблицу. Команда CREATE TABLE задаёт структуру: имена столбцов, их типы и ограничения:

SERIAL (или AUTO_INCREMENT в MySQL) автоматически генерирует уникальный числовой идентификатор. PRIMARY KEY — уникальный ключ строки. REFERENCES создаёт внешний ключ — связь между таблицами.

JOIN — объединение таблиц

Реляционные базы данных хранят информацию в нескольких связанных таблицах. Чтобы получить данные из нескольких таблиц одним запросом, используется JOIN. Существует несколько видов объединений:

• INNER JOIN — только совпадающие строки из обеих таблиц.
• LEFT JOIN — все строки из левой таблицы, совпадения из правой (или NULL).
• RIGHT JOIN — все строки из правой таблицы, совпадения из левой (или NULL).
• FULL OUTER JOIN — все строки из обеих таблиц, NULL там, где нет совпадений.

WHERE, ORDER BY, GROUP BY — фильтрация и сортировка

Три важнейших инструмента для управления результатом выборки. Подробный разбор ORDER BY с примерами читайте в нашем гайде по сортировке в SQL.

Ключевое отличие: WHERE фильтрует строки до группировки, HAVING — после. Агрегатные функции (COUNT, SUM, AVG, MIN, MAX) работают с группами строк.

Типы данных в SQL

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

• Числовые: INT / INTEGER — целые числа; BIGINT — большие целые; DECIMAL(p,s) — дробные с фиксированной точностью; FLOAT — числа с плавающей запятой.
• Строковые: VARCHAR(n) — строка до n символов; TEXT — строка без ограничений; CHAR(n) — строка фиксированной длины.
• Дата и время: DATE — дата (YYYY-MM-DD); TIME — время; TIMESTAMP — дата и время; INTERVAL — интервал.
• Логический: BOOLEAN — значения TRUE / FALSE / NULL.
• Специальные: UUID — уникальный идентификатор; JSON / JSONB — JSON-данные (PostgreSQL); ARRAY — массив значений.

Практическое правило: используйте наименьший подходящий тип. Для возраста достаточно SMALLINT, для идентификатора пользователя — INT, для финансовых сумм — DECIMAL, а не FLOAT (чтобы избежать ошибок округления).

SQL vs NoSQL — когда что использовать

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

• SQL подходит, когда: данные структурированы и схема стабильна; важна целостность и транзакции (банки, интернет-магазины); нужны сложные запросы с JOIN и агрегацией; команда умеет работать с реляционными БД.
• NoSQL подходит, когда: структура данных гибкая или меняется часто; нужна горизонтальная масштабируемость под огромные объёмы; данные неструктурированы (логи, события, JSON); требуется сверхнизкая латентность (кэш в Redis).

SQL и NoSQL — не конкуренты, а инструменты для разных задач. В одном проекте вполне можно использовать PostgreSQL для бизнес-данных и Redis для кэша.

Популярные СУБД: PostgreSQL, MySQL, SQLite, MS SQL

SQL-синтаксис стандартизирован, но каждая СУБД добавляет свои расширения. Вот краткое сравнение четырёх самых популярных:

• PostgreSQL — мощная open-source СУБД с богатым набором типов данных, поддержкой JSON, полнотекстового поиска и оконных функций. Лучший выбор для серьёзных проектов. Подробнее читайте в нашем руководстве по PostgreSQL для начинающих.
• MySQL / MariaDB — самая распространённая СУБД для веб-приложений, особенно в связке с PHP (WordPress, Drupal). Простая в настройке, быстрая для чтения.
• SQLite — встроенная база данных в одном файле, без сервера. Идеально подходит для мобильных приложений, тестирования и небольших проектов. Используется в Android, iOS, браузерах.
• Microsoft SQL Server — корпоративная СУБД от Microsoft, тесно интегрированная с экосистемой .NET и Azure. Популярна в крупных компаниях.

Если вы только начинаете, рекомендуем PostgreSQL или SQLite. PostgreSQL — для полноценной разработки, SQLite — для обучения без установки сервера.

Как начать учить SQL — ресурсы, песочницы, советы

SQL — один из самых практичных языков для изучения. Базовые команды можно освоить за неделю, а первые реальные запросы писать уже через несколько часов практики.

Подробную дорожную карту с последовательностью тем и рекомендуемыми ресурсами смотрите в нашей дорожной карте SQL для начинающих.

• SQLiteOnline.com — онлайн-песочница без регистрации. Запустите первый запрос прямо в браузере за 30 секунд.
• SQLBolt.com — интерактивный курс с упражнениями от SELECT до сложных JOIN. Полностью бесплатный, на английском.
• Stepik.org — бесплатный курс «Введение в базы данных» на русском языке с практическими заданиями.
• LeetCode / HackerRank — задачи на SQL для подготовки к техническим собеседованиям.
• Официальная документация PostgreSQL — самый полный и точный источник по возможностям СУБД.

Советы для эффективного обучения: практикуйтесь на реальных данных (импортируйте CSV-файл в SQLite), сразу изучайте индексы — они кардинально влияют на производительность. Читайте наш материал об SQL-индексах за 10 минут и 10 советов по оптимизации запросов.

Выводы

SQL — фундаментальный навык для любого, кто работает с данными. За полвека существования язык не только не устарел, но и стал ещё более востребованным: облачные хранилища BigQuery и Redshift, аналитические инструменты, современные ORM — всё это работает поверх SQL или совместимо с ним.

Что делать дальше:

1. Установите PostgreSQL или откройте SQLiteOnline.com и напишите первый SELECT.
2. Пройдите интерактивный курс на SQLBolt.com — займёт 3–5 часов.
3. Попрактикуйтесь на реальных данных: загрузите любой CSV-датасет с Kaggle.
4. Изучите индексы — это самый быстрый способ ускорить запросы.
5. Посмотрите нашу дорожную карту SQL и двигайтесь по ней системно.

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

Проблема: почему Prisma медленнее «чистого SQL»

Prisma — удобная ORM, но каждый запрос проходит через несколько уровней обработки:

Каждый уровень добавляет задержку. Улучшения в Prisma v7 не устраняют фундаментальные ограничения этой архитектуры.

Практический эффект:

Для высоконагруженных API, которые обрабатывают тысячи запросов в секунду, разница в 0.17 ms на запрос быстро превращается в заметную прибавку к общей задержке.

Решение: выполнять SQL напрямую

Единственный способ добиться производительности «чистого SQL» — обойти Query Engine Prisma, но при этом сохранить привычный API Prisma клиента.

Сравнение архитектур

Обычная Prisma:

Оптимизированный подход:

Если генерировать SQL прямо из JSON-запроса и выполнять его через проверенные драйверы, накладные расходы Query Engine исчезают. Процесс подготовки становится обычным превращением JSON в строку.

Реализация

1) Установка зависимостей

PostgreSQL:

SQLite:

2) Базовая настройка (runtime-режим)

PostgreSQL:

SQLite:

Готово. Код запросов менять не нужно. Все операции чтения теперь выполняются быстрее.

3) Продвинутый режим: generator (предварительная генерация SQL)

Для максимальной производительности можно «запечь» самые частые запросы на этапе сборки.

Добавьте в schema.prisma:

Сгенерируйте код:

Подключите сгенерированное расширение:

Сравнение накладных издержек:

• Prisma v7: ~0.34 ms
• Runtime-режим: ~0.20 ms (примерно в 1.7 раза быстрее)
• Generator-режим: ~0.03 ms (примерно в 11 раз быстрее)

Результаты бенчмарков

Тесты на 137 E2E-запросах, сравнивающих идентичные операции.

PostgreSQL

В среднем: в 2.10 раза быстрее, чем Prisma v7

SQLite

В среднем: в 5.48 раза быстрее, чем Prisma v7

Конфигурация для production

1) Режим отладки

Можно видеть сгенерированный SQL для каждого запроса:

2) Мониторинг производительности

Можно отслеживать время выполнения запросов в production:

3) Выборочная оптимизация

Можно ускорять только «горячие» модели:

4) Настройка пула соединений

Пример конфигурации postgres.js для production:

Поддерживаемые возможности

✅ Что ускоряется (выполняется через «чистый SQL»)

Запросы:

• findMany, findFirst, findUnique
• count
• aggregate (_count, _sum, _avg, _min, _max)
• groupBy с условиями having

Фильтры:

Связи:

Пагинация и сортировка:

❌ Что остаётся на стандартной Prisma (без изменений)

Запись:

• create, update, delete, upsert
• createMany, updateMany, deleteMany

Продвинутые возможности:

• Транзакции ($transaction)
• Сырые запросы ($queryRaw, $executeRaw)
• Middleware
• Другие расширения Prisma Client

Поддержка Edge Runtime

Vercel Edge Functions

Cloudflare Workers

Руководство по миграции

Со стандартной Prisma

Было:

Стало:

С Drizzle ORM

Было:

Стало:

Частые проблемы и решения

1)

Проблема:

Решение:

2) Исчерпан пул соединений

Проблема:

Решение:

3) Результаты отличаются от стандартной Prisma

Проблема:

Решение:

Если результаты действительно расходятся, создайте issue: https://github.com/multipliedtwice/prisma-sql/issues

4) Производительность почти не выросла

Проблема: ожидалось ускорение в 2–7 раз, но прирост минимальный.

Возможные причины:

1. Доминирует сеть: на удалённой БД задержка сети (10–50 ms) «затмевает» накладные издержки (0.2 ms)
2. Очень простые запросы: findUnique по индексированному ID и так быстрый
3. Нет индексов: запросы упираются в план выполнения БД

Что сделать:

Когда это не стоит применять

Оставьте стандартную Prisma, если:

1. Преобладает запись: больше 50% операций — запись
2. Простой CRUD: одна таблица, минимум связей
3. Команда не готова: нет опыта с postgres.js / better-sqlite3
4. Нужны неподдерживаемые функции Prisma: активное использование возможностей, которые здесь не покрыты

Этот подход подходит, когда:

1. Преобладает чтение: более 70% операций — чтение
2. Высокая пропускная способность: >1000 rps, где важны миллисекунды
3. Сложные запросы: много связей, агрегаций, условий
4. Оптимизация затрат: меньше задержка → меньше ресурсов

Заключение

Можно добиться 100% производительности «чистого SQL», не отказываясь от удобства Prisma.

Основные преимущества:

• Ускорение чтения в 2–7 раз без переписывания запросов
• Те же типы и тот же API Prisma Client
• Подходит для production (по заявлению авторов) и покрыто E2E-тестами
• Работает в существующих проектах Prisma

Быстрый старт:

1. Установите prisma-sql и postgres/better-sqlite3
2. Подключите расширение
3. Задеплойте и измерьте эффект

Дальнейшая оптимизация:

1. Подключите generator для «горячих» запросов
2. Включите мониторинг через onQuery
3. Настройте пул соединений

Ресурсы:

• NPM: https://www.npmjs.com/package/prisma-sql
• GitHub: https://github.com/multipliedtwice/prisma-to-sql
• Документация: https://github.com/multipliedtwice/prisma-to-sql#readme
• Примеры E2E-тестов: https://github.com/multipliedtwice/prisma-to-sql/tree/main/tests/e2e

В этой подборке — пять системы управления базами данных, которые закрывают разные сценарии: от транзакционных нагрузок до аналитики петабайтных хранилищ. Каждый продукт решает свой класс задач — одни оптимизированы под OLTP с частыми операциями чтения-записи, другие под OLAP с обработкой миллиардов строк, третьи дают задержки в миллисекунды для real-time систем.

1. РЕД База Данных: реляционная СУБД с режимом встраивания

Тип: реляционная СУБД общего назначения, OLTP

РЕД База Данных — реляционная OLTP-система общего назначения, которая включена в реестр российского ПО и имеет сертификат ФСТЭК России по 4 классу защиты. Команда разрабатывает продукт параллельно с Firebird уже 20 лет: общие ошибки исправляются в обеих ветках, доработки переносятся между проектами.​

Где используют

Один из публичных кейсов — АИС ФССП России. СУБД работает с терабайтными базами данных, скорость обработки запросов сопоставима с другими реляционными OLTP-системами на рынке.

Два режима работы

РЕД База Данных может работать как классическая серверная СУБД или в режиме встраивания — без выделенного сервера, как SQLite. В встраиваемом режиме функциональность сохраняется полностью, кроме сетевого доступа. Это позволяет использовать одну СУБД и для серверных задач, и для локальных приложений.

Поддерживаются Windows, Linux (включая РЕД ОС, Альт Линукс, AstraLinux, ROSA) и Android. Архитектуры: x86_64 (Intel, AMD), Эльбрус (e2k), Байкал (aarch64), ARM.

Отказоустойчивость и репликация

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

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

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

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

Многопоточная архитектура позволяет запускать множество транзакций в рамках одного подключения и поддерживать несколько подключений одновременно.​

Интеграция и инструменты

В экосистеме РЕД Базы Данных есть два основных инструмента:

РБД Эксперт для разработки и администрирования баз данных

РБД Монитор для мониторинга.​

СУБД имеет сертификаты совместимости с 80+ продуктами: медицинские информационные системы, банковское ПО, СКАДА-системы, системы резервного копирования. Полная совместимость с другими продуктами РЕД СОФТ (РЕД Виртуализация, РЕД ОС, РЕД Платформа и другие) позволяет собирать инфраструктуру на базе одного вендора.

Поддерживаются популярные языки и фреймворки: Java (Spring, Hibernate, Liquibase, FlyWay), NodeJS, Python (Django, SQLAlchemy), Ruby (Active Record), GO (GORM), C, C++, .NET, Rust, QT, ODBC, OLE DB, PHP, Erlang.

Доступность и поддержка

Продукт представлен в облаках VK Cloud и Яндекс Облако. Для VK Cloud есть бесплатная версия для тестирования. Покупка через интеграторов, лицензирование поядерное — минимум 2 ядра на установку. Для разработчиков прикладного ПО предусмотрена отдельная лицензия без ограничений.​

Техническая поддержка работает на двух уровнях: стандартном и расширенном. Для пользователей доступны техническая документация и база знаний, статьи на Хабре, каналы на RuTube и Дзен, чат в Telegram с разработчиками. Ежегодно проводится конференция, посвящённая Firebird, где можно пообщаться с командой напрямую.​

Что будет в версии 6

Шестая версия запланирована на 2026 год с фокусом на производительность и новые функции. В релиз войдут: геометрические типы данных, гетерогенные запросы, ROW-тип данных, партиционирование, катастрофоустойчивый кластер, восстановление на точку во времени, создание и удаление индексов без блокировки, улучшенные JSON-функции, новые методы доступа (HASH/MERGE OUTER JOIN, HASH GROUP BY), общий кеш метаданных и поддержка TRUNCATE.

2. Tantor Postgres: СУБД для высоких нагрузок и защищённых систем, в том числе 1С

Тип: универсальная СУБД на базе PostgreSQL

Tantor Postgres — это СУБД для высоконагруженных систем на основе PostgreSQL с глубокими доработками. Продукт выпускается в четырёх редакциях: Special Edition для нагруженных OLTP-систем и корпоративных хранилищ до 100 ТБ, Special Edition 1C с оптимизацией под приложения 1С, Certified с сертификацией ФСТЭК для защищённых ГИС и КИИ, и Basic Edition с базовыми улучшениями и поддержкой вендора.

Где применяют

СУБД Tantor Postgres в различных редакциях, включая сертифицированную ФСТЭК, используется в большинстве ключевых отраслей бизнеса, коммерческих и государственных организациях, в том числе на объектах КИИ. Так, правительство одного из крупнейших городов России использует продукты Tantor в большинстве комитетов, а АО "Губернские аптеки" — крупнейшая аптечная госсеть Красноярского края — мигрировала на Tantor Postgres при объёме данных свыше 2 ТБ и более 17 млн совершаемых транзакций в день. Проект охватил более 2000 рабочих мест. Инструменты мониторинга Tantor помогли выявить неоптимальные запросы и передать данные 1С-разработчикам для доработки, и в результате время массовых расчётов и перепроведения документов в 1С сократилось на 50%, что сэкономило массу времени десяткам бухгалтеров.

Производительность под 1С

Tantor располагает собственным центром экспертизы 1С, который решает технические вопросы клиентов и ставит конкретные задачи по развитию СУБД под специфику 1С. Для крупных внедрений 1С предлагается машина баз данных Tantor XData. С СУБД Tantor Postgres для 1С пройдены тесты на высоконагруженных системах: 30 000 одновременных пользователей 1С с APDEX 0.859 на МБД Tantor XData 2Y, 20 000 одновременных пользователей с APDEX 0.846 на МБД Tantor XData 2B, и 15 000 одновременных пользователей с APDEX 0.950 на МБД Tantor XData 2Y в альтернативном тестировании.

Отличия от PostgreSQL

Полный список отличий от "ванильной" версии доступен в документации.

Среди реализованных в 2025 году технологий и оптимизаций – технология Transparent Data Encryption (TDE) для прозрачного шифрования данных на диске + шифрование WAL, поддержка протокола аутентификации 0Auth 2.0, новый механизм работы с временными таблицами, улучшенная поддержка широких таблиц и таблиц с неравномерным распределением значений, множество оптимизаций производительности для систем «1С», оптимизация обработки дизъюнкций подзапросов, расширенная поддержка параллельного выполнения операций с временными таблицами, раздельное управление детализацией статистики для постоянных и временных таблиц. Таким образом, СУБД Tantor Postgres глубоко оптимизирована для более высокой производительности, в том числе для высоконагруженных систем 1С.

• Расширение Tantor PipelineDB обеспечивает агрегацию и вычисления на данных в реальном времени.
• Расширение columnar предоставляет колоночное хранение и обработку данных с возможностью транзакционного выполнения операций UPDATE и DELETE.
• Расширение transp_anon реализует динамическую анонимизацию данных.

В каждую редакцию СУБД Tantor Postgres входит графическая Платформа Tantor для администрирования и мониторинга баз данных на основе PostgreSQL.

Стратегическим направлением развития СУБД Tantor Postgres является реализация технологии разделения вычислений и хранения для независимого масштабирования под высокие и смешанные нагрузки (НТАР), адаптация к облачному использованию и использованию с ИИ.

Новые расширения в релизах 17.7 и 16.11

• pg_stat_kcache фиксирует физические операции чтения и записи, позволяя выявлять узкие места производительности, недоступные для обнаружения другими инструментами мониторинга.
• pgvector предоставляет тип данных vector и оптимизированные алгоритмы поиска по сходству для работы с многомерными представлениями данных.
• pg_ivm реализует инкрементальные материализованные представления, обновляя их по мере изменения данных в исходных таблицах.
• pg_throttle позволяет ограничивать скорость выполнения отдельных запросов и создавать пользовательские профили для управления ресурсами путём контроля нагрузки на систему.
• pg_trace обеспечивает глубокий анализ и профилирование SQL-запросов.
• pg_archive автоматически архивирует исторические данные из партиционированных таблиц.

Отказоустойчивость и надёжность

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

Безопасность и сертификация

Модуль ЗСУБД операционной системы Astra Linux Special EditionLSE 1.8 имеет сертификацию ФСТЭК по 1 категории, редакция Tantor Certified сертифицирована ФСТЭК по 4 категории. Поддерживается прозрачное шифрование данных (Transparent Data Encryption, TDE).

СУБД совместима с ОС Astra Linux Special Edition во всех режимах функционирования. Отдельное приложение pg_sec_check проводит комплексный аудит безопасности СУБД. Протокол аутентификации OAuth 2.0 позволяет приложениям получать защищённый доступ к данным без передачи паролей пользователей.

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

Экосистема и совместимость

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

Поддерживаемые ОС: Astra Linux, Alt Linux, МСВСфера, Ред Софт, CentOS, Red Hat, Rocky Linux, Ubuntu, Debian, Oracle Linux.

Tantor предоставляет единое окно технической поддержки для продуктов Tantor и «Группы Астра», что обеспечивает качество и скорость решения вопросов. Вендорская поддержка доступна для всех редакций СУБД, полное описание ограничений СУБД опубликовано в документации.

Лицензирование

Классическая модель — поядерное лицензирование физических или виртуальных ядер сервера. Для СУБД под 1С есть адаптированная схема для SMB-рынка, где стоимость лицензии рассчитывается исходя из количества работников заказчика.

Планы на 2026 год

Запланирована сертификация ФСТЭК для Tantor Postgres 17.x, выпуск СУБД Tantor Postgres 18, выпуск редакции с разделением Compute и Storage. В разработке интеграция RocksDB, реорганизация таблиц без блокировок, реализация Tantor Postgres DBaaS в Astra Cloud, развитие PipelineDB в сторону более тесной интеграции с Columnar, поддержка сжатия на уровне JDBC-драйвера.

3. Postgres Pro: форк PostgreSQL с российской разработкой и встроенным кластером

Тип: реляционная СУБД общего назначения на базе PostgreSQL

Postgres Pro — российская разработка на основе PostgreSQL. Компания объединяет 70% российских контрибьюторов PostgreSQL, входит в ТОП-5 мировых разработчиков этой СУБД. Продукт включён в реестр российского ПО, сертифицирован ФСТЭК России. На рынке 10 лет, в команде более 400 специалистов.

Где используют

• Один из масштабных кейсов — миграция ГИС ГМП Федерального казначейства на Postgres Pro Shardman. Система обрабатывает платежи национального масштаба и работает в распределённой архитектуре.
• «Авито» перенесли базы данных 1С с Microsoft SQL Server на Postgres Pro Enterprise. Объём данных — более 10 ТБ. Платформа обрабатывает 220 млн объявлений ежемесячно, обслуживает 62 млн пользователей и до 10 сделок в секунду.
• Газпромбанк мигрировал ключевую АБС с Oracle на Postgres Pro Enterprise. Проект потребовал перестройки архитектуры и детального тестирования под пиковыми нагрузками.
• «Росатом» развернул автоматизированную систему управления финансами и перенёс СЭД на Postgres Pro Enterprise Certified. Решение обслуживает более 250 предприятий атомной отрасли.

Редакции и специализация

Линейка включает пять основных редакций:

• Postgres Pro Enterprise — флагманская версия для высоконагруженных систем с более чем 100 дополнительными функциями относительно PostgreSQL. Поддерживает до 10 000 одновременно работающих пользователей.
• Postgres Pro Enterprise для 1С — оптимизирована под платформу 1С. Ускоряет ключевые операции, закрыть месяц можно до 10 раз быстрее по сравнению с базовыми решениями.
• Postgres Pro Enterprise Certified — сертифицированная ФСТЭК версия Enterprise со встроенными средствами защиты.
• Postgres Pro Standard — улучшенная версия PostgreSQL с повышенной производительностью и полнотекстовым поиском.
• Postgres Pro Certified — сертифицированная ФСТЭК версия Standard.

BiHA: встроенный отказоустойчивый кластер

BiHA (Built-in High Availability) — встроенный отказоустойчивый кластер, работает «из коробки» без внешних компонентов. При сбое основного узла система автоматически переключается на реплику. Механизм не требует отдельной настройки Pacemaker, Corosync или других решений для управления кластером — всё интегрировано в ядро СУБД.

Масштабирование: Shardman и Citus

Для горизонтального масштабирования доступны две технологии:

Postgres Pro Shardman — распределённая СУБД с автоматическим управлением шардами. Данные распределяются по узлам, система сама отслеживает топологию и балансирует нагрузку. Использовался в проекте миграции ГИС ГМП.

Citus — расширение для распределённых запросов и параллельной обработки. Подходит для аналитических задач и работы с большими объёмами данных.

Proxima и управление жизненным циклом данных

Proxima — встроенный пулер соединений и прокси-сервер. Оптимизирует управление подключениями, снижает накладные расходы на создание новых сессий.

ILM (Information Lifecycle Management) — управление жизненным циклом данных. Позволяет автоматически перемещать старые или редко используемые данные на более дешёвые носители без остановки системы.

Миграция с Oracle и других СУБД

Postgres Pro включает инструменты для упрощённой миграции с Oracle: поддержка PL/SQL-совместимого языка, эмуляция пакетов Oracle, совместимость типов данных.

Экосистема инструментов

Postgres Pro Enterprise Manager (PPEM) — графическая платформа для управления кластерами, мониторинга производительности и резервного копирования. Интерфейс позволяет управлять несколькими инстансами одновременно.

Postgres Pro Backup Enterprise — инструмент для инкрементального резервного копирования. Поддерживает восстановление на точку во времени (PITR) и сжатие данных.

Техническая поддержка и документация

Техническая поддержка работает 24/7, два уровня: базовая и расширенная. Расширенная включает решение задач, требующих изменений в ядре СУБД. Доступен портал техподдержки с личным кабинетом и базой знаний.

Документация включает книги, курсы, демобазу для обучения, глоссарий и HOW-TO видео. Для студентов и вузов есть отдельные программы.

Доступность

Продукты доступны через интеграторов и дистрибьюторов. Лицензирование поядерное. Для разработчиков прикладного ПО предусмотрены отдельные условия. Можно протестировать через личный кабинет на сайте.

Компания проводит регулярные мероприятия: PGPro TechDay, PGMeetup по шардированию и другим техническим темам.

4. Tarantool DB: in-memory СУБД для real-time систем

Тип: NoSQL in-memory СУБД, key-value/документная

Tarantool DB — российская in-memory СУБД с открытым кодом, разработка VK. Включена в реестр отечественного ПО (№ 23005 от 28.06.2024), сертифицирована ФСТЭК России. Основной фокус — системы реального времени с требованиями к задержке в единицы миллисекунд.

Где используют

• Tarantool применяют как кэш-слой для автоматизированных банковских систем и дисковых СУБД. Вместо полной замены core-систем создаётся быстрый промежуточный слой, который снижает нагрузку на основное хранилище.
• В банковской архитектуре СУБД работает как оперативное хранилище между клиентскими приложениями и базовой АБС. Это позволяет обрабатывать запросы без обращения к медленным дисковым системам.
• В телекоме и ритейле используют для организации «золотой записи» клиента, цифрового профиля, единой авторизации и real-time биллинга. В e-commerce — для обработки потоков событий и маркетинга в реальном времени.

Drop-in замена Redis

В поставке есть механизм замены Redis с минимальными изменениями кода. Поддерживаются 60+ команд Redis, типы данных Redis, Redis ACL для управления доступом и настройки, совместимые с Redis.

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

Схемы данных и работа с памятью

Tarantool поддерживает несколько схем: key-value, таблицы и документы. Данные хранятся в оперативной памяти с возможностью сжатия для экономии ресурсов.

Для сохранности предусмотрена упреждающая журнализация (WAL) и создание снимков состояния БД. При сбое система восстанавливается быстро благодаря механизму быстрого восстановления.

CRUD-операции работают с объектами в кластерном хранилище. Поддерживаются вторичные индексы и управление временем жизни данных (TTL). Справочники можно хранить прямо в кластере.

Репликация и шардирование

Доступна синхронная и асинхронная репликация. Шардирование (сегментирование данных) встроено в платформу — не нужны внешние инструменты для горизонтального масштабирования.

Failover для отказоустойчивости работает автоматически: при падении узла система переключается на реплику. Управление кластером реализовано через собственную технологию Tarantool.

API и интеграция

Для работы с данными из бизнес-приложений есть коннекторы на Java и Go. API поддерживает чтение и запись данных в кластерное хранилище.

Метрики мониторинга экспортируются в Prometheus и Grafana. Развёртывание возможно в Kubernetes. Поддерживаются российские ОС: Astra Linux и РЕД ОС.

Экосистема продуктов

Помимо Tarantool DB, в экосистеме есть:

• Tarantool Enterprise Edition — коммерческая версия с расширенной поддержкой
• Tarantool CDC — Change Data Capture для синхронизации с другими системами
• Tarantool Graph DB — графовая база данных
• Tarantool Queue Enterprise — система очередей
• Tarantool Column Store — колоночное хранилище для аналитики
• Tarantool Clusters Federation — управление федерацией кластеров
• Tarantool Kubernetes Operator — оператор для Kubernetes
• Tarantool Cloud Edition — облачная версия

Горизонтальное масштабирование

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

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

Документация и поддержка

Техническая документация доступна на русском языке. Есть руководства по началу работы для Enterprise Edition и Community Edition, документация по модулям и Data Grid.

Сообщество общается в Telegram, VK, GitHub и Stack Overflow. Есть блог с техническими статьями.

5. ClickHouse: колоночная СУБД для аналитики

Тип: колоночная OLAP-СУБД для онлайн-аналитической обработки

ClickHouse — колоночная СУБД для аналитических задач, доступна как open-source проект и облачный сервис. Разработка началась в Яндексе, сейчас развивается как независимый проект. Основной фокус — обработка больших объёмов данных в режиме реального времени с возвратом результата за время менее секунды.

OLAP vs OLTP

ClickHouse решает задачи онлайн-аналитической обработки (OLAP): SQL-запросы со сложными вычислениями, агрегациями и арифметикой по миллиардам и триллионам строк. Аналитические запросы обрабатывают большие объёмы данных, в отличие от транзакционных (OLTP), которые читают и записывают несколько строк за запрос.

Колоночное хранение

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

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

Производительность

На примере реальных данных веб-аналитики: запрос по 100 миллионам строк с фильтрацией и группировкой выполняется за 92 миллисекунды. Пропускная способность — около 1 миллиарда строк в секунду или около 7 ГБ данных в секунду.

Приблизительные вычисления

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

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

SQL и стандарт ANSI

ClickHouse поддерживает декларативный язык запросов на основе SQL, который во многих случаях соответствует стандарту ANSI SQL. Поддерживаются GROUP BY, ORDER BY, подзапросы в FROM, JOIN, оператор IN, оконные функции и скалярные подзапросы.

Синтаксис знаком разработчикам, работавшим с реляционными СУБД, но внутренняя логика выполнения запросов отличается из-за колоночного хранения.

Репликация и целостность данных

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

Восстановление после большинства сбоев выполняется автоматически или полуавтоматически в сложных случаях. Ролевое управление доступом (RBAC) реализовано через SQL-запросы, аналогично стандарту ANSI SQL и популярным реляционным СУБД.

Адаптивные алгоритмы соединения

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

Сценарии использования

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

Типичный паттерн — сбор событий в реальном времени (клики, просмотры, логи) и построение дашбордов с обновлением каждые несколько секунд. ClickHouse обрабатывает миллиарды записей и возвращает результаты агрегации быстрее, чем традиционные хранилища данных.

Open-source и облако

Проект доступен на GitHub под лицензией Apache 2.0. Есть коммерческое облачное предложение ClickHouse Cloud с управляемой инфраструктурой. Можно развернуть на собственных серверах или использовать облачный вариант без управления кластером.

Выбор СУБД зависит от типа задач и архитектуры проекта. Для транзакционных систем с частыми операциями чтения-записи подходят РЕД База Данных и Postgres Pro — обе работают по модели OLTP, поддерживают ACID и совместимы с существующими инструментами разработки. Универсальная СУБД Tantor Postgres имеет специализированную версию для работы с 1С, производительность которой подтверждена тестами с одновременной работой десятков тысяч пользователей. Tarantool закрывает сценарии, где критична задержка в миллисекунды: кэширование, сессии, real-time биллинг. ClickHouse и Arenadata DB решают аналитические задачи, но по-разному: первый оптимизирован под скорость отдельных запросов с колоночным хранением, второй — под корпоративные хранилища данных с MPP-архитектурой и полной совместимостью с PostgreSQL.

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

Шаг 1. Проверьте CPU, память и диск

Начинаем с базы — проверяем аппаратные и системные ресурсы. Иногда проблема кроется в том, что серверу объективно тяжело. CPU перегружен, память закончилась, диск устал, и PostgreSQL просто не из чего строить производительность. База работает как сениор-разработчик в последней стадии выгорания.

На что ориентироваться:

• Если CPU постоянно упирается в предел — анализируем активность запросов или рассматриваем масштабирование.
• Если Swap активен — не хватает памяти.
• Если видите высокий iowait или высокий %util диска, то кандидаты: медленное хранилище, случайные чтения, VACUUM, большие запросы.

Шаг 2. Изучите активность в pg_stat_activity

Представляет информацию о текущей активности каждого процесса в реальном времени. Благодаря pg_stat_activity можно увидеть, какие запросы сейчас ждут запуска, какие в работе, а какие съедают больше всего ресурсов производительности. Если смотреть сюда регулярно, большинство проблем видно ещё до аварии.

На что обратить внимание

• долгие транзакции;
• wait_event_type = 'Lock';
• idle in transaction — признак некорректной работы приложения с транзакциями.

Однажды в проде столкнулись с резким ростом задержек запросов, далее — массовые ошибки canceling statement due to lock timeout. Выяснилось: в ETL начали повсеместно использовать транзакции, в том числе там, где они не нужны. Долгие этапы блокировали частые операции. Перезапуск PostgreSQL помогал до следующего запуска ETL.

Решение: идентифицировать и завершить блокирующие процессы, переработать ETL на более короткие транзакции. В дальнейшем — маркировать подобные процессы и мониторить их отдельно.

Шаг 3. Найдите медленные запросы в pg_stat_statements

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

Что искать:

• запросы, потребляющие больше всего времени;
• случаи, когда чтение идёт с диска, а не из буфера (shared_blks_read >> shared_blks_hit).

Шаг 4. Выявите блокировки

Ищите ситуации, когда несколько запросов пытаются работать с одними и теми же данными одновременно. Если один процесс держит строку или таблицу, остальные ждут. Тогда база не падает, а просто стоит в очереди.

Ищем цепочки блокировок. Частые причины:

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

Шаг 5. Проанализируйте план запроса с EXPLAIN ANALYZE

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

Шаг 6. Проверьте и оптимизируйте индексы

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

Как оптимизировать:

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

Шаг 7. Устраните раздувание таблиц — bloat

PostgreSQL не удаляет ненужные данные сразу, а копит «мёртвые» строки. Если их становится слишком много, таблицы разрастаются. Тогда база тратит ресурсы впустую.

Диагностика:

Очистка:

Шаг 8. Настройте и проверьте autovacuum

Этот фоновый процесс нужен в PostgreSQL, чтобы автоматически обслуживать базу. Пока он работает, система в порядке. Если его выключить или не настроить, то накопится мусор, вырастут таблицы, а база замедлится.

Проверьте эффективность процессов:

Настройки должны соответствовать нагрузке и объёму данных.

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

Если n_dead_tup растёт, а autovacuum_count нет — это сигнал будущих проблем с производительностью и ростом bloat. Также важно следить за WAL: резкий рост записи может указывать на массовые обновления, проблемы с репликацией или приближающееся заполнение диска.

Шаг 9. Обновите статистику и настройте планировщик

PostgreSQL формирует план выполнения запроса на основе статистики о распределении данных в таблицах. Если статистика устарела, оптимизатор может выбрать неэффективный план.

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

Учитывайте важные параметры:

• random_page_cost для SSD ≈ 1.1
• effective_cache_size ≈ 50–75% RAM

Шаг 10. Контролируйте соединения

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

Текущее состояние соединений можно просмотреть с помощью:

Чтобы решить проблему, используйте пул соединений — например, через пулер PgBouncer или аналоги. Такие программы перераспределяют нагрузку между клиентами.

Шаг 11. Проанализируйте логи

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

Рекомендуемые параметры в postgresql.conf:

Шаг 12. Оптимизируйте конфигурацию

Значения по умолчанию предназначены для минимальных нагрузок — для работы на ноутбуке. Они не дают достаточной мощности в производственной среде.

Измените ключевые параметры конфигурации:

• shared_buffers ~25% RAM
• effective_cache_size ~50–75% RAM
• work_mem 4–16 MB per operation
• checkpoint_timeout 15–30 min
• random_page_cost = 1.1 для SSD

Многие думают, что 16 мегабайт — это глобальный лимит на соединение. На самом деле это лимит на операцию. Один запрос может использовать work_mem много раз.

Качество и целостность данных: типовые проблемы и решения

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

Какие ошибки встречаются чаще всего:

• дубли,
• неверные типы,
• конфликтующие или устаревшие значения,
• частичные и повреждённые записи.

Как поддерживать целостность данных:

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

Контроль качества данных включает также стратегию восстановления. Даже идеально настроенная валидация не спасает от сбоя диска или человеческого фактора. Резервные копии и репликации должны стать частью общей стратегии.

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

• проверенные бэкапы возвращают к нормальному состоянию,

• репликация сохраняет доступность, если падает основной сервер.

SAVEPOINT помогает в рамках одной транзакции, бэкапы и репликация — в рамках всей системы.

Как проверять входные данные

Задавайте допустимые форматы и диапазоны. Указывайте, какие значения вы считаете корректными. Пример:

• дата рождения не может быть позже текущего дня;
• возраст — только числа ≥ 18;
• формат email должен содержать @ и домен.

Проверяйте данные на двух уровнях. Чтобы пользователь увидел ошибку сразу, смотрите на клиенте — например, в форме сбора контактов.

Чтобы защититься, если приложение пропустило проблему — на сервере.

Используйте ограничения в базе. SQL-ограничения — это тот самый встроенный механизм надёжности:

• NOT NULL — поле не может быть пустым;
• UNIQUE — значение должно быть уникальным;
• CHECK — значение должно соответствовать условию;
• FOREIGN KEY — связь с другой таблицей;
• триггеры — дополнительная логика проверки.

Давайте понятные сообщения об ошибках. Пользователь должен понимать, что он сделал не так. Например, вместо Error 400 — invalid data напишите: «Возраст должен быть от 18 лет. Введено: 15».

Актуализируйте правила проверки. Если вчера минимальная сумма заявки была 5 тысяч, а сегодня 10 — проверка должна обновиться.

Отдайте контроль машине. Используйте автоматизированные проверки:

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

Документируйте и обучайте. Опишите, какие данные нужны, в каком виде и почему. Покажите команде и пользователям. Чем понятнее правила, тем меньше ошибок.

Идеальный сценарий: регулярные тестируемые бэкапы + репликация с мониторингом лагов.

Чек-лист диагностики за 15 минут

1. pg_stat_activity — долгие транзакции, ожидания
2. pg_locks — есть ли блокировки
3. pg_stat_statements — тяжёлые запросы
4. iostat, htop, free — ресурсы железа
5. Проверка автовакуума
6. Проверка WAL и места на диске
7. Анализ логов

Ещё 4 неочевидные причины деградации производительности

Что делать, если диагностика по стандарту не помогла? Владимир Васильев рассказал нам, где ещё можно найти источник проблем:

• «Тихое» повреждение данных на диске. Дисковая подсистема не сообщала об ошибках: контроллер RAID с кэшем-бутербродом, где батарея отжила своё. Некоторые страницы данных на диске были битые. Postgres при чтении таких страниц не падал, а уходил в бесконечные ожидания I/O, которые выглядели как резкий скачок нагрузки на диск. Вылечили включением zero_damaged_pages на свой страх и риск, с последующим дампом/рестором. Потом, конечно, заменили железо.
• Конфликт расширений. Была история с pg_stat_statements и auto_explain, которые при определённой настройке (совместная загрузка и высокая частота сэмплирования) начинали сильно тормозить из-за конкуренции за локи в общей памяти. Симптом — высокий wait_event типа LWLock для простых запросов.
• Проблема на уровне файловой системы. Очень старый, но запоминающийся случай: файловая система была заполнена почти под завязку, больше 95%. Это привело к драматическому падению производительности, так как механизмам VACUUM и CREATE INDEX не хватало места для создания временных файлов. Симптомы были самые странные, пока не посмотрели на df -h.
• Субтильный баг в версии PostgreSQL. Однажды апгрейд на минорную версию в рамках одного major привёл к деградации конкретного типа запросов с JOIN. Оказалось, баг в планировщике — он неправильно оценивал стоимость при определённом условии. Помог откат или установка enable_<type>scan = off в качестве временного костыля.

Выводы

Основные источники проблем:

• долгие транзакции и блокировки
• неэффективные планы выполнения
• недостаточная память и I/O-узкие места
• неверные настройки work_mem, autovacuum, max_connections
• игнорирование метрик и логов

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

Краткий чек-лист диагностики:

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

Читайте также

• Основы PostgreSQL для начинающих: от установки до первых запросов
• PostgreSQL vs. ClickHouse vs. Duck DB: какую опенсорс базу выбрать для аналитики в 2025 году?
• Вредные советы по работе с базами данных, или как расстроить DBA
• SQL-оптимизация: 5 запросов, которые ломают базу
• PostgreSQL: что нужно знать о счётчике транзакций

10 лет в развитии PostgreSQL

Бородин получил статус топ-контрибьютора спустя 10 лет активного участия в развитии сообщества и кодовой базы PostgreSQL.

При этом и команда Yandex Cloud активно сотрудничает с сообществом PostgreSQL. Каждый год в релизы СУБД попадает множество доработок от инженеров компании.

Процесс принятия изменений в ядро PostgreSQL считается одним из самых строгих в мире open-source, поэтому успешный апстрим-патч — знак качества и зрелости кода.

Кроме ядра, команда Яндекса развивает собственные опенсорс-решения. Например, SPQR — на его основе в сентябре 2025 года был запущен сервис Managed Service for Shared PostgreSQL.

Он обеспечивает горизонтальное масштабирование баз данных через шардирование — разделение данных между разными серверами.

Кто такой Андрей Бородин

До работы в Yandex Cloud, Бородин был инженером в AWS, а сейчас совмещает разработку с преподаванием в ШАД «Яндекса» и Уральском федеральном университете.

Первый патч в PostgreSQL он закоммитил еще в 2016 году. С тех пор он уже четырежды попадал в годовой топ-50 контрибьюторов проекта.

Теперь Bun официально позиционируется как full-stack платформа для фронтенда и бэкенда. И она объединяет сервер, сборщик, менеджер пакетов вместе с тест-раннером в одном инструменте.

В новую версию добавлены десятки ключевых функций: встроенные клиенты для Redis, MySQL, PostgreSQL и SQLite, единый SQL API, улучшенные WebSocket-модули, переработанный тест-раннер и поддержка VSCode Test Explorer.

Full-stack по-умному

Главное новшество — режим full-stack Bun.serve() с поддержкой роутинга, cookies и WebSockets.

Теперь фронтенд и бэкенд можно запускать в одном процессе без проблем с CORS, а приложение собрать в единый исполняемый файл с помощью bun build --compile.

Разработчики могут напрямую импортировать HTML, запускать React-приложения с хот-перезагрузкой и собирать проект одной командой bun init --react. По данным команды, скомпилированные React-приложения в Bun работают до 1,8 раза быстрее, чем через nginx.

Новый SQL и встроенный Redis

Bun 1.3 представил унифицированный Bun.SQL API — теперь один и тот же код работает с MySQL, PostgreSQL, SQLite и MariaDB. Добавлен хелпер sql.array() для работы с массивами в PostgreSQL, улучшена поддержка JSON и Unix-сокетов.

Кроме того, в рантайм встроен Redis-клиент, который поддерживает 66 команд, автоматическое переподключение, очереди сообщений и Pub/Sub. По данным разработчиков, он значительно быстрее ioredis, а поддержка кластеров и Lua-скриптов появится в будущих релизах.

Новые возможности

Среди прочих улучшений — Zstandard-сжатие, нативная поддержка YAML, API для безопасного хранения секретов (Bun.secrets), и серьезный прирост производительности: операции с криптографией ускорены до 400х, установка пакетов — до 2,5х.

Также обновлен менеджер пакетов с интерактивным bun update, изолированными установками и API для проверки безопасности зависимостей.

Почему это важно

Bun 1.3 превращает экспериментальный рантайм в полноценную платформу для веб-разработки, способную заменить Node.js, Vite и Redis-CLI одновременно.

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

Главное нововведение — асинхронный ввод-вывод, который в ряде сценариев ускоряет работу с диском до трех раз.

Но на этом список улучшений не заканчивается: PostgreSQL 18 ускорил обновления между версиями, добавил удобства разработчикам, улучшил текстовые операции и получил поддержку OAuth 2.0.

До трех раз быстрее благодаря новому вводу-выводу

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

В PostgreSQL 18 появилась полноценная поддержка асинхронного I/O, благодаря которой база может отправлять сразу несколько I/O-запросов — и не ждать завершения каждого по отдельности.

Это позволяет достичь серьезного прироста производительности при последовательном чтении, bitmap heap scan и даже во время VACUUM.

В зависимости от настроек (io_method) можно выбрать подходящий механизм — от worker до io_uring, или оставить синхронный режим (sync). Подробные параметры конфигурации описаны в официальной документации.

Обновления между версиями больше не обнуляют производительность

Одной из болезненных сторон мажорных обновлений PostgreSQL всегда было то, что после pg_upgrade приходилось заново собирать статистику — иначе планировщик начинал выбирать неоптимальные запросы.

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

Помимо этого, утилита pg_upgrade теперь работает быстрее на базах с большим количеством таблиц, может выполнять параллельные проверки (через --jobs) и поддерживает флаг --swap — для моментальной замены директорий без копирования файлов.

Что еще улучшили

В PostgreSQL 18 появилось множество изменений, не связанных напрямую с I/O, но делающих жизнь разработчиков и администраторов проще. Среди них:

• Новые методы индексирования (вроде skip scan), которые позволяют задействовать индексы даже без фильтрации по первым столбцам.
• Улучшения в JOIN: быстрее работают hash join, merge join и incremental sort.
• Поддержка виртуальных вычисляемых колонок, которые вычисляются на лету и не хранятся на диске.
• Новый генератор uuidv7() — UUID с временной сортировкой, который лучше индексируется и ускоряет выборки.
• Возможность использовать оба значения (OLD и NEW) в RETURNING при INSERT, UPDATE, DELETE и MERGE.
• Улучшения в полнотекстовом поиске и обработке текста, включая новый casefold() и быструю сортировку PG_UNICODE_FAST.

Также PostgreSQL теперь проще интегрировать с OAuth 2.0, появилась валидация для FIPS-режима, улучшено логгирование репликации и по умолчанию включены контрольные суммы страниц (page checksums), что может повлиять на стратегию обновления через pg_upgrade.

PostgreSQL 18 уже доступен для загрузки. Полный список изменений можно найти в официальных release note.

Он ожидал увидеть очевидное превосходство Redis, но результаты оказались не такими однозначными — особенно с учетом unlogged-таблиц в Postgres.

Как проводили тест

• Был написан простой HTTP-сервер на Go с двумя эндпоинтами: GET и SET.
• В качестве кэша использовались: Redis (через go-redis) и PostgreSQL с unlogged-таблицей (через pgx).
• Оба сервиса запускались в k8s с лимитами: 2 CPU и 8 ГБ ОЗУ.
• Генерация нагрузки — с помощью k6, с предзаполнением кэша 30 млн записей.
• Тестировались три типа нагрузки: только чтение, только запись, смешанная (80% чтения и 20% записи).

Что показали тесты

1. Redis быстрее почти по всем метрикам

• При чтении Redis обработал более 11 000 запросов в секунду против 7400 у PostgreSQL.
• Задержки в Redis в среднем были на 20–30 мс ниже.
• При записи разрыв еще больше: Redis справлялся с ~10 700. запросов в секунду, а PostgreSQL — с ~6000.

2. Unlogged-таблицы действительно ускоряют PostgreSQL

• При использовании обычных таблиц производительность записи в Postgres падала почти в 3 раза.
• На смешанной нагрузке unlogged-таблицы дали прирост примерно в 25%.

3. Redis стабильно использовал меньше ресурсов

• Redis не превышал 1.3 CPU и держал стабильное потребление памяти (~4–4.5 ГБ).
• PostgreSQL упирался в лимит CPU и требовал до 6 ГБ ОЗУ при нагрузке.

Когда стоит выбрать Postgres

Автор поста подчеркивает: несмотря на более высокую производительность Redis, он лично предпочитает Postgres в небольших и средних проектах:

• База данных все равно уже используется в проекте.
• Нет нужды в сложных TTL или автоудалении.
• Не хочется тянуть в проект еще одну зависимость.
• От 7000 до 8000 запросов в секунду — более чем достаточно для большинства задач.

7425 запросов в секунду — это больше полумиллиарда в день. Все на 10-летнем железе и обычном PostgreSQL. Мало кто работает на таких нагрузках.

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

Логика не по адресу

Как отмечает Эвальд Бенс, фуллстек разработчик и авторов популярного блога об IT, он предпочитает держать как можно больше логики в приложении, а не в SQL-хранилищах, представлениях и процедурах:

Я отношусь к базе как к тупому хранилищу данных. Вся логика — в коде. SQL просто не предназначен для сложных сценариев.

И дело не в том, что SQL чего-то «не умеет». Умеет — особенно с расширениями вроде PL/pgSQL или Oracle PL/SQL.

Но выразительность этих языков — далека от Python, TypeScript, Rust или C#, особенно когда речь идет о бизнес-логике, объектной модели или сложных расчетах.

Зачем выносить логику из базы?

1. SQL невыразителен

Для манипуляций с табличками и JOIN — он король. Но как только начинается рекурсия, классы, вложенные состояния или обработка ошибок — SQL превращается в монстра с BEGIN, IF, LOOP, EXCEPTION, RAISE, CURSOR, FETCH, WHILE и т.д...

2. Развертывание — боль

Обновить приложение можно за минуту, откатить — за две. А вот миграции на проде — это:

• повышенные права доступа;
• согласование с DBA;
• боязнь сломать что-то «наживую»;
• ручной откат схем.

3. Лочит на вендора

Логика, написанная на PL/SQL — это билет в один конец к Oracle. Переезд на PostgreSQL или SQL Server становится в 5 раз сложнее.

4. Меньше инструментов

Вокруг SQL есть утилиты, но полноценной среды с юнит-тестами, статическим анализом, форматтерами, профайлерами, линтерами и отладчиками — почти нет.

А что с производительностью?

Да, есть нюанс: иногда лучше обработать данные прямо в базе, чтобы не гонять десятки тысяч строк по сети. Это особенно актуально, если не хочется получить классическую проблему N+1-запросов.

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

Что делать?

Подход «база — хранилище, логика — в коде» стал де-факто стандартом во многих командах. Но это не догма:

• Для отчетности или простых ETL сценариев логика в SQL может быть уместной.
• Для монолитных решений без CI/CD и DevOps — процедурный SQL вполне оправдан.
• Но в современной разработке с частыми релизами, микросервисами и отказоустойчивостью бизнес-логика в приложении — просто удобнее и безопаснее.

Есть одна задача, которую программисты терпеть не могут — но именно она отличает хорошего инженера от посредственного: как они документируют свой проект? Несколько лет назад я отвечал за запуск финтех-проекта. Мы выбрали стратегию быстрого старта, поэтому масштабируемость не стала для нас приоритетом. Главной целью было проверить гипотезу — и мы двигались вперёд, разрабатывая API, архитектуру и системы — с упором на простоту, не особенно задумываясь о будущем.

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

Во время работы я наткнулся на подход, который мне очень понравился: ADR — Architectural Decision Record, или «протокол архитектурных решений».

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

Проще говоря, это как личный дневник — только для всей команды.

Почему это важно?

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

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

Будущие разработчики скажут вам спасибо. Подумайте о человеке, который через пять лет будет разбираться в вашем коде. Если вы не оставили объяснений, он, скорее всего, будет мучиться, пытаясь понять, зачем было сделано то или иное изменение. А теперь представьте другого разработчика в другой компании, который находит ADR-документ с чётким объяснением принятого решения. Он, без сомнения, будет вам благодарен.

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Ценность ADR я впервые осознала в 2019 году. В команду, где работала, активно набирали новых ребят, и приблизительно раз в неделю кто-нибудь из новых разработчиков спрашивал "а почему это сделано так, а не иначе?" Приходилось постоянно давать ответы на одни и те же вопросы, и тогда-то я и поняла, насколько будет удобно записывать ответы где-нибудь в документацию в confluence и просто кидать ссылку новичкам.

В 2019 году я еще не знала сам термин ADR и говорила "документация". С термином я познакомилась совсем недавно — этим летом, на курсе по архитектуре монолитных приложений. Тогда я поняла, насколько эффективно можно использовать ADR для ускорения разработки и уменьшения TTM. Дело в том, что начиная разрабатывать новый проект, разработчик первое время (от месяца до полугода! всё зависит от размера проекта) погружается в проект — разбирается, как всё устроено, чтобы вносить изменения соответственно архитектуре. В этот период разработчик, по сути, составляет собственные adr — обычно в виде мыслеобразов в своей голове :) Если записать основные решения, разработчик сможет намного быстрее погрузиться в проект.

Как писать ADR?

Существует несколько общепринятых правил, но вы всегда можете адаптировать их под себя.

Вдохновившее меня соглашение можно найти на GitHub . Вы также можете ознакомиться с процессом ADR на Amazon.

Вот пример шаблона, который вы можете использовать.

Такой тип документа может находиться прямо в репозитории проекта, в Confluence или, например, в JIRA.

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Многие руководители хотят видеть на своём проекте разработчиков, которые "сразу, без раскачки" начнут перформить. Совсем избежать периода погружения невозможно, но можно ускорить его в десятки раз за счёт ADR

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

Почему владение Django — не предел для разработчика

Особенности Django

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

Основные плюсы:

• Полноценный стек: ORM для работы с базой, мощная система маршрутизации URL, шаблоны для рендеринга, встроенная админка, формы, система аутентификации и авторизации.
• Архитектура MTV (Model-Template-View): похожа на классический MVC, но с особенностями, которые упрощают разделение логики, представления и данных.
• Безопасность: Django автоматически защищает от CSRF, XSS, SQL-инъекций и других распространенных атак. Не нужно писать много дополнительного кода.
• Активное сообщество и экосистема: тысячи сторонних пакетов, расширений и готовых решений.
• Поддержка нескольких баз данных: PostgreSQL, MySQL, SQLite, Oracle и др.

Ограничения:

• Синхронная природа Django.
• Монолитность: архитектура фреймворка ориентирована на создание крупных приложений, но в микросервисах может быть избыточна.
• Ограниченная гибкость ORM: нестандартные SQL-запросы иногда сложно выразить средствами ORM, приходится использовать raw SQL или сторонние библиотеки для запросов.
• Строгие правила организации кода: требуют дисциплины и могут ограничивать свободу в архитектурных решениях.
• Недостаточная производительность: уступает лёгким асинхронным фреймворкам (например, FastAPI), особенно под высокими нагрузками. Но для большинства проектов пока это не критично.

В каком направлении двигаться после изучения Django

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

Первое направление для развития — расширить инструментарий для решения разных задач в веб-разработке

Возможные пути:

• Изучить другие веб-фреймворки (Flask, FastAPI)
• Углубиться в асинхронное программирование (asyncio, aiohttp)
• Работать с API и микросервисами

Flask и FastAPI

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

FastAPI — современный асинхронный фреймворк, ориентирован на создание высокопроизводительных API. Поддерживает стандарт OpenAPI и автоматическую генерацию документации. Он быстрее Flask и Django благодаря asyncio и Pydantic.

Асинхронное программирование

Веб-разработка всё активнее использует асинхронные технологии. Django не всегда справляется с задачами высокой конкурентной нагрузки.

Поэтому изучение asyncio — стандартной библиотеки Python для асинхронного программирования — откроет перед вами новые возможности. Вместе с aiohttp или тем же FastAPI вы сможете создавать приложения, которые обрабатывают тысячи одновременных соединений. Это особенно важно для real-time сервисов, чат-приложений и систем с интенсивным обменом данными.

Второе направление — расширить навыки в смежных областях

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

Изучение DevOps и контейнеризации

Контейнеры позволяют запускать приложения в изолированной среде, это упрощает настройку и развертывание. Например, Docker помогает упаковать приложение с зависимостями в один контейнер, а Kubernetes — управлять такими контейнерами в продакшене. Знание этих технологий улучшит взаимодействие с операционной командой и ускорит выпуск новых версий приложений.

CI/CD и автоматизация процессов

Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment) — ключевые практики современной разработки ПО. Они позволяют автоматизировать сборку, тестирование и доставку приложений, масштабировать процессы.

Инструменты CI/CD (например, Jenkins, GitLab CI/CD, GitHub Actions) помогают настроить автоматические пайплайны, которые обеспечивают быструю обратную связь и минимизируют человеческий фактор в релизах. Автоматизация процессов снижает количество ошибок и позволяет сосредоточиться на разработке новых функций.

Настройка непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery) снижает поток ошибок при релизах и экономит время. Пример: GitHub Actions для автоматического запуска тестов и сборки проекта при каждом коммите.

Больше знаний в области баз данных

Помимо классических реляционных баз данных (PostgreSQL, MySQL), современные приложения часто используют NoSQL для специфичных задач. MongoDB, Redis, Cassandra обеспечивают гибкость в хранении данных, горизонтальное масштабирование и высокую производительность при работе с большими объемами информации.

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

Так, Redis хорошо подходит для кэширования данных, а Neo4j — для сложных связей между объектами.

Третье направление — переход к другим аспектам Python-разработки

Рассмотрим четыре варианта карьерного развития для Python-программиста: Data Science и машинное обучение, автоматизация бизнес-процессов, разработка десктопных приложений и встраиваемые системы (IoT).

Почему стоит попробовать?

• Высокий спрос на специалистов. Они востребованы в банках и инвестиционных компаниях, в сфере медицины и биотехнологии, в консалтинге, автомобильной промышленности и т.д..
• Широкий набор библиотек: pandas, NumPy, scikit-learn, TensorFlow, PyTorch.
• Возможность работать с реальными задачами: от бизнеса до науки.

Автоматизация и скрипты для бизнеса

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

Знание таких библиотек, как openpyxl (работа с Excel), requests (HTTP-запросы), BeautifulSoup и Scrapy (парсинг веб-страниц), а также умение писать скрипты под конкретные задачи, делают разработчика ценным специалистом в корпоративной среде.

Примеры задач:

• Автоматическая загрузка данных из Excel и их преобразование
• Скрипты для отправки email-рассылок
• Интеграция с CRM и другими сервисами через API

Разработка десктопных приложений (PyQt, Kivy)

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

Инструменты для создания:

• PyQt — мощный фреймворк для создания кроссплатформенных GUI.
• Kivy — библиотека для разработки приложений с поддержкой сенсорных экранов.

Этот путь подходит тем, кто хочет создавать удобные инструменты с графическим интерфейсом для пользователей на Windows, macOS или Linux.

Встраиваемые системы и IoT

В области IoT и встроенных систем Python набирает популярность благодаря легкости освоения и поддержке на маломощных устройствах. Помогают в этом платформы по типу Raspberry Pi и MicroPython.

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

Например, с помощью Python на Raspberry Pi можно разрабатывать датчики для мониторинга состояния оборудования на производстве и разрабатывать прототипы носимых устройств для сбора данных о здоровье.

Если рассматривать профессию “Python-разработчик на Django”, то сразу получится сужение до конкретной библиотеки на конкретном языке. Если же в резюме у специалиста стоит, что он “разработчик Python”, возможностей сильно больше. Если написать про себя “разработчик”, будет не понятно, разработчик чего. Но изменив резюме на “DevOps инженера”, становится понятен карьерный трек.

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

Получился антигайд: как гарантированно завалить базу данных — и что делать правильно. Если узнаете себя в этих советах, не расстраивайтесь. Через подобное проходят все. А если хотите услышать полную дискуссию о современных СУБД, инструментах и миграции на open source — послушайте оригинальный выпуск.

1. Временные файлы бесконечны — лейте терабайты джойнов

Берите две таблицы по миллиону записей каждая, смело делайте JOIN без WHERE, сортируйте результат — и удивляйтесь, почему закончилось место под временные данные.

Что происходит: PostgreSQL создает временные файлы в pg_tmp для обработки больших запросов. Когда места не хватает, падают конкретные запросы с ошибкой No space left on device, а не весь сервер. Особенно болезненно там, где несколько таких запросов запускаются параллельно — временное пространство переполняется быстрее, чем успевает сработать мониторинг.

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

2. Суперпользователь для всех задач — что может пойти не так

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

Реальная история: Разработчик развернул постгрес на виртуалке с дефолтными настройками — порт 5432 открыт, пользователь postgres/postgres с правами суперпользователя. Через семь (!) секунд в базу начали ломиться боты. Боты сканируют интернет на стандартные порты СУБД постоянно и превращают сервер в майнинг-ферму быстрее, чем вы успеете допить кофе. Диск переполнился от созданных таблиц, установились неизвестные расширения, начались HTTP-вызовы из базы наружу. Сервер превратился в часть ботнета.

И так все понятно, но еще раз напомним: Суперпользователь может подключить postgres_fdw, dblink и читать/писать любые базы кластера, создавая запросы, которые переполнят временное пространство за минуты. Неподписанные расширения могут содержать что угодно — от бэкдоров до майнеров. А если расширение вызовет segmentation fault, упадет вообще все.

Принцип минимальных прав: Создавайте отдельных пользователей с минимально необходимыми правами. Устанавливайте только официально поддерживаемые расширения. Закрывайте базу от внешнего доступа файрволом, настройте TLS для шифрования трафика, используйте fail2ban против брутфорса и уникальные пароли. Это кажется очевидным, но количество баз с дефолтными паролями в интернете говорит об обратном.

3. Держите транзакции открытыми — счетчик XID все стерпит

Открывайте длинные транзакции и держите их днями. Постгерс умный, сам разберется.

Что сломается: У PostgreSQL есть счетчик транзакций (XID), который может переполниться. Когда возраст транзакций становится критическим, сервер блокирует обычные подключения и пускает только суперпользователя для выполнения VACUUM FULL. Все приложения встают, начинается паника.

Как избежать: Настройте timeout для idle in transaction состояний. Разбивайте большие батчи на маленькие операции. Мониторьте возраст самых старых транзакций. И запомните: транзакция, которая висит неделю, — это не фича, это бомба замедленного действия.

4. На каждый SELECT — свой индекс

Создавайте индекс под каждый запрос. Чем больше индексов, тем быстрее будет работать.

Почему это убивает PostgreSQL: В отличие от других СУБД, PostgreSQL при UPDATE создает новую версию записи, а старую помечает как мертвую. Если у таблицы 30 индексов, каждый UPDATE генерирует 30 мертвых ссылок в индексах. VACUUM начинает работать постоянно, производительность рушится.

Правило 20/80: Покройте индексами 20% самых частых запросов, которые дают 80% нагрузки. Остальную аналитику выносите на реплику для чтения. Регулярно анализируйте статистику использования индексов — неиспользуемые безжалостно удаляйте .

5. Сайзинг не нужен

Ресурсы бесконечны. А DBA разберутся, как бэкапить ваши 100 терабайт.

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

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

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

6. Пихайте СУБД в контейнеры

Kubernetes решает все проблемы! Поэтому переносим в контейнеры все, базы данных тоже. Если что-то работает на виртуалках, то в контейнерах точно будет работать лучше.

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

Где контейнер оправдан? В CI/CD, локальной разработке, тестовых средах. В продакшне контейнеры тоже работают, если использовать Kubernetes-операторы (Patroni, CloudNativePG), правильно настроить Persistent Volumes и протестировать поведение при рестартах. База должна жить в памяти, прогревать кэши, работать стабильно. Но это требует серьезной экспертизы в Kubernetes и готовности разбираться с проблемами на стыке технологий. Если команда не готова изучать все тонкости — лучше не начинать.

Компромисс: Если выбираете контейнеры для продакшна, используйте StatefulSet, настройте правильные storage-классы и OOM-политики. Для stateless-сервисов контейнеры — отличный выбор.

7. Всю бизнес-логику держим в хранимках — так быстрее

Переносите всю логику в базу. Зачем нужны сервисы приложений?

Пример из практики: Система с хранимыми процедурами Oracle обыграла Java-реализацию в тестах производительности. Логика выполнялась рядом с данными, без сетевых задержек. Но когда нагрузка выросла в разы, уперлись в лимит CPU на сервере баз данных. Добавить ресурсы оказалось сложнее, чем масштабировать stateless-сервисы.

Компромисс: Тяжелые агрегации и отчеты делайте в функциях базы. CRUD-операции выносите в сервисы приложений. Следите за загрузкой CPU на сервере БД — когда она приближается к пределу, начинайте выносить логику наружу.

8. Коммерческая СУБД — единственный путь

Только коммерческие решения подходят для серьезных задач. Oracle и SQL Server проверены временем, а всякие open source базы — это для студентов и стартапов.

Что изменилось: События последних лет заставили многие компании пересмотреть подход к выбору СУБД. Компании массово переходят на PostgreSQL Pro и другие open source решения. Тренд только усиливается — игнорировать open source значит отстать от рынка и пропустить инновации, которые часто появляются именно в открытых проектах.

НО: Vanilla PostgreSQL без поддержки — это действительно риск. Когда расширение Oracle FDW падает с разными структурами таблиц, а автор из коммьюнити отвечает «мне в голову не приходило, что кто-то будет так делать», понимаешь ценность платной поддержки. Поэтому open source, но с поддержкой от надежных вендоров.

Заключение

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

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

И ему это удалось: производительность упала с 7082 транзакций в секунду до 0,016 TPS, то есть более чем в 42 000 раз.

Причем он не трогал железо, не удалял индексы и не вмешивался в код — все только через postgresql.conf.

Минимальный кэш и перегруженный autovacuum

Первый шаг — почти отключить кэш: shared_buffers = 2MB. Это резко снижает буферизацию страниц и увеличивает обращения к диску.

Затем — заставить Postgres непрерывно запускать autovacuum и analyze после каждой вставки. В итоге в логи будут падать десятки операций в секунду. Почти без пользы, но с большим I/O.

WAL, как у Брэндона Сандерсона

Потом автор усложнил систему логов WAL: настроил частые чекпоинты (checkpoint_timeout = 30, max_wal_size = 32MB) и принудил Postgres писать каждый байт максимально медленно (wal_sync_method = open_datasync, wal_level = logical).

Производительность упала до менее 1 TPS.

Отключение индексов и однопоточный I/O

Без удаления самих индексов автор просто сделал их бессмысленными для планировщика запросов: random_page_cost и cpu_index_tuple_cost были задраны до 1e300.

Вдобавок, Postgres был переведен на io_method = worker с io_workers = 1, чтобы все дисковое I/O выполнялось одним потоком.

Финал

В итоге Postgres смог обработать всего 11 транзакций за 2 минуты со 100 подключениями.

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

1. Pandas

Pandas — библиотека для работы с данными в Python, позволяющая легко загружать, анализировать, очищать и преобразовывать числовую информацию в удобной табличной форме. По сути, это Excel, который смог, и позволяет делать всё автоматизировано и на порядки быстрее.

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

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

Почему это меняет карьеру

Работа с Pandas становится границей между знанием Python и умением решать задачи бизнеса. Для джуна это шанс сразу показать практическую пользу: выгрузки, отчёты и базовый анализ можно делать в десятки раз быстрее и аккуратнее, чем вручную в эксельке.

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

Для ML-инженера владеть Pandas — значит уметь готовить датасеты качественно; быстро очищать и приводить данные к нужному виду, что напрямую влияет на результат моделей. Без этого работа над проектами машинного обучения часто превращается в бесконечную возню с данными.

Наконец, даже для разработчиков Pandas может стать неожиданным бустом в карьере. Например, когда нужно автоматизировать отчёты для бизнеса или быстро анализировать логи и данные из БД без поднятия дашбордов — Pandas даёт гибкость и скорость, которые редко даёт что-то ещё в экосистеме Python.

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

Django подходит как стартапам, которым нужно быстро выйти на рынок, так и крупным проектам с миллионами пользователей. Это не просто библиотека, а полноценный каркас для построения и сопровождения веб-сервисов.

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

Django позволяет сосредоточиться на бизнес-логике и продукте, не тратить недели на настройку инфраструктуры.

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

Сегодня PyTorch используется в продакшен системах, научных исследованиях, компьютерном зрении, NLP и генеративных моделях, занимая ведущее место в индустрии.

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

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

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

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

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

Polars меняет карьеру, потому что даёт преимущество в скорости и эффективности при работе с данными. Там, где Pandas уже не справляется, полярный медведь приходит на помощь.

Для дата-инженеров Polars полезен при построении ETL и пайплайнов обработки данных, где важна скорость и предсказуемое потребление ресурсов. Его можно использовать в продакшен-скриптах, для подготовки данных к ML и для автоматизации отчётности.

Для дата-сайентистов Polars даёт возможность анализировать больше данных за меньшее время, быстро итерировать гипотезы и ускорять исследования. Его API достаточно близок к Pandas, поэтому переход не требует месяцев переучивания.

Освоение Polars показывает работодателям, что ты не просто знаешь стандартные инструменты, но умеешь выбирать оптимальные решения для реальных задач, повышая эффективность работы команды. В эпоху роста данных это критично для любого Python-разработчика, работающего с аналитикой и машинным обучением.

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

Вместо долгой настройки, как у Flask или Django, в FastAPI многое готово изначально: удобная работа с запросами и ответами, декларативная валидация, документация Swagger, асинхронность и высокая производительность без лишних усилий.

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

Для ML-специалиста FastAPI становится инструментом для деплоя моделей: можно обернуть пайплайн предсказаний в API, подключить авторизацию или логирование и получить работающий сервис за считанные дни.

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

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

Typer меняет карьеру тем, что открывает путь к созданию удобных CLI-инструментов, которые автоматизируют рутину и повышают продуктивность.

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

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

Кроме того, работа с Typer улучшает навык структурирования кода, понимание CLI, использования type hints и разработки инструментов, которые делают работу проще для других. А это, очевидно, ценится в любой команде и повышает востребованность специалиста.

7. Rich

Rich — библиотека Python для красивого форматирования и интерактивного отображения информации в терминале. С её помощью можно выводить цветные таблицы, маркдаун, прогресс-бары, подсвеченный синтаксис кода, деревья каталогов и логирование в понятной и привлекательной форме.

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

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

Почему это меняет карьеру

Rich — это библиотека, которая помогает быстро повысить качество любого CLI-инструмента или дев-опыт в команде. Разработчик, который использует Rich, делает свои инструменты удобными не только для себя, но и для коллег: логирование становится понятным, а отладка скриптов — наглядной.

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

Кроме того, Rich позволяет быстро создавать CLI-интерфейсы, которые выглядят как продакшен-продукты, даже если это внутренние инструменты. Руководство будет радоваться и думать о вас как о крутом разрабе.

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

LangChain предоставляет удобный слой абстракции над вызовами LLM и ускоряет разработку чат-ботов, RAG-приложений, агентов с инструментами, систем анализа документов и других AI-сервисов.

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

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

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

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

LangChain позволяет быстро собирать и запускать MVP AI-продуктов, что дает конкурентное преимущество при создании стартапов или внутренних сервисов. А ещё учит мыслить структурами и проектировать масштабируемую архитектуру LLM-приложений и видеть, как генеративный ИИ можно превратить в рабочий инструмент.

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

Создадим минимальный пример для SQLite с таблицей пользователей:

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

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

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

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

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

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

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

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

Для построения более сложных графиков можно использовать диаграмму рассеяния:

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

Почему это меняет карьеру

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

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

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

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

Что такое счётчик транзакций и зачем он нужен?

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

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

MVCC в PostgreSQL работает похожим образом:

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

Каждая версия строки имеет специальные метки:

• xmin — идентификатор транзакции, которая создала версию.
• xmax — идентификатор транзакции, которая удалила (или обновила) версию. Если строка ещё не удалена, xmax пустой.

Когда транзакция читает данные, PostgreSQL определяет, какую версию строки ей показывать, на основе правил видимости:

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

Пример:

Допустим, у нас есть таблица users с данными:

1. Транзакция 1 (xid=100) начинается и читает таблицу Она видит обе строки, потому что они были созданы до её начала, и xmax у них пустой.

2. Транзакция 2 (xid=105) начинается и обновляет возраст Alice на 31. PostgreSQL не перезаписывает строку Alice, а создаёт новую версию:

3. Обратите внимание, что у старой версии Alice xmax теперь равен 105 (идентификатор транзакции 2), а у новой версии xmin равен 105.

4. Транзакция 1 снова читает таблицу. Она по-прежнему видит старую версию Alice (возраст 30), потому что новая версия была создана транзакцией, которая началась позже (105 > 100), а старая помечена как удалённая транзакцией с большим номером.

5. Транзакция 2 фиксируется.

6. Транзакция 3 (xid=110) начинается и читает таблицу Теперь она видит новую версию Alice (возраст 31), потому что транзакция 2, которая её создала, уже зафиксирована, и её xid меньше чем у транзакции 3.

Важно: номера транзакций (xid) не стоит сравнивать как обычные числа («больше» или «меньше»). Корректнее говорить «старше» или «младше». Дело в том, что номера транзакций сравниваются по модулю 232, образуя кольцо. Транзакции, отстающие от текущей на 231 назад, считаются «старше» («в прошлом»), а на 231 вперёд — «младше» («в будущем»).

Представьте себе круг:

• текущая транзакция — это точка на круге;
• «прошлые» транзакции — это точки слева от текущей, если двигаться против часовой стрелки;
• «будущие» транзакции — точки справа.

Каждая запись в базе данных имеет служебные поля xmin и xmax. В xmin записывается номер транзакции, создавшей запись, а в xmax — номер транзакции, удалившей её. Учетом этих номеров и занимается счетчик транзакций.

Как развивался счётчик транзакций

До версии PostgreSQL 8.2 при достижении максимального значения счётчика транзакций (примерно 4 миллиарда) PostgreSQL просто «падал». Чтобы продолжить работу, нужно было сделать дамп базы данных и создать её заново.

В версии 8.2 появился механизм циклического перезапуска счётчика. Для этого в фоновом режиме запускается процесс очистки (VACUUM).

Как это работает:

1. «Заморозка» старых транзакций: Когда на VACUUM передаётся значение, что счётчик транзакций скоро переполнится, он начинает помечать старые транзакции специальным идентификатором FrozenTransactionId. По сути, VACUUM говорит: «Эти транзакции настолько старые, что мы считаем их замороженными. Мы всегда будем считать их старше любых других транзакций.»
2. Счётчик эпох: Чтобы PostgreSQL знал, сколько раз счётчик уже «перезапускался», используется счётчик эпох. Каждый раз, когда счётчик транзакций доходит до конца и начинает заново, счётчик эпох увеличивается на единицу.
3. Циклический перезапуск: После того как VACUUM «заморозит» старые транзакции, счётчик транзакций может безопасно начать считать заново с трёх. PostgreSQL теперь знает, что все транзакции с идентификатором FrozenTransactionId старше любых других транзакций, даже если их номера меньше.

Это решило проблему «падения», но возникла новая: если VACUUM не успевает отработать вовремя, сервер может остановиться и потребовать запуска в монопольном режиме для очистки, что ведёт к простою.

В чём же проблема?

Сам по себе механизм счётчика транзакций работает хорошо. Проблема в том, что он создавался, когда 32-битное число (более 4 миллиардов) казалось огромным. Сейчас же, в системах с высокой нагрузкой (ретейл, крупные заводы, госучреждения), счётчик может оборачиваться раз в сутки.

Дополнительные сложности:

Среди служебных данных записи есть поле флагов. Для старых записей нужно периодически запускать VACUUM FREEZE, который помечает их как «замороженные» (FrozenTransactionId).

Для стабильной работы нужно, чтобы:

• разница между номером текущей транзакции и номером самой старой записи не превышала 2^32;
• VACUUM FREEZE выполнялся до нарушения первого условия.

В реальном мире это сложно:

• «долгие» транзакции мешают VACUUM FREEZE;
• сложно определить, когда транзакция «долгая», а когда «зависшая»;
• непонятно, когда бить тревогу из-за исчерпания идентификаторов;
• администратор БД несёт ответственность за потери бизнеса из-за своих действий.

Если вы можете остановить кластер БД, запустить его в монопольном режиме и подождать несколько часов, эта проблема вас не касается. Но в системах с высокими требованиями к доступности простой — недопустим.

Отдельно стоит упомянуть базы данных, в которые данные только добавляются (insert-only). В них VACUUM всё равно запускается для «заморозки» старых записей.

Решение: 64-битные идентификаторы транзакций

Казалось бы, простое решение — увеличить размер счётчика до 64 бит. Но это сложно:

• весь код PostgreSQL ожидает «видеть» 32-битные числа;
• в каждом кортеже (записи) хранятся xmin и xmax. Увеличение их размера с 8 до 16 байт значительно увеличит размер базы.

Мы в Postgres Professional разработали реализацию 64-битных идентификаторов транзакций (xid), увеличив их количество до 18 446 744 073 709 551 615 (264). Это решение используется во многих форках PostgreSQL. Проблема переполнения счётчика становится гипотетической (при высокой нагрузке 64-битный счётчик исчерпается примерно через 400 лет).

Патч с реализацией был предложен сообществу PostgreSQL, но пока не принят из-за его сложности. Однако многие разработчики форков PostgreSQL уже заявили о поддержке 64-битных xid в своих дистрибутивах.

Цель Postgres Professional — не продвигать свой вариант как единственно верный, а привлечь внимание к проблеме и стимулировать сообщество к поиску оптимального решения. Первая часть удалась: идея получила внимание. Но внедрение таких изменений — долгий процесс. Рост нагрузок на СУБД во всём мире показывает важность этой проблемы.

Мы надеемся, что PostgreSQL сможет адаптироваться к растущим нагрузкам и укрепить свои позиции на рынке.

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

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

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

Климатические инициативы в IT больше не просто красивые слова в корпоративных отчетах. В 2025 году за неэффективный код можно получить не только порицание сообщества, но и вполне реальный штраф.

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

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

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

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

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

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

C++ остается выбором для задач, где важна предсказуемая производительность. Новый стандарт C++26 добавил энергоэффективные режимы работы алгоритмов STL, что особенно важно для встраиваемых систем.

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

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

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

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

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

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

Особенности локальных хранилищ

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

Семь «грехов» локальных кластеров

Теперь поговорим о том, какие неприятные особенности встречаются во время эксплуатации локальных кластеров.

Структура данных и хаос

В реальных системах данные редко бывают аккуратными. Вместо красивых таблиц разработчик часто сталкивается с миллионами мелких файлов по 1-2 Кб и, например, видео по несколько Гб. Такие крайности требуют противоположных стратегий хранения и кэширования.

Файловая система, не оптимизированная для работы с малыми файлами, быстро забивается inode'ами (переполнение файловых дескрипторов). Системы хранения начинают задыхаться не от общего объема, а от количества объектов, что критически влияет на производительность. Например, известны случаи, когда после миллиона объектов OpenStack Swift начинал терять метаданные, а в хранилищах висели призраки удаленных объектов.

RAID — не универсальное спасение

Настройка RAID-массивов кажется очевидным решением, но не все так однозначно:

• RAID 5 и 6 плохо переносят большие объемы из-за длительного времени восстановления.
• RAID 10 требует удвоения или утроения объема хранения ради скорости и отказоустойчивости.
• На петабайтных объемах пересборка массива после сбоя может занимать больше недели.

Поддержка архивов и ZIP-файлов

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

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

Автоматизация мониторинга и ремонта

Любая система хранения живет с постоянным риском деградации: умирают диски, выходят из строя контроллеры, падают сети. На уровне сотен и тысяч узлов мониторинг «вручную» невозможен: требуется автоматизированная оркестрация алертов, самовосстановление, динамическая миграция данных на здоровые узлы. Иначе разрастание локальных отказов перерастает в потерю данных.

Шардирование данных: неизбежность и боль

На больших объемах данных (более 250 Тб) приходится шардировать — разбивать на независимые логические части, чтобы сохранить производительность. Но с шардированием есть проблемы:

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

Более того, встроенные механизмы шардирования некоторых популярных СУБД (MongoDB, PostgreSQL с партиционированием) не рассчитаны на миллиарды записей и начинают деградировать.

Проблемы метаданных

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

Резервное копирование на практике

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

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

Облачные хранилища

С локальными хранилищами разобрались, теперь рассмотрим технические особенности альтернативного решения.

Гибкость и масштабируемость без ограничений

В облаке увеличение объемов хранения происходит мгновенно:

• без ожидания закупки нового оборудования;
• без сложного планирования миграций;
• без перебоев в обслуживании приложений.

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

Финансовая прозрачность и удобная модель оплаты

Модель Pay-As-You-Go (оплата по факту использования) дает бизнесу и разработчикам:

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

Такая прозрачная модель помогает экономить бюджет без потери качества сервиса.

Надежность и отказоустойчивость «из коробки»

S3-совместимый Object Storage обеспечивает высокую доступность данных благодаря:

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

Оптимизация работы с любыми типами данных

Хранилище позволяет одинаково эффективно работать:

• с миллионами мелких файлов (фото, документы, логи);
• с тяжелыми объектами (видео или архивами).

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

Высокий уровень безопасности данных

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

• шифрования на стороне клиента и сервера;
• гибкого управления правами доступа (ACL, IAM);
• соответствия требованиям хранения ПДН и прочих стандартов безопасности;
• автоматического обнаружения потенциальных уязвимостей.

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

Инструменты для разработчиков и автоматизации

Хранение данных в облаке ориентировано на удобство интеграции и масштабирование за счет:

• полного набора API и SDK для популярных языков программирования;
• готовых модулей для работы с данными в распределенных системах;
• продвинутых средств мониторинга, алертинга и автоскейлинга;
• поддержки DevOps практик через IaC-инструменты.

Автоматизация всех процессов упрощает разработку и сопровождение проектов, значительно снижая риски человеческих ошибок.

Опыт хранения больших данных

Когда речь идет о масштабных системах хранения — таких как S3-совместимый сервис Object Storage на платформе VK Cloud, — производительность определяется не только скоростью сети и дисков. Ключевую роль играют архитектурные особенности приложений: как именно данные распределяются, обрабатываются и индексируются.

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

Как измеряется производительность облачного хранилища

Для реальной оценки производительности облачного хранилища важно замерять:

• Количество операций в секунду (RPS): сколько запросов на чтение/запись способна обработать система.
• Среднюю и 99-ю персентиль задержек: критично для оценки качества обслуживания конечных пользователей.
• Производительность на больших объемах объектов: важно не просто тестировать один файл, а моделировать реальную работу приложений с множеством параллельных операций.
• Влияние мелких и крупных файлов: системы по-разному работают при миллионах маленьких объектов и гигабайтных видео.

Практические сценарии измерений:

• многопоточная загрузка 100 миллионов объектов размером 1–10 КБ;
• массовое чтение миллионов объектов через S3 API;
• удаление больших объемов объектов для оценки работы сборки мусора;
• сценарии с версионированием объектов, чтобы проверить нагрузку на метаданные.

Почему шардирование критически важно для облачного хранилища

Правильная организация шардирования данных — один из ключевых факторов производительности больших хранилищ.

Что происходит без правильного шардирования:

• «Горячие» бакеты (S3-бакеты) с высокой нагрузкой становятся узким местом.
• Распределение нагрузки по серверам становится неравномерным.
• Метаданные начинают тормозить операции доступа.
• Снижается общая масштабируемость системы.

Реальная практика VK Cloud:

• Метаданные объектов распределяются по кластерам через шардирование по диапазонам ключей.
• При превышении нагрузки шард автоматически расщепляется (split) для перераспределения нагрузки между нодами.
• Для хранения метаданных используется Tarantool как высокоскоростная in-memory база данных, способная выдерживать сотни тысяч операций в секунду на один шард.

Такой подход позволяет обеспечить:

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

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

За что мы любим Tarantool

Принцип работы СУБД Tarantool кардинально отличается от классических SQL-баз (PostgreSQL, MySQL) в хранилищах:

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

Как правильно проектировать нагрузку на S3-совместимое облако

Если вы проектируете высоконагруженную систему, важно:

• Использовать естественное шардирование ключей (например, вставлять случайные префиксы в имена объектов).
• Ожидать миллионы объектов в бакете и строить приложения так, чтобы они не зависели от скорости листинга всех файлов.
• Минимизировать количество операций массового удаления объектов — использовать batch-удаление через S3 API.
• Понимать, что работа с метаданными так же важна, как и сама передача данных.

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

Заключение

Работа с петабайтными объемами данных требует серьезного подхода к проектированию инфраструктуры. На этом пути локальные решения сталкиваются с проблемами масштабирования, отказоустойчивости, обновления оборудования и обеспечения безопасности. Управление инфраструктурой превращается в отдельный проект со своими ресурсами.

Облачное хранилище обеспечивает:

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

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

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

METEOR — мощный инструмент для автоматизации процессов, с триггерами, серверными функциями и ИИ-аналитикой. Он позволяет гибко настраивать сложные операции.

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

После внедрения METEOR команды замечают, что продуктивность их работы сильно повышается:

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

Помимо самого Gitlife, разработчики делают Gitlife AI, в котором есть доступ к топовым ИИ-моделям и инструментам, чтобы разрабатывать ИИ-решения.

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

Cerebro — профессиональная система для совместной работы и управления проектами. Она помогает ставить задачи, планировать этапы, следить за выполнением, обмениваться файлами и комментировать их прямо в системе. Особенно полезна для команд, которые делают VFX, 3D, анимацию или дизайн — но при этом легко адаптируется и под другие команды.

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

А главная фишка — встроенный ИИ, к которому можно обращаться прямо во время написания кода. Инструмент разработан с акцентом на простоту входа, командную работу и быстрое прототипирование. Поддерживает более 50 языков программирования и позволяет запускать полноценные веб-приложения в облаке.

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

Replit Teams позволяет моментально начать работу: не нужно ставить зависимости, конфигурировать CI или закупать сервера. Подходит как для быстрой прокачки навыков, так и для реальных командных проектов в продакшене.

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

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

Откуда началось: мой путь в финтех

До Finance.kz я работал в казахстанских финтех-проектах — bai.kz и finbee.kz. Там понял, что рынок агрегаторов в Казахстане находится в зачаточном состоянии. Пользователи мучились, сравнивая предложения банков вручную, а сами финансовые организации не умели эффективно работать с цифровыми каналами привлечения клиентов.

Finance.kz существовал уже более 3 лет, но работал как классический сайт-витрина. Когда я пришёл в проект год назад, стало ясно: нужно полностью переосмыслить подход и создать технологическое решение нового поколения.

Состояние рынка: от монополии к жёсткой конкуренции

Казахстанский рынок агрегаторов финансовых продуктов переживает бум. Ещё два года назад здесь было 2-3 локальных игрока с простейшим функционалом. Сегодня ситуация кардинально изменилась — зашли зарубежные команды: vbr.kz, fintree.kz, moneypanda.com и другие.

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

Технологические вызовы: интеграция с госсервисами и банками

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

API-интеграции с банками и МФО

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

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

Интеграция с госорганами

Finance.kz интегрируется с государственными сервисами eGov и Палаты предпринимателей (ПКБ). Это позволяет автоматически подтягивать справки о доходах, данные о трудоустройстве и другие документы, необходимые для получения кредита.

Работа с госAPI — отдельная история. Протоколы меняются, документация часто устаревает, а техподдержка работает в режиме «как получится». Но результат того стоит: время оформления кредита сокращается с нескольких дней до 15-30 минут.

Архитектура продукта: ставка на микросервисы

При проектировании архитектуры Finance.kz мы отказались от монолитного подхода в пользу микросервисов. Это решение диктовалось спецификой агрегатора — нам нужно было обеспечить высокую доступность при интеграции с десятками внешних систем.

Backend

Основные сервисы написаны на Node.js с использованием Express.js. Для работы с базами данных используем PostgreSQL для транзакционных данных и Redis для кэширования. Очереди сообщений реализованы через RabbitMQ — это критично для обработки заявок пользователей.

Отдельно выделили сервис интеграций, который отвечает за взаимодействие с внешними API. Он построен по принципу circuit breaker — если один из банков не отвечает, это не ломает работу всего агрегатора.

Frontend

Фронтенд построен на React с использованием Next.js для серверной отрисовки. Это важно для SEO — львиная доля трафика приходит из поисковых систем по запросам типа «кредит онлайн».

Стратегия «единого окна»: от поиска до получения

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

Для этого мы реализовали несколько ключевых функций:

• Умный подбор продуктов на основе данных пользователя и машинного обучения
• Предварительный скоринг для оценки вероятности одобрения ещё до подачи заявки
• Автоматическое заполнение анкет с подтягиванием данных из госсервисов
• Отслеживание статуса заявки в реальном времени

Монетизация: CPS как основа устойчивого бизнеса

Мы работаем по модели CPS (Cost Per Sale) — получаем комиссию только за успешно выданные продукты. Для кредитов это 2% от суммы, для микрозаймов — фиксированная сумма от 7 до 15 тысяч тенге.

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

Конкурентные преимущества: локализация против красивых интерфейсов

Главное отличие Finance.kz от зарубежных конкурентов — интеграция в казахстанскую финтех-экосистему. Пока они тратят месяцы на адаптацию готовых решений, мы изначально строили продукт под местную специфику.

Что даёт локальный подход:

• Знание рынка: мы понимаем особенности работы казахстанских банков и МФО
• Связи с регуляторами: легче договариваться об интеграциях с госорганами
• Техническая экспертиза: наша команда уже прошла путь интеграции с местными API
• Гибкая настройка продукта под изменения законодательства и требований ЦБ

Результаты и метрики

За год активного развития мы достигли:

• 150 000 уникальных пользователей в месяц
• Интеграция с 15+ финансовыми организациями
• Конверсия заявка-выдача на уровне 35-40% (против 15-20% у конкурентов)
• Средний чек по кредитам — 1,2 млн тенге, по микрозаймам — 85 тысяч

Планы на будущее: от агрегатора к экосистеме

Ближайшие 1-2 года будут критичными для всего рынка. Мы видим несколько ключевых направлений развития:

Расширение продуктовой линейки

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

Внедрение ИИ и машинного обучения

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

Международная экспансия

Рассматриваем возможность выхода на рынки Узбекистана и Кыргызстана. Наша технологическая платформа легко масштабируется на соседние рынки.

Собственные финансовые продукты

В долгосрочной перспективе планируем получить лицензию МФО и предлагать собственные займы наиболее качественным клиентам.

Уроки и выводы

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

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

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

Этап 1: Простой MVP за $0

Изначально нужно создать максимально простое приложение для управления задачами: веб-страница с несколькими категориями и возможностью добавлять таски. На фронте разработчик использует библиотеку Shad CN UI, а на бэке — Flask. Данные хранятся просто в словаре Python. Все приложение — это один файл. Оно запускается в Docker-контейнере через docker compose.

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

Этап 2: Инфраструктура на $30

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

• База данных: PostgreSQL.
• Веб-сервер: Nginx для проксирования запросов и избавления от портов.
• Аутентификация: авторизация через JWT и интерфейсы входа и регистрации на фронтенде.

Все эти компоненты подключаются к существующему приложению через docker-compose.yml. Благодаря этому теперь можно запускать приложение на localhost, а не по порту, и все будет работать как полноценное веб-приложение. Размещение такой системы на бесплатном облачном тарифе или VPS обойдётся в пределах 30 долларов.

Этап 3: Допиливание до $100

Разработчик добавляет допфункции:

• Уведомления по email: вместо стороннего API — система очередей с RabbitMQ и воркером, который отправляет письма.
• Обновления в реальном времени: WebSocket’ы для синхронизации задач на разных устройствах.
• Кэширование: Redis для хранения данных в памяти, что значительно ускоряет работу.

Также подключается Docker Build Cloud — сервис для параллельной сборки контейнеров и шаринга кеша между проектами. Это повышает производительность и ускоряет разработку.

Теперь в системе работает очередь заданий, кеш, WebSocket-сервер, SMTP и полноценная база данных. Все эти компоненты увеличивают инфраструктурные затраты до примерно $100 в месяц.

Этап 4: Мониторинг и масштабирование за $500

Разработчик внедряет:

• Логирование: стек ELK (Elasticsearch, Logstash, Kibana).
• Мониторинг: Prometheus и Grafana.
• Горизонтальное масштабирование: добавляются реплики некоторых сервисов и балансировка нагрузки через Nginx.

Эти инструменты позволяют отслеживать метрики, визуализировать логи, следить за состоянием приложений и быстро выявлять сбои. Инфраструктура становится ближе к корпоративному уровню. Стоимость такого комплекса достигает уже около 400–500 долларов в месяц.

Этап 5: Целых $2000 долларов

Разработчик решает перейти на Kubernetes и развернуть приложение в разных дата-центрах по всему миру. Для управления трафиком используется глобальный балансировщик нагрузки (например, Cloudflare). А чтобы все работало стабильно, внедряются:

• Postgres с репликацией в реальном времени,
• Redis для быстрой отдачи данных.

Сейчас без ИИ приложение уже не имеет смысла. Поэтому разработчик решает добавить серверлесс-функции с категоризацией задач, приоритетами и предложениями на основе поведения пользователей, а также с использованием обработки естественного языка для создания тасков. Также подключаются правовые ограничения — поддержка GDPR и CCPA.

Для мониторинга:

• Jaeger — для распределённой трассировки,
• ELK Stack — для логов,
• Grafana + PagerDuty — для алертов и инцидентов.

Вишенка на торте — план восстановления после катастроф: бэкапы, автоматическое переключение на другие регионы и подготовка команды.

Хотя вся система началась с одного Python-файла и простого UI, шаг за шагом разработчик добавлял в нее компоненты, которые делают её пригодной для реального продакшена: защита, масштабируемость, отказоустойчивость, мониторинг, кеширование и очереди. И оно вполне может стоить несколько сотен или даже тысяч долларов в месяц при развертывании в облаке.

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

Учеба без бюджета — только ИИ и бесплатные курсы

Эрик решил не тратить ни копейки на курсы. Он выбрал Python как основной язык и прошел CS50 от Гарварда — сначала курс по Python, потом по веб-разработке.

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

Свой первый проект он сделал по мотивам Wordle — игру на угадывание слов он реализовал на Python под названием PyWordle.

Затем собрал полноценное веб-приложение Make My Meal Plan: генерация рецептов, списки покупок, TailwindCSS, Django, PostgreSQL, CI/CD и даже тестирование через Playwright — все своими руками за 150 часов. Проект включал 25 000 строк кода.

Работа после 100 дней

Через 3 месяца обучения он получил оффер. Без Leetcode, без алгоритмических задач — только благодаря портфолио. Его взяли на испытательный срок в консалтинговую компанию в Лондоне, чтобы он заменил Excel и устаревшие тулзы на автоматизированные пайплайны.

Эрик честно рассказал, что научился программировать за пару месяцев и активно использовал ИИ — и все равно его приняли.

По его словам, весь путь стоил $120 — подписки на Claude Pro и Cursor. Все остальное — бесплатные курсы и открытые материалы. Недавно он прошел испытательный срок, получил повышение и теперь работает с геоданными и статистикой, используя pandas и ArcGIS. Параллельно пишет Django-приложение для анализа населения и доходов в Великобритании.

«Точно вовремя» вместо «на всякий случай»

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

Как выучить SQL: ТОП-6 платформ для обучения

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

Критерии оценки

• Контент: глубина тем (от SELECT до оптимизации запросов), задачи из реальной работы, подготовка к собеседованиям, поддержка сообщества.
• Технические аспекты: мобильная версия, своя IDE, сертификат, адаптация под РФ, поддержка PostgreSQL.

SYNC STUDY

Ссылка: SYNC STUDY

Для кого: Новички, профи и те, кто готовится к собеседованиям.

• Глубина погружения: Полный цикл — от основ (WHERE, JOIN) до оконных функций и создания витрин.
• Собеседования: Отдельный модуль с кейсами из практики и с теоретическими вопросами с собеседований.
• Практика: Задачи на расчет LTV, ABC-анализ, парсинг логов.
• Техническая часть: Удобная мобильная версия, своя IDE. Полная адаптация под РФ.

• Решения воспроизводятся в реальной среде PostgreSQL.

Минусы:

• Поддержка в процессе прохождения: отсутствует.
• Сертификат по окончании курса: нет.

SQL Academy

Ссылка: SQL Academy

Для кого: Новички и практикующие разработчики.

• Глубина погружения: От простых запросов до триггеров и оптимизации. Подробные примеры из e-commerce.
• Собеседования: Нет отдельного раздела, но есть задачи уровня FAANG.
• Практика: Симулятор с интерактивными заданиями (например, расчет Retention Rate).
• Поддержка: Форум, где можно обсудить решение.
• Техническая часть: Своя IDE, работает на мобильных. Сертификат — после финального экзамена.
• Бесплатный доступ.

Минус: Мало информации по работе с большими данными (например, партицирование).

Karpov Courses

Ссылка: Karpov Courses

Для кого: Новички в IT, менеджеры, аналитики, дата-сайентисты и все, кто хочет освоить SQL и продуктовую аналитику с нуля.

• Глубина погружения: Акцент на практику — от основ SQL до продвинутых тем (оконные функции, объединения) и решения реальных продуктовых задач.
• Собеседования: Кейсы из собесов Альфа-Банка, Сбера, Ozon.
• Практика: 150+ SQL-задач на симуляторе. Работа над кейсом аналитика сервиса доставки: расчет бизнес-метрик, анализ данных, проверка гипотез.
• Поддержка: Доступ к чату сообщества для общения и вопросов.
• Техническая часть: IDE с подключением к реальной PostgreSQL и инструмент для визуализации Redash.

• Бесплатный доступ ко всем материалам, симулятору и инфраструктуре.

SQL-ex.ru

Ссылка: SQL-ex.ru

Для кого: Для тех, кто любит учиться через решение задач.

• Глубина погружения: Более 500 задач — от простых SELECT до хранимых процедур.
• Собеседования: Нет.
• Практика: Олимпиадные задания (например, расчет скользящего среднего без оконных функций).
• Поддержка: Форум с энтузиастами.
• Техническая часть: Устаревший интерфейс, нет мобильной версии.

Минус: Теория подается фрагментарно.

SQLZoo

Ссылка: SQLZoo

Для кого: Новички, которые хотят попробовать SQL бесплатно.

• Глубина погружения: Базовый уровень + JOIN, подзапросы.
• Собеседования: Нет.
• Практика: Интерактивные задачи с автоматической проверкой.
• Поддержка: Нет сообщества.
• Техническая часть: Работает на мобильных, своя IDE.

Минус: Нет продвинутых тем (CTE, оптимизация).

Stepik

Ссылка: Курсы на Stepik

Для кого: Для системного изучения с нуля.

• Глубина погружения: Полный курс с видеоуроками — от основ до анализа в Python.
• Собеседования: Нет.
• Практика: Задачи на анализ реальных датасетов (например, Airbnb).
• Поддержка: Обсуждения к каждому уроку.
• Техническая часть: Поддержка PostgreSQL, сертификат.

Минус: Мало задач на оконные функции.

Итог: Какую платформу выбрать?

• Для новичков: SQL Academy (бесплатно) или Stepik (структурный курс).
• Для подготовки к собеседованиям: SYNC STUDY или Karpov Courses (бесплатно).
• Для углубленного изучения: Karpov Courses (аналитика) или SQL-ex.ru (практика).
• Для мобильного обучения: SYNC STUDY или SQLZoo.

Какие бывают ошибки в SQL

Ошибки в SQL можно условно разделить на несколько категорий:

1. Синтаксические ошибки. Это ошибки в написании SQL-кода: пропущенные запятые, неверные ключевые слова, неправильный порядок конструкции. Они чаще всего ловятся самим движком базы при попытке выполнить запрос.
2. Логические ошибки. Самые коварные. Код выполняется, но результат не тот. Например, неверный фильтр, JOIN по неправильному полю, перепутанный порядок WHERE и HAVING или лишний DISTINCT. Эти ошибки особенно опасны в аналитике, потому что могут привести к неверным бизнес-решениям.
3. Ошибки работы с NULL. NULL — это отдельная категория значений в SQL, и она требует особого внимания. Сравнение через = и != с NULL не работает так, как многие ожидают. Здесь нужны IS NULL и IS NOT NULL.
4. Ошибки при работе с JOIN. Отсутствие условия соединения, неправильный тип соединения (INNER вместо LEFT, или наоборот), дублирование строк из-за некорректного связывания — всё это может нарушить итоговую выборку.
5. Ошибки производительности. Использование SELECT * в больших таблицах, отсутствие индексов на полях фильтрации, тяжёлые подзапросы и вложенные SELECT’ы там, где можно обойтись CTE или JOIN — всё это тормозит выполнение и грузит сервер.
6. Ошибки доступа. Запрос к несуществующей таблице, попытка обращения к колонке с опечаткой, отсутствие прав на SELECT/INSERT — это технические ошибки, но тоже распространённые. Часто возникают при смене окружения (dev → prod, другой пользователь и т.д.).

Перейдем к примерам распространенных ошибок.

Синтаксическая ошибка с некорректным GROUP BY

Ошибка возникает, если указать в SELECT столбцы, которые не попадают ни в агрегатную функцию, ни в GROUP BY.

Ошибочный запрос, который выдаст ошибку “ERROR: column “sales.product” должен присутствовать в предложении GROUP BY или использоваться в агрегатной функции:

Исправленный запрос:

Логическая ошибка при использовании DISTINCT с агрегатной функцией без GROUP BY

Комбинация DISTINCT и агрегатных функций, таких как SUM, AVG, COUNT, без явного указания GROUP BY, вводит SQL в замешательство. Запрос неясен: нужно ли агрегировать по customer_id, или просто выбрать уникальные строки? SQL требует однозначности — все неагрегированные поля в SELECT должны быть указаны в GROUP BY. Иначе возникает ошибка выполнения или, что хуже, некорректный результат.

Ошибочный запрос:

Результатом будет:

ERROR: column “sales.customer_id” must appear in the GROUP BY clause or be used in an aggregate function

Исправленный запрос:

Ошибка при использовании JOIN с несовместимыми типами данных

При соединении таблиц через поля с разными типами данных (INTEGER, TEXT, UUID, и т. д.) база данных может не только вернуть некорректные результаты, но и вовсе не выполнить соединение. Особенно это критично, если соединение происходит по полям с разной длиной или форматом — ошибки при этом могут быть скрытыми и долго не обнаруживаться.

Ошибочный запрос:

Тут order_id и customer_id имеют разные типы данных.

Исправленный запрос:

Удаление данных из таблицы без WHERE

Это классика жанра: забыть WHERE в DELETE — всё равно что взять и нажать «Удалить всё», и подтвердить. Вместо удаления пары строк исчезает вся таблица. Особенно больно, если это прод и нет бэкапа. Один неосторожный DELETE, и ваша база превращается в чистый лист.

Ошибочный запрос, который удалит все строки из таблицы:

Исправленный запрос:

Ошибка работы с NULL при сравнении через =

NULL в SQL — это не просто «пусто», а «неизвестно». А с неизвестным нельзя сравнивать напрямую. Условие amount = NULL никогда не даст TRUE, потому что результат сравнения с NULL — всегда NULL, то есть «неизвестно». Поэтому такой запрос не вернёт ни одной строки, даже если NULL в колонке есть. Для проверки нужно использовать IS NULL и IS NOT NULL.

Ошибочный запрос, который не выдаст ни одной строки:

Исправленный запрос:

Ошибка с JOIN без условий соединения

Забыть ON в JOIN — всё равно что сказать базе: «Соедини всё со всем, как хочешь». В первом случае вы получите синтаксическую ошибку, а во втором — декартово произведение: каждая строка из первой таблицы будет соединена с каждой строкой из второй. Это быстро превращает обычный запрос в лавину данных и боль для сервера (и аналитика).

Ошибочный запрос с синтаксической ошибкой:

Ошибочный запрос с декартовым произведением:

Исправленный запрос:

Неоправданное использование подзапросов

Подзапросы внутри SELECT могут выглядеть удобно, но часто создают лишнюю нагрузку. Каждый подзапрос выполняется отдельно для каждой строки — а это значит больше вычислений, больше времени и меньше масштабируемости. Там, где можно использовать JOIN, лучше так и сделать: это быстрее и понятнее.

Ошибочный запрос:

Исправленный запрос:

Ошибка производительности при выборе всех строк с SELECT *

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

Ошибочный запрос:

Исправленный запрос:

Отсутствие WHERE и LIMIT при больших данных в таблице

Без WHERE и LIMIT вы загружаете всю таблицу — даже если вам нужно 5 строк. Это всё равно что выгружать весь архив почты за 10 лет, чтобы найти одно письмо. Такой запрос сильно нагружает базу, тормозит интерфейс и может привести к таймаутам или сбоям.

Ошибочный запрос:

Исправленный запрос:

Неэффективное использование OR

Запросы с множеством OR выглядят безобидно, но могут мешать оптимизатору построить эффективный план выполнения. Особенно в больших таблицах это замедляет работу. Использование IN делает запрос компактнее, читаемее и зачастую быстрее.

Ошибочный запрос:

Исправленный запрос:

Заключение

Большинство ошибок новичков — это результат непонимания порядка выполнения SQL-запроса. Разбирайте, в какой момент работает WHERE, когда применяется GROUP BY, и когда можно использовать алиасы. Лучше медленно, но правильно, чем быстро и с багами. SQL прощает мало, но учит быстро — особенно если смотреть на результаты собственных запросов внимательно.

Не бойтесь экспериментировать, но всегда проверяйте себя: читайте, что именно возвращает ваш запрос, и задавайте себе вопрос: «А это точно то, что я хотел(а) получить?» Чем раньше вы привыкнете анализировать не только код, но и его поведение, тем быстрее исчезнет ощущение, что SQL — это какая-то магия. На самом деле, это просто строгое, но честное ремесло.

Еще больше полезных материалов в моем TG-канале. Подписывайтесь и читайте контент по ссылке.

Как работает database sharding

Database sharding (шардирование базы данных) — это техника горизонтального масштабирования, при которой большая база разделяется на несколько частей. Их называют шардами. Эти шарды распределяются по другим серверам и связываются в одну систему. Рассмотрим подробнее.

Принцип: разбиение данных на независимые сегменты (шарды)

Каждый шард работает как отдельная независимая база данных. Ключевым элементом здесь выступает ключ шардирования (shard key). Это правила, которые определяют, в какой именно шард попадёт конкретная строка данных.

Например, мы можем задать правило: если у нас есть user_id и его значение меньше тысячи, то данные попадают в шард 1, если значение больше тысячи, то в шард 2.

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

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

Общая архитектура: клиент — роутер — шард

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

Клиент: Программа на стороне пользователя, которая отправляет стандартный запрос к базе данных (например, SELECT * FROM users WHERE user_id = 123).

Маршрутизатор запросов или роутер (Query Router): Это что-то вроде посредника между клиентом и шардом, который выполняет роль диспетчера. Он принимает запрос, при помощи sharding ключа определяет, что это за данные, в какой шард и с какой целью их надо отправить. Далее он отправляет запрос на нужный шард.

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

Благодаря такой архитектуре мы можем «скрыть» database sharding на стороне клиента и обеспечить централизованное управление запросами. Не надо сильно заморачиваться с кодом и архитектурой приложений, ведь вся логика будет на серверах.

Основные компоненты: шард, маршрутизатор, реплика-сеты

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

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

Виды шардинга

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

Горизонтальный sharding (по строкам): самый популярный

При горизонтальном шардинге мы «нарезаем» нашу базу данных по строкам. Допустим, у нас таблица с клиентами. Мы задаём диапазон ключу шардирования с user_id от 1 до 1 000 000. Данные в этом диапазоне, построчно будут храниться в шадре 1. Если user_id попадает в диапазон от 1 000 001 до 2 000 000, то эти данные отправляем на шадр 2. И так далее.

Благодаря этому способу мы можем равномерно распределять данные, и нам будет проще масштабировать систему при помощи создания новых шадров и добавления серверов.

Горизонтальный sharding — идеальный вариант, когда основная проблема — это огромное количество строк в таблицах и высокая нагрузка на чтение/запись.

Вертикальный шардинг (по столбцам): разделение по функциональности

Если горизонтальный шардинг режет таблицу поперёк (по строкам), то вертикальный — вдоль, разделяя столбцы. Таблица делится на несколько с меньшим количеством столбцов. Обычно они группируются по частоте использования или по смысловой нагрузке. Например, в таблице юзеров можно выделить часто запрашиваемые user_id, username, email в одну таблицу, а редко используемые — biography, preferences, last_login_details — в другую.

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

Directory-based sharding: использование хеш-таблицы маршрутов

При горизонтальном и вертикальном шардинге маршрутизатор часто сам, при помощи специальных функций, определяет, какие данные в какой шадр отправить. Это не всегда удобно. При таком подходе мало гибкости. Поэтому был придуман вид шардинга, который опирается на хеш-таблицы и называется directory-based. Его суть в том, что мы создаём централизованный каталог, который связывает наши ключи шардирования и шарды.

Вот пример того, как это работает:

• Клиентское приложение отправляет запрос (например, получить данные для order_id = 98765).
• Маршрутизатор запросов перехватывает его.
• Маршрутизатор обращается к каталогу: с запросом, где найти order_id = 98765.
• Каталог ищет в своей таблице соответствий правило, под которое подпадает order_id = 98765. Для быстрого поиска он часто использует эффективные структуры данных, такие как хеш-таблицы или B-деревья (это внутренняя деталь реализации самого каталога).
• Допустим, каталог находит правило «Диапазон order_id 90000-99999 → Shard-3» и сообщает это маршрутизатору.
• Маршрутизатор перенаправляет исходный запрос на Shard-3.

При таком подходе удобнее перемещать данные между шардами, изолировать их и менять логику.

Range-based sharding: разбиение по диапазонам значений

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

Администратор системы (или автоматизированный инструмент) определяет границы диапазонов для ключа шардинга. Маршрутизатор получает запрос, смотрит на значение этого ключа и сравнивает его с известными диапазонами, чтобы определить целевой шард.

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

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

Когда пользователи начнут регистрироваться, у нас будет активен шард 1, потом шард 2. Далее вся нагрузка перейдёт на шард 3. Они не будут одновременно равномерно работать. Это может стать проблемой при оптимизации.

Hash-based sharding: равномерное распределение по хешу ключа

Этот подход помогает добиться максимально равномерного распределения нагрузки по всем шардам. Работает следующим образом:

Берём значение ключа для конкретной строки данных (например, user_id = 2001).

Применяем к нему хеш-функцию. Хеш-функция (например, MD5, SHA-1, MurmurHash) — это алгоритм, который превращает входные данные (наш user_id) в строку или число фиксированной длины (хэш), которое выглядит почти случайно. Даже небольшое изменение на входе (например, user_id = 2001 и user_id = 2002) обычно даёт совершенно разные хеши.

Вычисляем номер шарда. Чаще всего делим значение хеша на количество шардов и берём остаток от деления. Например, 548291 % 3 = 2. Далее в зависимости от остатка распределяем данные по шардам. Значение с остатком 2 пойдёт в шард 2, если остаток 1, то в шард 1 и так далее.

Так мы получаем более равномерное распределение данных. Но из минусов — в такой базе сложно обрабатывать диапазоны и добавлять новые шарды в систему.

Примеры реализации

MongoDB: встроенная поддержка шардинга

MongoDB — это NoSQL база данных, которая была разработана с закосом на горизонтальное масштабирование. То есть она адаптирована к тому, чтобы работать на нескольких серверах и расширять это число по мере необходимости. Поэтому sharding здесь доступен из коробки, нам не надо заморачиваться со внешними расширениями.

Рассмотрим пример, как настроить sharding и работать с ним:

• sh.addShard() — добавляем сервер в кластер как шард. MongoDB понимает, что может использовать этот сервер для хранения части данных.
• use socialApp; sh.enableSharding("socialApp") — переключаемся на базу данных «socialApp». При помощи команды sh.enableSharding() разрешаем шардинг в этой БД.
• sh.shardCollection("socialApp.users", { "user_id": 1 }) — применяем sharding к коллекции users. Мы указываем полное имя коллекции (socialApp.users) и ключ шарда ({ "user_id": 1 }). Цифра 1 означает, что мы используем шардинг по диапазонам. Эти диапазоны не нужно задавать вручную, MongoDB определяет их самостоятельно.
• db.users.insertMany([...]) — вставляем данные в коллекцию users. MongoDB автоматически определяет, на какой шард поместить каждого пользователя.
• db.users.findOne({ user_id: 1 }) — запрашиваем данные пользователя user_id = 1. Mongos сам определит, на каком шарде они находятся.

PostgreSQL + Citus

В PostgreSQL нет поддержки встроенного шардинга, поэтому приходится устанавливать на сервер Citus. Это популярное расширение, которое как раз добавляет возможности горизонтального масштабирования и шардинга. Оно превращает кластер стандартных серверов PostgreSQL в распределённую базу данных.

Посмотрим на пример использования SQL-команд для настройки шардинга с помощью Citus:

• CREATE EXTENSION citus; — активируем Citus в текущей базе данных.
• CREATE TABLE app_logs (...) — создаём таблицу app_logs на узле-координаторе точно так же, как создали бы обычную таблицу в PostgreSQL.
• SELECT create_distributed_table('app_logs', 'service_name'); — при помощи этой команды включаем sharding. Citus понимает, что таблицу app_logs нужно распределить по рабочим узлам, используя поле service_name как ключ шардинга. Citus по умолчанию применяет Hash-based sharding, то есть, равномерно распределяет по шардам при помощи хеш-функций.
• INSERT INTO app_logs — добавляем данные логов. Citus перехватывает запрос, вычисляет хеш от значения service_name для каждой строки и распределяет данные по шардам.
• SELECT ... FROM app_logs — запрашиваем данные. Если фильтруем по service_name (как в первом SELECT), Citus направит запрос на нужный шард.

MySQL + Vitess

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

Vitess вместо прямых команд для шардинга определяет его правила в отдельном JSON-файле, который называется VSchema (Vitess Schema).

Допустим, у нас есть база данных commerce. Вот как она выглядит в виде кода:

А вот так она выглядит в виде таблицы:

В базе данных есть таблица orders, её мы и хотим шардировать по customer_id при помощи хеширования (hash-based sharding).

Файл VSchema (vschema.json) может выглядеть примерно так:

• "sharded": true — указываем, что база данных шардирована.
• "vindexes" — определяем hash_index типа hash, который будет использовать хеш-функцию для распределения.
• "tables" — описываются правила для конкретных таблиц.
• "orders" — настраиваем таблицу orders.
• "column_vindexes" — определяем, какой столбец является ключом ("column": "customer_id") и какой vindex ("name": "hash_customer_id") использовать для него.

Проблемы шардирования

Перераспределение шардов (resharding)

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

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

Например, раньше у нас было 4 шарда. Мы брали user_id, например 9, делили на 4 и получали остаток — 1. Значит, данные шли на шард номер 1. После масштабирования стало 5 шардов, и 9 % 5 = 4 — теперь те же данные должны храниться на шардe 4.

Такое перемещение затратно по ресурсам: грузит сеть, диски, может занять часы или даже дни. Иногда для этого приходится останавливать запись, что делает процесс ещё рискованнее.

Неравномерная нагрузка (hot shards)

Вспомним вид шардирования Range-based sharding. Это когда мы разбиваем данные по диапазонам. У нас был пример выше с форумом и шардингом user_id:

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

Мы столкнулись с проблемой, что шард 1 и шард 2 после завершения диапазонов простаивали, а вся новая нагрузка приходилась на шард 3.

Такую проблему называют горячим шардом (hot shards). Производительность всей системы начинает зависеть от самого загруженного шарда. Преимущества шардирования снижаются.

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

Сложности с глобальными транзакциями и агрегациями

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

Но если счёт А находится на одном шарде, а счёт Б — на другом, стандартная транзакция не сработает. Между независимыми серверами нельзя просто так обеспечить ACID-гарантии. Для этого нужны сложные и медленные механизмы координации, например двухфазный коммит (2PC). Либо приходится идти на компромисс и использовать eventual consistency — когда данные приходят в согласованное состояние с небольшой задержкой. Например, деньги уже списались, но ещё не зачислились.

Аналогичная проблема и с агрегациями: посчитать сумму продаж или число пользователей уже не получится одной SQL-командой. Каждый шард сначала считает свою часть, а потом результат нужно собрать и объединить — это требует дополнительной координации и может усложниться при фильтрации или группировках.

Сложность управления и мониторинга

Шардированный кластер — это распределённая система, управлять которой сложнее, чем одним сервером.

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

Мониторинг: Требуется отслеживать состояние каждого шарда, равномерность распределения нагрузки, задержки в сети, работу маршрутизаторов. Нужны более сложные инструменты мониторинга.

Отладка: Найти источник проблемы в распределённой системе сложнее. Ошибка может быть где угодно: в приложении, маршрутизаторе, на одном из шардов или в сети.

Резервное копирование: Создание согласованных резервных копий и восстановление данных со множеством независимых шардов требует более сложных процедур.

Когда стоит применять Sharding

Рост объёма данных и нагрузок

Sharding стоит применять, если БД сильно разрослась, хранить её на одном сервере становится сложно и дорого. Серверу приходится обрабатывать много данных, и поэтому увеличивается время отклика.

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

Не справляется один сервер/реплика

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

Потребность в геораспределённости или отказоустойчивости

Если пользователи находятся в разных частях света, то деление данных и хранение ближе к ним может ускорить работу приложения. Мы можем при помощи шардинга размещать данные в разных дата-центрах, ближе к определённым группам пользователей. Например, так делает Youtube. Компания размещает свои сервера в разных странах, чтобы видео прогружались быстрее и в более высоком качестве.

Мы можем хранить все данные и обрабатывать запросы на одном сервере и сделать его реплику с копией данных. Если этот сервер падает, то его заменяет реплика. Но что, если эта реплика тоже упадёт? Тогда нам и помогает sharding с репликацией. В случае сбоев отвалятся только отдельные серверы с некоторыми наборами данных. Конечно, здесь тоже, в теории, можно положить весь кластер, включая реплики, но сделать это сложнее.

Шардирование — полезный инструмент при работе с СУБД. А узнать про большее число подобных инструментов можно в нашем телеграм канале!

Основные инструменты и технологии

Статьи, с которых стоит начать, если хочется обновить стек или разобраться в новых подходах:

ТОП 60 лучших инструментов для разработки ПО в 2025 — Собрали шестьдесят лучших инструментов для разработки программного обеспечения в 2025 году. От трекеров и редакторов до библиотек и фреймворков.

Топ 11 трендов, которые нужны айтишнику в 2025 году — Представляем одиннадцать ключевых трендов в IT, которые будут актуальны в 2025 году. Краткий гид по технологиям, которые будут на слуху.

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

Инструменты и фреймворки QA, которые (не) нужно знать — о том, что реально используется в тестировании.

Что изучать начинающему разработчику на C# — рассматриваем языки, среды и подходы, которые пригодятся новичкам. Рекомендуем, с чего начать изучение C# и какие темы освоить в первую очередь.

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

Базы, API, DevOps и CI/CD

Набор инструментов и практик, которые помогут масштабироваться и не выгорать:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — must-have решения для DevOps-команд.

PostgreSQL vs. ClickHouse vs. DuckDB: какую опенсорс базу выбрать для аналитики в 2025 году? — Сравниваем три популярные опенсорс СУБД для аналитики: возможности, производительность и кейсы использования.

Семь API, которые сократят вам недели разработки — Подборка решений, которые можно быстро внедрить.

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Делимся практическими советами по развертыванию инструментов CI/CD от профессионалов.

Как автоматизировать простые задачи с помощью скриптов? — Гайд по быстрой автоматизации без боли.

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

AI-инструменты и нейросети

Что может помочь вам уже сейчас — от подсказок до генерации кода:

Топ-5 ИИ-инструментов для программистов в 2025 году — Самые полезные AI-ассистенты по мнению редакции.

DeepSeek или Claude: какая нейросеть напишет код, за который не стыдно? — Сравниваем возможности нейросетей DeepSeek и Claude в контексте генерации качественного кода.

Edge AI: как работают нейросети на устройствах с ограниченными ресурсами — Объясняем, как нейросети работают на устройствах с ограниченными ресурсами и где это применимо.

10 способов заработать на искусственном интеллекте в 2025 — Рассказываем о десяти способах монетизации искусственного интеллекта в 2025 году.

Утилиты, лайфхаки и неожиданно полезные штуки

То, что экономит время, силы и нервы:

11 сайтов, экономящих время, которые нужны каждому разработчику — Подборка must-have ресурсов.

7 библиотек для анимаций на React — Обзор популярных библиотек для создания анимаций в React: от простых эффектов до сложных переходов.

30 самых полезных библиотек Python для веб-разработки в 2024 году — Подборка тридцати полезных библиотек Python, которые пригодятся веб-разработчикам в 2025 году.

7 программ для шифрования данных — Базовая кибер-гигиена для всех, кто работает с пользовательскими данными.

Топ самых полезных магических команд для завсегдатаев Colab — Рассказываем, как использовать магические команды в Colab, чтобы ускорить работу с данными и кодом.

5 ETL для обработки данных из Python-ботов — Представляем пять ETL-инструментов, которые помогут автоматизировать сбор, трансформацию и загрузку данных от Python-ботов

Работа с Excel: где он применяется, чем полезен и где освоить этот навык — Объясняем, где и как используется Excel, почему он важен для аналитиков и где научиться работать с ним.

Немного философии

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

Язык Elixir и функциональное программирование: что это за зверь и почему он хорош для отказоустойчивых систем — Знакомим пользователей с Elixir и его применением.

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

10 лучших платформ для создания приложений без единой строчки кода — Обзор десяти лучших no-code платформ, позволяющих создавать приложения без программирования.

Скорее пользуйтесь нашим гайдом и читайте предыдущие. Вот, например, по мобильной разработке и React.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

PostgreSQL: Универсальная объектно-реляционная СУБД

PostgreSQL — объектно-реляционная СУБД (система управления базами данных). Термин реляционная означает, что мы записываем данные в виде взаимосвязанных таблиц со строгой схемой. В этой схеме у нас есть столбцы и ячейки, где занесены значения определённого типа: строки, числа, даты. Прямо как в Excel.

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

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

PostgreSQL используют в интернет-магазинах, финансовых системах, банковских и геопространственных приложениях, системах управления контентом в блогах, социальных сетях и аналитике. Это универсальный гибкий инструмент.

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

ClickHouse: Скорость и аналитика от Яндекса

ClickHouse родился в стенах Яндекса в середине 2000-х. Изначально это была внутренняя разработка для Яндекс.Метрики — чтобы быстро обрабатывать миллиарды событий, подсчитывать статистику и выдавать отчёты, не теряя в скорости. В 2016 году разработку опубликовали на GitHub с опенсорс лицензией.

Особенность ClickHouse заключается в его колоночно-ориентированной архитектуре. Традиционные СУБД работают с данными построчно. Это значит, что каждая строка — как бы отдельная сущность с данными.

Допустим, нам надо считать данные с одного столбца. Классические СУБД пойдут искать ячейки столбца по строкам, вместо того, чтобы выбрать этот столбец.

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

ClickHouse поддерживает векторизацию. Это значит, что он нарезает БД (базу данных) на векторы — отдельные куски. СУБД сразу обрабатывает весь кусок целиком, вместо того чтобы по очереди заниматься каждой ячейкой. Здесь есть Simd-оптимизация — технология, которая позволяет процессору выполнять операции сразу над несколькими элементами данных параллельно.

Благодаря колоночной архитектуре и хорошей оптимизации ClickHouse быстро работает с данными. Его применяют в аналитике Uber, Bloomberg, Google, Netflix, VK, Avito, Т-банк, ну и, конечно же, Яндекс.

DuckDB: Локальная аналитика

DuckDB — ещё одна СУБД с открытым исходным кодом. Как и ClickHouse использует колоночную архитектуру, векторизацию и Simd-оптимизацию. Благодаря этому, хорошо справляется с аналитическими задачами.

Главная фишка DuckDB в том, что он предназначен для работы на стороне клиента и оптимизирован под обычные ПК и ноутбуки. DuckDB популярен среди аналитиков, которые работают с данными локально, например, через Python или R. Его можно подключить как библиотеку и работать с данными внутри проекта.

Сравнение возможностей СУБД

Производительность в тестах

Для сравнения я использовал ClickBench. Это набор данных с тестами для разных СУБД, весом более 70 гб и количеством около 100 млн строк.

В качестве оборудования выбрал c6a.4xlarge. Здесь 32 гб. ОЗУ, 16-ядерный процессор и диск объёмом 500 гб.

Тест предполагает, что СУБД обрабатывает данные при помощи 42 запросов. Cold Run — обработка некэшированных данных, Hot Run — работа с кэшированными данными, Storage Size — сжатие в гигибайтах (1 Гиб ≈ 1.073 Гб).

DuckDB оказался самым шустрым в тесте Cold Run, он обрабатывает некэшированные данные за 372 секунды, тогда как у ClickHouse 470 сек., а у PostgreSQL 937 сек.

Однако, ClickHouse оказывается быстрее в тесте Hot Run — когда данные в кэше. У него 372 сек., тогда как у DuckDB 470 сек. а у PostgreSQL всё те же 937 сек.

Также ClickHouse лучше всех работает с памятью. Он смог сжать 70 гб. данных до 13.48 гибибайт. На втором месте DuckDB, у него 22.03 Гиб. PostgreSQL не только не сжал данные, но и раздул их до 99.18 Гиб (примерно 106 гб). Возможно, ClickHouse и DuckDB проще сжимать информацию, так как у них колоночный подход к работе с данными, ведь в столбце повторяющиеся значения могут встречаться чаще, чем в строке. Увеличение объёма данных в PostgreSQL возможно вызвано тем, что СУБД наплодило много метатегов к данным.

В общем, PostgreSQL сильно уступает в производительности ClickHouse и DuckDB. С памятью работает тоже хуже.

Масштабируемость систем

PostgreSQL — хороший вариант для вертикального масштабирования

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

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

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

ClickHouse масштабируется вертикально и горизонтально

Тоже хорошо подходит для вертикального масштабирования, как и PostgreSQL. Однако он также поддерживает шадрирование и репликацию. Шадрирование означает, что ClickHouse может нарезать базу данных на кусочки и распределять эти кусочки между разными узлами. Репликация означает, что СУБД может копировать их на другие сервера в кластере.

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

DuckDB — только вертикальное масштабирование на обычных ПК и ноутбуках

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

Экосистема и удобство использования

PostgreSQL выделяется своей зрелой экосистемой. Он кроссплатформенный, можно установить на Windows, MacOS, Linux, Docker. После установки необходима небольшая настройка под свои задачи.

Мы можем управлять СУБД через графический интерфейс pgAdmin.

Он поддерживает создание и редактирование объектов, просмотр структуры, визуализацию схемы. Для этого даже необязательно вводить SQL запросы, хотя это тоже можно. Также есть консольный клиент psql.

PostgreSQL поддерживает интеграцию с BI системами, например, Tableau, Metabase, Power BI, и расширения наподобие PostGIS и TimescaleDB.

У PostgreSQL всё хорошо с расширяемостью, мы вправе писать свои функции, индексы, подключать сторонние модули. Здесь можно писать код не только на SQL, но и на Python, C, C++, Java, JS, Rubi, R, Lua.

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

ClickHouse ориентирован на аналитику больших данных в реальном времени, что отражается в его экосистеме. Поддерживает установку на Windows, MacOS, Linux, Docker.

ClickHouse готов к работе «из коробки» для аналитических задач. Можно ничего не настраивать и сразу создать таблицу, но при условии, что СУБД будет работать только на одном устройстве. Если мы собираемся запустить ClickHouse на кластере, то придётся немного повозиться с настройками шадринга и репликации. Есть поддержка как SQL, так и других языков, но только через клиентские библиотеки.

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

Например, на изображении интерфейс agx.

DuckDB можно установить на Windows, MacOS, Linux. Установка напоминает подключение библиотеки к проекту. Просто пишем команду pip install duckdb для Python или install.packages("duckdb") для R и всё установлено локально, без сервера. Поддерживает и другие языки через клиентские библиотеки.

Он разработан с акцентом на простоту и локальное использование, поэтому здесь можно сразу начать работу, без настройки.

В марте 2025 года у DuckDB появился свой графический интерфейс. В нём тоже можно писать SQL запросы, смотреть результаты и организовывать проекты в виде блокнотов.

Также есть интерфейсы от сторонних разработчиков и консольный клиент.

Поддержка транзакций (ACID)

ACID — это набор свойств, которые обеспечивают надёжность транзакций в базах данных:

• Atomicity (Атомарность): Все операции в транзакции выполняются полностью, или ни одна из них не выполняется. Если что-то идёт не так, изменения откатываются.
• Consistency (Согласованность): После каждой транзакции база данных остаётся в согласованном состоянии, соблюдая все ограничения (например, уникальность ключей, внешние ключи).
• Isolation (Изоляция): Транзакции изолированы друг от друга, то есть незавершённые транзакции не видны другим.
• Durability (Долговечность): После завершения транзакции все изменения сохраняются, даже в случае сбоя системы.

ACID особенно важен для OLTP — обработки транзакций в реальном времени. Такие транзакции есть, например, в банковских системах, где требуется строгая согласованность и надёжность. В аналитических сценариях (OLAP) требования к ACID могут быть менее строгими, так как приоритет отдаётся скорости и масштабируемости.

PostgreSQL изначально разработан для OLTP-нагрузок, где транзакционность критически важна. Он полностью поддерживает ACID, но в ущерб скорости обработки данных, что может снижать производительность в аналитических задачах.

ClickHouse жертвует полной поддержкой ACID ради скорости и масштабируемости. Это делает его идеальной СУБД для аналитических задач, но ограничивает использование в OLTP-сценариях.

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

Когда мы изменяем или удаляем данные, у нас создаётся новая строка, но старая никуда не девается, а просто помечается как изменённая или удалённая. В конце, при слиянии, ClickHouse всё же в фоне удаляет устаревшие данные, но из-за особенностей движка у нас есть промежуточное состояние, когда одновременно есть и старые, и новые строки. Это нарушает принципы атомарности и согласованности. Если представить, что ClickHouse отвечал бы за операции с оплатой в интернет-магазине, мы могли получить ситуацию, когда 2 пользователя купили один товар.

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

Из-за колоночной архитектуры здесь также, как и в ClickHouse есть сложности в плане поддержки атомарности.

Какую СУБД выбрать для аналитики

Выбирая между PostgreSQL, ClickHouse и DuckDB надо определиться, что важнее: транзакционная надёжность, аналитическая скорость или локальная простота.

PostgreSQL: для небольших данных и универсальности

PostgreSQL подойдёт для аналитики не сильно больших данных, например, в интернет-магазине, при условии, что это не маркетплейс размером с OZON. Это особенно хороший вариант для проектов, где нужна гибкость или поддержка транзакций по стандарту ACID.

ClickHouse: для больших данных в реальном времени

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

DuckDB: для локальной аналитики на ноутбуке

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

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

Кстати, для ИИ-приложений, в частности, для Retrieval-Augmented Generation (RAG), pg_vector для PostgreSQL — довольно популярное стартовое решение.

Если нужна «просто СУБД» — PostgreSQL отличное решение «по умолчанию».

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

Для более специфических задач — ultra-low latency, потоковая обработка данных, комбинированные решения — могут потребоваться другие, более сложные инструменты. Примеры: CockroachDB, YugabyteDB (оба — распределённые версии PostgreSQL), Apache Ignite (для ultra-low latency SQL и транзакции), Apache Druid (для быстрой аналитики).

DuckDB — скорее нишевый инструмент для data scientists и data engineers. Например, он подходит для обработки больших объёмов данных в скриптах на Python, когда это нужно сделать локально. Если вы разрабатываете приложения, то, скорее всего, вам DuckDB не нужен.

Я много лет разрабатываю распределённые базы данных (GridGain и Apache Ignite). Помог запустить множество систем, использовавших PostgreSQL и ClickHouse, или заменял их своим продуктом.
PostgreSQL — отличный продукт, очень гибкий. Но, чтобы раскрыть его потенциал нужна или очень сильная команда, или хороший внешний вендор, поэтому у Postgres Professional всё хорошо. Большинству компаний для нетиповых задач, особенно low-latency/real-time, проще найти альтернативное решение.

ClickHouse классно делает ровно одну вещь — быстро обрабатывает SQL запросы на больших данных. Им не решить все задачи аналитики в компании — долгосрочное хранение, трансформация данных и многое другое нужно будет решать другими инструментами.

PostgreSQL, ClickHouse и DuckDB — три очень разные системы, каждая со своей логикой и зоной применения. Тут не про «что лучше», а скорее — «что подойдёт именно под вашу задачу».

PostgreSQL

Это универсальный инструмент. Если не знаете, с чего начать — скорее всего, начинать стоит с него. Он хорошо справляется с большинством типовых задач: хранение данных, транзакции, запросы, индексы, API. Работает стабильно, предсказуемо, и его знают почти все разработчики. Проблемы начинаются, когда данных становится очень много, особенно если есть тяжёлые аналитические запросы — тогда он уже не так эффективен. Масштабируется скорее вертикально, и не всегда удобно тюнить для сложной аналитики.

ClickHouse

Если у вас огромные объёмы данных и вы хотите быстро гонять по ним аналитику — это ваш инструмент. СУБД для чтения, не для транзакций. Отлично показывает себя в задачах мониторинга, логирования, аналитики в реальном времени. Очень быстрая, но требует больше внимания: настроек, понимания архитектуры, знание её ограничений (например, с JOIN'ами и транзакциями). Это уже не «поставил и работает», тут придётся повозиться.

DuckDB

Это интересный новичок — очень лёгкая, быстрая аналитическая СУБД, которая отлично работает локально, особенно в связке с Python или Jupyter. Я бы назвал её «SQLite для дата-сайентистов». Не требует сервера, можно просто подключить к CSV, Parquet или Pandas DataFrame и писать SQL-запросы. Для быстрого анализа данных — идеально. В продакшене пока использовать её с осторожностью, но для локальной аналитики — инструмент номер один.

Когда что выбирать?

Если вы делаете обычное приложение — PostgreSQL. ClickHouse — лучший выбор для аналитики в реальном времени, дашбордов, логирования, мониторинга, и других сценариев с интенсивными SELECT-запросами. DuckDB — отличный выбор для дата-сайентистов, аналитиков и быстрой локальной аналитики. Особенно хорош в ситуациях, когда нужно быстро что-то «пощупать» без подъёма инфраструктуры.

AI, ML, нейросети, аналитика — это явно твоя тема. Поэтому скорее ждем в нашем тг-канале.

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

Что такое партиционирование и зачем оно нужно?

Партиционирование — это разбиение больших таблиц на более мелкие части для ускорения запросов.

Представьте себе большой архив документов. Если все бумаги хранятся в одной стопке, найти нужный документ будет сложно и долго. Если же разложить их по папкам — например, по годам или отделам — поиск займет секунды.

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

Даже если аналитик не пишет SQL-запросы вручную, понимание партиционирования помогает:

• Ускорять работу отчетов — база данных обрабатывает только нужные данные, а не весь массив (данные за последний месяц, а не за 10 лет).
• Эффективно взаимодействовать с инженерами DWH — осознанные запросы помогают оптимизировать хранилище.
• Избегать «тяжелых» запросов — если таблицы не разбиты на партиции, отчеты могут выполняться слишком долго.

Партиционирование и шардирование: в чем разница?

Партиционирование часто путают с шардированием, хотя это разные вещи:

• Партиционирование — разбиение данных внутри одной базы. Например, таблица с продажами разделяется по месяцам.
• Шардирование — распределение данных по разным серверам. Например, пользователи из Европы хранятся в одной базе, из Азии — в другой.

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

Как партиционирование помогает ускорить запросы?

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

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

Если таблица разбита по датам, то запрос:

будет читать только нужную партицию, а не всю таблицу.

Основные стратегии партиционирования

• По дате — самый популярный вариант для логов и транзакций;
• По регионам — когда данные имеют географическую привязку;
• По ID (например, user_id) — если важно равномерное распределение нагрузки.

Универсальный код для партиционирования:

Какие инструменты помогают работать с партиционированием?

Спойлер: в топе будет BigQuery — там партиции настраиваются в пару кликов, а Google сам подсказывает, как оптимизировать запросы.

Но мы все равно расскажем о популярных решениях, которые сделают жизнь аналитиков проще.

PostgreSQL: Ручное партиционирование через PARTITION BY

Шаг 1: Создание партиционированной таблицы

Шаг 2: Создание партиций

Шаг 3: Вставка данных (автоматически попадают в нужную партицию)

Шаг 4: Чтение данных (автоматический pruning)

Особенности PostgreSQL:

• Требует явного создания партиций;
• Поддерживает RANGE, LIST, HASH партиционирование;
• Можно добавлять/удалять партиции динамически (ALTER TABLE ... DETACH PARTITION).

Здесь же надо сказать, что оконные ранжирующие функции, которые содержат операцию PARTITION BY для получения ранга записи, это немного другое, но при выполнении запроса налету.

BigQuery: Автоматическое партиционирование

Создадим партиционированную таблицу:

Особенности BigQuery:

• Автоматическое управление партициями (не нужно создавать вручную);
• Лимит — 4000 партиций на таблицу;
• Кластеризация (дополнительная оптимизация) через CLUSTER BY region.

ClickHouse: Продвинутое партиционирование через PARTITION BY

Шаг 1: Создание партиционированной таблицы

Шаг 2: Вставка данных

Шаг 3: Чтение с pruning

Особенности ClickHouse:

• Гибкие ключи партиционирования (включая выражения);
• Оптимизация под аналитические запросы (высокая скорость);
• Ручное управление партициями (ALTER TABLE sales DROP PARTITION '202305').

Итоговые рекомендации:

PostgreSQL: Выбирайте для OLTP-систем, где важно ручное управление.

BigQuery: Идеален для аналитики в GCP (минимум настроек).

ClickHouse: Лучший выбор для высоконагруженных аналитических запросов.

Заключение

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

Главное, что нужно запомнить:

• Партиционирование — разбиение данных в одной базе, шардирование — распределение данных по разным серверам.
• Выбор стратегии партиционирования зависит от типа данных и запросов: чаще всего используется разбиение по дате.
• Разные DWH используют разные механизмы: PostgreSQL требует ручной настройки, BigQuery делает все автоматически, а ClickHouse дает максимальную гибкость.

Бонус: Если видите, что запрос тормозит, спросите инженера: «Эта таблица партицирована? Можно добавить партицию по моему фильтру?», — и вас сразу запомнят как продвинутого аналитика

Структура данных: реляционные таблицы vs. Документо-ориентированные, графовые, ключ-значение базы

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

Рассмотрим пример таблицы ниже:

Это таблица excel, в которую занесены данные о различных персонажах. В ней мы можем фильтровать данные, искать их, сортировать содержимое, писать значения с разными типами, обращаться к данным во внешних таблицах. При помощи запросов SQL возможно всё то же самое в реляционной базе.

Давайте создадим нашу таблицу при помощи SQL:

Командой CREATE TABLE создаём таблицу, которую называем «Персонажи». В скобках прописываем название столбцов, напротив указываем тип данных, который здесь будет храниться. Например, VARCHAR(50) — это текст до 50 символов, DATE — дата, INT — число. PRIMARY KEY — первичный ключ строки. Он нужен, чтобы у каждой строки таблицы был свой уникальный номер.

Далее заполним нашу таблицу при помощи команды INSERT INTO Персонажи VALUES:

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

А теперь добавим ещё одного персонажа и отфильтруем значения по столбцу «Фильм_Сериал»:

Команда INSERT INTO добавляет нового персонажа в уже существующую базу.

В скобках после INSERT INTO мы перечисляем столбцы, которые хотим заполнить. VALUES — значения для этих столбцов.

Эта команда выбирает все столбцы в таблице «Персонажи», проверяя, что новое значение добавилось.

Далее проводим фильтрацию по сериалу: «Игра престолов»:

• SELECT — выбирает данные из столбцов.
• После SELECTпишем, какие именно столбцы хотим видеть (не всё, а только эти шесть).
• FROM Персонажи — указываем таблицу, из которой берём данные.
• WHERE Фильм_Сериал — выбираем столбец, по которому будем искать данные.

В результате получим вот такие данные:

NoSQL в сравнении с SQL не просто другой язык, а целая философия организации базы данных. Никаких строгих таблиц — всё зависит от того, с чем работаем. В NoSQL есть много видов данных, под каждый из них существуют свои системы управления базами данных (СУБД). Вот основные из них:

Документо-ориентированные базы (MongoDB): данные лежат в виде документов, похожих на JSON, но это не совсем он, а BSON. Различия кроются в том, что это его бинарная версия.

Пример:

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

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

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

Графовые базы (Neo4j): здесь данные — это узлы.

CREATE (Джон:Персонаж {имя: "Джон Сноу", дом: "Старк"});

Создаётся узел с меткой Персонаж, который представляет Джона Сноу. Узел имеет два свойства: имя со значением «Джон Сноу» и дом со значением «Старк». Переменная Джон — временное имя для ссылки на узел.

CREATE (Тирион:Персонаж {имя: "Тирион Ланнистер", дом: "Ланнистер"});

Далее создаётся ещё один узел с меткой Персонаж, представляющий Тириона Ланнистера. У него тоже два свойства: имя — «Тирион Ланнистер» и дом — «Ланнистер». Переменная Тирион позволяет ссылаться на этот узел.

CREATE (Джон)-[:ЛАЙК]->(Тирион);

Затем появляется направленная связь (ребро) между узлами Джон и Тирион. Она имеет тип ЛАЙК и указывает, что Джон «лайкает» Тириона. Скобки () обозначают узлы, а [:ЛАЙК] со стрелкой -> показывает направление отношения.

Гибкость схемы SQL против NoSQL: строгая схема vs динамическая структура

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

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

В этом фундаментальное различие SQL и NoSQL. Первый плохо подходит для работы с неструктурированными данными.

В NoSQL мы можем при помощи MongoDB прописать значение только для одного персонажа, не трогая других:

Сравните данные Илона Маска и Сайтамы, у них есть различия в схеме.

Для такой записи в SQL нам пришлось бы добавлять поле «Чем известен» для всех персонажей в базе. Другие бы тогда получили значение null:

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

У NoSQL, в отличие от SQL, нет строгой схемы, благодаря этому он отлично подходит для работы с плохо структурированными данными.

Транзакции в SQL и NoSQL: ACID (SQL) vs. BASE (NoSQL)

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

ACID (SQL)

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

Атомарность (Atomicity) — транзакция выполняется как единое целое. Если хоть одна операция внутри неё не удалась, всё отменяется. Например, если при переводе денег сервер внезапно отключился, система откатит изменения, и средства не исчезнут.

Согласованность (Consistency) — данные всегда соответствуют правилам базы. Если на счёте 80$, а мы пытаемся перевести 100$, система просто не даст выполнить такую операцию.

Изоляция (Isolation) — параллельные транзакции не мешают друг другу. Пока одна выполняется, другая видит только конечный результат. Например, если один процесс переводит 100$ со счёта A на счёт B, а другой в этот момент проверяет баланс, он увидит либо старое состояние, либо уже обновлённое, но никогда промежуточное.

Долговечность (Durability) — завершённая транзакция остаётся в базе навсегда, даже в случае сбоя. Если мы пополнили счёт на 100$, эта информация будет сохранена, независимо от того, что произойдёт с сервером после.

BASE (NoSQL)

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

Базовая доступность (Basically Available) — система всегда отвечает на запросы, даже если часть данных ещё не синхронизирована. Например, ставя лайк, мы сразу видим его, даже если информация ещё не дошла до сервера.

Мягкое состояние (Soft State) — данные могут временно быть несогласованными. Ради высокой доступности система допускает, что информация изменяется без нашего участия. Например, когда у нового видео на YouTube лайков больше, чем просмотров — это результат того, что одни данные обновились быстрее других.

Конечная согласованность (Eventual Consistency) — если систему оставить в покое, она сама «додумает» и согласует данные между всеми узлами. Допустим, у поста 50 лайков, но у разных пользователей отображаются разные числа: кто-то видит 49, кто-то 53. Через некоторое время система синхронизируется, и у всех будет одинаковое значение.

BASE-жизнь — это про скорость и гибкость. Главное, чтобы данные в итоге сошлись, а не были идеальными в каждый момент времени.

Масштабируемость: вертикальное (SQL) vs горизонтальное (NoSQL) масштабирование

Вертикальное масштабирование (SQL)

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

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

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

Горизонтальное масштабирование (NoSQL)

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

Благодаря этому мы можем распределять нагрузку NoSQL среди множества серверов. Это значит, что если нам не хватает производительности, то можно просто докупить новые устройства.

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

Первое и главное преимущество SQL — строгая структура данных и операций. У базы есть контракт, который ты обязан соблюдать при добавлении, изменении или запросе данных. Правило простое: «Либо всё, либо откат». Второе преимущество — мощный и популярный язык запросов. Сложные аналитические задачи ему по плечу. Уверен, реляционные БД будущего будут опираться на опыт SQL.

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

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

Минусы в том, что у многих NoSQL свои системы команд и запросов — их приходится учить. Также есть сложности с консистентностью данных.

Где использовать SQL и NoSQL

Сценарии, где SQL незаменим

SQL хорош там, где важны точность, структура и сложные взаимосвязи данных.

Финансовые и банковские системы

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

Примеры систем: PostgreSQL, Oracle Database, Microsoft SQL Server.

Аналитика и сложные запросы

В аналитике нужно регулярно вытаскивать данные из таблиц и строить зависимости. В SQL есть операторы JOIN, GROUP BY и оконные функции, которые решают задачи, наподобие расчёта среднего чека за квартал, в пару строк.

Примеры систем: MySQL, Snowflake, Google BigQuery.

Работа с отчётами и BI-системами

Данные для бизнеса — это таблицы, сводки, графики. SQL легко интегрируется с инструментами вроде Power BI или Tableau. Строгая схема помогает избежать путаницы в метриках.

Примеры систем: PostgreSQL, SQL Server, Redshift.

Логирование и аудит данных

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

Примеры систем: SQLite, PostgreSQL, MariaDB.

Управление складом и инвентаризацией

Данные о товарах, поставках и остатках связаны между собой. Реляционная модель идеально описывает такие структуры. Запросы вроде «что заканчивается на складе» пишутся быстро и понятно.

Примеры систем: MySQL, Oracle Database.

Где NoSQL работает лучше?

NoSQL — это про скорость, гибкость и масштабирование. Там, где SQL требует строгих рамок, NoSQL даёт свободу и справляется с хаосом больших данных. Вот сценарии, где он выигрывает:

Высоконагруженные системы и real-time сервисы

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

Примеры систем: Cassandra, MongoDB, DynamoDB.

Гибкие структуры данных и работа с JSON

В реальной жизни данные далеко не всегда приходят в виде строгой схемы. У кого-то может быть указан email, у кого-то его нет, но есть телефон. Поэтому для работы с такой информацией лучше подходят документо-ориентированные базы, которые хранят JSON или BSON без строгой структуры. Если мы добавим новое поле, такая база не сломается.

Примеры систем: MongoDB, CouchDB, Firebase.

Графовые базы для рекомендаций и соцсетей

Иногда связи между объектами важнее самих данных. Графовые базы строят сети вроде «друзья друзей» или «похожие товары» за доли секунды. SQL для этой задачи медленнее.

Примеры систем: Neo4j, ArangoDB, OrientDB.

Почему SQL и NoSQL нужно знать вместе?

SQL даёт точность и структуру, данные в NoSQL — это про скорость и гибкость. В реальных проектах их часто используют вместе, чтобы закрыть слабые места друг друга.

Примеры гибридных архитектур: SQL и NoSQL в одном проекте

Работа с каталогами товаров, запросами и системой рекомендаций в интернет-магазинах

Представим интернет-магазин: каталог товаров и заказы лежат в SQL — там важны связи и точность. А рекомендации «похожие товары» или история просмотров — в NoSQL, чтобы быстро отдавать данные и не мучиться со схемой.

Например, PostgreSQL хранит данные о клиентах и транзакциях, а MongoDB — отзывы и пользовательские профили. Всё в одном проекте, каждый инструмент на своём месте.

Кеширование запросов с помощью Redis и SQL

SQL силён в сложных запросах, но в больших базах может тормозить. А если у нас есть операция, которая предполагает повторный подсчёт? Это будет долго. Здесь выручает Redis, NoSQL-база типа «ключ-значение».

Представим аналитику продаж: SQL вычисляет «топ-10 товаров за месяц» Готовый список сохраняем в Redis. Теперь, когда нам нужен этот топ, данные тянутся из Redis за миллисекунды, нам не надо заново проводить вычисления в SQL.

Использование NoSQL для логов, SQL — для отчётности

Логи — это поток данных: миллионы записей, структура не всегда предсказуема. NoSQL вроде Cassandra или MongoDB «переваривает» их без проблем благодаря скорости записи и горизонтальному масштабированию. А потом из этого хаоса SQL, например, MySQL, вытягивает нужное для отчётов: «сколько ошибок за день» или «кто чаще ломает систему». NoSQL собирает сырые данные, SQL их структурирует.

Стоит ли учить SQL? Мнение экспертов

Мы решили спросить у экспертов, что бы они посоветовали молодым разработчикам изучать в первую очередь, SQL или NoSQL. Делимся мнениями:

Мой совет — начинайте с SQL. Вот почему:

1) База знаний. SQL учит вас основам работы с данными — как их хранить и извлекать. Это фундамент, который пригодится в любом проекте, даже если вы потом перейдёте на NoSQL.

2) Широкое применение. SQL встречается повсюду — от стартапов до банков. Знание SQL сразу даёт вам больше шансов найти работу или понять, что происходит в существующем проекте.

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

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

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

Не существует как такового единого NoSQL как системы управления базы данных, зачастую это очень сильно различающийся набор решений, поэтому стоит начать с SQL, для разных СУБД он довольно мало отличается синтаксически. SQL — это фундамент. NoSQL даст более полное понимание того, как можно работать с базами данных. Можно отметить, что в SQL добавляются фичи NoSql и наоборот.

SQL и NoSQL желательно знать вместе. Как видно исходя из комментариев экспертов и примеров, SQL — первый ключ к базам данных, NoSQL — второй, для более сложных сценариев.

Согласно уведомлению, направленному в Конгресс, за атакой стояла группировка, спонсируемая государством (Advanced Persistent Threat, APT).

Однако самым удивительным стало то, каким именно способом взломщики проникли в защищённые серверы: всё произошло из-за SQL-инъекции, связанной с особенностями Unicode в PostgreSQL.

SQL-инъекция в PostgreSQL, которая оставалась незамеченной 9 лет

Критическая уязвимость была найдена в программе управления привилегированным доступом (PAM) от компании BeyondTrust, которая использовала PostgreSQL.

Проблема заключалась в функции pg_escape_string, отвечающей за экранирование пользовательского ввода, и её вызове внутри PostgreSQL-библиотеки libpq.

Хакеры использовали два байта (c0 27), которые PostgreSQL ошибочно интерпретировал как часть валидного Unicode-символа. В результате этот механизм позволил атакующим внедрить неэкранированный одиночный апостроф ('), открывший путь для SQL-инъекции.

Этот апостроф позволил хакерам захватить контроль над psql (CLI-интерфейсом PostgreSQL), а оттуда использовать команду \! для выполнения произвольного кода на серверах Минфина США.

Как такую уязвимость могли не заметить?

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

1. Скрывалась на уровне Unicode — у PostgreSQL не было встроенной валидации корректности Unicode-символов в PQescapeStringInternal.
2. Не представляла угрозы, пока не использовалась в командной строке psql — а это не самый частый сценарий.
3. Оставалась незамеченной более 9 лет в одном из самых популярных open-source проектов.

Теперь, после раскрытия проблемы, PostgreSQL выпустил обновление, исправляющее баг в pg_utf_mblen.

Выводы: строки сложны, Unicode ещё сложнее

Эта история ещё раз доказывает, что обработка строк и кодировки — источник огромного количества неожиданных уязвимостей.

Простая ошибка в обработке Unicode могла оставить PostgreSQL уязвимым на протяжении почти десятилетия.

И напоследок забавный факт: вы можете стать владельцем собственного символа Unicode — например, Buffalo Wild Wings уже «усыновили» эмодзи 🍗, а бейсбольная команда Oakland A’s владеет ⚾, 🐘 и 🌳.

MultiDirectory, разработанная компанией МУЛЬТИФАКТОР — российская служба каталогов с открытым кодом, в которой используется тот же набор атрибутов, что и в AD — это упрощает интеграцию с различными системами. Она поддерживает Kerberos, LDAP, SSO, двухфакторную аутентификацию и легко интегрируется с текущей IT-инфраструктурой. В статье расскажем:

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

Что такое службы каталогов и как они работают

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

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

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

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

Какие есть службы каталогов

Вот наиболее популярные решения:

• Microsoft Active Directory. Он интегрируется с Windows Server и поддерживает протокол LDAP и механизм доменов.
• OpenLDAP. Он используется в UNIX- и Linux-системах, подходит для опенсорсных систем. Но это только реализация LDAP — у него нет встроенного Kerberos, DNS, DHCP и так далее.
• Apache Directory. Java-реализация службы каталогов, поддерживающая LDAP и другие протоколы, часто используется в кроссплатформенных средах.

Зарубежные Open-Source-решения не поддерживаются официально либо требуют значительных затрат на локальную интеграцию и поддержку — это создаёт дополнительные риски для бизнеса.

В моменте, когда компании ищут замену Active Directory, они сталкиваются с проблемами:

• Не все решения поддерживают 2FA для Kerberos и совместимы с текущей инфраструктурой.
• Сложный перенос учётных записей пользователей.
• Не хватает встроенной двухфакторной аутентификации.

MultiDirectory имитирует работу AD, поэтому системы, в которых раньше была AD, можно перенастроить на MultiDirectory без изменений в работе — они будут думать, что всё так же работают с AD.

Основные технические характеристики MultiDirectory

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

Опенсорсный исходный код MultiDirectory написан на Python — это дает возможность гибкой настройки и контроля на отсутствие закладок. Код можно бесплатно использовать и предлагать исправления. Развёртывание происходит через Docker, что упрощает установку: система запускается на любом сервере с поддержкой контейнеров, без сложных зависимостей и долгой настройки.

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

Функциональные возможности и простая миграция

MultiDirectory позволяет плавно «переехать» с Active Directory, а еще в ней есть поддержка 2FA, SSO и централизованное управление учетными записями. Рассказываем об этих функциях ниже.

Централизованное управление учётными записями

Администраторы могут управлять учётными записями пользователей и правами через открытый API или вручную с помощью понятного веб-интерфейса. Также у них есть возможность создавать, изменять и удалять учётки и разграничивать права пользователей.

Доступ пользователей настраивается через группы и роли:

• Domain Admins — администраторы с полными правами
• Read Only — пользователи, которые могут только просматривать данные
• Domain Users — пользователи, у которых есть доступ только к своим учетным записям

Надежность, безопасность и 2FA

Хэши паролей хранятся в базе данных. А если нужно дополнительное шифрование, можно воспользоваться наложенными средствами защиты или встроенными функциями PostgreSQL. Для аутентификации используется Kerberos — протокол, реализация которого не предполагает передачу пароля по каналам связи. Это обеспечивает гораздо более высокий уровень безопасности по сравнению с тем же NTLM.

Двухфакторная аутентификация в MultiDirectory работает для нескольких интерфейсов: Admin API, LDAP и Kerberos. Каждый из них может быть защищен с помощью 2FA, а правила его использования настраиваются через политики безопасности.

1. Admin API (HTTP) поддерживает OTP или Push-уведомления.
2. LDAP также работает с OTP или Push.
3. Kerberos поддерживает только Push.

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

2FA снижает риск компрометации аккаунтов, даже если основной пароль утёк.

MULTIFACTOR — 2FA-система того же разработчика — интегрирована с MultiDirectory, поэтому настройка двухфакторной аутентификации не требует установки дополнительных адаптеров.

Режим Bypass

Если облачный сервис MULTIFACTOR временно недоступен, в MultiDirectory автоматически включается режим Bypass. В зависимости от настроек можно разрешить или запретить вход в систему без 2FA.

Настройки режима позволяют:

• Разрешить вход без 2FA в случае сбоя, чтобы бизнес-процессы не останавливались.
• Полностью запретить авторизацию при отсутствии двухфакторной проверки — если безопасность важнее доступности.

Поддержка DNS

MultiDirectory интегрируется с Bind9 и позволяет управлять всеми типами записей зоны через веб-интерфейс. При настройке DNS автоматически создаются необходимые записи для Kerberos и LDAP.

Быстрая авторизация с Single Sign-On (SSO)

Технология единого входа (SSO) позволяет пользователям вводить пароль только один раз — дальше система автоматически авторизует их в корпоративной почте, CRM, облачных сервисах и других внутренних приложениях.

В чем плюсы:

• Сотрудники не тратят время на постоянный ввод паролей.
• IT-отделу не приходится восстанавливать доступ к забытым учетным записям.
• Снижается риск утечек паролей.

Заключение

MultiDirectory — это российская альтернатива AD с поддержкой 2FA, SSO и централизованного управления.

Задачи, которые решает MultiDirectory:

• централизованное управление учетными записями, компьютерами группами;
• единая точка идентификации, аутентификации и авторизации;
• поддержка современных стандартов безопасности;
• управление DNS-записями через Bind9
• гибкая интеграция с внешними системами.

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

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

Анализируем производительность API

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

• Время отклика — сколько времени проходит от запроса до получения ответа.
• Нагрузка на сервер — сколько ресурсов потребляет API при обработке запросов.
• Частота ошибок — как часто сервер возвращает некорректные ответы.

Отслеживать эти показатели помогают инструменты вроде Postman, New Relic и APM-систем. Они визуализируют данные, автоматизируют тестирование и позволяют находить проблемы в режиме реального времени.

Postman

Используется для ручного тестирования запросов. Postman показывает время отклика и ошибки. Также через него удобно тестировать сценарии работы API.

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

Большой гайд по работе с Postman API Platform

New Relic

Платформа для мониторинга производительности приложений. Можно отслеживать время обработки API-запросов, статистику по операциям, загрузку системы.

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

APM-системы

Инструменты Datadog, AppDynamics или Dynatrace сохраняют данные о том, как работает API. Через них можно смотреть трассировку запросов, выявлять проблемы с медленными вызовами или зависимостями от внешних систем.

Ищем узкие места в запросах

Для выявления проблемных фрагментов кода необходимо посмотреть, как API реагирует на разные нагрузки, и как распределяется время обработки запроса.

Поиск состоит из 7 этапов:

• Анализ общей картины. С помощью APM-систем и логирования нужно выделить самые медленные запросы.
• Локализация длинных операций. В одном запросе может быть несколько узких мест (тяжелый SQL-запрос, внешний API-вызов).
• Поиск запросов с высокой частотой вызовов. Например, запросы к слою авторизации или ручки API, к которым обращаются массово при каждом действии пользователя.
• Проверка ошибок. Ошибки приводят к дополнительной нагрузке: например, если клиент совершает повторные запросы после тайм-аута.
• Анализ распределения нагрузки. Если одни эндпоинты перегружены трафиком, а другие используются редко, в рамках рефакторинга нужно сбалансировать нагрузку. Например, добавить серверы только под обработку горячих эндпоинтов.
• Тестирование в условиях пиковой нагрузки. Стресс-тест средствами JMeter поможет выявить проблемы, скрытые в условиях обычного трафика.
• Анализ зависимостей API. Замедленная работа внешнего сервиса увеличивает время отклика для каждого запроса. Через Jaeger или Zipkin можно посмотреть цепочку зависимостей.
• Локализация длинных операций. В одном запросе может быть несколько узких мест (тяжелый SQL-запрос, внешний API-вызов).

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

Уменьшить время отклика API без переписывания кода можно за счёт оптимизации работы с БД. Один из ключевых инструментов — индексы. Они ускоряют поиск данных, снижая нагрузку на сервер.

Что индексировать в первую очередь:

• Поля, используемые в WHERE, JOIN, ORDER BY, GROUP BY. Например, если запросы часто фильтруют по email, имеет смысл добавить индекс.

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

• Только те данные, где индексация действительно ускорит поиск. Например, индекс для gender (male/female) не даст прироста скорости.

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

Агрегация и выбор только необходимых полей

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

Например, команда SELECT * выбирает все колонки таблицы, включая неиспользуемые. Вместо SELECT * FROM users следует указывать целевые поля: SELECT id, name, email FROM users.

Если к запросу добавлены ненужные JOIN-ы, группировки или сортировки, в рамках рефакторинга нужно постараться избавиться от них. Избыточные операции на стороне БД рекомендуется переносить в бизнес-логику приложения.

Снизить объем данных можно за счет COUNT, SUM, AVG, MAX, MIN — эти функции возвращают обобщенные записи вместо отдельных значений. Частичную обработку данных можно выполнять на стороне БД. Например, в PostgreSQL есть встроенные функции по типу JSON_AGG.

Пагинация и лимиты в запросах

API, работающие со списками пользователей и транзакциями, обязательно должны использовать пагинацию. Лимит на объем возвращаемых записей предотвращает перегрузку серверов и клиента.

Самое простое решение — во время рефакторинга ограничить количество строк с помощью LIMIT или FETCH FIRST. Например, вместо загрузки всех пользователей SELECT id, name FROM users LIMIT 30 вернет только первые 30 строк.

Еще можно использовать постраничную выборку (комбинацию LIMIT и OFFSET):

Если производительность упала, значит офсет слишком большой. В таких случаях лучше перейти на модель курсоров.

Пагинация с курсорами заменяет OFFSET значением последнего взятого элемента. Например, вместо LIMIT 20 OFFSET 100 можно использовать запрос:

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

Пагинация на Go в PostgreSQL

Кэширование

Количество запросов к серверу можно сократить, если сохранять часто запрашиваемые данные. Это называется кэшированием. Рефакторинг кэширования уменьшает нагрузку на сервер, снижает время отклика API.

Рассмотрим инструменты для кэширования.

Redis

Подходит для серверного и распределенного кэширования. Поддерживает TTL, работу со списками, хэшами и включение репликации для отказоустойчивости. Для интеграции доступны библиотеки и клиенты — ioredis для Node.js или StackExchange.Redis для .NET.

Как использовать Redis для кэширования и очередей в веб-приложениях

Рефакторинг кэширования повысит производительность сервиса:

• если API возвращает неизменяемые или редко изменяющиеся данные,
• если часть запросов к БД выполняется кратно дольше остальных.

Например, в Redis можно сохранять список активных пользователей:

Memcached

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

Как использовать серверы Redis и Memcached для кэширования

Виды кэша

Выбор типа кэширования зависит от архитектуры API и характера данных.

• Клиентский кэш — данные хранятся на стороне клиента. Например, браузеры загружают страницу дольше в первый раз, но затем мгновенно извлекают её из кэша.
• Серверный кэш — данные сохраняются на сервере или в промежуточном хранилище (Redis, Memcached). Это снижает нагрузку на базу данных: повторные запросы возвращаются из кэша, а не пересчитываются заново.
• Распределённый кэш — данные кэшируются в нескольких узлах для масштабирования и высокой доступности. Например, Redis в режиме кластера помогает организовать кэширование в микросервисной архитектуре.

Уменьшение объема передаваемых данных

Скорость API зависит от объема данных, передаваемых между клиентом и сервером.

Оптимизация формата ответа: JSON vs Protobuf

Формат JSON популярен из-за читаемости и универсальной поддержки большинством языков программирования. Он менее эффективен по сравнению с бинарными форматами. JSON занимает больше места из-за текстового представления структур и значений.

Protobuf (Protocol Buffers) — бинарный формат, разработанный Google. Он компактен, быстрее сериализуется и занимает меньше места по сравнению с JSON. В формате Protobuf каждый элемент закодирован с минимальным количеством байтов.

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

Удаление избыточных данных и компрессия

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

• Удаление ненужных полей — ограничение выборки данных на стороне сервера: используются выборочные запросы к БД, настройка сериализаторов или фильтрация на уровне представлений.
• Сжатие Gzip — уменьшение размера текстовых данных (JSON, XML) на 70–90%, не требуя изменений в API. Включается на уровне Nginx, Apache или через middleware. Клиенты автоматически распаковывают такие ответы, сохраняя прозрачность процесса.

Версионирование API

Клиенты обычно нуждаются в данных разного объема. Вместо универсального ответа для всех пользователей рекомендуется разработать несколько версий API.

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

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

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

Параллелизация и объединение запросов

Оптимизировать API можно за счет рефакторинга batch-запросов. Они объединяют несколько запросов в один — количество обращений между клиентом и сервером сокращается.

Клиенты отправляют массив запросов, сервер обрабатывает их и возвращает всего один ответ.

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

Например, мобильное приложение может запрашивать информацию о пользователе и связанных с ним объектах (сообщения, уведомления) за один вызов.

Если API поддерживает вложенные запросы, клиент может запрашивать связанные данные одним вызовом. Пример на GraphQL:

Асинхронные операции

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

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

Для асинхронных операций часто используются очереди сообщений RabbitMQ или Apache Kafka.

Оптимизация на уровне серверной логики

Обработку запросов можно откладывать до момента, когда данные действительно понадобятся. Это полезно при работе с запросами, где связанная информация не требуется или используется не полностью. Такое поведение называется lazy loading (ленивая загрузка).

Загружать связанные данные можно заранее в одном запросе, чтобы сократить количество запросов к БД. Такой принцип работы API называется eager loading (стремительная загрузка). Используется в случаях, когда известно, что все связанные данные понадобятся в ходе операции.

Lazy loading подходит, если только небольшая связка данных используется в каждом запросе.

Eager loading лучше применять, когда количество запросов к БД критично или весь объем данных необходим для выполнения операции.

Очереди для обработки задач в фоне

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

Очереди используются для задач, не влияющих на основной ответ клиенту:

• отправка писем,
• формирование отчетов,
• обновление статистики,
• построение индексов,
• обработка данных.

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

Разделение сложных операций на этапы

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

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

Мониторинг и тестирование

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

• нагрузочное тестирование,
• сравнение метрик до и после рефакторинга,
• автоматизацию наблюдения за состоянием API.

Нагрузочное тестирование определяет, как API справляется с возрастающей нагрузкой. Оно выявляет точки перегрузки. Инструменты для стресс-теста API: Apache JMeter, Gatling.

На основе результатов нагрузочного тестирования можно проанализировать, насколько рефакторинг улучшил производительность API. В сборе метрик помогут APM-инструменты.

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

Автоматизация мониторинга повышает надежность API и предотвращает проблемы до их масштабного проявления. Инструменты для поддержания производительности в реальном времени: Prometheus + Grafana, Datadog.

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

• Производительность API оценивается с помощью метрик: времени отклика, нагрузки на сервер и частоты ошибок.
• Для мониторинга API используются инструменты Postman, New Relic и APM-системы, которые выявляют узкие места системы.
• Оптимизация запросов к базе данных включает индексацию, удаление избыточных операций и выбор только необходимых полей. Для работы с большими объемами данных используется пагинация с применением LIMIT, OFFSET или курсоров.
• Кэширование снижает нагрузку на сервер, сохраняя востребованные данные локально.
• Уменьшение объема передаваемых данных достигается за счет перехода с JSON на Protobuf, компрессии Gzip и фильтрации полей.
• Для сокращения числа запросов к API применяются batch-запросы.
• Асинхронная обработка операций с помощью очередей RabbitMQ или Kafka ускоряет время отклика API для клиентов.
• Очереди для фоновой обработки задач снижают нагрузку на основной поток запросов.
• Нагрузочное тестирование помогает оценить улучшения после рефакторинга.
• Автоматизация мониторинга предотвращает проблемы API до их критического проявления.

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang. Также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, что объединяет Go-разрабов каждого грейда.

А почитать о том, как сейчас стать Go-разрабом, можно в предыдущей статье.

Навык собеседований vs. навык работы

Для начала важно разделять два понятия: навык прохождения собеседований и навык работы. Интервью длится 3-4 часа — этого невероятно мало, чтобы прочувствовать весь ваш кругозор в бою, поэтому индустрия использует стандартные задачи-заглушки. У большинства компаний такие задачи примерно про одно и то же, поэтому сейчас не редка ситуация, когда на собеседовании ваш реальный грейд на единицу или полторы выше реального — как раз потому, что такие заглушки отскакивают от зубов.

• Что это значит для кандидата: в такой ситуации можно быстрее вырасти в реальном навыке работы, потому что через навык собеседований вы получаете грейд. Эти задачи не даются просто так на позиции, которая соответствует навыку реальной работы. Так, в стрессовой ситуации вы максимально выравниваетесь за короткий срок.
• Что это значит для компании: для работодателя это плохо, поскольку определить грейд — еще сложнее. И есть шанс нанять кандидата, на которого потратят больше денег, чем он теоретически может принести.

Теперь разберем, что требуется от Go-разработчиков на каждом уровне.

Что нужно с точки зрения навыка собеседований

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

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

Грейд: Junior

Сейчас на рынке Go очень много джунов — он перегрет, и попасть в компанию без коммерческого опыта будет крайне сложно. Более того, от начинающих разработчиков ждут немало знаний и навыков. О них — ниже.

Углубленное знание Go

• Уметь абстрактно рассказать про очереди в планировщике.
• Знать про мапу под капотом: как устроено хеширование, коллизии и разрешение конфликтов.
• Уметь решать задачи по concurrency на относительно базовом уровне (воркер пул) и на слайсы
• Понимать принципы работы горутин и каналов.

Базы данных

• Знать виды баз данных и рассказать про максимальное количество юзкейсов из опыта с разными типами данных.
• Знать индексы и ACID и уметь их базово писать.
• Знать SQL, уметь составлять схемы и идейно понимать, как работают самые известные базы — PostgreSQL, ClickHouse.
• Понимать репликацию и шардирование

Системный дизайн

Да-да, теперь даже джуну нужно иметь абстрактное понимание сисдиза:

• Монолит vs. микросервисы: знать плюсы и минусы каждой архитектуры.
• Знать варианты коммуникаций между сервисами (брокеры сообщений, REST API, gRPC).

Алгосы и Computer Science

• Уметь решать медиум-задачки на LeetCode. Фокус при этом на задачах со слайсами, деревьями и графами.
• В Computer Science — знать про устройство Linux, планировщик, потоки/процессы, а еще про устройство сети — OSI, TCP/IP, протоколы и т.д.

Также в некоторых компаниях сейчас ко всему этому требуют еще и знание Kubernetes.

Вот здесь собрал дорожную карту, как влиться в IT на примере Go. Из полезных ссылок:

1. Один из лучших курсов по Go на Youtube
2. Крутой урок по системному дизайну
3. Все про каналы в Go

А здесь можно посмотреть, как джуну стать мидлом.

Грейд: Middle

Схема примерно такая же, как и с джунами, правда, знать все нужно гораздо глубже.

Go

• Знать планировщик на уровне того, какая структура данных используется в локальных очередях.
• В слайсах — уметь решать задачи со срезом по capacity, плюс более уверенное решение кейсов по concurrency.

Базы данных

• MVCC,
• Проблема разбухания индексов,
• Селективность,
• Шардирование на уровне реальных решений основной проблемы решардинга — Consistent Hash,
• Реприликация и паттерн Raft.

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

Сисдиз

Нужно знать про паттерны межсервисного взаимодействия: Saga, Transactional Outbox, Circuit Breaker. На мидла могут уже спокойно давать практические задачи на внедрение каких-то идейных дизайнерских штук, например, идемпотентности.

Алгосы и Computer Science

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

Грейд: Senior

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

Go

Нужно знать библиотеку Reflection со всякими приколами, которые могут ускорить concurrency. Также разбираться в аренах памяти и планировщике.

Сисдиз

В паттернах межсетевого взаимодействия история с обычным рассказом не пройдет — юзкейсы здесь must-have. Поэтому важно уметь проходить System Design-интервью — собирать функциональные и нефункциональные требования, считать нагрузку, проектировать на разных уровнях абстракции, углубляться и решать проблемы в своей же архитектуре. Это сложно, и без хотя бы косвенного соприкосновения с проектированием, будет непросто. Поэтому в качестве совета — стремитесь максимально участвовать на архитектурных сессиях и грумингах, будучи мидлом.

Базы данных

Будет круто знать, как под капотом реализован, например, PostgreSQL: как он поднимает что-то в буфер, как хранит данные на диске, что такое чекпоинты и бэкапы и как реализована MVCC.

В случае с ClickHouse лучше верхнеуровнево понимать LSM-дерево, а с ElasticSearch — инвертированные индексы.

Алгосы и Computer Science

Алгоритмы уже почти не играют роли в большинстве компаний, а Computer Science требуется примерно на том же уровне, что и на джуна. Единственное — в Linux могут чуть капнуть.

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

Мне часто на трансляциях говорят: «Зачем мне знать планировщик или уметь решать сложные задачи по concurrency? Когда мне это пригодится в работе?». Действительно, на эффективность в решении рабочих задач это влияет незначительно, но все же это особенность собеседований (подробнее можно посмотреть здесь):

• Собес ≠ работа. Принято считать, что знания, требуемые на собеседовании, пригодятся в работе — это не так. За несколько часов невозможно полностью оценить кандидата, поэтому интервью строятся на проверке общих знаний и концепций.
• Почему спрашивают про планировщик? Банально узнают софты.
• Жесткая конкуренция. Все просто: знание — сила.

Что нужно с точки зрения реальной работы

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

• Грейд Junior. Нужно уметь делать максимально базовые задачи. Например, добавить поле или прокинуть фича-флаг. Или же при курировании и ревью быть мотивированными. Этого достаточно. Да, как бы грустно это ни звучало, здесь по классике предполагается, что тебе нельзя доверить что-то серьезное без сторонней помощи.
• Грейд Middle. Относительно безболезненно брать на себя полноценные части продукта в зону ответственности, фича-лидить. Здесь предполагается, что ты можешь действовать относительно самостоятельно, приходя с вопросами лишь иногда. Тут уже желательно участвовать в каких-либо технических обсуждениях.
• Грейд Senior. Здесь нужно разрабатывать фичи любого уровня сложности под ключ. Тебе достаточно предоставить бизнес-требования, сходить с ними по командам с экспертизой. Затем спроектировать качественную архитектуру, которая развалится с минимальной вероятностью, самому реализовать и принести лиду таску в Done. Здесь также важно менторить сотрудников, активнейшим образом участвовать на грумингах и любых других технических созвонах.

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

Это не шутка. Именно такую сумму заплатила американская сеть казино Caesars Entertainment злоумышленникам, которые увели их БД.

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

Такие разные базы данных

Базы данных — основной инструмент программирования. БД хранят важную информацию о пользователях и позволяют этой информацией управлять.

Они делятся на два основных типа: реляционные и нереляционные.

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

Все очень аккуратно, ничего не теряется, но если нужно что-то изменить, например, носки переложить в ящик с платками –– будет не так-то просто.

Чтобы делать запросы к реляционной базе, нужно использовать язык SQL. А обрабатывать эти запросы будет СУБД –– система управления базами данных. Простыми словами –– штука, которая помогает вам управлять самой базой. Что-то из шкафа вытащить, кого-то в него спрятать.

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

Какой тип БД выбрать для проекта –– зависит от целей компании, размера и особенностей бизнеса. Разберём каждый тип.

Реляционные базы данных (SQL)

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

Посмотрим на конкретные примеры.

MySQL

Очень популярная база с открытым исходным кодом. Она надежная, удобная и быстрая. MySQL часто используют для веб-приложений. Например, Airbnb, Netflix и Uber.

Её любят, потому что у неё качественная и подробная документация, а также большое сообщество.

PostgreSQL

Мощная и универсальная реляционная база данных, которая предлагает расширенные возможности. Среди них — работа с JSON, хранение массивов и поддержка пользовательских типов данных. Это делает PostgreSQL гибким инструментом для решения самых разнообразных задач.

СУБД используется в сложных приложениях, где важны высокая надежность и гибкий функционал.

SQLite

Эта однофайловая СУБД мало весит и не требует сервера для работы. Она идеально подходит для небольших приложений, мобильных устройств и тестирования.

Если нужно будет что-то куда-то переносить –– процесс пойдёт быстро. За эту простоту SQLite и любят.

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

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

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

Разберём самые популярные варианты нереляционных баз.

MongoDB

NoSQL-база данных, которая хранит данные в формате JSON, обеспечивает гибкость и простоту работы. MongoDB часто используется в приложениях, требующих динамической структуры данных, а также в учебных и небольших проектах благодаря своей доступности и лёгкости освоения.

Redis

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

В чём разница между базами данных

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

Структура данных

Масштабируемость

Скорость и производительность

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

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

Подключаемся к MySQL

Для реляционных баз данных используются стандартные операции:

• SELECT — получить данные;
• INSERT — добавить новые данные;
• UPDATE — обновить существующие данные;
• DELETE — удалить данные.

Поработаем с ними на примере MySQL. Представим, что у нас есть база с пользователями нашего блога. Чтобы поработать с ней, нужно настроить соединение с программой. Разберём этот процесс шаг за шагом.

Шаг 1. Устанавливаем библиотеку

Для работы с MySQL в Python нам понадобится библиотека mysql-connector-python.

Дла этого напишем команду в терминале:

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

Шаг 2. Настраиваем подключение

Чтобы подключиться к базе данных MySQL, необходимо знать её параметры:

• Хост: адрес сервера, где находится база данных. Это может быть localhost;
• Порт: номер порта для подключения. По умолчанию для MySQL — 3306-й порт;
• Пользователь: имя пользователя, который имеет доступ к базе;
• Пароль: пароль для этого пользователя;
• Имя базы данных: конкретная база, с которой вы хотите работать.

Как это может выглядеть:

• Хост: localhost
• Порт: 3306
• Пользователь: root
• Пароль: “”
• Имя базы данных: test_db

Шаг 3. Подключаемся к базе данных

Теперь создадим программу, которая установит соединение с MySQL.

Что тут происходит:

1. Импорт нужных библиотек: mysql.connector — это основной модуль для работы с MySQL в Python. Error — класс для обработки ошибок;
2. Настройка подключения: Используем метод mysql.connector.connect, в который передаются параметры: host, user, password и database. Это наши настройки для базы данных;
3. Проверка подключения:Метод is_connected() из переменной connection проверяет, удалось ли установить соединение;
4. Выполнение запросов:Создаём курсор для выполнения SQL-запросов с помощью connection.cursor(). После этого можно делать запросы к базе. Выбираем конкретную базу, получаем все данные, добавляем в неё сущность, а затем удаляем её. Последний запрос — получение одного конкретного юзера;
5. Закрытие соединения:Закрываем соединение с помощью метода connection.close() для того, чтобы избежать утечек ресурсов и проблем с безопасностью.

Вы также можете обернуть код в try-except, чтобы отловить непредвиденные ошибки и не уронить сервер.

С помощью этого подхода можно быстро настроить подключение к MySQL и начать работу с базой данных в Python-проекте.

Подключаемся к MongoDB

Для нереляционных баз используем NoSQL-запросы. Функционал такой же: добавление, удаление, изменение и получение данных. А выглядят они по-другому. Посмотрим на примере MongoDB.

Для работы с MongoDB в Python используется библиотека pymongo. Разберём, как настроить соединение, выбрать базу данных и выполнить простой запрос.

Шаг 1. Устанавливаем библиотеку

Для начала установим библиотеку pymongo на своём компьютере. Введём команду в терминал:

Шаг 2. Настраиваем подключение

Чтобы подключиться к MongoDB, нужно знать параметры базы:

• Хост: адрес сервера;
• Порт: порт, на котором работает MongoDB. По умолчанию — 27017;
• Имя базы данных: название базы, которую вы хотите использовать;

MongoDB автоматически создаст базу данных, если она не существует.

Пример настроенной базы:

• Хост: localhost
• Порт: 27017
• Имя базы данных: test_db

Шаг 3. Подключаемся и выполняем запрос

Нам нужно подключиться к базе данных MongoDB, добавить, удалить и получить данные коллекции:

Разберём подробнее:

1. Импорт библиотеки: Используем MongoClient из библиотеки pymongo, чтобы создать подключение к базе;
2. Создание подключения: Используем данные хоста и порта, где запущен MongoDB;
3. Выбор базы данных и коллекции: Выбираем нужную базу данных. В нашем случае –– test_db. Если базы нет, MongoDB создаст её при добавлении первого документа;
4. Добавление документа: Добавляем новый документ с пользователем с помощью insert_one(). А также выводим в консоль информацию о добавленном пользователе;
5. Удаление. Удаляем юзера и проверяем, получилось ли. Если нет, в консоли увидим запись, что такого юзера не существует;
6. Выполнение запроса: Ищем только что добавленный документ методом find_one() и проверяем, нашли ли. Тут то же самое: если юзера нет, то в консоли мы это увидим;
7. Закрытие подключения: Закрываем вызов через client.close() и оповещаем самих себя в консоли.

Вы могли заметить, что мы везде заканчиваем код закрытием соединения. Это важно по нескольким причинам:

1. Подключение к базе данных –– ресурсы сервера и клиента. Если соединение не закрыть, ресурсы останутся занятыми. Значит, их нельзя будет использовать для более нужных вещей;
2. Неиспользуемые открытые соединения приводят к утечкам памяти;
3. Открытое соединение может стать уязвимостью для атак, несанкционированного доступа или SQL-инъекций.

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

В этой статье мы лишь поверхностно коснулись темы баз данных. Если у вас ещё нет лишних денег на выкуп своих данных, рекомендуем инвестировать время в изучение основ и тонкостей работы с БД.

Качественно спроектированная база данных не только повысит эффективность и прибыльность бизнеса, но и защитит его от серьёзных рисков. Кроме того, вы значительно прокачаете свои навыки программирования.

Удачи в разработке и безопасности ваших данных! 🚀

При этом PostgreSQL уже занимал первое место в 2017, 2018, 2019 и 2023 годах. Среди 423 систем, мониторящихся DB-Engines, PostgreSQL показала наибольший прирост популярности за 2024 год.

На втором месте расположилась Snowflake, а третье заняли продукты Microsoft — Azure SQL Database и SQL Server.

Почему PostgreSQL остаётся лидером?

История PostgreSQL начинается почти 35 лет назад с системы Postgres. С тех пор она эволюционировала, став одной из самых современных и стабильных систем управления базами данных.

В 2024 году PostgreSQL представила новую версию — PostgreSQL 17, которая включила:

• Улучшения производительности.
• Расширенные опции репликации.
• Дополнительные функциональные возможности для разработчиков.

Конкуренты: Snowflake и Microsoft

Snowflake

Snowflake — облачная СУБД, которая активно набирает популярность благодаря уникальной архитектуре разделения хранения и вычислений. Среди её преимуществ:

• Поддержка мультиоблачных сред.
• Возможности обмена данными между различными системами.

Эти особенности сделали Snowflake популярным выбором для компаний, работающих с облачными хранилищами данных.

Microsoft

Продукты Microsoft, такие как Azure SQL Database и SQL Server, продолжают удерживать высокие позиции благодаря:

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

Как определяется победитель?

DB-Engines оценивает популярность СУБД на основе роста интереса к системе за год. Этот рост включает в себя:

• Количество упоминаний в вакансиях.
• Упоминания в профессиональных профилях.
• Цитаты в сети.

Для определения СУБД года используется разница в популярности между январём 2024 и январём 2025 года, что позволяет объективно оценить рост без перекоса в сторону менее известных систем.

Международное сообщество PostgreSQL является одним из самых активных и сплоченных в мире OpenSource-проектов. Выход каждой новой версии — это итог кропотливой работы множества участников. Как рассказала на проходившей в октябре в Афинах европейской конференции PostgreSQL Клэр Джордано, руководитель группы разработчиков открытого исходного кода Postgres в компании Microsoft, в период создания 17 версии было отправлено 2 680 коммитов от 232 авторов кода и документации со всего мира. Сообщество активно растет и развивается, в том числе и за счет появления новых участников, среди которых — как разработчики форков свободной СУБД, так и создатели всевозможных полезных утилит и дополнений для нее. Более 35 тысяч сообщений в рассылке pgsql-hackers за период разработки свидетельствуют о динамичном обсуждении и решении сложных технических задач.

Вклад в кодовую базу

Большая часть отправленных коммитов в исходный код PostgreSQL 17 были небольшими по объему изменений. Так, 316 коммитов не изменили ни одной строки кода, 636 коммитов затронули от 2 до 10 строк, и только 70 коммитов изменили более одной тысячи строк кода. Временной промежуток между первым обсуждением в рассылке и непосредственным коммитом варьировался: 220 коммитов были осуществлены в тот же день, 476 коммитов — в течение недели, а некоторые идеи ждали реализации более пяти лет. Разработка новой версии включала как исправления старого кода, так и добавление новых функций. Примечательно, что были удалены или изменены около 150 строк кода, включенных еще в Postgres95, одну из первых версий, что свидетельствует о постоянном обновлении и модернизации системы.

Российские разработчики играют значительную роль в развитии PostgreSQL. В числе уже упомянутых 232 авторов кода фигурировали 17 россиян. Среди них сотрудники компаний «Яндекс», Postgres Pro и других, а также независимые программисты. Для сравнения, граждан Китая среди авторов кода всего 13 человек, а индийцев – только 7. Участие российских компаний также высоко ценится сообществом, о чем упомянула Клэр Джордано.

Открытость и дружелюбие

Клэр Джордано также отметила, что сообщество PostgreSQL признано одним из самых открытых и дружелюбных. В нем действуют различные программы менторства, например, очень популярен сервер PostgreSQL Hacker Mentoring, где опытные разработчики помогают новым участникам освоиться и внести свой вклад. Крупные компании также активно поддерживают PostgreSQL, спонсируя мероприятия и способствуя развитию сообщества. Так, в 13 организациях трудятся 30 коммитеров PostgreSQL.

Активность в комьюнити

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

Ежегодно проводятся международные конференции, такие как PGConf и PGCon, где эксперты делятся опытом, представляют новые разработки и обсуждают актуальные темы в области PostgreSQL. Во многих странах организуются региональные конференции и встречи. Эти события позволяют локальным сообществам обмениваться знаниями на родном языке и учитывать специфические региональные потребности.

Что касается России и Белоруссии, то здесь также проводятся региональные мероприятия под эгидой сообщества — PG BootCamp. Они уже проводились в Москве, Минске и Казани. Это важно, как для российского и белорусского, так и для мирового комьюнити. Несмотря на тот факт, что рынок наших двух стран частично отрезан от западной экономики, в Postgres-сообществе идет интенсивный обмен идеями, мнениями и видением подходов по дальнейшему технологическому развитию одной из самых популярных в мире СУБД. А для России плюс также состоит в том, что в связи с уходом западных вендоров, таких как Oracle и Microsoft, отечественные игроки получили отличный шанс занять достойное место на рынке.

Отечественных разработчиков на международных мероприятиях слушают и слышат. В период разработки PostgreSQL 17 было проведено 29 официальных мероприятий, в которых приняли участие 397 спикеров из 39 стран, в том числе 11 человек из России.

В каких компаниях работают 437 спикеров, выступавших на международных мероприятиях во время работы над Postgres 17? Большая часть экспертов трудится в ИТ-гигантах, таких как AWS и Microsoft. В то же время из российских компаний наибольшую активность показала «Тантор Лабс» с долей в 1%. Это немало, учитывая что 2/5 приходится на именитые мировые компании, а 3/5 всех спикеров суммарно занимают ровно тот же 1%.

Такой процент участия в мероприятиях включает как международные конференции и встречи, так и PG BootCamp Russia.

На конференции звучали доклады по самым разным темам: оптимизация запросов с помощью pg_stat_advisor, аудит безопасности PostgreSQL, работа с планировщиком, векторная обработка данных (с приростом производительности до 64 раз) и анонимизация данных с помощью pg_anon.

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