📚 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 без тотального переписывания прикладного кода»"

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

📚 Как-то попросили меня разобрать статью: Direct I/O for Cassandra Compaction: Cutting p99 Read Latency by 5x

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

В статье показывается, что compaction в Cassandra может заметно портить p99 read latency не только потому, что потребляет диск или CPU, а потому что вмешивается в работу Linux page cache.

Compaction читает большие объёмы SSTable-данных, которые часто нужны ровно один раз: прочитать старые файлы, собрать новые, старые потом удалить. Но при обычном buffered I/O эти страницы всё равно попадают в page cache и могут вытеснять оттуда действительно горячие данные пользовательских запросов.

Решение, которое обсуждается в статье, читать данные для compaction через Direct I/O, то есть мимо page cache. По сути, база данных говорит операционной системе:

"Эй, БРО! Здесь не надо мне помогать с кэшированием, я лучше знаю семантику этой операции".

Мне эта статья кажется важной не только как заметка про Cassandra. Она хорошо подсвечивает более общий тезис: универсальные механизмы ОС иногда начинают мешать СУБД, потому что ОС видит страницы, файлы и процессы, а база данных видит совсем другое - hot read path, compaction, SSTable, tombstone, TTL, foreground-запросы и background housekeeping.

В этом месте невольно вспоминается идея DBOS (DataBase-oriented Operating System). Это, конечно, гораздо более радикальная постановка вопроса, чем Direct I/O для compaction, но логика такая же. Если управление состоянием, историей изменений, восстановлением и фоновыми процессами становится центральной задачей системы, то, возможно, системный слой будущего должен быть не просто process/file-oriented, а database-aware.

В этом смысле статья не только про Cassandra. Она про границу между СУБД и операционной системой - и про то, как эта граница постепенно становится всё менее очевидной 🧐.

Лето! Этим всё сказано!

С пятницей!

#mems

📚 IBM invites CockroachDB to infest its mainframes with PostgreSQL

С моей колокольни, новость - бомба 💥💥💥

IBM объявила партнёрство: CockroachDB теперь предлагается как PostgreSQL-совместимая распределённая СУБД для LinuxONE, Linux on Z, Power Systems и OpenShift.

Сделка века, не иначе 😊 Очень продуманный и хитрый ход. Причем одинаково полезный как для IBM, так и для Cockroach Lab.

Это не история про замену Db2 на CockroachDB (к сожалению, Db2 никогда не умрет 🧟). И это не про простой перенос старых mainframe-приложений в PostgreSQL-мир.
Это попытка IBM закрыть пробел в портфеле, дать клиентам cloud-native distributed SQL для новых приложений внутри привычной экосистемы.

Главный фича - закрыть требование к масштабированию систем из коробки и дать людям знакомый синтаксис.

CockroachDB похожа на PostgreSQL только на уровне интерфейса. Под капотом - другая распределённая СУБД. А миграция enterprise-систем, это целая эпопея! Даже простой SELECT FOR UPDATE может вести себя иначе, и это всплывёт только на проде.

Самое сложное обычно в другом:
🧩 SQL-диалект
🧩 хранимые процедуры
🧩 транзакционная семантика
🧩 драйверы
🧩 блокировки
🧩 эксплуатационные привычки
🧩 прикладной код вокруг СУБД

Поэтому обещания "модернизации без переписывания" всегда стоит читать осторожно (это вам не Диасофт).

Итого:
✅ Для новых cloud-native приложений в инфраструктуре IBM - CockroachDB шикарный вариант.

❌ Для зрелых Db2/mainframe-нагрузок - это не волшебный мост в PostgreSQL-мир.

🎦 Осипов, Рыбак -- #1 (2026)

Не могу пройти мимо беседы двух умных и уважаемых мной людей о мире баз данных.

Не буду делать детальный обзор. Алексей в своем канале уже дал полную текстовую расшифровку
❗️Пост 1
❗️Пост 2

Даже на Хабре есть текстовая расшифровка

Я хочу подсветить тезисы, которые задели лично меня:
👉 До эпохи NoSQL все чаты хранились в MySQL
👉 Discord хранит свои данные в ScyllaDB
👉 Есть ряд научный статей по разработке эффективного алгоритма удаления данных по TTL
👉 Accord для Cassandra сделала команда Apple. (У меня два студента в этого году пишут НИР по этой теме)
👉 CSO (безопасники) выбирают базу данных для проекта.
👉 Подавляющее большинство пользователей Redis без AOF без реплики. Просто мемкэш. Резиновый КЭШ.