Базы данных *

Как выбрать только нужные колонки по шаблону, не перечисляя их в SELECT

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

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

В классических базах данных мы бы сидели и вручную перечисляли названия всех нужных колонок в SELECT. В ClickHouse это делается гораздо изящнее.

Чтобы не писать десятки колонок руками, можно использовать выражение COLUMNS('regexp'). Оно автоматически находит и подставляет в выборку все столбцы, названия которых подходят под регулярное выражение.

В качестве примера рассмотрим таблицу traffic, в которой хранятся метки рекламных кампаний и метрики:

┌─utm_source─┬─utm_medium─┬─utm_campaign─┬─clicks─┬─costs─┐
│     google │        cpc │      promo_1 │    150 │    10 │
│     yandex │        cpc │      promo_2 │    200 │    15 │
└────────────┴────────────┴──────────────┴────────┴───────┘

Чтобы выбрать только utm-метки, обычно мы привыкли писать так:

SELECT 
  utm_source, 
  utm_medium, 
  utm_campaign 
FROM traffic

С использованием COLUMNS можно написать гораздо короче:

SELECT COLUMNS('utm') 
FROM traffic

┌─utm_source─┬─utm_medium─┬─utm_campaign─┐
│     google │        cpc │      promo_1 │
│     yandex │        cpc │      promo_2 │
└────────────┴────────────┴──────────────┘

Несколько нюансов:

1. Внутри скобок пишется регулярное выражение (синтаксис re2). Например, COLUMNS('a') выберет все колонки, в названии которых есть хотя бы одна буква «a».

2. Выбранные столбцы возвращаются в том порядке, в котором лежат в таблице (а не по алфавиту).

3. Если регулярному выражению не соответствует ни один столбец, и кроме COLUMNS в SELECT больше ничего нет — ClickHouse выдаст ошибку.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

«Диасофт» приглашает на День СУБД 2026

27 октября в Кибердоме (Москва) пройдет вторая конференция «Диасофт», посвященная промышленной эксплуатации СУБД.

Почему стоит идти:

🔵 Увидеть сценарий миграции вживую

Демонстрация переноса целевой схемы с MS SQL и Oracle без переписывания кода — на сцене, с реальной консолью, а не на слайдах.

 🔵 Задать вопросы команде разработки

Архитекторы и руководители направлений Digital Q.DataBase ответят лично — без тикетов, SLA и линии поддержки.

 🔵 Забрать готовый чек-лист миграции

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

🔵 Поговорить с теми, кто уже завершил миграцию

Три часа нетворкинга с командами, которые прошли переход в 2025-2026 годах. Можно записаться на персональную консультацию прямо в форме.

 О чем поговорим:

1. Изменение подхода к импортозамещению СУБД: от «заменить любой ценой» — к управляемой миграции.

2. Национальная СУБД как важный элемент технологического суверенитета – итоги первого полугодия в открытом доступе.

3. Импортозамещение СУБД в высоконагруженных системах: MPP, шардирование, терабайтные объемы данных.

4. Кейсы клиентов и партнеров «Диасофт» по переходу на Digital Q.DataBase — с конкретными цифрами и сроками.

5. Совместимость как продукт: диалекты Oracle и MS SQL, протокол TDS, эмуляция Instant Client.

Digital Q.DataBase — сертифицированная ФСТЭК российская СУБД на ядре PostgreSQL. Встроенная поддержка диалекта и транспортного протокола TDS позволяет перейти с MS SQL без участия разработчиков, поддержка PL/SQL и эмуляция Oracle Instant Client — быстро мигрировать с Oracle. Запись в реестре российского ПО № 15 561, сертификат ФСТЭК по 4-му уровню доверия № 4843.

 ➡️ Зарегистрироваться на мероприятие можно по ссылке

Как применить одну функцию к нескольким колонкам, не перечисляя их в SELECT

В прошлом посте я рассказывал про модификатор REPLACE, с помощью которого можно менять значения «на лету», не перечисляя все колонки в SELECT. Сегодня расскажу про еще один полезный модификатор — APPLY.

Иногда бывают ситуации, когда нам нужно применить одну и ту же функцию сразу к нескольким колонкам (например, посчитать сумму).

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

В ClickHouse это делается проще.

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

В качестве примера рассмотрим таблицу metrics, в которой хранится количество кликов, просмотров и затрат:

┌─clicks─┬─views─┬─spend─┐
│     10 │   100 │    50 │
│     15 │   150 │    70 │
└────────┴───────┴───────┘

Чтобы посчитать сумму по каждому полю обычно мы привыкли писать так:

SELECT
  sum(clicks),
  sum(views),
  sum(spend)
FROM metrics

┌─sum(clicks)┬─sum(views)─┬─sum(spend)─┐
│         25 │        250 │        120 │
└────────────┴────────────┴────────────┘

С использованием APPLY можно написать короче:

SELECT * APPLY(sum) 
FROM metrics

┌─sum(clicks)┬─sum(views)─┬─sum(spend)─┐
│         25 │        250 │        120 │
└────────────┴────────────┴────────────┘

Несколько нюансов:

