🎊 11 и 12 марта прошла конференция Monster SCALE Summit 2026 в режиме онлайн.
О том, как устроена конференция я писал ранее. Сейчас немного поговорим о докладах.
Я отсмотрел более 70% видео. Вроде бы они интересные, но какие-то скучные 😞. Может просто спикер не запал в мое сердечко, не знаю )) бывает 😁.
Расскажу про видео, которые мне откликнулись.
❇️Monster SCALE Summit 2026 | Designing Data-Intensive Applications Second Edition by Martin and Chris
По сути это небольшое интервью с авторами книги "Кабанчик 2.0". Да, да, оно уже вышло и его заказал. Когда придет, не знаю )
В целом, интервью откровенное слабое. Как журналист ведущий очень слаб. Пару тезисов я всё-таки выцепил
❇️Monster SCALE Summit 2026 | Fast and Simple Analytics on MongoDB with DuckDB by Stephanie Wang
Доклад вроде бы банальный, но меня привлекло то, что пытаются скрестить с DuckDB не РСУБД в виде PostgerSQL, а MongoDB.
1️⃣Вы пишете обычный SQL-запрос в DuckDB.
2️⃣Расширение (extension) для MongoDB «пробрасывает» фильтры и проекции в саму базу (Projection/Filter Pushdown).
3️⃣Из MongoDB извлекаются только нужные данные и передаются в DuckDB.
4️⃣DuckDB выполняет сложные джойны (joins), агрегации и оконные функции локально в памяти, используя векторный движок.
Финальный посыл: используйте подход «Local-first analytics». Начинайте с простого - используйте мощь современных локальных систем и добавляйте сложность (распределенность) только тогда, когда нагрузка этого действительно требует.
❇️Monster SCALE Summit 2026 | The Future of Data Consistency in ScyllaDB by Alex Dathskovsky
ScyllaDB явно движется к унификации вокруг Raft. Раньше для разных задач у них был “зоопарк” механизмов: gossip для cluster state, Paxos для LWT, отдельные схемы репликации и repair. Сейчас Raft уже используется для schema/topology metadata, а дальше, похоже, курс взят на более широкую strong consistency там, где она действительно нужна.
На этом фоне интересно смотреть на Redis/Valkey Cluster. Там gossip отвечает не только за membership, но и за ping/pong, обнаружение узлов, failure suspicion и распространение служебных cluster-сообщений.
Мне кажется, если Redis/Valkey когда-нибудь и пойдут в сторону Raft, то первым шагом будет “не сделать CP-систему”, а перевести на Raft control plane: membership, topology, failover decisions, config metadata. Это дало бы более детерминированное управление кластером, более предсказуемые topology changes и менее двусмысленный failover. А пользовательские данные при этом могли бы ещё долго жить в старой async-модели. Это долгий путь - и не факт, что он вообще нужен. Но как направление эволюции control plane идея выглядит вполне разумной.
❇️What Speedrunning Can Teach Us
Доклад креативный, но визуально скудный. Не хочу его пересказывать, поэтому сведу одну общую мысль:
Лучший доклад всей конференции!💪 Кайфанул очень сильно! 🔥
Сделаю отдельный разбор доклада в следующем посте! 😎
p.s. Из каждого угла сайта конференции активно пиарится книга
Database Performance at Scale: A Practical Guide. Дойдут руки, почитаю её.
О том, как устроена конференция я писал ранее. Сейчас немного поговорим о докладах.
Я отсмотрел более 70% видео. Вроде бы они интересные, но какие-то скучные 😞. Может просто спикер не запал в мое сердечко, не знаю )) бывает 😁.
Расскажу про видео, которые мне откликнулись.
❇️Monster SCALE Summit 2026 | Designing Data-Intensive Applications Second Edition by Martin and Chris
По сути это небольшое интервью с авторами книги "Кабанчик 2.0". Да, да, оно уже вышло и его заказал. Когда придет, не знаю )
В целом, интервью откровенное слабое. Как журналист ведущий очень слаб. Пару тезисов я всё-таки выцепил
👉300 000+ проданных экземпляров первого издания! Для технической книги это очень много.
👉Мартин ушел с головой в академическую деятельность и немного подотстал от техничего прогресса. Наверстать ему помог Крис. Так и получилось 2-ое издание.
👉ИИ меняет мир, но мы пока не понимаем как. То, что сегодня кажется оптимальным решением. Через полгода может стать не актуальным.
👉Мартин: Не позволяйте своим инженерам писать книги. Иначе они могут уйти!
❇️Monster SCALE Summit 2026 | Fast and Simple Analytics on MongoDB with DuckDB by Stephanie Wang
Доклад вроде бы банальный, но меня привлекло то, что пытаются скрестить с DuckDB не РСУБД в виде PostgerSQL, а MongoDB.
👉 Многие компании начинают строить аналитику с огромных стеков: ETL-процессы, хранилища (DWH) и распределенные движки. Это оправдывают «масштабируемостью» и «будущим ростом».Как это работает технологически:
👉 Однако исследования (например, данные AWS Redshift) показывают, что 99% аналитических запросов на самом деле небольшие (сканируют менее 10 ГБ данных).
1️⃣Вы пишете обычный SQL-запрос в DuckDB.
2️⃣Расширение (extension) для MongoDB «пробрасывает» фильтры и проекции в саму базу (Projection/Filter Pushdown).
3️⃣Из MongoDB извлекаются только нужные данные и передаются в DuckDB.
4️⃣DuckDB выполняет сложные джойны (joins), агрегации и оконные функции локально в памяти, используя векторный движок.
Финальный посыл: используйте подход «Local-first analytics». Начинайте с простого - используйте мощь современных локальных систем и добавляйте сложность (распределенность) только тогда, когда нагрузка этого действительно требует.
❇️Monster SCALE Summit 2026 | The Future of Data Consistency in ScyllaDB by Alex Dathskovsky
ScyllaDB явно движется к унификации вокруг Raft. Раньше для разных задач у них был “зоопарк” механизмов: gossip для cluster state, Paxos для LWT, отдельные схемы репликации и repair. Сейчас Raft уже используется для schema/topology metadata, а дальше, похоже, курс взят на более широкую strong consistency там, где она действительно нужна.
На этом фоне интересно смотреть на Redis/Valkey Cluster. Там gossip отвечает не только за membership, но и за ping/pong, обнаружение узлов, failure suspicion и распространение служебных cluster-сообщений.
Мне кажется, если Redis/Valkey когда-нибудь и пойдут в сторону Raft, то первым шагом будет “не сделать CP-систему”, а перевести на Raft control plane: membership, topology, failover decisions, config metadata. Это дало бы более детерминированное управление кластером, более предсказуемые topology changes и менее двусмысленный failover. А пользовательские данные при этом могли бы ещё долго жить в старой async-модели. Это долгий путь - и не факт, что он вообще нужен. Но как направление эволюции control plane идея выглядит вполне разумной.
❇️What Speedrunning Can Teach Us
Доклад креативный, но визуально скудный. Не хочу его пересказывать, поэтому сведу одну общую мысль:
Speedrunning учит тому, что оптимизация - это не набор хитрых трюков, а искусство выбирать маршрут, балансируя выигрыш, риск и стоимость ради лучшего общего результата.❇️You Can’t Scale When You’re Dead
Лучший доклад всей конференции!💪 Кайфанул очень сильно! 🔥
Сделаю отдельный разбор доклада в следующем посте! 😎
p.s. Из каждого угла сайта конференции активно пиарится книга
Database Performance at Scale: A Practical Guide. Дойдут руки, почитаю её.
ScyllaDB
Monster Scale Summit On Demand
Monster Scale Summit Extreme scale engineering Discover the latest trends and best practices impacting data-intensive applications. Register for access to all 60+ sessions available on demand. Featured Sessions All Sessions
❤2
🎦 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 ТБ, то восстанавливается она дольше, чем падает следующий узел. Система ломается быстрее, чем чинится.
7 стадий эволюции баз данных
✅ Решение: "Диагональное масштабирование"
Вместо того чтобы просто добавлять узлы, 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.я понимаю, что в докладе очень много маркетинга, но как же это красиво! ☺️
Лучший доклад всей конференции по моему мнению! 💪Я слушал, смотрел видео и кайфовал! 😌
Очень много прикольный цитат. Очень здорово сделана презентация и видеоряд 🎥. Мне очень понравилось! Супер! 💥
Автор доклада - 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.я понимаю, что в докладе очень много маркетинга, но как же это красиво! ☺️
Please open Telegram to view this post
VIEW IN TELEGRAM
ScyllaDB
You Can't Scale When You're Dead - ScyllaDB
Scale is about survivability, not just performance: a system that can't stay alive when things break can't scale at all. This talk examines the limits holding back most OLTP systems, traces database architecture through seven stages of survivability, and…
❤6🤩2🔥1
📚Почему Redis такой быстрый на одном потоке?
Люблю такие статейки про Redis. Вдруг там что-то интересное написано? Или хотя бы подача креативная? 😏
Статья длинная и мне кажется не очень понятная. Думаю стоит её чуть оживить. Краткое "самари" по ней:
Redis быстрей не только потому-то он in-memory, но потому, что он "дружит" с ядром ОС.
1️⃣. I/O Multiplexing (epoll)
Redis не ждет данных от каждого клиента. Он использует системный вызов epoll: ядро само сигнализирует, когда в сокете появились байты. Это позволяет одному потоку обслуживать тысячи соединений без переключения контекста.
2️⃣. Никаких блокировок (Locks)
В многопоточных БД потоки часто стоят в очереди за доступом к данным (lock contention). В Redis один поток, а следовательно, ноль конкуренции, ноль мьютексов, максимальная скорость CPU.
3️⃣. Но он не совсем однопоточный
👉 До v6.0: Вспомогательные потоки (BIO) уже тогда фоном чистили память и сбрасывали логи на диск.
👉 После v6.0: Появились I/O Threads. Они парсят сетевые пакеты параллельно, но команды по-прежнему выполняет только один главный поток, сохраняя атомарность.
⚠️ Нюанс:
В однопоточной среде любая команда O(n) (например, KEYS *) — это приговор. Она блокирует весь сервер для всех клиентов, пока не выполнится.
Redis - это пример того, как отказ от сложности (многопоточности) в пользу умного I/O дает предсказуемую и бешеную производительность💪
Люблю такие статейки про Redis. Вдруг там что-то интересное написано? Или хотя бы подача креативная? 😏
Статья длинная и мне кажется не очень понятная. Думаю стоит её чуть оживить. Краткое "самари" по ней:
Redis быстрей не только потому-то он in-memory, но потому, что он "дружит" с ядром ОС.
1️⃣. I/O Multiplexing (epoll)
Redis не ждет данных от каждого клиента. Он использует системный вызов epoll: ядро само сигнализирует, когда в сокете появились байты. Это позволяет одному потоку обслуживать тысячи соединений без переключения контекста.
2️⃣. Никаких блокировок (Locks)
В многопоточных БД потоки часто стоят в очереди за доступом к данным (lock contention). В Redis один поток, а следовательно, ноль конкуренции, ноль мьютексов, максимальная скорость CPU.
3️⃣. Но он не совсем однопоточный
👉 До v6.0: Вспомогательные потоки (BIO) уже тогда фоном чистили память и сбрасывали логи на диск.
👉 После v6.0: Появились I/O Threads. Они парсят сетевые пакеты параллельно, но команды по-прежнему выполняет только один главный поток, сохраняя атомарность.
⚠️ Нюанс:
В однопоточной среде любая команда O(n) (например, KEYS *) — это приговор. Она блокирует весь сервер для всех клиентов, пока не выполнится.
Redis - это пример того, как отказ от сложности (многопоточности) в пользу умного I/O дает предсказуемую и бешеную производительность💪
Medium
Redis Is Single-Threaded… So Why Is It So Fast?
Understanding Redis Internals: From Event Loops to I/O Threading
🤪3👍1
📚 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? Не понятно... 😔
В крупных компаниях часто я слышу в адрес коллег такое:
И очень часто народ тупит над этим вопрос😵💫. Мне кажется это проверка на ЧСВ 🤴. Надо растить это чувство, чтобы народ понимал, что ты самый ох**нный специалист на свете 💪!
➡️Harnessing the Potential of CXL for Cloud-Native Databases
Статья и новой технологии CXL (Compute Express Link).
Главная идея статьи - переход от традиционного разделения ресурсов к дизагрегации памяти, что позволяет базам данных работать быстрее, надежнее и дешевле.
RDMA для disaggregated memory уже недостаточно хороша для будущих cloud-native БД, а CXL может дать более тонкий доступ к памяти, лучшую когерентность, более быстрое recovery и лучшую экономику инфраструктуры.
Технология решает главную проблему облачных БД — неэффективное использование дорогой оперативной памяти и долгие простои при сбоях.
❗️Тема номера: Кто присматривает за СУБД? Как меняются роли DBA и специалистов по данным.
Дисклеймер: традиционно разбираю только небольшой набор статей.
➡️SURVEY: DATA INFRASTRUCTURE IS NOT READY FOR THE AI AGE
Традиционно 1-ая статья про ИИ. Забавно, что в этот раз она основана не на опросе компаний, а на результатах исследования компании Cockroach Labs, которое выявило серьезный разрыв между амбициями компаний в сфере ИИ и готовностью их ИТ-инфраструктуры.
Мы сами сейчас внедряем свой "карманный" ИИ и сталкиваюсь с описанными проблемами. Тормозит жестко...
Кто бы сомневался 🤔 Опять облака всех спасут
➡️ 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.
Please open Telegram to view this post
VIEW IN TELEGRAM
Database Trends and Applications
Database Trends and Applications Magazine: February/March 2026 Issue
The February/March issue of Database Trends and Applications magazine includes a special MultiValue database technology report.
📚 "дезинтермедиации" (disintermediation) баз данных
Пора почитать блоги других исследователей в области ИТ-технологий 🔎.
И так, товарищ из аналитической компании RedMonk написал статью о том, что эпоха «баз-посредников» подходит к концу. Наступает дезинтермедиация.
😵💫 Что происходит?
👉 Хранение ушло в свободное плавание. Раньше данные принадлежали базе. Теперь они лежат в дешевых облаках и открытых форматах типа Apache Iceberg, что позволяет придать «бесформенным» блобам свойства таблиц (схемы, ACID-транзакции). Это отделяет логику хранения данных от вычислительных движков.
👉 Движки запросов стали расходным материалом. Инструменты для выполнения запросов (query engines) становятся отделяемыми от уровня хранения. Это означает, что "сложность их переноса" больше не является таким серьезным барьером для смены технологий, как раньше. Привязка к вендору (Vendor Lock-in) ломается прямо на глазах.
👉 ИИ крадет интерфейс (AI-native). Зачем учить диалекты SQL, если можно спросить ИИ-агента человеческим языком? База данных превращается в «черный ящик» где-то глубоко под капотом, до которого пользователю нет дела.
👉 Стирание границ между транзакциями (OLTP) и аналитикой (OLAP). HTAP в кадым дом! Транзакционные базы (например, PostgreSQL) все чаще используются для аналитики. OLAP и OLTP системы движутся к друг другу
Конечно, старый добрый PostgreSQL не умрет завтра, можете расслабиться (он переживет нас всех). Но для новых проектов база перестает быть "священным граалем"🏆. Теперь это просто конструктор: здесь храним, там считаем, а ИИ объясняет, почему всё тормозит 🤗.
Зановес
Пора почитать блоги других исследователей в области ИТ-технологий 🔎.
База Данных традиционно является центром притяжения для ИТ-архитектуры. Мы выбирали СУБД как спутника жизни, один раз, по любви или расчету, и на всю жизнь! ❤️💋
И так, товарищ из аналитической компании RedMonk написал статью о том, что эпоха «баз-посредников» подходит к концу. Наступает дезинтермедиация.
😵💫 Что происходит?
👉 Хранение ушло в свободное плавание. Раньше данные принадлежали базе. Теперь они лежат в дешевых облаках и открытых форматах типа Apache Iceberg, что позволяет придать «бесформенным» блобам свойства таблиц (схемы, ACID-транзакции). Это отделяет логику хранения данных от вычислительных движков.
👉 Движки запросов стали расходным материалом. Инструменты для выполнения запросов (query engines) становятся отделяемыми от уровня хранения. Это означает, что "сложность их переноса" больше не является таким серьезным барьером для смены технологий, как раньше. Привязка к вендору (Vendor Lock-in) ломается прямо на глазах.
👉 ИИ крадет интерфейс (AI-native). Зачем учить диалекты SQL, если можно спросить ИИ-агента человеческим языком? База данных превращается в «черный ящик» где-то глубоко под капотом, до которого пользователю нет дела.
👉 Стирание границ между транзакциями (OLTP) и аналитикой (OLAP). HTAP в кадым дом! Транзакционные базы (например, PostgreSQL) все чаще используются для аналитики. OLAP и OLTP системы движутся к друг другу
Конечно, старый добрый PostgreSQL не умрет завтра, можете расслабиться (он переживет нас всех). Но для новых проектов база перестает быть "священным граалем"🏆. Теперь это просто конструктор: здесь храним, там считаем, а ИИ объясняет, почему всё тормозит 🤗.
Зановес
Alt + E S V
The Disintermediation of Databases
The database has been the center of gravity in data architecture for decades. It owned the storage, the query layer, and the interface. That center of gravity is changing. We’re seeing this structural erosion happening from multiple directions at once: cheaper…
🎦 The End of Eventual Consistency | CockroachDB
Кликбейтное название + тайминг в 6:28 = секрет успешного видео! Люблю такое!😍
Понятное дело, что строгая согласованность лучше согласованности в конечном счета. Это понятно 👌
В целом, автор видео это наглядно нам продемонстрировал.
Меня в этом видео зацепил сам эксперимент.
Автор взял кластер из трех нод CockroachDB (3 мастера) и RDS for PostgreSQL (1 мастер + 2 реплика. Причем не понятно, репликация синхронная или асинхронная)
Затем смоделировал нагрузку, а-ля, e-commerce-сценарий в котором агенты (или пользователи) создают и забирают ваучеры.
Тест запускался параллельно для 10 агентов, где каждый создавал по 100 ваучеров.
Результаты очевидны:
В целом, ничего удивительного. Но мне захотелось воспроизвести этот сценарий тестирования. Надо бы написать подобный скрипт с нагрузкой и проверить его на Постгресе с двумя синхронными репликами. Еще можно собрать мастер-мастер кластер из трех нод на PostgresPro дистрибутиве . Мне кажется результаты будут другие.
В общем, отличная тема для открытого урока!
Возьму на заметку 📝
Кликбейтное название + тайминг в 6:28 = секрет успешного видео! Люблю такое!
Понятное дело, что строгая согласованность лучше согласованности в конечном счета. Это понятно 👌
В целом, автор видео это наглядно нам продемонстрировал.
Меня в этом видео зацепил сам эксперимент.
Автор взял кластер из трех нод CockroachDB (3 мастера) и RDS for PostgreSQL (1 мастер + 2 реплика. Причем не понятно, репликация синхронная или асинхронная)
Затем смоделировал нагрузку, а-ля, e-commerce-сценарий в котором агенты (или пользователи) создают и забирают ваучеры.
Тест запускался параллельно для 10 агентов, где каждый создавал по 100 ваучеров.
Результаты очевидны:
🪳 CockroachDB
все ваучеры созданы и захвачены корректно, без дублирования (Strong Consistance всё-таки)🐘 RDS PostgreSQL
В "вежливом" режиме, 36 случаев двойного захвата одного ваучера. В "невежливом" режиме. появились случаи тройного захвата. Причина в том, что агент проверяет статус ваучера на реплике, где данные ещё не обновились, и повторно захватывает уже занятый ресурс.
В целом, ничего удивительного. Но мне захотелось воспроизвести этот сценарий тестирования. Надо бы написать подобный скрипт с нагрузкой и проверить его на Постгресе с двумя синхронными репликами. Еще можно собрать мастер-мастер кластер из трех нод на PostgresPro дистрибутиве . Мне кажется результаты будут другие.
В общем, отличная тема для открытого урока!
Возьму на заметку 📝
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
The End of Eventual Consistency | CockroachDB
This video demonstrates why eventual consistency in databases is becoming increasingly problematic with the rise of AI agents. Rob Reid explains why choosing a database built for strong consistency reduces the complexity and potential for error in rapidly…
📚Introducing Valkey Admin: Visual Cluster Management for Valkey 2026-02-25 · Allen Helton, Arseny Kostenko
Какая классная тема! Первая opensource GUI для Valkey! Проект пока на очень ранее стадии, но надеюсь они доведут его до ума. Я обожаю всяческие графические управляшки. Супер! Буду обязательно следить за проектом.
Написан на TypeScript + JavaScript
Текущие особенности:
👉 Визуализация топологии кластера
👉 Мониторинг узлов
👉 Управление ключами (просмотр, редактирование, удаление)
👉 Диагностика производительности
👉 Встроенный CLI
В будущем планируется веб-версия. RedisInsight подвинься...
Valkey Admin - новый инструмент с графическим интерфейсом для визуального управления кластерами Valkey.
Какая классная тема! Первая opensource GUI для Valkey! Проект пока на очень ранее стадии, но надеюсь они доведут его до ума. Я обожаю всяческие графические управляшки. Супер! Буду обязательно следить за проектом.
Написан на TypeScript + JavaScript
Текущие особенности:
👉 Визуализация топологии кластера
👉 Мониторинг узлов
👉 Управление ключами (просмотр, редактирование, удаление)
👉 Диагностика производительности
👉 Встроенный CLI
В будущем планируется веб-версия. RedisInsight подвинься...
valkey.io
Valkey: Introducing Valkey Admin: Visual Cluster Management for Valkey
Valkey Admin is an open-source desktop application that provides visual cluster topology, hot key detection, performance diagnostics, and interactive key management for Valkey clusters without piecing together CLI commands. Now in preview!
❤1
📚Open Source, Community, and Consequence: The Story of 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 полюбил как вендора только благодаря маскоту. Хотя сам я эту СУБД нигде не использую. Но отношение к ней максимально положительное 🤪
История эволюции 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: Платформа данных (Сегодня)
👉 Векторный поиск для ИИ, полнотекстовый поиск, аналитика в реальном времени.
Как итог я бы сказал, что сообщество - ключ к успеху. Надо делать всё возможное, чтобы привлекать народ к своему продукту. Реклама, маркетинг, бренд маскот и т.п.
Я ScyllaDB полюбил как вендора только благодаря маскоту. Хотя сам я эту СУБД нигде не использую. Но отношение к ней максимально положительное 🤪
Please open Telegram to view this post
VIEW IN TELEGRAM
InfoQ
Open Source, Community, and Consequence: the Story of MongoDB
Andrew Davidson and Akshat Vig discuss the journey of disrupting the transactional database market. They explain why the document model became the "Buckminster Fuller" moment for modern apps and share lessons on scaling from "web-scale" memes to mission-critical…
❤2
📚 ClickHouse не тормозит, но заставляет глаз дергаться. Materialized Views
Не буду обозревать эту статью. Она на 4 минутки и так можно прочесть 😎.
По сути автор жалуется, что материализованные представления в РСУБД и они же в Кликхаусе работают совершенно по другому 😲. Нужно отдельно про них читать и вникать в нюансы. Это прекрасно подчеркнуто в комментарии:
Мне даже добавить нечего. Всё, что вы знаете по РСУБД справедливо только для РСУБД. Представления, констрейнты, индексы и триггеры в других СУБД могут работать совсем не так, как вы ожидаете. Будьте к этому готовы 😉
Не буду обозревать эту статью. Она на 4 минутки и так можно прочесть 😎.
По сути автор жалуется, что материализованные представления в РСУБД и они же в Кликхаусе работают совершенно по другому 😲. Нужно отдельно про них читать и вникать в нюансы. Это прекрасно подчеркнуто в комментарии:
Когда вы имеете дело с продуктом, который на первый взгляд выглядит как типичная реляционная СУБД, но у которого, внезапно, первичный ключ не предполагает уникальности, вы не только вправе, но даже обязаны ожидать от него чего угодно.
Мне даже добавить нечего. Всё, что вы знаете по РСУБД справедливо только для РСУБД. Представления, констрейнты, индексы и триггеры в других СУБД могут работать совсем не так, как вы ожидаете. Будьте к этому готовы 😉
Хабр
ClickHouse не тормозит, но заставляет глаз дергаться. Materialized Views
Вы пришли из мира PostgreSQL, Oracle или MSSQL. Вы знаете: материализованное представление — это «замороженный» результат запроса. Удобно. Предсказуемо. Вы открываете документацию ClickHouse. Видите...
👍4
📚 Почему "достаточно хорошие2 облачные базы данных становятся риском для бизнеса?
В последнее время часто встречаются статьи исследований, которые делают аналитические и RnD агенства по заказу компаний разработчиков СУБД. Что CockroachLab, что Scylla сейчас. Почему в РФ нет такой практики? Такое ощущение, что люди сами себе аналитики и не хотят платить за исследования. Хотя по DevOps регулярно проводятся разные опросы и исследования.
Подниму этот вопрос на каких-нибудь конференциях и спрошу народ... Если не забуду 😊
Вернемся к статье. Главные тезис:
По сути это классическая ловушка. Система сейчас работает и всё ОК, но что будет через год-два, когда данных станет больше? Как поведет себя система? Спрогнозировать тяжело. Хотя вру, не тяжело. Дорого 💰 Попробуй выбить у руководство бюджет на подобные тесты 😊
Я сам переживал только последний вариант. Реально, пришел новый СТО и сказал всем перейти с БД Oracle. Это было давно, но всё-таки. Мы все массово всем банком пошли в новое будущее....
Никогда не видел, чтобы меняли СУБД исходя из каких-то технических ограничений или ошибок и т.д.
СУБД меняют только тогда, когда компания-разработчик "умерла" или ушла с рынка. Всё.
Довольно забавный вывод из статьи. Действительно проблема на лицо. Сейчас на хайпе PostgreSQL. Найти спеца по это СУБД очень легко. Понятное дело, что есть нюансы, но по крайне мере выбор есть. Найти специалиста по Valkey или MongoDB или YDB даже по Tarantool, а? Реально на рынке? Особенно если он не бывший сотрудник Яндекса или VK. Проблема в обучение специалистов технологиями 2-ого или 3-ого эшелона на лицо.
Как итог можно сказать следующее, что это статья не про базы данных, а про поведение компаний в разных ситуациях. Все архитектурные решения откладываются до тех пор, пока система не начинает приносить убытки.
В исследовании Futurum Group, выполненное по заказу ScyllaDB, рассматриваются расходы на облачные базы данных, проблемы с производительностью и причины миграции на другие системы.
В последнее время часто встречаются статьи исследований, которые делают аналитические и RnD агенства по заказу компаний разработчиков СУБД. Что CockroachLab, что Scylla сейчас. Почему в РФ нет такой практики? Такое ощущение, что люди сами себе аналитики и не хотят платить за исследования. Хотя по DevOps регулярно проводятся разные опросы и исследования.
Подниму этот вопрос на каких-нибудь конференциях и спрошу народ... Если не забуду 😊
Вернемся к статье. Главные тезис:
У многих команд с текущей облачной БД всё "вроде бы нормально", но уверенности в будущем нет. 33% респондентов довольны текущей конфигурацией, но при этом 38% опасаются, что их нынешняя база не справится с будущими техническими требованиями, включая рост данных, AI/ML-нагрузки и новые требования по соответствию. То есть сегодня система ещё устраивает, а завтра уже может стать проблемой.
По сути это классическая ловушка. Система сейчас работает и всё ОК, но что будет через год-два, когда данных станет больше? Как поведет себя система? Спрогнозировать тяжело. Хотя вру, не тяжело. Дорого 💰 Попробуй выбить у руководство бюджет на подобные тесты 😊
Решение о смене БД редко принимается “рационально”.
Обычно это:
👉 не меняем ➡️ потому что работает
👉 терпим ➡️ потому что высокая цена миграции
👉 меняем ➡️ когда пришёл новый CTO
Я сам переживал только последний вариант. Реально, пришел новый СТО и сказал всем перейти с БД Oracle. Это было давно, но всё-таки. Мы все массово всем банком пошли в новое будущее....
Никогда не видел, чтобы меняли СУБД исходя из каких-то технических ограничений или ошибок и т.д.
СУБД меняют только тогда, когда компания-разработчик "умерла" или ушла с рынка. Всё.
Замкнутый круг
экономим ресурсы ➡️падает производительность
➡️ не хватает экспертизы ➡️ не можем оптимизировать
➡️ система кажется плохой ➡️ но менять дорого ➡️ работаем с тем, что есть
Довольно забавный вывод из статьи. Действительно проблема на лицо. Сейчас на хайпе PostgreSQL. Найти спеца по это СУБД очень легко. Понятное дело, что есть нюансы, но по крайне мере выбор есть. Найти специалиста по Valkey или MongoDB или YDB даже по Tarantool, а? Реально на рынке? Особенно если он не бывший сотрудник Яндекса или VK. Проблема в обучение специалистов технологиями 2-ого или 3-ого эшелона на лицо.
Как итог можно сказать следующее, что это статья не про базы данных, а про поведение компаний в разных ситуациях. Все архитектурные решения откладываются до тех пор, пока система не начинает приносить убытки.
The New Stack
Why “good enough” cloud databases are becoming a business risk
Research finds 38% of tech leaders doubt their database can handle future AI workloads, yet most wait for a crisis before migrating.
❤1
📚 DuckDB использует реляционную базу данных для решения классической проблемы «небольших изменений» в системах хранения данных.
DuckDB предлагает неожиданный поворот в архитектуре lakehouse.
Вкратце, они решили вернуть в lakehouse… классическую реляционную базу данных. Но используют её не для хранения данных, а для хранения метаданных и обработки мелких изменений .
Казалось, а зачем? Проблема современных lakehouse (Iceberg, Delta и др.) в том, что они плохо справляются с маленькими изменениями. Добавили пару строк - получили новый файл или обновили метаданные - сделали лишние операции с хранилищем.
❌В итоге:
👉 много мелких файлов
👉 лишние IO
👉 падение производительности
DuckDB предлагает следующее:
1️⃣ сначала писать изменения в обычную SQL-БД
2️⃣ накапливать их
3️⃣ и только потом батчами выгружать в Parquet
✅Что это даёт:
👉 меньше файлов
👉 меньше накладных расходов
👉 данные записываются быстрее
По сути, это попытка сбалансировать два мира:
гибкость lakehouse + строгость и эффективность классических СУБД
Мне кажется это никак не революция, а какой-то шаг назад, чтобы чуть подумать и потом сделать более осознанный шаг вперед. Это промежуточная конструкция.
Данный "костыль" поднимает новые вопросы
🤔 не станет ли RDBMS новым узким местом?
🤔 не усложняется ли архитектура?
🤔 не теряется ли идея serverless?
DuckDB аккуратно подталкивает индустрию к мысли, что будущее не в чистом lakehouse, а в гибридных решениях.
DuckDB предлагает неожиданный поворот в архитектуре lakehouse.
Вкратце, они решили вернуть в lakehouse… классическую реляционную базу данных. Но используют её не для хранения данных, а для хранения метаданных и обработки мелких изменений .
Казалось, а зачем? Проблема современных lakehouse (Iceberg, Delta и др.) в том, что они плохо справляются с маленькими изменениями. Добавили пару строк - получили новый файл или обновили метаданные - сделали лишние операции с хранилищем.
❌В итоге:
👉 много мелких файлов
👉 лишние IO
👉 падение производительности
DuckDB предлагает следующее:
1️⃣ сначала писать изменения в обычную SQL-БД
2️⃣ накапливать их
3️⃣ и только потом батчами выгружать в Parquet
✅Что это даёт:
👉 меньше файлов
👉 меньше накладных расходов
👉 данные записываются быстрее
По сути, это попытка сбалансировать два мира:
гибкость lakehouse + строгость и эффективность классических СУБД
мы слишком увлеклись “файловой” архитектурой lakehouse и забыли, что у СУБД уже давно есть решения для транзакций, метаданных и мелких операций.
Мне кажется это никак не революция, а какой-то шаг назад, чтобы чуть подумать и потом сделать более осознанный шаг вперед. Это промежуточная конструкция.
Данный "костыль" поднимает новые вопросы
🤔 не станет ли RDBMS новым узким местом?
🤔 не усложняется ли архитектура?
🤔 не теряется ли идея serverless?
DuckDB аккуратно подталкивает индустрию к мысли, что будущее не в чистом lakehouse, а в гибридных решениях.
The Register
DuckDB uses RDBMS to attack classic 'small changes' problem in lakehouses
: Batching teensy changes in chunks creates massive performance boost, DuckDB Labs team claims
❤2
📚 Как Redis Auto Failover повышает отказоустойчивость наших БД
Классная статья про адаптацию опенсор версии Redis под требования реального мира. Кластер Redis является хорошим решением, но не идеальным. Если у вас одномоментно выходит из строя кворум мастеров, то кластер считается разваленным, даже если реплики с нужными данными живы.
Ребята из WB прикрутили свой дополнительный механизм Auto Failover поверх Redis Cluster. Он очень похож на слой координации, аналогичный DCS (Distributed Configuration Store).
Идея хорошая. Я о подобном писал недавно.
Надеюсь, что WB выложат свой доработку в opensource.
Классная статья про адаптацию опенсор версии Redis под требования реального мира. Кластер Redis является хорошим решением, но не идеальным. Если у вас одномоментно выходит из строя кворум мастеров, то кластер считается разваленным, даже если реплики с нужными данными живы.
Ребята из WB прикрутили свой дополнительный механизм Auto Failover поверх Redis Cluster. Он очень похож на слой координации, аналогичный DCS (Distributed Configuration Store).
Идея хорошая. Я о подобном писал недавно.
Надеюсь, что WB выложат свой доработку в opensource.
Хабр
Как Redis Auto Failover повышает отказоустойчивость наших БД
Введение Привет! Меня зовут Иван Откидач, я DevOps-инженер в команде DBA. Моя основная специализация — NoSQL-базы данных, в частности Redis и MongoDB. С каждым месяцем количество Redis, находящихся на...
👍3
📚 NoSQL Data Modeling Explained with DynamoDB Single Table Design
Очень показательная идея из статьи про DynamoDB:
Я всё хочу погрузиться в идею проектирования нереляционных схем данных, но что-то никак повода не найду. Мне самому тяжело понять весь профит от такого проектирования. Думаю это статья будет драйвером, которая сподвигнет меня сесть за эту тему.
📊 Как бы решили задачу в реляционной БД
Допустим, у нас сервис поиск пациентов через платный API ($5 за запрос).
Нам нужно:
👉не платить повторно за одинаковый поиск
👉хранить историю
👉считать биллинг
В классической СУБД (например, PostgreSQL) мы бы сделали:
✅таблица patients
✅таблица search_requests
✅таблица billing
И далее классика:
Данные нормализуем ➡️ нужное собираем запросом
➕ гибкость
➕ можно добавлять новые сценарии
➖ больше JOIN
➖ нагрузка растёт с объёмом
⚡️ Как это решается в NoSQL (например, Amazon DynamoDB)
Мы заранее думаем:
👉 как будем искать?
👉 как проверять “уже был такой запрос”?
👉 как считать биллинг?
И делаем одну таблицу, например:
И рядом:
👉 теперь:
❇️проверка кэша ➡️ 1 запрос
❇️получение результата ➡️ 1 запрос
❇️биллинг ➡️ 1 запрос
Без JOIN вообще.
🧠 Где ключевой сдвиг мышления
⚖️ Что стало лучше
✔️ быстрее (меньше round-trip)
✔️ дешевле (меньше операций)
✔️ проще на чтение (всё рядом)
⚠️ Что стало хуже
❌ почти нет гибкости
❌ сложно добавить новый тип запроса
❌ дублирование данных
❌ ошибки в модели очень дорогие
🎯 Итого
Идея красивая, но надо будет на цифрах это всё проверить 😊
Очень показательная идея из статьи про DynamoDB:
в NoSQL ты проектируешь не таблицы - ты проектируешь запросы.
Я всё хочу погрузиться в идею проектирования нереляционных схем данных, но что-то никак повода не найду. Мне самому тяжело понять весь профит от такого проектирования. Думаю это статья будет драйвером, которая сподвигнет меня сесть за эту тему.
📊 Как бы решили задачу в реляционной БД
Допустим, у нас сервис поиск пациентов через платный API ($5 за запрос).
Нам нужно:
👉не платить повторно за одинаковый поиск
👉хранить историю
👉считать биллинг
В классической СУБД (например, PostgreSQL) мы бы сделали:
✅таблица patients
✅таблица search_requests
✅таблица billing
И далее классика:
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 ты обязан собрать их заранее
Идея красивая, но надо будет на цифрах это всё проверить 😊
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
NoSQL Data Modeling Explained with DynamoDB Single Table Design
Get your data model wrong and everything downstream pays for it.
❤2
🎥 ClickHouse в 2026: сценарии, сильные стороны, лучшие практики
Видеознакомство с Кликом от Алексея Белозерского из ВК.
Приятный вебинар 🙂 Чтобы понять нишу и основные задачи Клика - супер! Советую глянуть...
Видеознакомство с Кликом от Алексея Белозерского из ВК.
Приятный вебинар 🙂 Чтобы понять нишу и основные задачи Клика - супер! Советую глянуть...
VK Видео
ClickHouse в 2026: сценарии, сильные стороны, лучшие практики
Что будет на вебинаре: - Применение ClickHouse в архитектуре современных дата-платформ (Data Warehouse / Data Lakehouse) - Устройство ClickHouse: что под капотом и что нужно понимать аналитику и инженеру данных - Типичные ошибки при работе с ClickHouse …
❤1
🎦 Avito Database meetup
Основные доклады
Меня больше всего заинтересовал 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
Однако:
Основные доклады
🕚 Как мы прошли путь от разрозненных Ceph кластеров к единой платформе с 100 000+ бакетов;
🕚 Почему нам не подошла FoundationDB и чем удивила Cassandra 5;
🕚 Как мы предоставляем базы данных с чувствительными данными внутри DBaaS
Меня больше всего заинтересовал 2-ой доклад. Про сравнение FoundationDB vs Cassandra 5.
И так, Авито искали автошардируемую базу данных,
чтобы заменить сложную инфраструктуру с MongoDB.
В текущей архитектуре:
👉 используется MongoDB
👉 сотни шардов / тысячи инстансов
👉 self-sharding (логика на стороне сервиса)
данные шардуются не БД, а приложением
🔥 последствия:
👉сложная логика в коде
👉сложные миграции
👉дорого по ресурсам (x4 из-за реплик и бэкапов)
🎯 Что хотели получить
🔸 автошардинг “из коробки”
🔸 простой кластер (желательно masterless)
🔸 меньше инфраструктуры
🔸 open-source лицензия
🔸 горизонтальное масштабирование
🔸 мульти-DC
🧠 Что показали тесты
Cassandra
FoundationDB
🏆 Победитель - Cassandra
Однако:
Cassandra победила как решение конкретной задачи (замена многосотшардовой MongoDB)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2