Иногда на экзамене люди неожиданно меняются и от этого бывает немного дискомфортно.
С пятницей!
#mems
С пятницей!
#mems
😁4❤2🤔1
📚🦆 DuckLake 1.0: Data Lake Format with SQL Catalog Metadata
DuckDB продолжает активно расширять свою экосистему. После успеха embedded analytics движка команда решила зайти на территорию Data Lake / Lakehouse и представила DuckLake.
Главная идея проекта звучит неожиданно😱 ШОК 💥
Подводочка. Сегодняшние lakehouse-системы это:
👉 Apache Iceberg
👉 Delta Lake
👉 Apache Hudi
Они хранят метаданные в виде файлов прямо в S3/GCS/Azure Blob Storage:
➡️ JSON
➡️ Avro
➡️ manifests
➡️ snapshots
Это позволило отказаться от центральной СУБД для метаданных и лучше масштабировать систему. Но со временем архитектура начала обрастать сложностью:
👉 тысячи metadata-файлов,
👉 expensive LIST operations,
👉 compaction,
👉 catalog services,
👉 coordination layers,
👉 сложные commit protocols.
И тут DuckLakeдостаёт из широких штанин предлагает почти "еретическую"идею 😈 :
Архитектура DuckLake:
И вот тут начинается самое интересное 🧐. На самом деле идея НЕ новая. Старый Hadoop/Hive мир уже жил примерно так же.
Данные лежали в HDFS, а Hive Metastore хранился в MySQL/PostgreSQL. То есть ранние Data Lake уже были database-native для metadata.
Потом индустрия решила уйти от СУБД для метаданных:
👉 из-за масштабирования,
👉 distributed workloads,
👉 cloud-native pipelines.
Так появился Iceberg/Delta-подход:
👉 metadata как immutable files.
И теперь история делает красивый круг 🔄
На мой взгляд, самое интересное здесь даже не сам формат, а цикличность архитектуры.
IT-индустрия очень часто:
1️⃣ уходит от централизованной модели,
2️⃣ сталкивается со взрывом сложности,
3️⃣ а потом аккуратно возвращает часть централизации обратно, но уже на новом технологическом уровне.
DuckDB продолжает активно расширять свою экосистему. После успеха embedded analytics движка команда решила зайти на территорию Data Lake / Lakehouse и представила DuckLake.
Главная идея проекта звучит неожиданно😱 ШОК 💥
Подводочка. Сегодняшние lakehouse-системы это:
👉 Apache Iceberg
👉 Delta Lake
👉 Apache Hudi
Они хранят метаданные в виде файлов прямо в S3/GCS/Azure Blob Storage:
➡️ JSON
➡️ Avro
➡️ manifests
➡️ snapshots
Это позволило отказаться от центральной СУБД для метаданных и лучше масштабировать систему. Но со временем архитектура начала обрастать сложностью:
👉 тысячи metadata-файлов,
👉 expensive LIST operations,
👉 compaction,
👉 catalog services,
👉 coordination layers,
👉 сложные commit protocols.
И тут DuckLake
А зачем вообще хранить metadata как файлы, если человечество уже придумало SQL database?
Архитектура DuckLake:
Компонент ➡️ Где хранится
Data ➡️ Parquet
Metadata ➡️ SQL database
Query Engine ➡️ DuckDB
И вот тут начинается самое интересное 🧐. На самом деле идея НЕ новая. Старый Hadoop/Hive мир уже жил примерно так же.
Данные лежали в HDFS, а Hive Metastore хранился в MySQL/PostgreSQL. То есть ранние Data Lake уже были database-native для metadata.
Потом индустрия решила уйти от СУБД для метаданных:
👉 из-за масштабирования,
👉 distributed workloads,
👉 cloud-native pipelines.
Так появился Iceberg/Delta-подход:
👉 metadata как immutable files.
И теперь история делает красивый круг 🔄
❗️Hive-era:➖ metadata in DB➖ simple➖ but scaling pain
❗️Iceberg-era:➖ metadata as files➖ scalable➖ but operationally complex
❗️ DuckLake:➖ maybe SQL DB was not such a bad idea after all 🙂
На мой взгляд, самое интересное здесь даже не сам формат, а цикличность архитектуры.
IT-индустрия очень часто:
1️⃣ уходит от централизованной модели,
2️⃣ сталкивается со взрывом сложности,
3️⃣ а потом аккуратно возвращает часть централизации обратно, но уже на новом технологическом уровне.
Please open Telegram to view this post
VIEW IN TELEGRAM
InfoQ
DuckLake 1.0: Data Lake Format with SQL Catalog Metadata
DuckDB Labs recently released DuckLake 1.0, a data lake format that stores table metadata in a SQL database rather than across many files in object storage. The first implementation is available as a DuckDB extension and includes catalog-stored small updates…
👍7
🎦 Что должен знать каждый backend про N+1, lazy preload и производительность / Евгений Демин #83
Разберу довольно интересное интервью с Евгением Демином - Ruby-разработчик и автор нескольких популярных open source библиотек, которые решают проблемы с базами данных, валидацией и производительностью.
Меня зацепило это видео тем, что в нем поднимаются проблемы конситентности на уровне БД и Приложения.
Видимо что-то навеяло мне после недели зачетов и выслушивания 100500 вариантов расшифровки аббревиатур ACID, BASE, LSM, PAXOS, GOSSIP, RAFT
❇️ База данных не должна верить приложению на слово
Важная мысль для всех, кто работает с базами данных:
Типичный пример: в приложении написано, что поле
То же самое с уникальностью. Проверка на уровне приложения удобна для пользовательского сообщения об ошибке, но от "race condition" защищает только
Интересна и тема
Отдельная тема - N+1. Часто говорят: "это проблема ORM". Но на самом деле запросы в цикле можно написать и без ORM. ORM просто делает эту ошибку менее заметной. Для DB-специалиста здесь важнее не спор "ORM или SQL руками", а вопрос,
❇️ Главный вывод из интервью такой:
🔑Если инвариант живёт только в коде приложения, он живёт до первого обходного пути.
Разберу довольно интересное интервью с Евгением Демином - 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. Это слой, который должен защищать инварианты продукта: типами, ограничениями, индексами, внешними ключами и транзакционной семантикой.
🔑Если инвариант живёт только в коде приложения, он живёт до первого обходного пути.
YouTube
Что должен знать каждый backend про N+1, lazy preload и производительность / Евгений Демин #83
В этом выпуске у меня в гостях Евгений Дёмин — Ruby-разработчик и автор нескольких популярных open source библиотек, которые решают проблемы с базами данных, валидацией и производительностью. Женя начинал как математик в Калининграде, попал на западный рынок…
❤3👍1
Как вы думаете, в сказке про Красную Шапочку волк сумел так мастерски замаскироваться, что Шапочка ничего не заметила, или у самой Шапочки были проблемы со зрением и слухом?
С пятницей!
#mems
С пятницей!
#mems
😁3
📚«День СУБД 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