1. Правила вызова пишутся в круглых скобках. Синтаксис такой: APPLY(имя_функции) без аргументов.

2. Передаваемая функция в APPLY должна уметь работать со всеми полями выборки и их типами данных. Например, для sum все поля должны быть числовыми.

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

4. APPLY можно использовать не только для агрегации, но и для изменения типов данных. Например, APPLY(toString) быстро переведет все выбранные колонки в строковый формат.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

Как менять значения «на лету», не перечисляя все колонки в SELECT

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

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

В классических транзакционных базах, таких как PostgreSQL, мы бы вручную перечисляли в SELECT абсолютно все поля: и те, которые нужно просто вывести, и те, значения в которых нужно как-то изменить.

В ClickHouse это делается проще.

Чтобы не писать десятки колонок руками, можно использовать модификатор REPLACE. Он работает в связке со звездочкой * и позволяет вывести все поля, заменив значения только в конкретных.

Обычно мы пишем так:

SELECT
  id,
  category,
  user_id,
  -- ... перечисляем десятки остальных колонок руками ...
  LOWER(email) AS email
FROM table

С использованием REPLACE запрос становится короче:

SELECT * REPLACE (LOWER(email) AS email)
FROM table

А если нам надо и исключить колонки, и заменить значения, можно писать EXCEPT и REPLACE вместе:

SELECT * 
    EXCEPT (updated_at) 
    REPLACE (LOWER(email) AS email)
FROM table

Несколько нюансов:

1. Правила замены пишутся в круглых скобках. Синтаксис такой: (выражение AS имя_существующей_колонки).

2. Можно изменять сразу несколько колонок, перечислив их через запятую: REPLACE (LOWER(email) AS email, price * 0.85 AS price).

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

Про еще один модификатор расскажу в следующем посте.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

«Сибур-Нефтехим» заработал 160 миллионов рублей на том, что закончил ремонт на восемь суток раньше.

Меняли катализатор в реакторах окисления этилена. Раньше на это уходило 28 суток на каждую линию, и всё это время установка стоит. В этот раз одну линию закрыли за 25 суток, вторую за 23. Установка отработала выигранные сутки и дала лишние 4,5 тысячи тонн продукции.

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

Поговорили с Василием Можаровым. Он отвечает за систему управления знаниями в СИБУРе. Вот что рассказал:

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

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

Сложить документы в одно место оказалось мало

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

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

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

Разделы мы нарезали по задачам, а не по отделам

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

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

Ждать, что сотрудник сам расскажет о своей практике, не стоит

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

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

Всё это оформили как лучшую практику и передали на «Нижнекамскнефтехим» и другие предприятия, где меняют катализатор.

Один реестр мы отдали языковой модели целиком

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

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

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

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

Владельцев разделов и регламент обновления мы завели задолго до всякого ИИ. Восемь суток на ремонте катализатора выиграли тоже без него.

Подписывайтесь на наш тг‑канал. Он полезен айтишникам, которые хотят понять, что реально происходит в промышленном ИТ.

Как исключить ненужные колонки из SELECT *

Когда пишешь SQL-запрос к широким таблицам (где 50 и больше колонок), часто необходимо вывести только конкретные поля исключив ненужные. В стандартном SQL для этого, как правило, приходится вручную перечислять в SELECT все необходимые колонки (например 48 из 50). Ну, либо копировать их список из DDL и удалять лишнее. А если таблица меняется, запрос приходится переписывать.

В ClickHouse можно исключать ненужные колонки проще.

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

Обычно мы пишем так:

SELECT
  id,
  category,
  user_id,
  -- ... перечисляем остальные колонки руками ...
FROM table

С использованием EXCEPT запрос становится короче:

SELECT * EXCEPT (updated_at)
FROM table

Несколько нюансов:

1. Исключаемые колонки пишутся в круглых скобках через запятую.

2. Не путайте модификатор EXCEPT с оператором вычитания множеств.

3. Модификатор отлично комбинируется с другими модификаторами, например с REPLACE или APPLY (напишу про них в следующих постах).

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

В копилку обновлений PostgreSQL 

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

Настроить поиск:

1️⃣ fuzzystrmatch — помогает находить похожие по написанию строки, в том числе с опечатками.

2️⃣ unaccent — игнорирует диакритические знаки в буквах при поиске. 

Для работы с гео:

3️⃣ earthdistance — считает расстояние между двумя точками по координатам.

4️⃣ cube — нужен для работы earthdistance, а еще ищет похожие записи сразу по нескольким числовым параметрам.

Упростить структуры данных:

5️⃣ ltree — упорядочивает данные с уровнями вложенности: раздел, подраздел, элемент.

6️⃣ hstore — хранит пары «ключ — значение» в одном поле, даже если набор ключей отличается у разных записей.

7️⃣ intarray — ускоряет работу с массивами целых чисел: добавляет свои операции и индексы для быстрого поиска.

Увеличить производительность:

8️⃣ pg_prewarm — позволяет заранее загрузить нужные данные в кеш и снизить просадку производительности после перезапуска.

Как включить: выберите нужный кластер → «Конфигурация»  → «Расширения»  → «Изменить». Все доступные расширения описаны в документации.

