Зачем нужны ACK/NACK в распределенных системах?

Стали постоянно попадаться аббревиатуры ACK/NACK, решил кратко написать, что это. Это элементарно “статус обработки”:
🤩ACK = Acknowledgement (подтверждение успешной обработки)
🤩NACK = Negative Acknowledgement (отрицательное подтверждение, “не шмогла”)

Это механизмы подтверждения доставки сообщений между компонентами в системе. Они нужны, чтобы обеспечить надежность доставки сообщений. Вообще мне всегда казалось, что статусов NACK должно быть как минимум два: “временно не шмогла”, и “не шмогла и не шмогу” (что-то неверно, уже удален какой-то связанный id) - но в целом это всё NACK.

Встречается повсеместно, особенно в разнообразных message queues: RabbitMQ, Kafka, NATS и других. Логика тоже тривиальна. Отправитель передает сообщение. Получатель успешно получил и обработал сообщение и отправляет ACK — «Обработано, всё ОК». Отправитель может удалить сообщение из очереди, снять его с контроля, не делать retry. Типа, consumer в Kafka читает партицию, обрабатывает сообщение, и commit-ит offset (это аналог ACK).

А если получатель не смог обработать сообщение (ошибка, таймаут, сбой), отправляется NACK — «Не смог принять». И уже отправитель решает, что делать: переотправить сообщение (retry), положить в dead letter queue (DLQ), логировать алерт.

В распределенных системах:
🤩 Сообщения теряются
🤩 Узлы валятся
🤩 Перемещение сообщений — небезопасно
🤩 Далеко не все сообщения обрабатываются успешно

Использование или неиспользование ACK/NACK определяют гарантии доставки:
🤩 At most once delivery (нет подтверждений, сообщения теряются при сбое)
🤩 At least once delivery (повторная доставка до получения ACK)
🤩 Exactly once delivery (более сложный протокол с учетом ACK и с поддержкой идемпотентности на принимаемой стороне)

Если интересушься этими темами – обрати внимание на старт курса Владимира Перепелицы по Кафке и NATS👇

——
Учись, пока AI тебя не заменил:
Интенсив по очередям: Kafka и NATS (3 июля),
Docker и Kubernetes: основы разработки под облачную инфраструктуру (18 июня),
Системный дизайн (14 июля)

Гео-распределенность и консистентность

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

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

Катастрофоусточивость = строгая консистентность, синхронное обновление. Из определений выше видно, что попытка организовать катастрофоусточивость между разными регионами может привести к очень большим задержкам (грубо 100 ms на любой транс-атлантический запрос, например -- в сто раз больше задержек между зонами).

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

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

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

Современные cloud-native СУБД, такие как Cockroach, Yugabyte, YDB, Scylla - из коробки умеют задавать конфигурации и на уровне региона, и на уровне датацентра. Классические СуБД типа PostgreSQL или MySQL в бесплатных версиях не умеют вообще ничего. Конечно всё или почти всё можно настроить вручную, но вот положа руку на сердце, разрыв в удобстве, особенно если делаешь это в первый раз – колоссальный.

Добавляйте если что забыл.

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

——
Учись, пока AI тебя не заменил:
Интенсив по очередям: Kafka и NATS (3 июля),
Системный дизайн (14 июля)

Раз в месяц постим анонсы по обучению на месяц. Чтобы вы или ваши команды могли всё спланировать. Кстати, для физиков: если приводите друга, есть скидка 20% обоим.

Итак, ближайшие запуски Devhands, включая новый интенсив 🔥 Performance review в инженерных командах

🤩 3-го июля: Интенсив по очередям:
Kafka и NATS (Владимир Перепелица)

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

🤩 14-го июля: Системный дизайн
высоконагруженных проектов (Алексей Рыбак)

Прокачайте теорию и навыки проектирования больших проектов, распределенных много-серверных систем. Любые проекты, рабочие или хобби. От социальных сетей и электронной коммерции до CDN и рассылок. 10-100M DAU (daily active users).

🤩 17-го июля: PostgreSQL 17
архитектура и тюнинг SQL-запросов (Николай Ихалайнен)

Курс, сочетающий фундаментальную теорию и практику, архитектура СУБД вообще и PostgreSQL в частности, типы и особенности индексов, MVCC, ваккума, типы SQL и практический алгоритм использования EXPLAIN для оптимизации запросов.

🤩 31-го июля:🔥Performance review в инженерных командах: интенсив (Соня Рыбак)

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

