🎦 You Can’t Scale When You’re Dead

Лучший доклад всей конференции по моему мнению! 💪Я слушал, смотрел видео и кайфовал! 😌

Очень много прикольный цитат. Очень здорово сделана презентация и видеоряд 🎥. Мне очень понравилось! Супер! 💥

Автор доклада - Joran Greef, Creator, Tigerbeetle.

В целом, он мне продал свою базу данных 💰. Была бы возможность, то сразу же запросил прайслист и дистриб на тестирование.

Начнем...

🛡 Масштабируемость - это не скорость. Это выживаемость
Многие думают, что масштаб - это про миллионы RPS и бесконечные кластеры. Но на самом деле масштаб - это способность системы не умереть окончательно, когда всё летит в тартарары.

Автор Tiger Beetle (БД для финтеха на языке Zig) выкатил мощный манифест о том, как пережить 1 триллион транзакций.

Вот краткая выжимка того, почему текущий стек может быть "слишком большим, чтобы выжить":

❌ Где все ошибаются?
1️⃣Шардирование (Horizontal Scaling): Оно убивает локальность кэша. Ваша CPU тратит время на ожидание сети, а не на вычисления.

2️⃣Разделение хранения и вычислений (Decoupling): Круто для аналитики, но слишком медленно для транзакций (OLTP) из-за задержек объектных хранилищ (типа S3).

3️⃣Смертельная спираль: Если база на 100 ТБ, то восстанавливается она дольше, чем падает следующий узел. Система ломается быстрее, чем чинится.

➖ MTTR > MTBF
➖ Масштабировать систему сложно, потому что трудно обеспечить живучесть.
➖ Вы больше не являетесь владельцем Системы, Система владеет Вами

7 стадий эволюции баз данных