В комментариях делитесь, какие еще расширения стоит добавить👇🏻

Как не провалить пилот ESB: разберем два реальных сценария на онлайн-конференции

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

На практике вопросов гораздо больше.

• Что именно включать в пилот?

• Какие сценарии действительно показательны?

• Нужно ли проверять только функциональность или еще производительность, мониторинг и удобство сопровождения?

• Стоит ли отдавать пилот интегратору или пробовать силами внутренней команды?

15 сентября в 11:00 вместе с DATAREON проведем онлайн-конференцию «Архитектурная лаборатория: как выбрать ESB под вашу ИТ-архитектуру». Разберем не только возможности платформы, но и то, как организовать пилот так, чтобы он действительно помог принять решение.

Что будет в программе

Сергей Скирдин, технический директор «Белого кода», расскажет:

• как сегодня выглядит российский рынок шин данных;

• какие критерии стоит учитывать при выборе ESB;

• в чем преимущества DATAREON Platform;

• зачем пилотировать платформу на реальном ИТ-ландшафте;

• какие задачи стоит закладывать в пилот.

Иван Макушов, аналитик Ikon Tyres, поделится опытом пилота с внешним подрядчиком:

• как в компании подходили к выбору новой интеграционной платформы;

• какие технические требования сформировали;

• какие сценарии включили в пилот;

• на что стоит обратить внимание при работе с интегратором..

Дмитрий Сидоренков, архитектор 1С «Уральской Агропромышленной Группы», расскажет про другой путь — пилот и дальнейшее внедрение внутренними силами:

• почему одного обучения недостаточно, чтобы начать реальный проект;

• какие специалисты нужны внутри команды;

• почему хотя бы один человек должен быть глубоко погружен в проект;

• где самостоятельной команде все же полезна внешняя экспертная поддержка;

• как перейти от первого работающего обмена к самостоятельному развитию интеграций.

По сути, сравним два сценария:

пилот с подрядчиком
и
пилот внутренней командой.

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

15 сентября, 11:00 по МСК

Участие бесплатное, нужна регистрация.

Регистрация

Как оптимизировать хранение строк в ClickHouse

Помню как-то спорили с дата-инженерами, стоит ли использовать LowCardinality в DDL-запросах на создание объектов или это бесполезная фича и особого профита вообще не дает. С их стороны даже исследование какое-то было проведено. Как итог, LowCardinality стали использовать, но никто так и не смог наглядно показать в чем его преимущество.

На самом деле достаточно провести несколько тестов и все становится очевидно.

Создадим две таблицы. В одной тип данных определим как String во второй LowCardinality:

-- Таблица с обычным String
CREATE TABLE test_string (
    id UInt64,
    category String
) ENGINE = MergeTree()
ORDER BY id;

-- Таблица с LowCardinality
CREATE TABLE test_low_cardinality (
    id UInt64,
    category LowCardinality(String)
) ENGINE = MergeTree()
ORDER BY id;

Загружаем в каждую по 100 млн строк:

-- Заполняем первую таблицу (это займет пару секунд)
INSERT INTO test_string
SELECT 
    number AS id, 
    concat('category_name_', toString(number % 50)) AS category
FROM numbers(100000000);

-- Заполняем вторую таблицу такими же данными
INSERT INTO test_low_cardinality
SELECT 
    number AS id, 
    concat('category_name_', toString(number % 50)) AS category
FROM numbers(100000000);

Смотрим сколько данные занимают на диске:

SELECT 
    table,
    column,
    type,
    formatReadableSize(data_uncompressed_bytes) AS uncompressed_size,
    formatReadableSize(data_compressed_bytes) AS compressed_size_on_disk
FROM system.columns
WHERE table IN ('test_string', 'test_low_cardinality') 
  AND column = 'category'
ORDER BY table;

table               |column  |type                  |uncompressed_size|compressed_size_on_disk|
--------------------+--------+----------------------+-----------------+-----------------------+
test_low_cardinality|category|LowCardinality(String)|95.68 MiB        |750.46 KiB             |
test_string         |category|String                |1.56 GiB         |9.19 MiB               |

Можно заметить невооруженным глазом, что с LowCardinality данные на диске (compressed_size_on_disk) занимают в разы меньше места чем если бы мы просто хранили их в String. При распаковке данных (uncompressed_size) при чтении LowCardinality также сильно выигрывает. В оперативку будет загружено на порядок меньше данных, следовательно и сами запросы должны будут выполняться быстрее.

Проверим это на простых запросах на агрегацию:

-- Без LowCardinality
SELECT 
    category, 
    count() AS cnt
FROM test_string
GROUP BY category;

50 rows in result, 0.10 sec.
100.0%, Read 100.00 million rows, 2.38 GB

-- С LowCardinality
SELECT 
    category, 
    count() AS cnt
FROM test_low_cardinality
GROUP BY category;

50 rows in result, 0.02 sec.
100.0%, Read 100.00 million rows, 100.00 MB 
 

Запрос с LowCardinality выполнился в 5 раз быстрее и задействовал всего 100 MB RAM против 2.38 GB.

Вот и говорите потом, что LowCardinality не дает профита.