Приходите сами, приводите друзей!

Всем привет!

Сделали с Владимиром Перепелицей серию мини-интервью про инсайты архитектуры очередей. В этом посте - про Share Groups в Kafka 4.0 и почему это измение такое важное.

Q: Владимир, в 4-й Кафке завезли более «классические» очереди. А чем топики с партициями не очередь? В чём отличие «классической» очереди от топика с партициями?

Топик в кафке по своей природе — это распределённый лог, а не очередь.

Основные отличия:

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

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

🤩 Гранулярность «ack». В Кафке стандартный способ подтверждения обработки — это коммит смещения (оффсета). Коммит подтверждает разом все сообщения до этого оффсета. Подтверждать обработку индивидуальных сообщений нельзя. В очередях обычно подтверждение происходит индивидуально по сообщению, позволяя точно контролировать повторную доставку.

Q: Что поменялось с введением Kafka Queues, как они работают?

С выходом Kafka 4.0 по KIP-932 появились Share Groups (разделяемые группы) — псевдо-очереди поверх топиков. Под капотом всё остаётся так же, но изменяется модель потребления:

🤩 Share Groups подразумевают кооперативное потребление без жёсткого назначения партиций. Несколько потребителей в одной группе могут одновременно читать из одной и той же партиции, кооперируясь между собой по блокам сообщений.

🤩 Индивидуальный ack. Сообщения повторно доставляются потребителям до тех пор, пока не будет подтверждена их обработка.

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

Q: Как масштабируются эти очереди?

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

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

Спасибо Владимиру за разъяснения!

Если вам интересны вопросы архитектуры очередей, их свойства, гарантии, паттерны, кластеризация и практика пограничных кейсов, и конечно намеренный вывод из строя части кластера и анализ реакции систем на аварии - приходите на курс Владимира Интенсив по очередям: Kafka и NATS, старт уже 3-го июля. А также смотрите наш супер-стрим с В. Перепелицей Devhands Open Sessions // Queues 2025, что выбрать: Kafka, RabbitMQ, NATS или что-то ещё? https://www.youtube.com/watch?v=2vSj-HHu-wo

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

Q: Три наиболее популярных решения в мире очередей - это Kafka, Rabbit и NATS. В чём фундаментальные отличия между ними? Кого кем можно заменять и в каких случаях?

Окей, ну давай сначала кратко, кто есть кто:

Kаfka
🤩 Реплицированный шардированный лог сообщений.
🤩 Бесконечное горизонтальное масштабирование с помощью партиций.
🤩 Минимальный набор примитивов (pub/sub log).
🤩 Кластера в пределах одного «близкого» дата-центра или облачной зоны.

Rabbit
🤩 Классическая "очередь".
🤩 Традиционный брокер с протоколом AMQP.
🤩 Богатой функциональностью «из коробки».
🤩 Не масштабируется горизонтально.

NATS
🤩 Мультипарадигменная распределённая доставка сообщений (pub/sub, request/reply, key/value, streams).
🤩 JetStream: надёжный механизм потоковой обработки.
🤩 Кластеризация от одного узла до глобальных суперкластеров с гео-маршрутизацией.
🤩 Легковесный и современный.

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

Теперь посмотрим на детали, начнем с активно набирающего популярность NATS (детали посвященные Kafka и RabbitMQ в следующем посте - прим АР)

NATS vs (Kafka | Rabbit)

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

🤩 Getting Started, Удобство локальной разработки. Запуск в docker. Rabbit сложнее запустить, Kafka требует большего количества компонент и настроек.

🤩 End-to-end latency. NATS доставляет сообщение с sub-millisecond latency за счёт использования golang и in-memory подходов. Rabbit обычно немного отстаёт, у кафки латенси может быть выше на порядок.

🤩 Поиск и фильтрация сообщений на сервере. NATS JetStream создавался с оглядкой на вещи, которых не хватало в Kafka Streams и с учётом недостатков AMQP по поиску сообщений в брокере.

🤩 Простота администрирования. Использование golang подходов делает NATS намного более простым в диагностике и настройке в промышленной эксплуатации. Rabbit c его erlang на порядки сложнее при проблемах. Kafka использует экосистему Java и в целом занимает среднюю позицию за счёт широкого распространения.

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

Спасибо Владимиру за разъяснения, в следующей части - подробности про Kafka и RabbitMQ и общие выводы!

