📚«День СУБД 2026»: как «Диасофт» меняет подход к импортозамещению СУБД
📚 RuDB и Digital Q.DataBase: как в России развивают СУБД класса Enterprise
Разберу тандем статей от компании Диасофт.
К сожалению, не смог присутствовать лично на "Дне СУБД", т.к. был в отпуске, но обойти эту тему нельзя, т.к. ребята решили заморочиться.
Забавный факт, Диасофт вложила в пиар мероприятия и рекламу новой СУБД RuDB, но в профессиональных сообществах по базам данных ни одного коммента на этот счет. Даже на Хабре 0 комментов. Странно, не так ли? Давайте разберемся, что же нам презентовали.
❇️ После «Дня СУБД 2026» Диасофт активно продвигает два связанных продукта:
👉 Digital Q.DataBase - коммерческую enterprise-СУБД для миграции с Oracle и Microsoft SQL Server.
🆕RuDB - бесплатную СУБД на базе PostgreSQL 18.2.
На первый взгляд возникает закономерный вопрос:
Если рассматривать 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-based fork, проект рискует потеряться на перегретом рынке российских СУБД.
Но в связке с Digital Q.DataBase логика начинает виднеться.
Ставка Диасофта - это не на "мы сделали ещё один PostgreSQL", а:
Нужно ли это клиентам? Маркетологи считают, что да 😊
Будем верить в ребят! 👀
📚 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 без тотального переписывания прикладного кода»"
Нужно ли это клиентам? Маркетологи считают, что да 😊
Будем верить в ребят! 👀
Хабр
«День СУБД 2026»: как «Диасофт» меняет подход к импортозамещению СУБД
21 апреля компания «Диасофт» провела первую в своей истории конференцию «День СУБД 2026». Мероприятие посетили более 250 экспертов: представители крупнейших банков, IT-разработчиков и интеграторов,...
👍3
📚🔴 Redis выглядит нормально. В этом и проблема.
Попалась забавная статья про старую, но всё ещё актуальную атаку на плохо защищённые Redis-серверы.
Сценарий примерно такой:
1️⃣ Redis доступен из недоверенной сети.
2️⃣ Аутентификации нет или она слабая.
3️⃣Атакующий подключается как обычный клиент.
4️⃣Через
5️⃣Заставляет Redis записать SSH-ключ в
6️⃣Возвращает настройки обратно.
7️⃣Redis продолжает работать как ни в чём не бывало.
В очередной раз кто-то выставил "голой попой" 🍑 СУБД в сеть интернет и словил вирус. Казалось бы, что тут нового?
И вот в этом главный смысл статьи:
➕ Процесс жив.
➕ Latency нормальная.
➕ Ключи на месте.
➕ Ошибок в логах почти нет.
⚠️ Но сервер уже может быть скомпрометирован на уровне ОС 🐞
Эксплуатационный урок в следующем, для Redis и Valkey безопасность - это контроль поверхности атаки(наконец-то получилось применять словосочетание "поверхность атаки", а то прочел об этом в умных ВУЗовских книжках, а применить было не где. И вот, удобный случай 😊.
Привила хорошеготона инженера:
❗️
❗️ доступ должен закрываться firewall/security groups;
AUTH/ACL должны быть включены;
❗️ опасные команды вроде
❗️ Redis не должен запускаться от root;
❗️ изменения
Главный вывод:
Попалась забавная статья про старую, но всё ещё актуальную атаку на плохо защищённые Redis-серверы.
Сценарий примерно такой:
1️⃣ Redis доступен из недоверенной сети.
2️⃣ Аутентификации нет или она слабая.
3️⃣Атакующий подключается как обычный клиент.
4️⃣Через
CONFIG SET меняет директорию и имя файла дампа.5️⃣Заставляет Redis записать SSH-ключ в
authorized_keys.6️⃣Возвращает настройки обратно.
7️⃣Redis продолжает работать как ни в чём не бывало.
В очередной раз кто-то выставил "голой попой" 🍑 СУБД в сеть интернет и словил вирус. Казалось бы, что тут нового?
И вот в этом главный смысл статьи:
Redis после компрометации может выглядеть абсолютно здоровым.
⚠️ Но сервер уже может быть скомпрометирован на уровне ОС 🐞
Эксплуатационный урок в следующем, для Redis и Valkey безопасность - это контроль поверхности атаки
Привила хорошего
❗️
bind должен быть настроен только на нужные интерфейсы;❗️ доступ должен закрываться firewall/security groups;
AUTH/ACL должны быть включены;
❗️ опасные команды вроде
CONFIG, SAVE, BGSAVE, MODULE, DEBUG, FLUSHALL, REPLICAOF должны быть ограничены;❗️ Redis не должен запускаться от root;
❗️ изменения
authorized_keys, cron, конфигов и неожиданные CONFIG SET должны попадать в мониторинг/аудит.Главный вывод:
Redis - это не "просто кеш". Это сетевой сервис, который при неправильной настройке может стать точкой входа в инфраструктуру для злых дядей 🤷♂️
Please open Telegram to view this post
VIEW IN TELEGRAM
Security Boulevard
Your Redis Server Looks Fine. That’s the Problem.
Introduction There’s an automated attack circulating right now that breaks into unprotected Redis servers, takes over the underlying machine, and then carefully puts everything back the way it found it. It restores the database filename. It deletes the tools…
❤2👍2
📚 Как-то попросили меня разобрать статью: 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 и могут вытеснять оттуда действительно горячие данные пользовательских запросов.
Решение, которое обсуждается в статье,
Мне эта статья кажется важной не только как заметка про 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. Она про границу между СУБД и операционной системой - и про то, как эта граница постепенно становится всё менее очевидной 🧐.
Я не разработчик, поэтому мне сложно будет оценить все тонкости данного исследования, но я постараюсь выцепить основную тенденцию.
В статье показывается, что 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. Она про границу между СУБД и операционной системой - и про то, как эта граница постепенно становится всё менее очевидной 🧐.
Sam Lightfoot
Direct I/O for Cassandra Compaction: Cutting p99 Read Latency by 5x
A patch I contributed to Apache Cassandra 6 cuts p99 read latency by 5x during compaction.
Compaction pollutes the page cache with data the application knows is throwaway, but the kernel does not. Compaction is unavoidable, the price Cassandra pays for fast…
Compaction pollutes the page cache with data the application knows is throwaway, but the kernel does not. Compaction is unavoidable, the price Cassandra pays for fast…
🔥6👍1
Мультивселенная СУБД pinned «📚 Как-то попросили меня разобрать статью: Direct I/O for Cassandra Compaction: Cutting p99 Read Latency by 5x Я не разработчик, поэтому мне сложно будет оценить все тонкости данного исследования, но я постараюсь выцепить основную тенденцию. В статье показывается…»
📚 Пап, а это HTAP? — Ну такое, это две разные СУБД в длинном плаще
После статьи Тантора про HTAP внутри PostgreSQL у меня осталось двойственное ощущение.
С одной стороны, тезис статьи довольно простой: связка "PostgreSQL для OLTP + ClickHouse/DuckDB/Parquet через CDC для OLAP" - это НЕ HTAP. Это две разные системы, соединённые трубой передачи данных.
*️⃣ Да, это может быть практично.
*️⃣ Да, это может работать быстро.
*️⃣ Да, это может быть нормальной промышленной архитектурой.
❗️Но это не единый контур.
В строгом смысле HTAP должен давать:
✅ общий логический набор данных;
✅ единую транзакционную видимость;
✅ минимум data movement между OLTP и OLAP;
✅ согласованную SQL-семантику;
✅ изоляцию аналитической нагрузки от транзакционной.
HTAP преподносится как способ убрать сложность: меньше ETL, меньше CDC, меньше рассинхронизации. На практике сложность не исчезает, а переезжает внутрь одной большой СУБД. А это очень рискованная затея...
OLTP - критичный контур. Если он лежит, бизнес теряет деньги (не проходят платежи, не создаются заказы и т.п.)
OLAP тоже важен, но обычно менее критичен. Его можно перегрузить, перестроить или даже временно отключить.
Поэтому разделение OLTP и OLAP - это не только про разные нагрузки. Это про разделение рисков.
Главный вопрос к HTAP должен быть примерно такой:
Иерархия получается такая
HTAP СУБД будут полезны в следующих проектах:
➕ выявление мошенничества (антифрод)
➕ скоринг
➕ управление текущими остатками
➕ Телеком
После статьи Тантора про HTAP внутри PostgreSQL у меня осталось двойственное ощущение.
С одной стороны, тезис статьи довольно простой: связка "PostgreSQL для OLTP + ClickHouse/DuckDB/Parquet через CDC для OLAP" - это НЕ HTAP. Это две разные системы, соединённые трубой передачи данных.
❗️Но это не единый контур.
В строгом смысле HTAP должен давать:
HTAP преподносится как способ убрать сложность: меньше ETL, меньше CDC, меньше рассинхронизации. На практике сложность не исчезает, а переезжает внутрь одной большой СУБД. А это очень рискованная затея...
OLTP - критичный контур. Если он лежит, бизнес теряет деньги (не проходят платежи, не создаются заказы и т.п.)
OLAP тоже важен, но обычно менее критичен. Его можно перегрузить, перестроить или даже временно отключить.
Поэтому разделение OLTP и OLAP - это не только про разные нагрузки. Это про разделение рисков.
Главный вопрос к HTAP должен быть примерно такой:
Как она гарантирует, что аналитика не убьёт OLTP?
Иерархия получается такая
OLTP
↓
HTAP / operational analytics
↓
OLAP / DWH / Data Lake / BI / ML
HTAP СУБД будут полезны в следующих проектах:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2
📚 IBM invites CockroachDB to infest its mainframes with PostgreSQL
С моей колокольни, новость - бомба 💥💥💥
Сделка века, не иначе 😊 Очень продуманный и хитрый ход. Причем одинаково полезный как для IBM, так и для Cockroach Lab.
Это не история про замену Db2 на CockroachDB (к сожалению, Db2 никогда не умрет 🧟). И это не про простой перенос старых mainframe-приложений в PostgreSQL-мир.
Это попытка IBM закрыть пробел в портфеле, дать клиентам cloud-native distributed SQL для новых приложений внутри привычной экосистемы.
Главный фича - закрыть требование к масштабированию систем из коробки и дать людям знакомый синтаксис.
CockroachDB похожа на PostgreSQL только на уровне интерфейса. Под капотом - другая распределённая СУБД. А миграция enterprise-систем, это целая эпопея! Даже простой
Самое сложное обычно в другом:
🧩 SQL-диалект
🧩 хранимые процедуры
🧩 транзакционная семантика
🧩 драйверы
🧩 блокировки
🧩 эксплуатационные привычки
🧩 прикладной код вокруг СУБД
Поэтому обещания "модернизации без переписывания" всегда стоит читать осторожно (это вам не Диасофт).
Итого:
✅ Для новых cloud-native приложений в инфраструктуре IBM - CockroachDB шикарный вариант.
❌ Для зрелых Db2/mainframe-нагрузок - это не волшебный мост в 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-мир.
theregister
IBM and CockroachDB partner to bring PostgreSQL to mainframe
: Vendors promote bridge to modern architecture for legacy systems, but Db2 not going anywhere just yet
👍4
🎦 Осипов, Рыбак -- #1 (2026)
Не могу пройти мимо беседы двух умных и уважаемых мной людей о мире баз данных.
Не буду делать детальный обзор. Алексей в своем канале уже дал полную текстовую расшифровку
❗️Пост 1
❗️Пост 2
Даже на Хабре есть текстовая расшифровка
Я хочу подсветить тезисы, которые задели лично меня:
👉 До эпохи NoSQL все чаты хранились в MySQL
👉 Discord хранит свои данные в ScyllaDB
👉 Есть ряд научный статей по разработке эффективного алгоритма удаления данных по TTL
👉 Accord для Cassandra сделала команда Apple. (У меня два студента в этого году пишут НИР по этой теме)
👉 CSO (безопасники) выбирают базу данных для проекта.
👉 Подавляющее большинство пользователей Redis без AOF без реплики. Просто мемкэш. Резиновый КЭШ.
Не могу пройти мимо беседы двух умных и уважаемых мной людей о мире баз данных.
Не буду делать детальный обзор. Алексей в своем канале уже дал полную текстовую расшифровку
❗️Пост 1
❗️Пост 2
Даже на Хабре есть текстовая расшифровка
Я хочу подсветить тезисы, которые задели лично меня:
👉 До эпохи NoSQL все чаты хранились в MySQL
👉 Discord хранит свои данные в ScyllaDB
👉 Есть ряд научный статей по разработке эффективного алгоритма удаления данных по TTL
👉 Accord для Cassandra сделала команда Apple. (У меня два студента в этого году пишут НИР по этой теме)
👉 CSO (безопасники) выбирают базу данных для проекта.
👉 Подавляющее большинство пользователей Redis без AOF без реплики. Просто мемкэш. Резиновый КЭШ.
YouTube
Осипов, Рыбак -- #1 (2026)
Беседа Алексея Рыбака (devhands.io) с Константином Осиповым (Picodata) о выборе баз данных для хранения больших объёмов. Обсудили, что:
- MySQL/Postgres — рабочие варианты, но требуют ручного шардирования; у Postgres проблема с MVCC-сборкой мусора на больших…
- MySQL/Postgres — рабочие варианты, но требуют ручного шардирования; у Postgres проблема с MVCC-сборкой мусора на больших…
👍3
Продолжаем летнюю тематику. С годами эволюционирует не только человек, но и весь животным мир!
С пятницей! И с праздником всех!
#mems
С пятницей! И с праздником всех!
#mems
❤3
📚 Дочитал на днях Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems или в простонародье, Кабанчик 2.0.
Из минусов, стало заметно меньше иллюстраций 🧑🎨. Большинство схем посвящены взаимодействию компонентов во времени - кто кому отправил сообщение, кто кого реплицировал, кто кого выбрал лидером. Скукота 😒.
Стоит ли сравнивать первое и второе издания, не знаю. Первое я читал лет 5 назад и помню уже довольно смутно, поэтому полноценного сравнения не получится ☹️.
К книге...📖 Забавно, что главная мысль книги, которая не покидала меня на протяжении всего чтения, указана в самом начале:
Собственно, вокруг этих компромиссов и строится вся книга.
Где-то в 2023 году мне активно доказывали, что любую современную ИТ-архитектуру можно построить вообще без реляционной СУБД. И, честно говоря, аргументы были весьма убедительными.
Но после чтения книги и наблюдения за развитием экосистемы PostgreSQL у меня возникла противоположная мысль:
Сегодня PostgreSQL умеет быть не только реляционной СУБД. Полнотекстовый поиск, JSON-документы, векторные индексы, геоданные, временные ряды, очереди сообщений, аналитика - список расширений уже выглядит как каталог отдельных продуктов 🛍.
По сути, плагины серьёзно изменили границы применимости PostgreSQL.☀️
При этом Клепман последовательно показывает другую тенденцию. Одна из ключевых идей последних глав книги заключается в том, что функции, которые раньше были сосредоточены внутри одной СУБД, всё чаще распределяются между специализированными системами: Kafka, Flink, Spark, Elasticsearch, Redis, объектными хранилищами, аналитическими платформами и так далее.
То есть автор скорее выступает за подход:
а не за попытку решить всё одним продуктом.
И вот тут у меня возник внутренний спор с книгой.
С одной стороны, аргументы Клепмана выглядят очень убедительно. Но всё-же очень хочется однажды спроектировать какой-нибудь видеохостинг или онлайн-магазин целиком на базе PostgreSQL, просто настроив разные экземпляры под разные роли.
Возможно, я живу в иллюзии, что PostgreSQL способен заменить половину современного инфраструктурного стека. А возможно, многие идеи книги выросли из опыта компаний масштаба Netflix, Uber, LinkedIn или Amazon, где объёмы данных и нагрузки принципиально отличаются от того, с чем сталкивается большинство команд в РФ.
Не исключаю, что для огромного числа проектов связки вида:
действительно хватает на долгие годы без необходимости тащить в инфраструктуру десяток дополнительных продуктов.
В любом случае книга отличная 💪. Для меня это по-прежнему одна из лучших книг по архитектуре систем хранения и обработки данных.
❗️Бестселлер❗️ 100 000 проданных экземпляров первого издания 🤩🥳 Это вам, ни это 🤪
Теперь остаётся дождаться русского перевода второго издания. Читать 700+ страниц про распределённые системы на английском оказалось отдельным испытанием🦈 🏖️
Из минусов, стало заметно меньше иллюстраций 🧑🎨. Большинство схем посвящены взаимодействию компонентов во времени - кто кому отправил сообщение, кто кого реплицировал, кто кого выбрал лидером. Скукота 😒.
Стоит ли сравнивать первое и второе издания, не знаю. Первое я читал лет 5 назад и помню уже довольно смутно, поэтому полноценного сравнения не получится ☹️.
К книге...📖 Забавно, что главная мысль книги, которая не покидала меня на протяжении всего чтения, указана в самом начале:
Не существует универсальной "лучшей" системы данных. Любая технология представляет собой набор компромиссов между надёжностью, масштабируемостью, согласованностью, производительностью, стоимостью сопровождения и другими требованиями
Собственно, вокруг этих компромиссов и строится вся книга.
Где-то в 2023 году мне активно доказывали, что любую современную ИТ-архитектуру можно построить вообще без реляционной СУБД. И, честно говоря, аргументы были весьма убедительными.
Но после чтения книги и наблюдения за развитием экосистемы PostgreSQL у меня возникла противоположная мысль:
А что если современную архитектуру можно построить практически целиком из PostgreSQL и его расширений?
Сегодня PostgreSQL умеет быть не только реляционной СУБД. Полнотекстовый поиск, JSON-документы, векторные индексы, геоданные, временные ряды, очереди сообщений, аналитика - список расширений уже выглядит как каталог отдельных продуктов 🛍.
По сути, плагины серьёзно изменили границы применимости PostgreSQL.☀️
При этом Клепман последовательно показывает другую тенденцию. Одна из ключевых идей последних глав книги заключается в том, что функции, которые раньше были сосредоточены внутри одной СУБД, всё чаще распределяются между специализированными системами: Kafka, Flink, Spark, Elasticsearch, Redis, объектными хранилищами, аналитическими платформами и так далее.
То есть автор скорее выступает за подход:
правильный инструмент для правильной задачи,
а не за попытку решить всё одним продуктом.
И вот тут у меня возник внутренний спор с книгой.
С одной стороны, аргументы Клепмана выглядят очень убедительно. Но всё-же очень хочется однажды спроектировать какой-нибудь видеохостинг или онлайн-магазин целиком на базе PostgreSQL, просто настроив разные экземпляры под разные роли.
Возможно, я живу в иллюзии, что PostgreSQL способен заменить половину современного инфраструктурного стека. А возможно, многие идеи книги выросли из опыта компаний масштаба Netflix, Uber, LinkedIn или Amazon, где объёмы данных и нагрузки принципиально отличаются от того, с чем сталкивается большинство команд в РФ.
Не исключаю, что для огромного числа проектов связки вида:
PostgreSQL + расширения
действительно хватает на долгие годы без необходимости тащить в инфраструктуру десяток дополнительных продуктов.
В любом случае книга отличная 💪. Для меня это по-прежнему одна из лучших книг по архитектуре систем хранения и обработки данных.
❗️Бестселлер❗️ 100 000 проданных экземпляров первого издания 🤩🥳 Это вам, ни это 🤪
Теперь остаётся дождаться русского перевода второго издания. Читать 700+ страниц про распределённые системы на английском оказалось отдельным испытанием
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
🎦 Seattle Valkey Meetup - April 2026
Народ из Valkey выложили на своем канале видео митапа из Сиетла. В целом, каких-то откровений там нет, то поднимаются интересные кейсы. Valkey, как и Redis, расширяет свой функционал дополнительными фичами и становится еще более полезным для зрелой инфраструктурной платформы.
Разбираются 2 выступления:
❇️ Первое - user quotas.
Это попытка решить классическую эксплуатационную проблему "шумного соседа" (noisy neighbor). Один сервис или тенант может занять все соединения и начать слишком активно читать/писать или устроить connection storm после рестарта. Поэтому важно иметь возможность настройки лимитов на количество соединений и read/write RPS в разрезе пользователя. Это уже не про безопасность в стиле ACL, а про resource governance (т.е. про надежность).
❇️Второе - Valkey Search 1.2.
Поиск развивается от векторных сценариев к full-text и hybrid search: текст, теги, числовые фильтры, векторы, агрегации. Спикер основной акцент ставит на near-real-time обновление индекса, что делает Valkey интересным не только для кэша, но и для e-commerce, session stores, inventory и других сценариев, где данные часто меняются.
Как итог можно сказать следующее: Valkey пытается закрывать не только функциональные gaps после Redis, но и реальные production-боли, которые стали более очевидны с версии 9.0. Например, multi-tenancy, fairness, search, совместимость, наблюдаемость и контроль нагрузки.
Народ из Valkey выложили на своем канале видео митапа из Сиетла. В целом, каких-то откровений там нет, то поднимаются интересные кейсы. Valkey, как и Redis, расширяет свой функционал дополнительными фичами и становится еще более полезным для зрелой инфраструктурной платформы.
Разбираются 2 выступления:
❇️ Первое - user quotas.
Это попытка решить классическую эксплуатационную проблему "шумного соседа" (noisy neighbor). Один сервис или тенант может занять все соединения и начать слишком активно читать/писать или устроить connection storm после рестарта. Поэтому важно иметь возможность настройки лимитов на количество соединений и read/write RPS в разрезе пользователя. Это уже не про безопасность в стиле ACL, а про resource governance (т.е. про надежность).
⚠️Оффтоп. Часто студенты путают понятия надежности и безопасности, а если еще добавить слово отказоустойчивость, то это фаталити для юного ума
❇️Второе - Valkey Search 1.2.
Поиск развивается от векторных сценариев к full-text и hybrid search: текст, теги, числовые фильтры, векторы, агрегации. Спикер основной акцент ставит на near-real-time обновление индекса, что делает Valkey интересным не только для кэша, но и для e-commerce, session stores, inventory и других сценариев, где данные часто меняются.
Как итог можно сказать следующее: Valkey пытается закрывать не только функциональные gaps после Redis, но и реальные production-боли, которые стали более очевидны с версии 9.0. Например, multi-tenancy, fairness, search, совместимость, наблюдаемость и контроль нагрузки.
YouTube
Seattle Valkey Meetup - April 2026
00:52 User quotas by Sachin Murthy (OCI Cache engineer)
This demo introduces a fairness and protection layer for shared Valkey deployments that enforces per-user quotas at the server level using ACL identities, preventing issues like noisy neighbors and thundering…
This demo introduces a fairness and protection layer for shared Valkey deployments that enforces per-user quotas at the server level using ACL identities, preventing issues like noisy neighbors and thundering…
❤3
📚Introducing Valkey Admin 1.0: Visual Cluster Management for Valkey
GUI Valkey Admin за три месяца прошёл путь: от февральского preview-инструмента до майского релиза 1.0. Довольно быстрый скачок, на мой взгляд. Это в очередной раз говорит нам о том, что комьюните Valkey довольно активное!
Если в первой статье это был скорее визуальный desktop-GUI для оператора Valkey, то в майском анонсе продукт выглядит уже как зачаток полноценного эксплуатационного слоя: desktop-приложение, Docker-образ, Kubernetes deployment, поддержка ElastiCache-сценариев, hot key detection, command logs, key browser и кластерная топология.
Самое интересное здесь это общий вектор развития↗️ . Valkey постепенно строит вокруг себя не только сервер и модули, но и экосистему инструментов для production-эксплуатации: диагностика, визуализация, работа с ключами, анализ горячих участков, понимание того, на каком узле кластера возникла проблема.
При этом Valkey Admin пока не выглядит как замена Prometheus/Grafana или полноценная enterprise-консоль. Скорее это официальный операторский инструмент, который закрывает разрыв между
Valkey начинает оформляться не просто как форк Redis, а как самостоятельная платформа с собственным эксплуатационным контуром. Конкурент RedisInsignt во всей красе с важным отличием в политике лицензирования.
Обязательно включу Valkey Admin в новый запуск курса по Redis/Valkey на платформе DevHands.
GUI Valkey Admin за три месяца прошёл путь: от февральского preview-инструмента до майского релиза 1.0. Довольно быстрый скачок, на мой взгляд. Это в очередной раз говорит нам о том, что комьюните Valkey довольно активное!
Если в первой статье это был скорее визуальный desktop-GUI для оператора Valkey, то в майском анонсе продукт выглядит уже как зачаток полноценного эксплуатационного слоя: desktop-приложение, Docker-образ, Kubernetes deployment, поддержка ElastiCache-сценариев, hot key detection, command logs, key browser и кластерная топология.
Самое интересное здесь это общий вектор развития
При этом Valkey Admin пока не выглядит как замена Prometheus/Grafana или полноценная enterprise-консоль. Скорее это официальный операторский инструмент, который закрывает разрыв между
valkey-cli и тяжёлым observability-стеком.Valkey начинает оформляться не просто как форк Redis, а как самостоятельная платформа с собственным эксплуатационным контуром. Конкурент RedisInsignt во всей красе с важным отличием в политике лицензирования.
Обязательно включу Valkey Admin в новый запуск курса по Redis/Valkey на платформе DevHands.
Please open Telegram to view this post
VIEW IN TELEGRAM
valkey.io
Valkey: Introducing Valkey Admin 1.0: Visual Cluster Management for Valkey
Valkey Admin is a new open source observability and management tool from the Valkey project that brings cluster visibility, data inspection, and troubleshooting into a single view. It ships as a native desktop application for macOS and Linux, and as a containerized…
❤2
📚 Попалась прикольная PDF-ка от VK: Тренды развития рынка СУБД
VK провели исследование рынка и обозначили 5 трендов рынка СУБД.
⚠️Честно говоря, я бы этот отчет разобрал с кем-то на видео, т.к. очень много тезисов в отчете откровенно спорные и я с большинством не согласен. Вы не подумайте, данный отчет отнюдь не лживый, но писать о том, что это тренд - перебор. Найду оппонентов - сделаем небольшой стрим. Если кто хочет поучаствовать в разборе отчета, то пишите!⚠️
А пока просто сухие факты
ВК считает, что эра "вендор-лока" прошла и мы пришли к мультивендорной архитектуре.
Высокий уровень безопасности - ключевой критерий выбора СУБД
У компаний растёт интерес к AI/LLM-сценариям: поиск по смыслу, RAG, рекомендации, поиск похожих изображений, гибридный поиск. Однако новую БД они вводить не хотят, поэтому используют возможности текущих (pgvector)
ИИ-ассистенты и агенты для работы с данными
Текущий стек: OLTP-база + Kafka/стриминг + ClickHouse. Компаниям кажется он довольно сложный и избыточный. HTAP должен стать решением всех проблем.
Очень спорный отчет, но зерно истины в нём есть.
VK провели исследование рынка и обозначили 5 трендов рынка СУБД.
⚠️Честно говоря, я бы этот отчет разобрал с кем-то на видео, т.к. очень много тезисов в отчете откровенно спорные и я с большинством не согласен. Вы не подумайте, данный отчет отнюдь не лживый, но писать о том, что это тренд - перебор. Найду оппонентов - сделаем небольшой стрим. Если кто хочет поучаствовать в разборе отчета, то пишите!⚠️
А пока просто сухие факты
1️⃣Уход от монолитной инфраструктуры данных;
ВК считает, что эра "вендор-лока" прошла и мы пришли к мультивендорной архитектуре.
2️⃣Рост требований к безопасности и управлению рисками;
Высокий уровень безопасности - ключевой критерий выбора СУБД
3️⃣векторные индексы в существующих СУБД под AI-сценарии;
У компаний растёт интерес к AI/LLM-сценариям: поиск по смыслу, RAG, рекомендации, поиск похожих изображений, гибридный поиск. Однако новую БД они вводить не хотят, поэтому используют возможности текущих (pgvector)
4️⃣ИИ для демократизации данных и для управления дата-инфраструктурой;
ИИ-ассистенты и агенты для работы с данными
5️⃣интерес к HTAP для real-time аналитики
Текущий стек: OLTP-база + Kafka/стриминг + ClickHouse. Компаниям кажется он довольно сложный и избыточный. HTAP должен стать решением всех проблем.
Очень спорный отчет, но зерно истины в нём есть.
❤4
Небольшой пост от коллег из разработки SereneDB. Я как-то писал о том, что они привлекли кучу инвестиций и все фаундеры - россияне. Сам стартап немецкий 🇩🇪.
Сейчас они снова напомнили о себе успешно пройдя ряд популярных бенчмарков. Надо будет дать студентам на изучение эту СУБД. Потенциально проект довольно интригующий
Напомню, что SereneDB - The First Real-Time Search Analytics Database
Сейчас они снова напомнили о себе успешно пройдя ряд популярных бенчмарков. Надо будет дать студентам на изучение эту СУБД. Потенциально проект довольно интригующий
Напомню, что 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)
Telegram
Мультивселенная СУБД
📚 Немецкий стартап SereneDB получает 2,1 миллиона долларов инвестиций в первом раунде
Раунд возглавили фонды Entourage и High-Tech Gründerfonds
SereneDB разрабатывает распределенную базу данных для поиска в режиме реального времени.
Меня всегда привлекают…
Раунд возглавили фонды Entourage и High-Tech Gründerfonds
SereneDB разрабатывает распределенную базу данных для поиска в режиме реального времени.
Меня всегда привлекают…
❤1
Forwarded from tl;dr data
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
На 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
🤔1
На днях смотрел небольшой обзор наших политических блогеров и меня сильно зацепила следующая гениальная идея некоторых западных стран.
🔥Идея: для иностранных граждан обучение в ВУЗах по некоторым направлениям совершенно бесплатно! И бакалавриат и магистратура! Всё бесплатно 👀. Дополнительно, таким студентам еще выплачивается повышенная стипендия и даются льготы на жилье 🤑.
Круто, согласитесь! 💪
Однако после обучения если такой студент желает остаться в стране, то это обучение будет считаться ПЛАТНЫМ 😨! И на уже бывшего студента автоматически вешается кредитный долг😱! Дальше он работает и выплачивает его👮♀️ .
А если человек уезжает обратно, то он максимально лоялен стране, которая его "приютила" на все 6 лет обучения и "дула в попку" 🌬! Дальше сами можете додумать...
Гениально! Win-Win с любой стороны!
В общем, к чему это всё. Меня периодически спрашивают про зарубежное образование и хвастаются мне о том, что они там на халяву учатся в той же Германии, Австрии или даже в США. Мол, круто?! Конечно круто 💪. Однако, везде есть свои нюансы 😈.
⚠️Обязательно читайте договора на обучении!⚠️
Нет ли там пункта о том, что что-то бесплатное сейчас при некоторых условиях становится платным👮♀️ Как следствие, огромным финансовым бременем...💸
🔥Идея: для иностранных граждан обучение в ВУЗах по некоторым направлениям совершенно бесплатно! И бакалавриат и магистратура! Всё бесплатно 👀. Дополнительно, таким студентам еще выплачивается повышенная стипендия и даются льготы на жилье 🤑.
Круто, согласитесь! 💪
Однако после обучения если такой студент желает остаться в стране, то это обучение будет считаться ПЛАТНЫМ 😨! И на уже бывшего студента автоматически вешается кредитный долг😱! Дальше он работает и выплачивает его
А если человек уезжает обратно, то он максимально лоялен стране, которая его "приютила" на все 6 лет обучения и "дула в попку" 🌬! Дальше сами можете додумать...
Гениально! Win-Win с любой стороны!
В общем, к чему это всё. Меня периодически спрашивают про зарубежное образование и хвастаются мне о том, что они там на халяву учатся в той же Германии, Австрии или даже в США. Мол, круто?! Конечно круто 💪. Однако, везде есть свои нюансы 😈.
⚠️Обязательно читайте договора на обучении!⚠️
Нет ли там пункта о том, что что-то бесплатное сейчас при некоторых условиях становится платным
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
📚 Valkey 9.1 In-Memory Data Store Released with Database-Level ACLs
И так, к статье...
Вышел 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 - мелочь, но очень полезная для нормальной интеграции с системами логирования.
В мире СУБД ценность часто не в красивой новой фиче, а в том, что систему становится проще безопасно эксплуатировать под нагрузкой.
Я понимаю, что посты про Valkey мало кому интересны, но эта СУБД важна лично для меня, т.к. я целый курс про неё написал. Уже прошло 3 запуска и скоро планируется 4-ый. Обязательно включу в него все фичи релиза 9.1.
И так, к статье...
Вышел Valkey 9.1. Там нет каких-то прям мегафич. Этот релиз больше направлен на прокачку эксплуатационной зрелости. Хотя как и в любом другом релизе, Valkey стал еще быстрее! Еще и еще! 🤪
👉 database-level ACL. В релизе 9.0 ввели поддержку множества база данных в одном кластере Valkey. Однако ACL был общий на все базы. Теперь же ACL можно настроить под каждую базу данных кластера. Для multi-tenant-сценариев и изоляции приложений это давно напрашивалось. И да, напомню, что баз может быть до 15 штук.
👉 улучшение безопасности. Lua вынесли из ядра в отдельный модуль. Если скрипты не нужны, "поверхность атаки"
👉 Новые метрики по наблюдаемости (observability). Появились метрики использования main thread и I/O threads, потому что обычная CPU utilization для Valkey может быть обманчивой. Плюс добавили JSON logging - мелочь, но очень полезная для нормальной интеграции с системами логирования.
В мире СУБД ценность часто не в красивой новой фиче, а в том, что систему становится проще безопасно эксплуатировать под нагрузкой.
Linuxiac
Valkey 9.1 In-Memory Data Store Released with Database-Level ACLs
Valkey 9.1 in-memory data store adds database-level ACLs, JSON logging, Lua modularization, TLS updates, and performance improvements.
❤3👍2🔥1
📚 Что такое 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 текущим персоналом - невозможно. Слишком много сил уходит на этап подготовки. Чтобы привести текущие потоки данных к чему-то общему требуются заряженные и поглощенные только этим проектом люди!
Это большой вводный материал про 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 текущим персоналом - невозможно. Слишком много сил уходит на этап подготовки. Чтобы привести текущие потоки данных к чему-то общему требуются заряженные и поглощенные только этим проектом люди!
👍4
📚 Dell и Kioxia разработали первый сервер на 9,8 ПБ
Ацкий треш 😱! Двух юнитовый сервер с 9.8 петабайтным хранилищем 🤯 ! Это один сервер!1️⃣
Зачем нужны эти распределенные системы? Кластера балансировки нагрузки и т.п.? Можно спокойно масштабироваться вертикально и горя не знать! 😎
Западный рынок поражает своими инновациями для Бизнеса. Эпоха горизонтального масштабирования ради производительности - мертво 🪦. HA-кластеры наше будущее!🚀 NLB можно на свалку истории отправлять 🚮
Я конечно чуть передергиваю 😅, но тренд на лицо.
Dell и Kioxia представили сервер сверхвысокой плотности хранения: Dell PowerEdge R7725xd с флеш-памятью до 9,8 ПБ в форм-факторе 2U
Dell PowerEdge R7725xd может комплектоваться 40 NVMe SSD Kioxia LC9 в форм-факторе E3.L, каждый объёмом до 245,76 ТБ. В сумме получается почти 9,8 ПБ флеш-хранилища в одном 2U-сервере. Платформа рассчитана на Enterprise-сегмент: AMD EPYC 9005 Turin, до 3 ТБ DDR5, PCIe 5.0, сетевые адаптеры до 400 Гбит/с, управление через Dell iDRAC
Ацкий треш 😱! Двух юнитовый сервер с 9.8 петабайтным хранилищем 🤯 ! Это один сервер!
Зачем нужны эти распределенные системы? Кластера балансировки нагрузки и т.п.? Можно спокойно масштабироваться вертикально и горя не знать! 😎
Западный рынок поражает своими инновациями для Бизнеса. Эпоха горизонтального масштабирования ради производительности - мертво 🪦. HA-кластеры наше будущее!
Я конечно чуть передергиваю 😅, но тренд на лицо.
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Dell и Kioxia разработали первый сервер на 9,8 ПБ
Недавно мы рассказывали о новых дисках от Micron на 245TB, где упоминали о более раннем анонсе дисков от Kioxia. С последними была объявлена крутая коллаборация с Dell. В Токио 15 мая 2026 года...
❤3