P.S. Главное правило: используйте LowCardinality только для полей с небольшим количеством уникальных значений (статусы, категории, типы). Для уникальных ID или URL он только навредит.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

Как фильтровать результат оконных функций в ClickHouse

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

В ClickHouse можно проще.

Недавно наткнулся на фичу, которая позволяет сделать такую фильтрацию вообще без использования подзапросов или CTE. Это предложение QUALIFY.

Оно работает по аналогии с WHERE, но с одним важным отличием. WHERE отрабатывает до вычисления оконных функций, поэтому оно просто их «не видит», а QUALIFY — после.

Поэтому раньше приходилось писать так:

SELECT * 
FROM (
    SELECT 
        id, 
        category, 
        ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
    FROM my_table
) 
WHERE rn = 1;

А с использованием QUALIFY запрос становится короче:

SELECT 
    id, 
    category, 
    ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
FROM my_table
QUALIFY rn = 1;

Несколько нюансов:

• В QUALIFY можно фильтровать данные прямо по алиасу из SELECT и не дублировать весь код оконной функции.

• Оконную функцию можно написать прямо внутри QUALIFY. Выводить её в итоговый SELECT не обязательно. Фильтрация всё равно сработает «под капотом».

• Если в запросе нет ни одной оконки, QUALIFY выдаст ошибку. Для обычной фильтрации всё так же используем WHERE.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

Open-source-проект — это не просто код под открытой лицензией.

Недавняя покупка DuckLabs - создателя DuckDB, — вызвала немало обсуждений в сообществе разработчиков баз данных и не только (см., например, обсуждение на news.ycombinator.com). Вставлю и я свои пять копеек.

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

Насколько я вижу как сторонний наблюдатель, до сих пор все ключевые решения в DuckDB принимала небольшая группа core-разработчиков. Внешних контрибьюторов немало (вспомним хотя бы команду MotherDuck), но само ядро принимающих решения «разнообразным» назвать трудно. Так что это был открытый код, но не open-source-проект в моём понимании - со всеми спорами, компромиссами, голосованиями и вообще той самой динамикой открытых сообществ.

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

Поэтому, на мой взгляд, AWS сделала умный ход: наняла разработчиков, а проект оставила открытым. Возможно, там читали свежие исследования на эту тему (см., например, Vasilescu et al., 2015 и Tamburri et al.) и хотят снизить риск «Death Spiral» для этого вполне себе оригинального проекта. Моя гипотеза: они таким образом пытаются подтолкнуть других игроков рынка вкладываться в проект.

Так это или нет - станет понятно из их дальнейших шагов: как быстро люди из других компаний начнут появляться в списке core-коммиттеров и в управлении проектом. Первый ориентир - технический консультативный совет, анонсированный при DuckDB Foundation. Если это случится скоро, а независимые новички действительно расширят проект - это будет новая страница в истории open-source-модели разработки. По крайней мере, той её части, которую знаю я.

Может таким макаром и bare-metal инженерные проекты также смогут получать поддержку больших компаний при использовании открытой модели разработки? Было бы любопытно иметь в открытом доступе полное КД на новую модель автоваза (без деталей реализации корпоративного форка, конечно) или паровой турбины ТЭС - а вы что думаете?

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

Главная выгода от использования единой экосистемы redb (RedBase) вместо разрозненных библиотек — это радикальное сокращение стоимости и времени разработки (Time-to-Market).

Автор спроектировал все четыре компонента (Core, Route, Tsak, Identity) так, чтобы они идеально знали друг друга «из коробки». Для бизнеса и разработчиков это дает пять ключевых преимуществ:

1. Архитектурная гармония (Один стек — один стиль)

В классическом .NET-приложении вам приходится собирать «зоопарк» из чужеродных технологий: Entity Framework для БД, MassTransit для очередей, Keycloak для авторизации и Hangfire для задач. Каждый инструмент имеет своего автора, свои правила.

• Выгода: В redb вся экосистема написана в едином стиле на чистом C#. Вы один раз понимаете логику работы фреймворка, и вам больше не нужно переучиваться при переходе от работы с базой данных к настройке безопасности или очередей сообщений.

2. Избавление от «инфраструктурного ада»

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

• Выгода: С RedBase вы забываете про SQL-миграции. База данных сама адаптируется под ваши C#-классы при старте. А благодаря встроенному серверу авторизации redb.Identity и движку redb.Route, вам не нужно разворачивать тяжелые внешние сервисы вроде Keycloak или Apache Camel — всё работает внутри единого .NET-процесса.

3. Колоссальная экономия времени на старте ( я бы выделил это отдельно)

Вместо того чтобы тратить первые недели (или даже месяцы) проекта на настройку авторизации, логирования, интеграционных шин и доступов к СУБД, разработчик использует готовые шаблоны dotnet new redb.

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

4. Экстремальная производительность (In-Memory мосты)

Когда ваши микросервисы общаются между собой, они обычно гоняют трафик по сети через HTTP или gRPC, что тратит ресурсы процессора и создает задержки (latency).

