📚 Попалась прикольная PDF-ка от VK: Тренды развития рынка СУБД

VK провели исследование рынка и обозначили 5 трендов рынка СУБД.

⚠️Честно говоря, я бы этот отчет разобрал с кем-то на видео, т.к. очень много тезисов в отчете откровенно спорные и я с большинством не согласен. Вы не подумайте, данный отчет отнюдь не лживый, но писать о том, что это тренд - перебор. Найду оппонентов - сделаем небольшой стрим. Если кто хочет поучаствовать в разборе отчета, то пишите!⚠️

А пока просто сухие факты

1️⃣Уход от монолитной инфраструктуры данных;

ВК считает, что эра "вендор-лока" прошла и мы пришли к мультивендорной архитектуре.

2️⃣Рост требований к безопасности и управлению рисками;

Высокий уровень безопасности - ключевой критерий выбора СУБД

3️⃣векторные индексы в существующих СУБД под AI-сценарии;

У компаний растёт интерес к AI/LLM-сценариям: поиск по смыслу, RAG, рекомендации, поиск похожих изображений, гибридный поиск. Однако новую БД они вводить не хотят, поэтому используют возможности текущих (pgvector)

4️⃣ИИ для демократизации данных и для управления дата-инфраструктурой;

ИИ-ассистенты и агенты для работы с данными

5️⃣интерес к HTAP для real-time аналитики

Текущий стек: OLTP-база + Kafka/стриминг + ClickHouse. Компаниям кажется он довольно сложный и избыточный. HTAP должен стать решением всех проблем.

Очень спорный отчет, но зерно истины в нём есть.

Забыл всех поздравить с пятницей 🥲 Ну, тогда с новой рабочей неделей!

#mems

Небольшой пост от коллег из разработки SereneDB. Я как-то писал о том, что они привлекли кучу инвестиций и все фаундеры - россияне. Сам стартап немецкий 🇩🇪.

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

Напомню, что SereneDB - The First Real-Time Search Analytics Database

Мы в SereneDB в марте мы приняли участие в бенчмарке Search Benchmark Game с нашим поисковым движком IResearch (С++ альтернатива Lucene и Tantivy). Проект пока не слишком известен, но так получилось, что мы выиграли бенчмарк.
Особенно приятно было, что мейнтейнеры Tantivy лично проверили результаты и приняли коммит.

Мы подумали, что возможно было бы интересно почитать про то, как устроена внутренняя кухня поискового движка.
Пару месяцев спустя, родилась техническая ретроспектива-разбор “Search Optimization Journey” из 5 частей, про оптимизации которые помогли нам добиться таких результатов:
Collecting top-K candidates
Block scoring
Norm gathering optimization
Lazy Two Phase Queries
Adaptive posting list format

Надеюсь, вам будет интересно, если понравилось, то поставьте нам звездочу!
Наш репозиторий: https://github.com/serenedb/serenedb/ (код движка в libs/iresearch)

Databricks объявил конец эпохи пайплайнов.

На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных. Идея радикальная: приложения, BI-системы и AI-агенты работают с одним источником данных напрямую, без CDC, ETL и бесконечных репликаций между OLTP и аналитическими хранилищами.

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

PostgreSQL → CDC → Kafka → ETL → Data Warehouse → BI → AI

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

Ответ Databricks — хранить операционные и аналитические данные в одном месте. В основе подхода лежит Lakebase, PostgreSQL-совместимая система, работающая поверх объектного хранилища и интегрированная с Lakehouse. Компания называет это первым LTAP-подходом, который должен заменить как традиционные ETL-процессы, так и многочисленные реплики баз данных.

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

Но сам тренд выглядит очень интересным. Если раньше индустрия спорила, что лучше — Data Lake или Data Warehouse, то теперь главный вопрос звучит иначе:

Нужно ли вообще перемещать данные между системами, если все сервисы, аналитика и AI могут работать поверх одной копии данных?

Похоже, именно вокруг этого вопроса и будет строиться следующая большая битва в мире Data Engineering.

@tldr_data

📚 Valkey 9.1 In-Memory Data Store Released with Database-Level ACLs