Если вам интересны вопросы архитектуры очередей, их свойства, гарантии, паттерны, кластеризация и практика пограничных кейсов, и конечно намеренный вывод из строя части кластера и анализ реакции систем на аварии - приходите на курс Владимира Интенсив по очередям: Kafka и NATS, старт уже 3-го июля. А также смотрите наш супер-стрим с В. Перепелицей Devhands Open Sessions // Queues 2025, что выбрать: Kafka, RabbitMQ, NATS или что-то ещё? https://www.youtube.com/watch?v=2vSj-HHu-wo

Заключительные комментарии Владимира Перепелицы - в серии постов про Kafka/NATS/RabbitMQ. Предыдущие посты: (1) share groups в Kafka и (3) сравнение с подробностями про NATS.

Теперь сравнение с подробностями про Kafka и Rabbit, и выводы.

Kafka vs (NATS | Rabbit)

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

🤩 Горизонтальное масштабирование, Пропускная способность, Репликация и отказоустойчивость. Эти свойства были основными целями, которые стояли перед создателями Kafka на стадии дизайна, поэтому не удивительно, что Kafka бьёт всех по этим показателям. Весьма удачная архитектура партиционированного реплицированного лога с кворумом позволяет хорошо одновременно сочетать данные критерии.

🤩 Stream processing. Потоковая обработка данных в этом формате получила максимальное распространение именно благодаря Kafka. В NATS данная функциональность была добавлена в виде JetStream, Rabbit добавил потоковую обработку как отдельную функцию, но её возможности не дотягивают до возможностей Kafka.

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

🤩 Зрелость проекта. Доки и обучение. Сообщество и поддержка. Экосистема и интеграции. С момента своего появления на IT-ландшафте Kafka быстро заняла нишу обработки данных и впоследствии расширила эту нишу до значительного сектора. Как результат — рост сообщества и появление большого количества материалов. За несколько лет Kafka стала фактически стандартом де-факто для сценария потоковой передачи данных, что спровоцировало интеграцию с большим количеством существующих инструментов и появление новых. RabbitMQ является достаточно старым и стандартным инструментом. Он накопил сообщество и информацию, но в последние годы теряет свою популярность. NATS достаточно новый инструмент и на текущий момент находится в фазе роста популярности.

Rabbit vs (Kafka | NATS)

Самый старый продукт из представленных, создавался как реализация открытого протокола AMQP на замену проприетарным и дорогим брокерам сообщений.

Как протокол, так и его реализация не закладывали в дизайн распределённые системы и горизонтальное масштабирование и это сказалось на итоговых свойствах: будучи весьма производительным и функциональным "монолитом" RabbitMQ имеет пределы пропускной способности. Будучи реализован на Erlang обладает малой базой коммитеров.

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

Являясь классическим брокером, реализующим референс протокола AMQP, а также некоторые другие протоколы, RabbitMQ прочно занимает первое место по этим показателям.

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

ИТОГО:

Ориентируясь на эти критерии можно оценить применимость и заменимость того или иного инструмента под задачу
🤩RabbitMQ если нужна классическая очередь
🤩NATS если нужны легковесность, быстрота и простота
🤩Apache Kafka если требуется зрелый промышленный инструмент для больших потоков данных с богатой экосистемой

Если вам интересны вопросы архитектуры очередей, их свойства, гарантии, паттерны, кластеризация и практика пограничных кейсов, и конечно намеренный вывод из строя части кластера и анализ реакции систем на аварии - приходите на курс Владимира Интенсив по очередям: Kafka и NATS, старт уже 3-го июля. А также смотрите наш супер-стрим с В. Перепелицей Devhands Open Sessions // Queues 2025, что выбрать: Kafka, RabbitMQ, NATS или что-то ещё? https://www.youtube.com/watch?v=2vSj-HHu-wo

Из Физтеха в бигтехи - 2

Продолжаем публиковать интервью со студентами Физтеха и их научным руководителем, Константином Ратвиным. Константин - сотрудник кафедры Банковских Информационных Технологий Физтеха. Кафедра специализируется на высоких нагрузках, распределенных системах, машинном обучении. Предыдучая часть: https://t.iss.one/rybakalexey/268.

Костя, расскажи пожалуйста кратко о студенческих проектах?