• Выгода: Компоненты экосистемы redb общаются друг с другом в памяти одного процесса через специальный direct-vm - мост (redb.Route.Core). Например, проверка прав пользователя в Identity или передача сообщения в шину Route происходит мгновенно, без сетевых задержек.

5. Снижение стоимости владения и поддержки (Zero-Key Pro)

Многие современные фреймворки завлекают бесплатной базовой версией, но требуют огромных денег за коммерческие «Pro»-функции (кэширование, массовые операции, аудит).

6. DevOps-рантайм готовый к эксплуатации (redb.Tsak): Этот компонент полностью закрывает вопросы девелопмента и поддержки в проде. Он предоставляет готовый кластерный контейнер для Kubernetes с нативными пробами, сбором метрик (OpenTelemetry/Prometheus) и встроенным веб-дашбордом. Самая крутая фича для админов — Hot-Reload модулей без перезапуска процесса, что позволяет обновлять бизнес-логику на лету, не теряя сообщения «в полете» и давая возможность дежурному вручную «переигрывать» упавшие транзакции прямо из панели управления. Как микросервисом так и монолитом, или можно собрать свою версию.

• Выгода: Все Enterprise-пакеты экосистемы RedBase с приставкой .Pro являются абсолютно бесплатными. Вы получаете оптимизированные bulk-операции, продвинутый трекинг изменений и кэш без покупки лицензионных ключей.

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

Если было полезно, ⭐ на GitHub поможет другим это найти.

Другие мои статьи — redb.ru/articles, ещё — на Хабре.

Подборка вебинаров на сентябрь

В сентябре покажем, как за пять дней построить Data Lakehouse, защитить данные при работе с LLM, выстроить безопасную ИИ-инфраструктуру и обеспечить отказоустойчивость PostgreSQL для продакшен-нагрузок. Выбирайте интересную тему и регистрируйтесь. 

Как построить управляемый Data Lakehouse за неделю на Evolution Data Platform
Покажем, как за несколько дней с нуля построить архитектуру Data Lakehouse на Evolution Data Platform — от загрузки сырых данных до курированных витрин. Разберем принципы работы с Apache Iceberg, централизованное управление метаданными, контроль качества данных, единый SQL-слой и оркестрацию пайплайнов. Все увидите на демо.
🧑‍💻 Для кого: архитекторы данных, дата-инженеры, руководители аналитики и data-направлений, ИТ-директора, специалисты по управлению данными.
📅 Когда: 8 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Как защитить чувствительные данные при работе с LLM с помощью Guardrails
Разберем, как работают Guardrails LLM и Guardrails Filter: чем они отличаются, какие данные помогают обнаруживать и как адаптировать правила проверки под задачи компании. Отдельно рассмотрим, как защитный слой Guardrails работает в контуре Evolution Foundation Models, а также какую роль в проверке запросов играют модели-классификаторы HiveTrace. На демо покажем работу open source версии Guardrails Filter.
🧑‍💻 Для кого: специалисты по защите данных и ИБ, команды разработки ИИ-приложений и тем, кто внедряет LLM в бизнес-процессы.
📅 Когда: 15 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ИИ в облаке: кто отвечает за безопасность
Безопасность ИИ в облаке — это общая ответственность провайдера и бизнеса. Разберем, где проходят границы этой ответственности и как выстроить безопасную ИИ-инфраструктуру без лишних рисков. Обсудим подход Zero Trust: расскажем, как контролировать доступ к данным, моделям и сервисам в Cloud.ru Evolution и какую роль в этом играет Evolution Managed Identities (IAM).
🧑‍💻 Для кого: руководители и специалисты по ИБ (CISO), архитекторы и инженеры, проектирующие ИИ-инфраструктуру, специалисты, работающие с чувствительными данными, руководители, отвечающие за внедрение ИИ в компании.
📅 Когда: 17 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

PostgreSQL для продакшен-нагрузок: Multi-AZ, реплики и переключение ролей
От доступности PostgreSQL зависит стабильная работа backend-сервисов и пользовательских сценариев. Разберем, как обеспечить высокую доступность PostgreSQL в облаке. Покажем, как в Evolution Managed PostgreSQL устроена архитектура Multi-AZ, какую роль играют реплики базы данных и как работают ручное и автоматическое переключение при плановых работах и сбоях.
🧑‍💻 Для кого: DevOps-инженеры, SRE-инженеры, инфраструктурные инженеры и все технические специалисты, работающие с PostgreSQL.
📅 Когда: 29 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Юлий Гольдберг (GlowByte): Lakehouse — уже не экспериментальное направление

В интервью на РБК руководитель направления GlowByte Юлий Гольдберг рассказал о том, как меняется рынок СУБД в России, почему Lakehouse перестал быть экспериментом и какие барьеры остаются у отечественных вендоров.

Ключевое из интервью:

Рынок СУБД: от срочного импортозамещения к зрелости. Заказчики всё реже ищут просто «российскую альтернативу» — они выбирают платформу под архитектуру данных, аналитику и ИИ-сценарии. При этом многие крупные компании не торопятся отказываться от Oracle и MS SQL: лицензии постоянные, системы «вылизаны», а миграция — дорогой и долгий проект.