1. log, журнал
2. Снапшоты
3. LSM-Tree
4. Репликация машины состояние (1988, основа Ver, за 1 год до Рафта)
5. Горизонтальное масштабирование (часть состояния машины)
6. Разделись всё. Отдельно сторадж и отдельно вычисления. Айсберг
7. (диагональное масштабирование (Diagonal Scaling) RSM + LSM + Object Storage

✅ Решение: "Диагональное масштабирование"
Вместо того чтобы просто добавлять узлы, Tiger Beetle предлагает гибрид: RSM + LSM + Object Storage.

RSM (Replicated State Machine): Обеспечивает отказоустойчивость и строгую последовательность (Strict Serializability).

LSM-деревья: Эффективно работают с иерархией памяти (кэш -> RAM -> NVMe).

Облачное хранилище: Для бесконечного и дешевого хранения исторических данных.

🚀 Результаты Tiger Beetle
800,000 транзакций в секунду на обычном кластере из 3-х узлов.

В демо-ролике система обрабатывает 800,000 транзакций в секунду (TPS) на кластере из 3 узлов (очень красивое видео).

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

P.s.я понимаю, что в докладе очень много маркетинга, но как же это красиво! ☺️

📚 Database Trends and Applications Magazine: February/March 2026

❗️Тема номера: Кто присматривает за СУБД? Как меняются роли DBA и специалистов по данным.

Дисклеймер: традиционно разбираю только небольшой набор статей.

➡️SURVEY: DATA INFRASTRUCTURE IS NOT READY FOR THE AI AGE

Традиционно 1-ая статья про ИИ. Забавно, что в этот раз она основана не на опросе компаний, а на результатах исследования компании Cockroach Labs, которое выявило серьезный разрыв между амбициями компаний в сфере ИИ и готовностью их ИТ-инфраструктуры.

1️⃣ Разрыв между амбициями и реальностью. Бизнес находится в состоянии эйфории от возможностей ИИ, но технические специалисты не могут заставить его работать 😏. Классическая ситуация, когда софт (модели ИИ) на десятилетие опередил железо и методы управления данными.
2️⃣База данных - новое "узкое горлышко". Традиционные архитектуры просто не рассчитаны на ту интенсивность и непредсказуемость, которую создают автономные ИИ-агенты. Это всё к тому, что зарождается маркетинговый термин AI-native базы данных.
3️⃣Управленческая слепота: Компании инвестируют в ИИ, но не получают отдачи, так как система постоянно "падает" или тормозит под нагрузкой 😞.
Мы сами сейчас внедряем свой "карманный" ИИ и сталкиваюсь с описанными проблемами. Тормозит жестко...
4️⃣ Необходимость новой архитектуры. Авторы подводят к мысли, что для эпохи ИИ нужны принципиально другие системы, например, облачно-ориентированные, способные к мгновенному масштабированию и сверхбыстрой обработке транзакций.

Кто бы сомневался 🤔 Опять облака всех спасут💭. Ну-ну... я вижу как страны персидского залива кайфуют после выхода из строя уже двух ЦОД Amazon😶‍🌫️.

➡️ Who’s Minding the Database? The Changing Role of DBAs and Data Professionals
❗️Главная статья номера.

Это явно продолжение статьи из прошлого номера.

Современный DBA перестает быть просто "хранителем2 серверов и становится стратегическим партнером бизнеса.

Фу...😠 Наймите вы отдельных людей для этого. Почему все мучают бедных DBA? Не понятно... 😔

DBA как «Стюард платформы данных»
Вместо того чтобы быть изолированным «контролером» (gatekeeper), специалист по данным теперь:

👉Определяет правила и стандарты (governance), по которым разработчики могут сами изменять схемы данных.

👉Отвечает за надежность и скорость данных, которые питают аналитику и ИИ.

👉Управляет стоимостью облачных ресурсов и соблюдением законодательных норм.

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

В крупных компаниях часто я слышу в адрес коллег такое:

"Как твоя работа влияет на наш Бизнес? Как ты приносишь деньги?"

И очень часто народ тупит над этим вопрос😵‍💫. Мне кажется это проверка на ЧСВ 🤴. Надо растить это чувство, чтобы народ понимал, что ты самый ох**нный специалист на свете 💪!

➡️Harnessing the Potential of CXL for Cloud-Native Databases
Статья и новой технологии CXL (Compute Express Link).

CXL - это высокоскоростной открытый стандарт интерконнекта для когерентной связи CPU-устройств (например, ускорителей, GPU, SSD) и CPU-памяти (позволяя процессору использовать память устройств как свою собственную и наоборот).

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

RDMA для disaggregated memory уже недостаточно хороша для будущих cloud-native БД, а CXL может дать более тонкий доступ к памяти, лучшую когерентность, более быстрое recovery и лучшую экономику инфраструктуры.

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

Lifelong Learners
...
In short, the great DBA of 2026 is a hybrid: part technologist, part strategist, part businessperson, part diplomat. They’re not just managing databases, they’re managing complexity, risk, and opportunity.

🎦 The End of Eventual Consistency | CockroachDB

Кликбейтное название + тайминг в 6:28 = секрет успешного видео! Люблю такое! 😍

Понятное дело, что строгая согласованность лучше согласованности в конечном счета. Это понятно 👌
В целом, автор видео это наглядно нам продемонстрировал.

Меня в этом видео зацепил сам эксперимент.

Автор взял кластер из трех нод CockroachDB (3 мастера) и RDS for PostgreSQL (1 мастер + 2 реплика. Причем не понятно, репликация синхронная или асинхронная)

Затем смоделировал нагрузку, а-ля, e-commerce-сценарий в котором агенты (или пользователи) создают и забирают ваучеры.
Тест запускался параллельно для 10 агентов, где каждый создавал по 100 ваучеров.

Результаты очевидны:

🪳 CockroachDB
все ваучеры созданы и захвачены корректно, без дублирования (Strong Consistance всё-таки)

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

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

В общем, отличная тема для открытого урока!

Возьму на заметку 📝

📚Open Source, Community, and Consequence: The Story of MongoDB

История эволюции MongoDB от простой нишевой документоориентированной БД до полнофункциональной платформы данных..

Конечно она далеко не полная, но кое-какие вызовы подсвечивает.

"нереляционных" данных не существует. Любые данные имеют связи. Разница лишь в том, как мы их моделируем.

Я попытался разбить текст статьи на исторические вехи

🚀 Этап 1: Рождение из боли (2007–2009)
👉 Основатели работают в DoubleClick (рекламный гигант). Реляционные базы не справляются с веб нагрузками.

👉 Идея: Хватит пытаться втиснуть объекты из кода в таблицы. Сделаем «документную модель» — JSON-подобные структуры, которые понятны разработчику.

🔥 В результате появилась MongoDB.

🌪 Этап 2: Хайп и «Web-Scale» (2010–2014)
Взрыв популярности. Весь мир строит приложения на «MERN/MEAN» стеке.

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

🛠 Этап 3: Техническое взросление (2015–2018)
⚡️Покупка движка WiredTiger. MongoDB полностью переписывает систему хранения.

👉Появление ACID-транзакций. База перестает быть «игрушкой для стартапов» и заходит в банки и энтерпрайз. Я бы еще добавил, отказ от BASE и добавлением необходимых "корпоративных" фич.

☁️ Этап 4: Облачные войны и Atlas (2019–2023)
🧨 Бизнес-бомба: Ввод лицензии SSPL. Запрет использования облачным провайдерам кода MongoDB без дополнительной платы.

👉 Релиза своего облачного сервиса Mongo Atlas.

🤖 Этап 5: Платформа данных (Сегодня)
🤘Это уже не просто NoSQL. Теперь это «Developer Data Platform».

👉 Векторный поиск для ИИ, полнотекстовый поиск, аналитика в реальном времени.

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

Я ScyllaDB полюбил как вендора только благодаря маскоту. Хотя сам я эту СУБД нигде не использую. Но отношение к ней максимально положительное 🤪

📚 NoSQL Data Modeling Explained with DynamoDB Single Table Design

Очень показательная идея из статьи про DynamoDB:

в NoSQL ты проектируешь не таблицы - ты проектируешь запросы.

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

📊 Как бы решили задачу в реляционной БД

Допустим, у нас сервис поиск пациентов через платный API ($5 за запрос).
Нам нужно:
👉не платить повторно за одинаковый поиск
👉хранить историю
👉считать биллинг

В классической СУБД (например, PostgreSQL) мы бы сделали:
✅таблица patients
✅таблица search_requests
✅таблица billing

И далее классика:

JOIN + индексы + агрегации

Данные нормализуем ➡️ нужное собираем запросом

➕гибкость
➕можно добавлять новые сценарии
➖больше JOIN
➖нагрузка растёт с объёмом

⚡️ Как это решается в NoSQL (например, Amazon DynamoDB)

Мы заранее думаем:
👉 как будем искать?
👉 как проверять “уже был такой запрос”?
👉 как считать биллинг?

И делаем одну таблицу, например:

PK = SEARCH#<query_hash>
SK = RESULT#<timestamp>

И рядом:

PK = USER#123
SK = BILLING#2026-04

👉 теперь:
❇️проверка кэша ➡️ 1 запрос
❇️получение результата ➡️ 1 запрос
❇️биллинг ➡️ 1 запрос

Без JOIN вообще.

🧠 Где ключевой сдвиг мышления

В SQL:
сначала модель → потом запрос

В NoSQL:
сначала запрос → потом модель

⚖️ Что стало лучше

✔️ быстрее (меньше round-trip)
✔️ дешевле (меньше операций)
✔️ проще на чтение (всё рядом)

⚠️ Что стало хуже

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

🎯 Итого

в SQL ты собираешь данные на лету
в NoSQL ты обязан собрать их заранее

Идея красивая, но надо будет на цифрах это всё проверить 😊

🎦 Avito Database meetup

Основные доклады

🕚 Как мы прошли путь от разрозненных Ceph кластеров к единой платформе с 100 000+ бакетов;
🕚 Почему нам не подошла FoundationDB и чем удивила Cassandra 5;
🕚 Как мы предоставляем базы данных с чувствительными данными внутри DBaaS

Меня больше всего заинтересовал 2-ой доклад. Про сравнение FoundationDB vs Cassandra 5.

И так, Авито искали автошардируемую базу данных,
чтобы заменить сложную инфраструктуру с MongoDB.

В текущей архитектуре:
👉 используется MongoDB
👉 сотни шардов / тысячи инстансов
👉 self-sharding (логика на стороне сервиса)

данные шардуются не БД, а приложением

🔥 последствия:
👉сложная логика в коде
👉сложные миграции
👉дорого по ресурсам (x4 из-за реплик и бэкапов)

🎯 Что хотели получить
🔸 автошардинг “из коробки”
🔸 простой кластер (желательно masterless)
🔸 меньше инфраструктуры
🔸 open-source лицензия
🔸 горизонтальное масштабирование
🔸 мульти-DC

🧠 Что показали тесты

Cassandra
➕высокий RPS (выше MongoDB)
➕latency на уровне Mongo
➕автошардинг работает
➕masterless → быстрое восстановление
➕экономия диска ~30%
➕зрелая экосистема
➖требовательна к настройке ОС
➖сложный data modeling
➖масштабирование “пачками” (по replication factor)

FoundationDB
➕очень низкая latency
➕хорошая модель транзакций
➕автошардинг есть
➖низкий RPS
➖сильная зависимость от дисков
➖нет сжатия → x3 по месту
➖лимит 100KB на значение
➖сложный клиент (высокий порог входа)
➖проблемы с конфликтами транзакций

🏆 Победитель - Cassandra

Однако:

Cassandra победила как решение конкретной задачи (замена многосотшардовой MongoDB)

📚 Забудьте о Redis: DuckDB обрабатывает 78 % наших аналитических запросов быстрее

Звучит как «Redis не нужен»? На самом деле это очередной пример "кликбейтного" названия статьи, хотя суть её совершенно про другое. Я прочел и был крайне недоволен. Автор, как бы выразиться покультурнее, не прав.

Что у них было:
👉 основная (OLTP) база данных
👉 сложные аналитические запросы (фильтры, агрегации, группировки)
👉 Redis как кэш результатов

Цепочка следующая:
запрос ➡️ считаем в БД ➡️ кладём результат в Redis ➡️ надеемся на cache hit

Проблема началась, когда аналитика усложнилась:
👉 комбинаций фильтров стало слишком много
👉 кэш начал «взрываться»
👉 cache hit падал
👉 latency стала непредсказуемой

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

Зановес!

Это не история про Redis vs DuckDB. Это история про неправильный выбор движка выполнения (execution engine).

❌ OLTP база + кэш (Redis) 🔜 попытка ускорить аналитику
✅ OLAP движок (DuckDB) 🔜 нативное выполнение аналитики

Redis в этом кейсе использовался примитивно — как key-value cache. При этом у Redis есть инструменты для аналитики:
➕ Sorted Sets (топы, ранжирование)
➕ HyperLogLog (approximate distinct)
➕ Векторный и семантический поиск
И многое другое

Вывод:

OLAP-движок (DuckDB) лучше справился с их аналитическим workload, чем схема "OLTP БД + кэш Redis"

И если вы начинаете кешировать аналитические запросы, то возможно, проблема не в скорости, а в архитектуре.