В 2024-2025 учебного году я курировал более 10 выпускных работ. По роду моей деятельности они все связаны с СУБД. Перечислять все особого смысла нет, но я бы отметил работу своей студентки «LLM как персональный администратор БД». Она провела отличную исследовательскую работы и попытались переосмыслить наработки закрытых проектов в СберТехе в этой области. В своей работе она попыталась спрогнозировать параметры нагрузочного тестирования в зависимости от заданных показателей RPS. Мне кажется её результаты будут полезны при дальнейшей работе сотрудников компании.

Есть пример из прошлого года, когда моя студентка участвовала в бета-тестировании СУБД SoQoL. На кафедре она рассказала об этой СУБД, о её целях создания и основных киллер-фичах, которые выделяют ее на рынке РСУБД. Было довольно интересно.

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

🤩 Векторные базы данных. Vector similarity search (VSS). Встраивание векторного поиска в Apache Ignite

В этой работе студент выступает в роли разработчика СУБД. Александр написал модуль приближённого поиска ближайших соседей (ANN) на основе алгоритма HNSW с интеграцией в распределённую СУБД Apache Ignite. Провел эксперименты на задаче выявления мошенничества с использованием датасета IEEE-CIS Fraud Detection, продемонстрировавшие высокую точность и низкую задержку запросов. Результаты показывают, что реализованный модуль может эффективно применяться в финтех-задачах, где важны скорость и точность поиска по векторному сходству.

🤩 Тесты детерминированного исполнения для СУБД Tarantool

Довольно уникальная работа. Студент прошел отбор в Tarantool Lab и с их подачи выбрал тему и провел исследование. Работа имеет QA-направленность, хотя разработать подобный инструмент тестирования задача не из легких.

🤩 Методы восстановления данных из поврежденной СУБД. Создание «Best Practice» по восстановлению БД. Разработка генератора «повреждений»

Тема последний работы у меня родилась после прослушивания доклада на PG.Conf.2023 Russia про методы восстановления баз данных. Хотелось, чтобы кто-то из студентов раскрыл эту тему более подробно. Павел проделал огромную работу по составлению списка возможных повреждений БД на примере PostgreSQL и составил план действий для потенциальных администраторов как решить их. Да, от всех бед нас спасёт резервная копия (если сможем восстановиться). Но на практике бывают ситуации, когда восстановление невозможно или крайне нежелательно. Специалистам по БД приходится заниматься реанимаций, как настоящим хирургам.

Обсуждение деталей проектов со студентами - в следующих постах.

Что планируется в PostgreSQL 18

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

Коля, скоро выйдет постгрес 18й, что там будет интересного?

Список нововведений как обычно длинный, но лично мне наиболее интересны следующие моменты:
🤩EXPLAIN теперь включает BUFFERS по умолчанию (статистику больше не нужно запрашивать отдельно), а это лучше помогает понимать все запросы: по количеству строк и обычным костам можно не заметить тяжёлые запросы или плохую структуру БД. Подпланы, триггеры, функции теперь тоже будут видны лучше в EXPLAIN.
🤩Не забыли и инструментацию дисковой подсистемы. Есть такой хороший экстеншен pg_stat_io и он теперь умеет выдавать статистику использования дисков по процессам - обработчикам запросов (backends)
🤩C расширениями постгреса есть настоящий подарок для облачных систем - новая переменная (GUC) extension_control_path. Теперь будет гораздо проще давать устанавливать расширения в облачных и managed инсталляциях постгреса.
🤩Неожиданно приятно, с 18 постгреса, можно авторизоваться через OAuth2.
🤩Логическая репликация продолжает развиваться, добавили логирование конфликтов. Что даёт надежду на улучшение надёжности Master-Master репликаций в дальнейших версиях.

А что именно поменялось в Explain относительно подпланов и триггеров-функций?

В PostgreSQL 18 EXPLAIN ANALYZE теперь предоставляет больше информации в более удобном виде. Подпланы отображают время выполнения, количество строк и стоимость прямо в дереве плана. Триггеры показывают время выполнения и количество вызовов, что упрощает выявление их влияния на производительность. Функции теперь отображают общее и среднее время выполнения. Эти улучшения значительно повышают прозрачность процедурной и реактивной логики в запросах.

Будем после релиза выдавать машины с 18-м постгресом на твоем курсе?

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

Вторая часть беседы - про uuid, адаптивные конфигурации и прочее - в следующем посте.

——

🤩 17-го июля: PostgreSQL 17: архитектура и тюнинг SQL-запросов
Курс для бекендеров и инженеров инфры, сочетающий фундаментальную теорию и практику, архитектура СУБД вообще и PostgreSQL в частности, типы и особенности индексов, MVCC, ваккума, типы SQL, практический алгоритм использования EXPLAIN для оптимизации и очень много практики на собственном выделенном сервере.