Главный тренд — переход к Lakehouse. Вместо монолитных СУБД (Oracle, Teradata) — разделение хранения (S3+Parquet/Iceberg) и систем обработки (Spark, Trino, Impala). Подход доказал состоятельность: GlowByte совместно с Data Sapience за три года реализовали более 15 проектов, крупнейшие — на несколько петабайт данных.

Архитектура усложняется, но становится гибче. СУБД в новой парадигме — это набор взаимодополняющих компонентов. Можно собрать ровно то, что нужно, и не платить за лишнее. Но нагрузка на архитекторов и DevOps‑инженеров растет в разы.

Главный барьер — размер рынка. Российский рынок СУБД небольшой по сравнению с мировым, экспорт технологий затруднен. Инвестиции в продукты несопоставимы с зарубежными. Почти все российские СУБД, кроме ClickHouse и Tarantool, базируются на open source, а риски смены лицензий (как в случае с Greenplum) сохраняются.

ИИ меняет требования к СУБД. LLM и AI-агенты работают с неструктурированными данными — текстами, картинками. Традиционные СУБД заточены под структурированную информацию, а Lakehouse с S3-хранилищем и набором движков обработки закрывает этот пробел.

Критерии выбора СУБД на 2027 год: стоимость владения, горизонтальное масштабирование для крупных компаний, managed‑сервисы для небольших игроков.

Российский рынок СУБД на сегодня — это рынок различных клонов Postgres. Как ни смотри, хоть в штуках, хоть в деньгах. И вряд ли что-то здесь изменится в ближайшем будущем, тем более что Postgres тоже не стоит на месте и развивается туда, куда ждут потребители, — в область поддержки ИИ (pgvector, например) или в сторону параллелизма вычислений. Если кто-то и бросает вызов, то в конкретных нишах — как, например, Lakehouse в аналитических задачах на больших объемах данных, — говорит Юлий Гольдберг, GlowByte.

Читать интервью эксперта GlowByte в РБК

JDBC, Hibernate, Spring Data, MyBatis, jOOQ — почему в Java столько способов работать с базами данных?

Разбираемся на бесплатном вебинаре «Java Persistence: обзор фреймворков для доступа к данным». В прямом эфире пройдём от низкоуровневых инструментов до высокоуровневых абстракций.

Программа:

☕ JDBC и Spring JDBC — основы работы с БД без абстракций.
☕ JPA и Hibernate — что такое ORM, persistence context и как это работает внутри.
☕ Spring Data JPA vs Spring Data JDBC — различия репозиториев и критерии выбора.
☕ MyBatis и jOOQ — почему выбирают SQL-центричные фреймворки ради полного контроля.
☕ Альтернативные реализации JPA — что кроме Hibernate.
☕ Reactive Data Access — когда нужен R2DBC, а когда достаточно JDBC.
☕ Как выбрать фреймворк — сценарии, компромиссы и рекомендации. 

📆 Когда: 31 августа в 16:00 (Мск)

🙍‍♂ Спикер: Александр Краснянский, эксперт в Java/Kotlin и архитектуре ПО

✍ Записаться

Что подтянуть бэкендеру для продакшена: 12 практических открытых уроков

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

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

Очереди и надёжная доставка

• 26 августа, 20:00. «Работа с Kafka через библиотеку Kafka Clients». Записаться

• 17 сентября, 20:00. «RabbitMQ в Production: Transactional Outbox, идемпотентность и DLQ в ASP.NET Core». Записаться

Базы данных и конкурентный доступ

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 8 сентября, 20:00. «Борьба с блокировками в PostgreSQL: как достичь высокой параллельности при большой нагрузке». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Нагрузка и производительность

• 3 сентября, 20:00. «ASP.NET Core API под нагрузкой: как сделать сервис устойчивым к сбоям и росту трафика». Записаться

• 9 сентября, 20:00. «Go‑профилирование: как найти и исправить „тормоза“ в продакшене». Записаться

• 22 сентября, 20:00. «Горутины и каналы: под капотом (under the hood) и нюансы в продакшене». Записаться

HTTP и серверная разработка

• 21 сентября, 20:00. «HTTP‑сервер на чистой Java за 30 минут». Записаться

• 20 октября, 19:00. «Балансировка HTTP и L4 сервисов в Angie». Записаться

Продакшен и наблюдаемость

• 23 сентября, 20:00. «eBPF: рентгеновское зрение для production». Записаться

• 23 сентября, 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться

ЧТО ПОЧИТАТЬ БЭКЕНД‑РАЗРАБОТЧИКУ

Если удобнее разбираться в теме в своём темпе, собрали несколько практических материалов: про серверы, обновление стека, обработку ошибок и тонкости C++.

• «Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт»

• «Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод»

• «std::expected в C++23: гайд по миграции с исключений на функциональный error handling»

• «Move‑семантика в C++: пять задач, в которых легко ошибиться»

PostgreSQL WAL, fsync и p99 на NVMe: что ограничивает запись

Чтобы оценить PostgreSQL WAL, fsync и p99 на NVMe, смотреть нужно на время commit. На p99 влияют файловая система, метод синхронизации, защищённость кэша, RAID или виртуализация и профиль транзакций.

