Судьба тех кто завалит предзащиты по НИР!

С пятницей!

#mems

📚Introducing Valkey Admin: Visual Cluster Management for Valkey 2026-02-25 · Allen Helton, Arseny Kostenko

Valkey Admin - новый инструмент с графическим интерфейсом для визуального управления кластерами Valkey.

Какая классная тема! Первая opensource GUI для Valkey! Проект пока на очень ранее стадии, но надеюсь они доведут его до ума. Я обожаю всяческие графические управляшки. Супер! Буду обязательно следить за проектом.

Написан на TypeScript + JavaScript

Текущие особенности:

👉 Визуализация топологии кластера
👉 Мониторинг узлов
👉 Управление ключами (просмотр, редактирование, удаление)
👉 Диагностика производительности
👉 Встроенный CLI

В будущем планируется веб-версия. RedisInsight подвинься...

📚 ClickHouse не тормозит, но заставляет глаз дергаться. Materialized Views

Не буду обозревать эту статью. Она на 4 минутки и так можно прочесть 😎.

По сути автор жалуется, что материализованные представления в РСУБД и они же в Кликхаусе работают совершенно по другому 😲. Нужно отдельно про них читать и вникать в нюансы. Это прекрасно подчеркнуто в комментарии:

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

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

Пора начинать трудиться! Вперед на грядки!

С пятницей!

#mems

📚 Почему "достаточно хорошие2 облачные базы данных становятся риском для бизнеса?

В исследовании Futurum Group, выполненное по заказу ScyllaDB, рассматриваются расходы на облачные базы данных, проблемы с производительностью и причины миграции на другие системы.

В последнее время часто встречаются статьи исследований, которые делают аналитические и RnD агенства по заказу компаний разработчиков СУБД. Что CockroachLab, что Scylla сейчас. Почему в РФ нет такой практики? Такое ощущение, что люди сами себе аналитики и не хотят платить за исследования. Хотя по DevOps регулярно проводятся разные опросы и исследования.

Подниму этот вопрос на каких-нибудь конференциях и спрошу народ... Если не забуду 😊

Вернемся к статье. Главные тезис:

У многих команд с текущей облачной БД всё "вроде бы нормально", но уверенности в будущем нет. 33% респондентов довольны текущей конфигурацией, но при этом 38% опасаются, что их нынешняя база не справится с будущими техническими требованиями, включая рост данных, AI/ML-нагрузки и новые требования по соответствию. То есть сегодня система ещё устраивает, а завтра уже может стать проблемой.

По сути это классическая ловушка. Система сейчас работает и всё ОК, но что будет через год-два, когда данных станет больше? Как поведет себя система? Спрогнозировать тяжело. Хотя вру, не тяжело. Дорого 💰 Попробуй выбить у руководство бюджет на подобные тесты 😊

Решение о смене БД редко принимается “рационально”.
Обычно это:
👉 не меняем ➡️ потому что работает
👉 терпим ➡️ потому что высокая цена миграции
👉 меняем ➡️ когда пришёл новый CTO

Я сам переживал только последний вариант. Реально, пришел новый СТО и сказал всем перейти с БД Oracle. Это было давно, но всё-таки. Мы все массово всем банком пошли в новое будущее....
Никогда не видел, чтобы меняли СУБД исходя из каких-то технических ограничений или ошибок и т.д.
СУБД меняют только тогда, когда компания-разработчик "умерла" или ушла с рынка. Всё.

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

Довольно забавный вывод из статьи. Действительно проблема на лицо. Сейчас на хайпе PostgreSQL. Найти спеца по это СУБД очень легко. Понятное дело, что есть нюансы, но по крайне мере выбор есть. Найти специалиста по Valkey или MongoDB или YDB даже по Tarantool, а? Реально на рынке? Особенно если он не бывший сотрудник Яндекса или VK. Проблема в обучение специалистов технологиями 2-ого или 3-ого эшелона на лицо.

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

📚 DuckDB использует реляционную базу данных для решения классической проблемы «небольших изменений» в системах хранения данных.

DuckDB предлагает неожиданный поворот в архитектуре lakehouse.

Вкратце, они решили вернуть в lakehouse… классическую реляционную базу данных. Но используют её не для хранения данных, а для хранения метаданных и обработки мелких изменений .