Из Физтеха в бигтехи - 3: Open Source, Тарантул, RAFT (Эдгар Атабекян)

Продолжаем публиковать посты про проекты кафедры Банковских Информационных Техноголий МФТИ. На наши вопросы отвечал выпускник, Эдгар Атабекян, который вместе с командой Tarantool выполнил работу “Тесты детерминированного исполнения для СУБД Tarantool” (научный руководитель - Константин Ратвин).

О себе и о учебе: Учился в физико-математической школе в Ереване. Статус призёра в олимпиадах дал мне квоту на зачисление. Поговорив с выпускниками нашей школы, уже учившимися в МФТИ, окончательно понял, что хочу учиться именно там. Самым челленджовым в учебе был первый семестр. Не привык к нагрузке и темпам, нужно было быстро адаптироваться и успевать закрывать все предметы. Затем возвращение после армии. Во втором семестре вернулся после двух-летнего академического отпуска: пришлось одновременно освежать старые знания и осваивать новые. Поступление на кафедру БИТ: конкурс был высоким, кафедра входит в число лучших, пришлось вложить максимум усилий.

Как выбирали дипломный проект? Был ли конкурсный отбор, какой?

Я нацелился на Tarantool ещё после презентации их команды на курсе по базам данных. Через Константина Александровича связался с Tarantool и попросил взять меня. У них как раз была программа для студентов - «TarantoolLab», посвящённая исследовательским задачам. Был конкурс: тестовое задание и собеседование, оба этапа затрагивали основные концепции и технологии использующиеся в ядре Tarantool.

Почему выбрали тему, связанную с RAFT?

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

Алгоритмы консенсусного лога типа RAFT нетривиальны. Вам преподавали его на кафедре или пришлось изучать самому?

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

Какие впечатления от работы с Tarantool?

🤩 Плюсы. Tarantool — сложная система, через которую я освоил множество концепций системного дизайна и интересных backend-решений.
🤩 Минусы. Lua-API не слишком «user-friendly», документация фрагментарна, но это дало опыт работы со сложными интерфейсами и неполной документированностью.

Какие основные результаты вашей работы?

Были разработаны сразу два сервиса: один — классический fuzzer, который за ночь генерирует тысячи хаотичных сценариев и ломает кластер в самых неожиданных местах; второй — маленький ИИ-агент на базе LLM, который читает логи, понимает, где больнее всего, и сам придумывает следующий “удар”.

Они работают паралельно: fuzzer даёт ширину покрытия, а LLM целится в самые тонкие, редкие состояния. Итог — мы нашли пять критических багов в репликации, причём четыре из них раньше вообще никто не видел. Для всех сразу открыли публичные issues.

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

Результаты вашей работы окажутся в открытом доступе?

Да. Код выложен в публичном форке Tarantool на GitHub, а все найденные ошибки оформлены как issues в основном репозитории.

Насколько участие в open source помогает учиться писать качественный production-код?

Open source не гарантирует «production-grade» стиль кода, но вынуждает глубоко разбираться в архитектуре и чужих решениях. Это развивает навык чтения, рефакторинга и улучшает инженерное мышление.

Как по-вашему, должны ли крупные компании, активно использующие open source, быть обязаны возвращать изменения и вкладываться в развитие сообществ?

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

PostgreSQL 18, часть 2 - продолжение разговора с Николаем Ихалайненым

Если пропустили первую часть - вот она.

Расскажи подробнее про extension_control_path в PostgreSQL 18 - что это и почему важно?

С первого взгляда, это изменение ухудшает безопасность и больше ничего полезного не даёт. extension_control_path говорит Постгресу, где находятся файлы расширения. Хочешь поставить pg_cron - положи файлы в $SHAREDIR/extension. В докере и кубере надо собрать все файлы приложения в одном "архиве". Для всех комбинаций - версии постгреса и набора расширений нельзя наделать образов. Поэтому облачные провайдеры делают ограниченный список поддерживаемых расширений, или ухудшают безопасность, разрешая запись в директорию extensions. Теперь же можно взять образ нужной версии прямо от разработчиков постгреса, а каждое расширение подключать в своей директорией. Как раз кстати, в свежих Kubernetes можно подмонтировать образ с расширением, как поддиректорию основной файловой системы постгреса.