Какая операция WAL сильнее всего влияет на задержку commit?

При synchronous_commit=on задержку commit обычно определяет flush WAL на диск: PostgreSQL отвечает после локальной синхронизации. При синхронной репликации добавляется ожидание ответа standby, а блокировки, высокая загрузка CPU или сеть могут сильнее повлиять на результат и скрыть задержку накопителя.

От записи WAL до подтверждения клиенту

Задержка записи WAL PostgreSQL включает путь от WAL-буферов до диска: XLogFlush сбрасывает WAL до нужного LSN через ядро, файловую систему и контроллер. Изменённые страницы пишутся отдельно, поэтому связь с checkpoint проверяют по времени.

Какие гарантии должны оставаться одинаковыми в каждом тесте

Зафиксируйте synchronous_commit, fsync, full_page_writes, способ синхронизации, параметры монтирования и режим кэша. При fsync=off сбой повредит кластер. Сравнивайте p99 fsync на NVMe без смены гарантий.

Очереди, прошивка, температура и заполнение накопителя

Снимите nvme id-ctrl /dev/nvme0, nvme smart-log /dev/nvme0 и укажите тип подключения. Отчёт от 27 мая 2025 года: бенчмарк pg_test_fsync для PostgreSQL 16 показал 1643 мкс на fdatasync для Samsung 990 Pro с XFS и 24 мкс для Micron 7400 с PLP в другом стеке. Разница здесь между классами накопителей, а не между конкретными моделями.

Почему пиковые IOPS NVMe не предсказывают p99 fsync?

Пиковые IOPS достигаются при глубокой очереди, а синхронный WAL часто ждёт одиночный flush. Средняя пропускная способность скрывает редкие паузы кэша, прошивки или сборки мусора. При этом паспортный показатель помогает при первичном отборе, но не заменяет длительное измерение задержки fsync на том же стеке, где будет лежать pg_wal.

pg_test_fsync и fio при шаблоне, похожем на WAL

В той же файловой системе, что и pg_wal, запустите

pg_test_fsync -f /test/pgfs -s 30

затем fio на отдельном файле:

fio --name=wal --filename=/test/wal.fio --size=2G --rw=write --bs=8k --iodepth=1 --fdatasync=1 --runtime=300 --time_based --output-format=json+

Если при одинаковой нагрузке вместе растут задержка synchronous_commit и fio sync latency, проверяйте накопитель.

Как fsync проявляется в pgbench под управляемой нагрузкой

Создайте базу

pgbench -i -s 100 benc

и выполните по три 10-минутных прогона при N=1, 8 и 32:

pgbench -M prepared -c N -T 600 -l bench

По журналам рассчитайте p50, p95 и p99. Их рост вместе с задержкой fsync и очередью указывает на узкое место хранилища WAL.

Queue depth, await и редкие провалы NVMe

Параллельно снимайте iostat -x 1 и nvme smart-log. Рост await и aqu-sz вместе с пиками commit latency указывает на очередь. Но похожую картину даёт checkpoint, поэтому сопоставляйте метрики по времени и фиксируйте wal_sync_method.

Как правильно интерпретировать pg_test_fsync?

1. Сравнивайте методы на файловой системе будущего pg_wal.

2. Читайте полный вывод вместе с условиями теста.

3. Сверяйте результаты с pgbench и мониторингом: микротест не предсказывает p99 commit.

Что меняет профиль записи, а что меняет гарантию

При групповом commit один flush обслуживает несколько транзакций, поэтому throughput и queue depth меняются с конкуренцией. wal_sync_method выбирают по результатам теста. synchronous_commit=off грозит потерей подтверждённых транзакций: это другая гарантия сохранности, а не настройка производительности.

Как перевести измерения в требование к хранилищу

Например, SLO допускает до 1% транзакций дольше 10 мс и до 30 секунд непрерывного нарушения. Тест проводят при рабочем заполнении. После смены прошивки, файловой системы или хоста снова проверяют tail latency.

Хранилище выбирают по p99 commit при тех же гарантиях сохранности. PostgreSQL WAL, fsync и p99 на NVMe сопоставляют по времени: pg_test_fsync измеряет flush, pgbench его эффект, а iostat – состояние очереди.

Программа Tantor JAM 2026

10 сентября (чт) в Москве особое мероприятие для всех, кто интересуется передовыми решениями в области СУБД: компании «Тантор Лабс» исполняется пять лет. Мы приглашаем разработчиков СУБД, инженеров, архитекторов, администраторов, представителей заказчиков и партнеров, чтобы обсудить, куда движется российская инфраструктура данных и какие технологии уже сейчас меняют привычный подход к работе с Postgres-инфраструктурой.

Программа и регистрация

• Вадим Яценко, генеральный директор «Тантор Лабс». 5 лет «Тантор Лабс». Российским СУБД пора играть по-крупному

• Алексей Барган, руководитель отдела разработки Платформы Tantor
  AI-first подход в управлении и администрировании СУБД. Как меняется профессия DBA?

• Семен Курепин, пресейл-инженер
  Платформа Tantor 7.0: Интеграция предиктивной аналитики в контур эксплуатации СУБД

