Базы данных *

Как не провалить пилот 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

Приглашаем на вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»

10 августа в 13:00 (мск) компания «Диасофт» проведет практический вебинар о новых возможностях Digital Q.DataBase «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase».

Ключевые темы:

• Полиглотная архитектура Digital Q.DataBase. Как в единой среде работать с базами PostgreSQL, Microsoft SQL Server и Oracle

• Симбиоз СУБД и AI. Поддержка векторных операций и интеграция с большими языковыми моделями (LLM) под капотом СУБД

• Высокая скорость работы с данными. Архитектура и новые возможности встроенного KV-хранилища DGrid для сверхбыстрого доступа к информации

• Развитие RuDB. Обзор новой функциональности и обновленных пакетов платформы

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

Как реализовать семантический поиск для RAG-архитектуры в PostgreSQL без усложнения инфраструктуры?

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

Да, семантический поиск в RAG-сценариях можно реализовать прямо в PostgreSQL без выделенной векторной базы данных (ClickHouse, Opensearch, Qdrant, Milvus и т. д). 

Для этого используется PostgreSQL + расширение pgvector, которое добавляет поддержку хранения эмбеддингов (векторов) и поиск по расстоянию до ближайших соседей (KNN) прямо внутри SQL-движка. Разберем, как это работает на практике.

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

Для этой задачи будем использовать pgvector — это расширение к PostgreSQL, которое добавляет тип данных vector и операторы поиска по расстоянию до ближайших соседей (KNN).

Поддерживаются три основные метрики сравнения векторов:

• L2 (евклидово расстояние) — классическое расстояние между двумя точками в многомерном пространстве. Хорошо работает, если векторы не нормализованы и распределение значений относительно равномерное.

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

• Inner product (внутреннее произведение) — скалярное произведение двух векторов. Может использоваться как прокси для оценки «сходства» при обучении моделей и в задачах ранжирования.

Допустим, мы получаем на наш запрос именно такой вектор от модели OpenAI. Для хранения создаем таблицу с типом VECTOR:

CREATE TABLE items (
 id SERIAL PRIMARY KEY,
 title TEXT,
 embedding VECTOR(1536)
);

Добавим данные для нескольких векторов разных объектов:

INSERT INTO items (title, embedding) VALUES
 ('PostgreSQL embeddings', '[0.10, -0.80, 0.45]'),
 ('Neural image processing', '[0.42, 0.18, -0.35]'),
 ('Sound pattern matching', '[-0.20, 0.70, 0.60]'),
 ('Document clustering', '[0.09, -0.79, 0.48]');

Теперь сравним их попарно и отсортируем по расстоянию:

SELECT
  a.title AS title_a,
  b.title AS title_b,
  a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;

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

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

А если вы не хотите самостоятельно заниматься настройкой индексов, тюнингом памяти и производительности, а также обновлением версии PostgreSQL, то воспользуйтесь DBaaS от Selectel. Мы предоставим вам кластер PostgreSQL с преднастроенными расширениями, готовый к эксплуатации под нагрузкой. Это позволит сосредоточиться на RAG-логике и качестве поиска, а не на инфраструктурной оптимизации.

Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?

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

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

Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.

Откройте конфигурационный файл клиентской аутентификации:

nano /etc/postgresql/17/main/pg_hba.conf

Обратите внимание, что тут рассматривается настройка репликации на примере PostgreSQL 17.

Найти точное расположение файла можно в командной строке PostgreSQL с помощью команды SHOW:

sudo -u postgres psql -c "SHOW hba_file;"

Добавьте в pg_hba.conf следующую строку, указав вместо REPLICA_ВНУТРЕННИЙ_IP сетевой адрес вашего ведомого сервера:

host    replication    replicator    REPLICA_ВНУТРЕННИЙ_IP/32    scram-sha-256

Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:

ALTER ROLE replicator WITH REPLICATION;

Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.

Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:

systemctl reload postgresql

В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.

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

На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.

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

Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.

Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.

Где бэкенд начинает тормозить: 18 открытых уроков по языкам, данным и архитектуре

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

В августе и сентябре преподаватели OTUS проведут бесплатные уроки для бэкенд‑разработчиков. В программе — Python, Go, C# и JVM, микросервисная архитектура, PostgreSQL, брокеры сообщений, наблюдаемость и контейнеризация. Выбирайте свою тему и присоединяйтесь к практическим разборам.

Архитектура и взаимодействие сервисов

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 19 августа, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

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

Языки, память и конкурентность

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python. Асинхронность, процессы, потоки». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 18 августа, 20:00. «Python asyncio: gather, wait, TaskGroup на практике». Записаться

• 18 августа, 20:00. «Горутины и каналы: базовые принципы параллелизма в Go». Записаться

• 18 августа, 20:00. «Архитектурные ошибки, которые совершают даже опытные C#-разработчики». Записаться

Базы данных и работа с состоянием

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

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

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

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

Наблюдаемость и контейнеризация

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 20 августа, 20:00. «Docker для Python-разработчика». Записаться

Что почитать перед практикой

1. Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт
   _{Путь от чтения RFC и реализации обработчика запросов до запуска сервера в контейнере. Внутри — защита исполняемого файла, ограничения для HTTP/2, работа с облачными площадками и поиск утечки памяти в OpenSSL.}

2. std::expected в C++23: гайд по миграции с исключений на функциональный error handling
   _{Как сделать ошибку явной частью сигнатуры функции, выстраивать цепочки операций и постепенно внедрять std::expected в существующий проект.}

3. Move-семантика в C++: пять задач, в которых легко ошибиться
   _{Разбор ловушек, которые успешно компилируются, но приводят к лишним копированиям, замедлению программы или неопределённому поведению.}

4. Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод
   _{План обновления рабочего сервиса с промежуточными этапами, автоматизированными проверками, канареечным развёртыванием и заранее подготовленным сценарием отката.}

JSON или XML: сравнение популярных форматов обмена данными

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

В статье разобрали оба формата на одинаковых примерах, прошлись по истории и причинам, по которым JSON вытеснил XML в вебе. Сравнили по ключевым параметрам: синтаксис, объем, скорость обработки, поддержка типов данных, комментарии, пространства имен, валидация через JSON Schema и XSD. И отдельно написали про области применения.

Подробности — в блоге Рег.облака.

Программирование с явно выделенным состоянием

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

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

Сейчас, в эру агентного программирования, это стало еще важнее. Агент может догадаться до правила, но ему нужно на это время и отдельный анализ. Можно конечно написать об этом в правилах, но зачем, когда можно просто поправить модель данных? Все что требуется, это введение текстового поля со статусом, которое явным образом скажет о происходящем с этой записью.

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

Приглашаем на пятилетие «Тантор Лабс». 10 сентября - Tantor JAM 2026

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

Программу скоро представим. Среди главных премьер:

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

• Результаты испытаний МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе.

• Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.

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

10 сентября 2026 года, Москва

Регистрация уже открыта.

Участие бесплатное (требуется подтверждение от организатора).