Я понимаю, что посты про Valkey мало кому интересны, но эта СУБД важна лично для меня, т.к. я целый курс про неё написал. Уже прошло 3 запуска и скоро планируется 4-ый. Обязательно включу в него все фичи релиза 9.1.

И так, к статье...

Вышел Valkey 9.1. Там нет каких-то прям мегафич. Этот релиз больше направлен на прокачку эксплуатационной зрелости. Хотя как и в любом другом релизе, Valkey стал еще быстрее! Еще и еще! 🤪

👉 database-level ACL. В релизе 9.0 ввели поддержку множества база данных в одном кластере Valkey. Однако ACL был общий на все базы. Теперь же ACL можно настроить под каждую базу данных кластера. Для multi-tenant-сценариев и изоляции приложений это давно напрашивалось. И да, напомню, что баз может быть до 15 штук.

👉 улучшение безопасности. Lua вынесли из ядра в отдельный модуль. Если скрипты не нужны, "поверхность атаки" (как же меня прёт от этого словосочетания) можно уменьшить. TLS тоже стал удобнее для production: Valkey теперь показывает сроки действия сертификатов через INFO и умеет перезагружать сертификаты в фоне без простоя.

👉 Новые метрики по наблюдаемости (observability). Появились метрики использования main thread и I/O threads, потому что обычная CPU utilization для Valkey может быть обманчивой. Плюс добавили JSON logging - мелочь, но очень полезная для нормальной интеграции с системами логирования.

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

Мем на все времена!

С пятницей!

#mems

📚 Что такое DWH (КХД) и как работает корпоративное хранилище данных

Это большой вводный материал про DWH, где рассказывается в n-раз что такое корпоративное хранилище данных, зачем оно бизнесу, как туда попадают данные, ETL/ELT, LSA, Kimball, Inmon и Data Vault.

✅Из хорошего:
В не даны базовые понятия для начинающих аналитиков, студентов, менеджеров, который только пытается понять, зачем ему хранилище данных, это вполне полезный ликбез. Особенно удачно показана мысль, что DWH - это не "ещё одна большая база", а отдельный аналитический контур: источники → загрузка → очистка → единая модель → витрины → BI.

❌ Из минусов
Почти нет разговора о главных болях реального DWH: качестве данных, lineage, SLA загрузок, инкрементальности, CDC, backfill, late arriving data, версионировании справочников, стоимости хранения, деградации витрин, тестировании пайплайнов и владении данными. То есть архитектурные термины названы, но эксплуатационная сложность хранилища почти не раскрыта.

Ещё спорный момент, местами DWH подаётся слишком линейно и красиво: собрали данные, почистили, положили в витрины, подключили BI - и бизнес счастлив. В реальности корпоративное хранилище часто начинается не с выбора базы данных (ClickHouse) или схемы слоёв, а с неприятных вопросов: кто владелец показателя, почему в CRM и ERP разные цифры, какой источник является мастер-системой, кто отвечает за качество данных и что делать, когда отчёт «не сходится».

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

В банке около 8 независимых баз данных, где эти телефоны хранятся. В дополнении к этому в одной базе могут быть еще 5-10 таблиц, куда независимыми сервисами сохраняются эти номера. За лет 15 такой работы эти телефоны могли устареть, сами клиенты закрыть счета и т.д.

Мы всеми главами ИТ-департаментов 5 месяцев собирались раз в неделю на совещании и делились прогрессом по задаче. Планов по синхронизации номеров придумало было тьма-тьмущая. Часов потраченных на верификацию всеми отделами я даже подсчитать не могу. Знаете, что в итоге? Ничего. Просто забили болт. Пришли более приоритетные задачи и эта задача ушла в бэглог навсегда.

Зановес

Мораль: внедрение DWH должны делать отдельные новые люди! Заниматься DWH текущим персоналом - невозможно. Слишком много сил уходит на этап подготовки. Чтобы привести текущие потоки данных к чему-то общему требуются заряженные и поглощенные только этим проектом люди!

Эх, какой был фильм в своё время! Сейчас так не снимают.

С пятницей!