• Екатерина Мартьянова, директор по продукту Tantor XData; Михаил Сёмкин, team lead СУБД Tantor Polar
  Машина баз данных Tantor XData Gen3: постгресовый дрифт в сторону enterprise

• Максим Милютин, руководитель группы исследований и разработки
  Нативная (без ETL) аналитика на оригинальных данных. PX-движок для Tantor Polar

• Александр Симонов, технический руководитель направления развития 1С
  Postgres для 1С: от «работает» к «быстро» — за два года

• Сергей Соловьев, разработчик СУБД Tantor Postgres
  Новая эпоха TDE

• Андрей Погудин, инженер
  Защита данных в Tantor Postgres

Программа и регистрация

«Это написал Клод» — комментарий из-за рубежа, и почему идее хранилища больше двадцати лет (даже если так было бы, то клод выпивая тонные кофе это всё родил ...)

Под англоязычной версией статьи про SQLite-провайдер на dev.to появился комментарий в духе «даже без "load-bearing" и тире через всё предложение видно, что это писал Клод». Не первый раз слышу что-то подобное, так что решил ответить не в комментариях, а отдельным постом заодно расскажу то, что давно собирался: откуда вообще взялась идея хранилища, на котором всё это стоит.

Сначала честно про долю ИИ

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

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

А теперь откуда это всё вообще взялось

Основная идея хранилища не изобретение последних месяцев. Первая версия появилась в 2004 году, когда я писал на Delphi за двадцать с лишним лет до того, как Клод вообще начал существовать.

Задача была дать объекту динамические поля на ходу, не фиксируя их жёстким классом заранее. Delphi для этого уже нёс нужный кусок RTTI (Run-Time Type Information): каждый класс несёт метаданные о своих полях и свойствах, доступные в рантайме, не только на этапе компиляции. Поверх этого интерфейс IDispatch из COM: GetIDsOfNames резолвит имя поля в DISPID, Invoke вызывает по этому DISPID, передавая значение через VARIANT. Вместе это давало то, чего не даёт обычный жёсткий класс: объект мог обзавестись полем, которого не существовало на момент компиляции, а вызывающая сторона спросить о нём по имени и получить настоящий типизированный ответ.

Система прожила у меня внутри собственных проектов много лет, никуда не публикуясь. За это время она полностью пережила Delphi и COM переехала на .NET, механизм сменился до неузнаваемости (никакого VARIANT, никакого DISPID сейчас это типизированные колонки в Postgres/MSSQL/SQLite, которые я уже разбирал построчно в статье про 13 таблиц), а вопрос остался ровно тем же: как дать объекту гибкий набор полей, не потеряв возможность спросить "а какого оно вообще типа".

Отсюда, кстати, и название RTTI-based storage, не маркетинговый термин, а прямое родство с тем самым механизмом Delphi. И не EAV там никогда не было обезличенной колонки "значение", RTTI всегда знало настоящий тип.

Клод помогал полировать это перед тем, как это увидело свет публично. Сама идея и её первое воплощение старше Клода на десятилетия.

Цикл про redb:

• redb — типизированное хранилище для .NET поверх Postgres/MSSQL: без миграций, без Include, с полным LINQ

• REDB изнутри, статья 1: 13 таблиц, на которых работает всё

• Анатомия SQLite-провайдера: уходим от EF Core — статья, под которой появился тот самый комментарий

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

Пассажир меняет билет прямо в дороге — а маршрут собран из трёх GDS и ж/д. Что происходит с данными

Сотруднику нужно долететь до одного города, доехать поездом до другого, и обратно тем же путём — одна командировка, билеты из разных систем бронирования. А потом он уже в дороге пишет в телеграм: "планы изменились, летим не туда, перебронируй".

Три системы под самолёты — Amadeus, Sabre, Travelport: исторически несовместимые XML-диалекты одного и того же понятия перелёта, выросшие из мейнфреймов 60-80-х, каждый со своими причудами и полями, которых нет у соседа. Плюс отдельная, никак не связанная с ними система бронирования под железную дорогу — свой формат, своя логика мест и классов, ничего общего по структуре с авиационными GDS. Запросить всё это параллельно, свести разноформатные ответы в одно и собрать из них валидный маршрут по стыковкам — уже само по себе задача не для россыпи if и ручных мапперов.

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

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

Первая — как описать саму логику поверх этого зоопарка источников. И сбор из четырёх систем разом, и ветка "можно менять / нельзя менять" превращаются либо в DSL на языке общепринятых интеграционных паттернов (Scatter-Gather, Content-Based Router — тот же словарь, что у Apache Camel), который прочитает и поймёт человек, ни разу его не писавший, — либо в код, который через полгода не восстановит и автор.

Вторая — куда положить результат. Маршрут — не два поля outbound/return, а последовательность разнотипных плеч (самолёт ≠ поезд), где число элементов и состав не известны заранее и меняются посреди собственной жизни объекта. Стандартный ответ — либо гора nullable-колонок под все виды транспорта разом, либо миграция на каждый новый вид.

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

Скоро.

ссылки: хабр redb.ru