В последнее время в новостях эко-системы PostgreSQL мы часто слышим об OrioleDB - и ты втащил в курс этот известный в узких кругах проект. Какую практику получает участник?

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

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

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

На практике какие улучшения в OrioleDB по сравнению с ванильным PostgreSQL вы заметили?

На курсе у нас часто используется TPC-H датасет, это данные электронного магазина, с заказами, корзинами, товарами - миллионы записей.

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

Второе улучшение важно для OLTP нагрузки: можно перезаписывать одни и те же строки. Движки хранения с UNDO не пишут новую версию строки рядом со старой. Новая версия строки записывается в ту же страницу, в ту же строку. При попытке обновления поля user.LastOnline с высокой частотой на ванильном постгресе, таблица замусоривается старыми версиями и VACUUM убивает производительность. Приходится заставлять разработчиков убирать такие функции приложения или переносить их в другие базы, например в Redis. OrioleDB на такой нагрузке держит размер таблицы под контролем.

——
🤩 17-го июля: PostgreSQL 17: архитектура и тюнинг SQL-запросов

UUID-7 в PostgreSQL 18

Заключительная часть комментариев Николая Ихалайнена про нововведения в PostgreSQL 18. Предыдущие части: первая – общий обзор и EXPLAIN, вторая – экстеншены и OrioleDB.

Краткая справка: UUID (Universally Unique Identifier) это 128-битный идентификатор, используемый для создания уникальных значений, которые практически невозможно повторить. Представляется как строка из 36 символов в формате: f47ac10b-58cc-4372-a567-0e02b2c3d479.

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

Расскажи пожалуйста поподробнее про проблему UUID в постгресе и что сделано в 18-м постгресе для улучшения?

UUID часто применяется как первичный или внешние ключи и для Postgresql . При использовании B-tree индексов каждая вставка может приводить к обновлению целой страницы, т.к. новые ключи для дерева не последовательные, а случайные. Начиная с Postgresql 18 доступен формат UUIDv7, в этом типе данных находится дата, время, счётчик и случайное число, что позволяет делать вставки возрастаюших ключей, адаптированных к деревьям. Эффекты от плохого и хорошего использования UUID видны с EXPLAIN BUFFERS и в 18 улучшение будет сразу заметно.

Таким образом получаем:
🤩 Упорядоченность по времени: UUID v7 увеличиваются с ростом времени, значит новые записи добавляются в конец B‑tree индекса, а не «разбросаны» по всему дереву. Это снижает фрагментацию и количество page splits, улучшая вставки и уменьшая беспорядок в страницах.
🤩 Упрощённое кэширование буферов: Последовательные вставки означают, что данные «горячих» страниц находятся рядом, их легче держать в памяти, снижается нагрузка на диск.
🤩 Меньше задержек при вставке: Так как не требуется перестраивать деревья или читать/перезаписывать «старые» страницы, throughput и latency операций INSERT улучшаются.

Кстати, Константин Ратвин (@databasethinking) нашел вот такой свежий доклад Андрея Бородина (Яндекс), это именно его нужно благодарить за UUID-7 в PostgreSQL: Новый UUID как первичный ключ в вашей базе данных (видео 39 минут).

——
🤩 17-го июля: PostgreSQL 17: архитектура и тюнинг SQL-запросов

Архитектура Neon, разделение compute/storage

Аренадата в своем блоге на Хабре выпустила, как мне кажется, первую в русско-язычном сегменте статью, в которой не только рассказывается про внутрянку Neon, но и достаточно подробно освещается тренд разделения Compute и Storage в cloud-native СУБД — и с точки зрения архитектуры, и с точки зрения эксплуатации. Обязательна к прочтению всем, кому интересны тренды развития СУБД. Если знаете другие примеры подобных статей — скидывайте в каменты.

Читать: https://habr.com/ru/companies/arenadata/articles/927464/
Автор: Алексей Быков

Для справки:

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

🤩Разделение слоёв compute и storage — современный тренд в развитии СУБД. Это позволяет масштабировать вычисления и хранение независимо друг от друга, повышая гибкость и экономичность. Подход особенно популярен в облачных и серверлесс решениях, где важна эффективность использования ресурсов. Он упрощает менеджмент баз, утилизацию ресурсов, бэкапы, клоны, быстрый запуск инстансов и восстановление, но приводит к сложной платформенной инфраструктуре, а также может приводить к повышенной задержке доступа к данным.