Казалось, а зачем? Проблема современных lakehouse (Iceberg, Delta и др.) в том, что они плохо справляются с маленькими изменениями. Добавили пару строк - получили новый файл или обновили метаданные - сделали лишние операции с хранилищем.

❌В итоге:
👉 много мелких файлов
👉 лишние IO
👉 падение производительности

DuckDB предлагает следующее:
1️⃣ сначала писать изменения в обычную SQL-БД
2️⃣ накапливать их
3️⃣ и только потом батчами выгружать в Parquet

✅Что это даёт:
👉 меньше файлов
👉 меньше накладных расходов
👉 данные записываются быстрее

По сути, это попытка сбалансировать два мира:
гибкость lakehouse + строгость и эффективность классических СУБД

мы слишком увлеклись “файловой” архитектурой lakehouse и забыли, что у СУБД уже давно есть решения для транзакций, метаданных и мелких операций.

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

Данный "костыль" поднимает новые вопросы
🤔 не станет ли RDBMS новым узким местом?
🤔 не усложняется ли архитектура?
🤔 не теряется ли идея serverless?

DuckDB аккуратно подталкивает индустрию к мысли, что будущее не в чистом lakehouse, а в гибридных решениях.

📚 Как Redis Auto Failover повышает отказоустойчивость наших БД

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

Ребята из WB прикрутили свой дополнительный механизм Auto Failover поверх Redis Cluster. Он очень похож на слой координации, аналогичный DCS (Distributed Configuration Store).

Идея хорошая. Я о подобном писал недавно.

Надеюсь, что WB выложат свой доработку в opensource.

Психология - страшная вещь!

С пятницей!

#mems

🎥 ClickHouse в 2026: сценарии, сильные стороны, лучшие практики
Видеознакомство с Кликом от Алексея Белозерского из ВК.

Приятный вебинар 🙂 Чтобы понять нишу и основные задачи Клика - супер! Советую глянуть...

Сессия на подходе

С пятницей!

#mems

🎦 SmartData 2025. Запускаем YugabyteDB в production, Василий Осадчий
Презентация

Если выкинуть детали, то главный вывод вообще не про конкретную СУБД.

Он про смену традиционного реляционного мышления при проектировании схемы данных.

Команда хотела "PostgreSQL, но распределённый". На рынке есть много продуктов, которые предоставляют данные функции.

Главный слом происходит в проектировании схемы данных.

В привычной (single-node) модели:
👉 primary key = просто уникальный идентификатор
👉 индексы = оптимизация
👉 где лежат данные - неважно

В распределённой базе:
👉 primary key = shard key
👉 он определяет, где физически лежат данные
👉 ошибка в нём = fan-out по всему кластеру

И дальше начинается цепочка изменений:
Запрос - это уже не просто SQL.Это:
👉 сколько нод будет задето
👉 будет ли scatter
👉 не создаём ли hotspot

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

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

Итог:

Распределённые СУБД — это не «галочка HA + scaling».
Это другая модель проектирования.

Single-node мышление — «как выполнить запрос»
Distributed мышление — «как разложить данные, чтобы запрос был дешёвым»

И именно это - главный барьер при переходе, а не выбор технологии. Хотя очень приятно увидеть пример с Distributed SQL СУБД. Очень классно 😊

Иногда на экзамене люди неожиданно меняются и от этого бывает немного дискомфортно.

С пятницей!

#mems

🎦 Что должен знать каждый backend про N+1, lazy preload и производительность / Евгений Демин #83

Разберу довольно интересное интервью с Евгением Демином - Ruby-разработчик и автор нескольких популярных open source библиотек, которые решают проблемы с базами данных, валидацией и производительностью.

Меня зацепило это видео тем, что в нем поднимаются проблемы конситентности на уровне БД и Приложения.

Видимо что-то навеяло мне после недели зачетов и выслушивания 100500 вариантов расшифровки аббревиатур ACID, BASE, LSM, PAXOS, GOSSIP, RAFT

❇️ База данных не должна верить приложению на слово
Важная мысль для всех, кто работает с базами данных:

многие проблемы качества данных рождаются не внутри СУБД, а на границе между приложением и БД.