#mems

Немного нецензурное видео, но очень полезное! 👍

Я бы этим видео подытожил первые 2 курса любого технического ВУЗа или 3 курса колледжа.

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

Советую их закрыть 😉

📚 Percona celebrates 20th birthday with new foundation — and a goat cake

Percona на 20-летии, похоже, решила вернуться к своей главной идее - это экспертной поддержке open source СУБД.

Компания раньше инвестировала в собственную DBaaS-платформу Everest, которая теперь стала open source, но основная выручка и репутация Percona всё равно строились вокруг консалтинга, т.е. сопровождения сложных database-инфраструктур, миграций, обновлений, бэкапов, производительности и отказоустойчивости.

❇️ Новый слоган Percona - "The Way Is Open". Это не только про open source как идеологию, а про вполне практичную вещь, борьбу с vendor lock-in. Открытые СУБД дают компаниям больше свободы, можно менять инфраструктуру, уходить из облака, мигрировать между платформами и не зависеть полностью от одного вендора.

❇️ Отсюда же поддержка Valkey. Кстати, Percona единственная компания, которая оказывают техподдержку по этой СУБД, а так же много инвестирует в развитие экосистемы Valkey. Для Percona это способ показать позицию, что если технология остаётся открытой и совместимой, её можно безопасно брать в production при наличии нормальной экспертизы и поддержки.

❇️ Интересен и их подход к AI: без попытки переименовать всё в "что-то + AI". AI рассматривается как инструмент для инженеров: быстрее анализировать тикеты, находить контекст, помогать с root cause analysis, мониторингом и аварийным восстановлением.

Базы данных становятся всё более критичными, гибридными и дорогими в сопровождении. И здесь ценность не только в продукте, а в экспертизе: кто поможет, когда PostgreSQL, MySQL, MongoDB или Valkey в production начинают вести себя не так, как в документации? 🥺

📚 Redis резко повернул в сторону AI-инфраструктуры.

Честно, не хотел делать про это пост, но почему-то многие новостные паблики это расфорсили по не понятной мне причине. Ладно, я тоже выскажу свое "диванное мнение".

Сначала Redis анонсирует Vector Sets - новую структуру данных для хранения embeddings и similarity search прямо внутри Redis. Затем LangCache - semantic cache для LLM-ответов, чтобы похожие запросы не гонять каждый раз в модель. А дальше всё это собирается в более крупную историю: Redis Iris / Context Engine - слой памяти, контекста и свежих данных для AI-агентов.

На первый взгляд выглядит логично. Redis всегда был быстрым in-memory слоем для приложений. Теперь эта же роль переупаковывается под LLM-приложения с доступ к актуальным бизнес-данным.

Но есть и вопрос: откуда такая внезапная щедрость?

Redis годами развивал экосистему довольно осторожно. А тут сразу целый набор AI-продуктов: Vector Sets, LangCache, Agent Memory, Context Retriever, Iris. Похоже, после изменения лицензии и появления Valkey Redis нужно заново доказать рынку, что коммерческий Redis - это не просто знакомый key-value store с другой лицензией, а новая платформа для AI-приложений.

Ах, да, все новые инструменты - коммерческие, т.е. платные 💰

Стратегически это попытка заново занять место в головах разработчиков. Раньше Redis был «быстрым кешем для приложений». Теперь он хочет стать "памятью для AI-агентов".

Вопрос только в том, поверит ли рынок, что это эволюция Redis, а не срочная AI-переупаковка чтобы успеть занять нишу в новых инфраструктурных проектах...

Пора отпусков продолжается! Надеюсь все подготовились к пляжному отдыху...

С пятницей!

#mems

💬 Возврат к автономным базам данных

Как только СУБД стали сложными промышленными системами, возникло естественное желание, а нельзя ли научить базу самой подстраиваться под нагрузку, выбирать настройки, диагностировать проблемы, чинить себя и снижать зависимость от ручной работы DBA? 🧐