Типичный пример: в приложении написано, что поле name обязательно. Но в самой таблице нет NOT NULL. Пока все данные проходят через основной backend, то вроде бы всё хорошо. А потом появляется импорт, скрипт, bulk insert, отключённый callback или второй сервис. В итоге в базе оказываются данные, которые приложение считало невозможными.

То же самое с уникальностью. Проверка на уровне приложения удобна для пользовательского сообщения об ошибке, но от "race condition" защищает только UNIQUE INDEX или UNIQUE CONSTRAINT. Поэтому хорошее правило простое:

application validation - это про UX,
database constraint - это про целостность данных.

Интересна и тема schema as code. В Rails актуальная схема базы хранится в репозитории, и это открывает дорогу для автоматических проверок. Можно сравнивать модель приложения с реальной структурой БД, искать nullable-поля там, где бизнес-логика требует обязательности, проверять уникальные индексы, внешние ключи, несовпадение типов PK и FK.

Отдельная тема - N+1. Часто говорят: "это проблема ORM". Но на самом деле запросы в цикле можно написать и без ORM. ORM просто делает эту ошибку менее заметной. Для DB-специалиста здесь важнее не спор "ORM или SQL руками", а вопрос,

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

❇️ Главный вывод из интервью такой:

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

🔑Если инвариант живёт только в коде приложения, он живёт до первого обходного пути.

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

С пятницей!

#mems

📚«День СУБД 2026»: как «Диасофт» меняет подход к импортозамещению СУБД
📚 RuDB и Digital Q.DataBase: как в России развивают СУБД класса Enterprise

Разберу тандем статей от компании Диасофт.

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

Забавный факт, Диасофт вложила в пиар мероприятия и рекламу новой СУБД RuDB, но в профессиональных сообществах по базам данных ни одного коммента на этот счет. Даже на Хабре 0 комментов. Странно, не так ли? Давайте разберемся, что же нам презентовали.

❇️ После «Дня СУБД 2026» Диасофт активно продвигает два связанных продукта:
👉 Digital Q.DataBase - коммерческую enterprise-СУБД для миграции с Oracle и Microsoft SQL Server.
🆕RuDB - бесплатную СУБД на базе PostgreSQL 18.2.

На первый взгляд возникает закономерный вопрос:

Зачем нужна RuDB, если на российском рынке уже есть Postgres Pro Standard, Tantor, Pangolin, Jatoba и другие PostgreSQL-based решения?

Если рассматривать RuDB как самостоятельный PostgreSQL-форк, её ценность около нулевая. Ниша уже занята более зрелыми игроками: с поддержкой, документацией, внедрениями, экспертизой и промышленной историей, поэтому как конкурент RuDB пока выглядит слабовато.

Предполагаю, что ставка Диасофта - не на RuDB и "«Ассоциацию Разработчиков СУБД", а на Digital Q.DataBase и механизм «Полиглот».

Идея "Полиглота" - предоставить слой совместимости с Oracle и Microsoft SQL Server: PL/SQL, T-SQL, системные функции, пакеты, привычную прикладную логику. То есть продавать не просто PostgreSQL, а снижение стоимости миграции с тяжёлых enterprise-СУБД.

Почему-то компания Диасофт в 2026 решили тему миграции сделать главной темой своих продуктов.

С моей колокольни, миграция была актуальна с 2022-2024 годах. Все, кто хотел мигрировать уже смигрировали. А те, кто остается на Oracle/MSSQL могут спокойно еще 5 лет сидеть и не париться. За весь ИТ-рынок говорить не буду, но тема миграции ушла из прайм-тайм давно.

Как я понял, Диасофт предлагаю следующую картину:

- RuDB = бесплатная PostgreSQL-compatible база / entry point
- Digital Q.DataBase = коммерческий enterprise-продукт
- Полиглот = ключевая технология миграции Oracle/MSSQL workloads

❗️RuDB сама по себе пока не выглядит сильной технологической необходимостью.

Если это просто ещё один PostgreSQL-based fork, проект рискует потеряться на перегретом рынке российских СУБД.
Но в связке с Digital Q.DataBase логика начинает виднеться.
Ставка Диасофта - это не на "мы сделали ещё один PostgreSQL", а:

"мы дадим путь миграции с Oracle/MS SQL Server без тотального переписывания прикладного кода»"

Нужно ли это клиентам? Маркетологи считают, что да 😊
Будем верить в ребят! 👀