На практике путь оказался не простым. До полноценной "автономной базы" индустрия шла через отдельные self-managing-функции: автоматический сбор статистики, advisors, tuning tools, автоматическое управление памятью, хранилищем, индексами и планами запросов. То есть шаги были, но чаще это были отдельные подсистемы, а не цельная автономная СУБД.

В 2017 году Oracle громко объявила Autonomous Database Cloud на Oracle OpenWorld, а в 2018 начала активно продвигать Autonomous Database как self-driving, self-securing и self-repairing cloud-сервис. Но автономные БД так и не стали универсальным стандартом рынка 😞. Скорее они остались важным направлением автоматизации, а не полной заменой DBA.

Почему создать по-настоящему автономную базу сложно? 🧐

Во-первых, нет простого критерия "сделай хорошо". Для одной нагрузки важнее latency, для другой throughput, для третьей стоимость, для четвёртой предсказуемость и отказоустойчивость.

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

В-третьих, автоматизация не отменяет скрытые затраты и vendor lock-in. Чем умнее managed-сервис, тем сложнее понять, что именно он делает внутри и насколько легко будет уйти на другую платформу.

В-четвёртых, передача контроля автоматике требует пересмотра модели безопасности и ответственности. Кто виноват, если AI-рекомендация сломала производительность? Кто отвечает, если автоматика выбрала не тот план, не тот индекс или не ту стратегию восстановления?

И главное:

Как обучить базу данных мыслить?

Однако тема снова оживает на фоне Kubernetes, managed services, autonomous databases и AI-агентов. Но вывод получается не в том, что DBA исчезает. Скорее наоборот: меняется сама роль DBA. Надсмотрщик за СУБД никуда не девается 😊

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

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

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

Хороший DBA будущего - это уже не просто "администратор базы". Это database architect / data infrastructure engineer: человек, который понимает СУБД, облака, Kubernetes, надёжность, производительность, стоимость и бизнес-критичность данных.

1️⃣ Why the need for humans won’t disappear in the age of autonomous databases
2️⃣ Autonomous agents have met their biggest challenge yet: The database

📚 Не хочу писать отдельные посты, поэтому просто разберу несколько интересных статей с Хабра 🙂

Масштабируй! Почему Cassandra 5 стала спасением, а FoundationDB прилегла в чулан
Спусти 3 месяца товарищи из Авито решили выпустить текстовую версию своего доклада с митапа от 1 апреля.
Статья набрала 9 лайков, поэтому можно смело сказать, что она так се. Если кому-то интересно освежить её в памяти, то можно пролистать... 🎩

«Лягут все», или почему у российских компаний проблемы с disaster recovery
Самая "вкусняшка" в комментариях к статье ☺️.
По сути одним из драйверов роста распределенные системы является страх отказа ЦОД. Поэтому все стараются распределить свою инфраструктуру на 2, 3 или даже больше ЦОДов. Люди тестируют миграцию, восстановление после отказа одного из ЦОД и т.д. Все это считается Disaster Recovery Plan. ✨

Как подметили в комментах зафиксирована масса случаев, когда сервисы крупных компаний не работали днями, неделями или даже месяцами 😨😱! И...ни чё, пережили как-то . Да, было грустно, но не смертельно🤪. Возникает мысль не слишком ли переоцениваем нужду в DR-сайте? Возможно стоит пересмотреть систему рисков. 🥸

Разбираемся с лицензией Redis. И что выбрать продуктовой команде
Как надоели люди, которые вспоминают KeyDB и пытаются его сунуть в какие-то сравнения. Ну, всё уже. Это мертвый проект ☠️. Ни будет ничего ⚰️. Забудьте уже о нем. Нет, автор опять что-то пытается доказать....
Короче, для РФ можно использовать и Redis и Valkey. Кому, что нравится больше. Я за Valkey конечно 😬

ObjectId против UUID: как выбор _id в MongoDB влияет на API, индексы и миграции
Прочел статью 2 раза и ничего не понял 🤨
"что такое хорошо и что такое плохо..."
Даже ИИшка не помогла 🙃
Единственное, что можно уловить:

"разработчики Монги придумали ObjectId. Какие молодцы эти ребята! Класс! "

Если кто-то что-то полезно из статьи извлечет, напишите мне