В продолжении прикольных новостей по Valkey
📚 Valkey's lean memory tactics amid global DRAM crunch
Краткая выжимка:
В целом, это обычная маркетинговая статья. Но я очень жду, когда Valkey по завету своего "родителя" добавит поддержку вероятностных структур данных. Именно эти структуры нацелены на экономию RAM. Поглядим, будет ли в Valkey 10.0 встроенные в ядро новые структуры данных...
📚 Valkey's lean memory tactics amid global DRAM crunch
Краткая выжимка:
🗣 дефицит DRAM приводит к росту цен на память. Разработчики вынуждены оптимизировать потребление памяти, чтобы не жертвовать производительностью.
✅ Valkey сфокусирован на снижении расхода RAM.
👉 В Valkey 8.0 достигнуто до 20% повышения эффективности (больше ключей на узел) за счёт мелких оптимизаций внутренних структур.
👉 Valkey 9.0 добавил multi-database в кластерном режиме, что позволяет консолидировать рабочие нагрузки и ещё больше экономить ресурсы.
⚠️Рекомендации пользователям1️⃣ Обновляться до свежих версий Valkey2️⃣ Пересмотреть политики вытеснения (eviction) и TTL.3️⃣ Выбирать подходящие структуры данных, т.к. разница в потреблении памяти может достигать 50%
В целом, это обычная маркетинговая статья. Но я очень жду, когда Valkey по завету своего "родителя" добавит поддержку вероятностных структур данных. Именно эти структуры нацелены на экономию RAM. Поглядим, будет ли в Valkey 10.0 встроенные в ядро новые структуры данных...
Please open Telegram to view this post
VIEW IN TELEGRAM
IT Brief US
Valkey's lean memory tactics amid global DRAM crunch
With DRAM in short supply, Percona urges developers to cut RAM use and fine‑tune Valkey to keep apps fast on tighter hardware budgets.
📚 Как CockroachDB и Spanner хранят ваши данные: от Pebble и RocksDB до первичного ключа
Я крайне редко натыкаюсь на статьи по проектированию распределенных схем баз данных и тут такой подарок. Конечно хотелось бы большего, но хоть что-то.
Я пропущу традиционное вступление о том, что CockroachDB выросла из Google Spanner и зарекомендовала себя на рынке, как сверхнадежная транзакционно-распределенная СУБД. Архитектурное описание тоже пропущу. Собственно про проектирование.
В распределённых базах типа CockroachDB данные живут на нескольких машинах.
Главный нюанс: PRIMARY KEY (PK) сильно влияет на то, где физически окажутся строки, а значит, будет ли всё быстро или начнутся походы по сети и "тормоза".
❇️ Что важно помнить
1️⃣PK задаёт раскладку данных
Первое поле в PK - это почти как "папка", по которой база группирует строки. Если выбрать неудачно, то ваши данные размажутся по кластеру и даже простой запрос приведет к опросу всех узлов.
2️⃣ Кладите рядом то, что читаешь вместе
Если у вас multi-tenant и запросы обычно "внутри клиента", то ставьте tenant_id первым в ключе (и часто в индексах тоже).
Так данные одного клиента чаще будут рядом → меньше сетевых скачков.
3️⃣ Монотонные ключи убивают производительность записи
Пример "как часто делают" для лого событий:
Новые записи всегда самые свежие → они постоянно падают в одно и то же место → одна нода данных "перегревается".
Решение: добавить "распределитель", bucket. Это небольшое число, чтобы равномерно раскладывать новые записи:
где bucket = hash(id) % 16 (например)
Теперь новые события распределяются по 16 "полкам", и база не упирается в одну горячую точку.
4️⃣ Индекс - это такая же таблица
Вторичный индекс в такой архитектуре - это просто другая сортировка тех же данных. Он живет своей жизнью и может находиться на других узлах.
Каждый новый индекс = дополнительная Raft-транзакция при записи. 5 индексов = 5 консенсусов.
Лайфхак: Делайте индексы покрывающими (include все нужные поля). Это позволит не ходить в основную таблицу, если она "далеко".
И да пребудет с вами tenant_id в начале каждого ключа 😇. Аминь 🙏
Я крайне редко натыкаюсь на статьи по проектированию распределенных схем баз данных и тут такой подарок. Конечно хотелось бы большего, но хоть что-то.
Я пропущу традиционное вступление о том, что CockroachDB выросла из Google Spanner и зарекомендовала себя на рынке, как сверхнадежная транзакционно-распределенная СУБД. Архитектурное описание тоже пропущу. Собственно про проектирование.
В распределённых базах типа CockroachDB данные живут на нескольких машинах.
Главный нюанс: PRIMARY KEY (PK) сильно влияет на то, где физически окажутся строки, а значит, будет ли всё быстро или начнутся походы по сети и "тормоза".
❇️ Что важно помнить
1️⃣PK задаёт раскладку данных
Первое поле в PK - это почти как "папка", по которой база группирует строки. Если выбрать неудачно, то ваши данные размажутся по кластеру и даже простой запрос приведет к опросу всех узлов.
2️⃣ Кладите рядом то, что читаешь вместе
Если у вас multi-tenant и запросы обычно "внутри клиента", то ставьте tenant_id первым в ключе (и часто в индексах тоже).
Так данные одного клиента чаще будут рядом → меньше сетевых скачков.
3️⃣ Монотонные ключи убивают производительность записи
Пример "как часто делают" для лого событий:
PRIMARY KEY (tenant_id, created_at)
Новые записи всегда самые свежие → они постоянно падают в одно и то же место → одна нода данных "перегревается".
Решение: добавить "распределитель", bucket. Это небольшое число, чтобы равномерно раскладывать новые записи:
PRIMARY KEY (tenant_id, bucket, created_at, id)
где bucket = hash(id) % 16 (например)
Теперь новые события распределяются по 16 "полкам", и база не упирается в одну горячую точку.
4️⃣ Индекс - это такая же таблица
Вторичный индекс в такой архитектуре - это просто другая сортировка тех же данных. Он живет своей жизнью и может находиться на других узлах.
Каждый новый индекс = дополнительная Raft-транзакция при записи. 5 индексов = 5 консенсусов.
Лайфхак: Делайте индексы покрывающими (include все нужные поля). Это позволит не ходить в основную таблицу, если она "далеко".
И да пребудет с вами tenant_id в начале каждого ключа 😇. Аминь 🙏
Medium
How CockroachDB and Spanner Store Data
Imagine you are migrating a multi-tenant SaaS platform to CockroachDB. You have done everything right — proper replication factor…
👍2
Я обычно так не делаю, но тут три новости отлично объединятся в одну 🚀
1️⃣ Базы данных для искусственного интеллекта: векторы, эмбеддинги и архитектура
2️⃣ Что происходит с базой данных, когда пользователь является ИИ-агентом
3️⃣ Базы данных не предназначены для разрастания агентов — SurrealDB хочет это исправить
Эти статьи появились примерно в одно время и пытаются ответить на вопрос:
Я планировал об этом статью написать на хабре. Возможно так и поступлю чуть попозже, а пока некоторые промежуточные выводы.
❇️ Общий тренд: Мы переходим от эпохи «Базы Данных как хранилища» к эпохе «Базы данных как оперативной памяти ИИ».
Основные составляющие этого тренда:
👉 Конец «базового разврата» (Database Exhaustion)
Какой прикольный термин "базовый разврат". Надо будет обязательно его на лекции использовать.
Последние 10 лет девизом было Polyglot Persistence: "используй отдельную БД для каждой задачи" (Redis для кеша, Postgres для таблиц, Neo4j для графов, Pinecone для векторов).
Для ИИ-агентства эта модель - тупик 🚫. Агенту нужно всё и сразу в одном контекстном окне. Перекачка данных между пятью базами создает задержки (latency), которые убивают логику агента.
❇️ Тренд: Возврат к мультимодельным системам, которые объединяют векторы, графы и транзакции "под одним капотом".
👉 Смена «главного пользователя»
Раньше базы данных проектировались под запросы человека (через SQL) или бэкенд-приложения. Теперь главным потребителем данных становится LLM/Агент. У него другие паттерны. Он делает тысячи микро-запросов, ему нужна идеальная семантическая точность.
👉 Появление Agent-Native Infrastructure. База данных перестает быть пассивным архивом и становится активным участником процесса, который сам умеет запускать логику (через WASM или плагины, как в SurrealDB 3.0).
✅ Данные - это теперь "Контекст", а не просто "Строки"
Статьи подчеркивают, что для ИИ-агента данные бесполезны без связей. Просто найти похожий вектор (RAG) уже мало. Агенту нужно понимать иерархию и зависимости (графы).
👉Слияние Vector Search и Graph Relations. Будущее за системами, которые позволяют ИИ-агенту «рассуждать» прямо над структурой данных, не выходя за пределы БД.
Инструменты работы с данными, оптимизированные для человека-аналитика, перестают быть эффективными в мире, где решения принимают ИИ-агенты. Наступает эра "agent-first" инфраструктуры, где базы данных должны быть перепроектированы вокруг потребностей машин: скорость, работа с векторами, эфемерность и тесная интеграция с логикой ИИ.
Мы входим в эру консолидации🪬. Разработчики устали от сложности "зоопарка" баз данных. Победят те решения, которые предложат ИИ-агентам единую, быструю и "умную" среду обитания, где память, логика и данные не разделены сетевыми барьерами.
Иными словами, разгоняем хайп AI-native баз данных по полной!
1️⃣ Базы данных для искусственного интеллекта: векторы, эмбеддинги и архитектура
2️⃣ Что происходит с базой данных, когда пользователь является ИИ-агентом
3️⃣ Базы данных не предназначены для разрастания агентов — SurrealDB хочет это исправить
Эти статьи появились примерно в одно время и пытаются ответить на вопрос:
Что меняется в мире СУБД и приходом ИИ-агентов (LLM) ?
Я планировал об этом статью написать на хабре. Возможно так и поступлю чуть попозже, а пока некоторые промежуточные выводы.
❇️ Общий тренд: Мы переходим от эпохи «Базы Данных как хранилища» к эпохе «Базы данных как оперативной памяти ИИ».
Основные составляющие этого тренда:
👉 Конец «базового разврата» (Database Exhaustion)
Последние 10 лет девизом было Polyglot Persistence: "используй отдельную БД для каждой задачи" (Redis для кеша, Postgres для таблиц, Neo4j для графов, Pinecone для векторов).
Для ИИ-агентства эта модель - тупик 🚫. Агенту нужно всё и сразу в одном контекстном окне. Перекачка данных между пятью базами создает задержки (latency), которые убивают логику агента.
❇️ Тренд: Возврат к мультимодельным системам, которые объединяют векторы, графы и транзакции "под одним капотом".
👉 Смена «главного пользователя»
Раньше базы данных проектировались под запросы человека (через SQL) или бэкенд-приложения. Теперь главным потребителем данных становится LLM/Агент. У него другие паттерны. Он делает тысячи микро-запросов, ему нужна идеальная семантическая точность.
👉 Появление Agent-Native Infrastructure. База данных перестает быть пассивным архивом и становится активным участником процесса, который сам умеет запускать логику (через WASM или плагины, как в SurrealDB 3.0).
✅ Данные - это теперь "Контекст", а не просто "Строки"
Статьи подчеркивают, что для ИИ-агента данные бесполезны без связей. Просто найти похожий вектор (RAG) уже мало. Агенту нужно понимать иерархию и зависимости (графы).
👉Слияние Vector Search и Graph Relations. Будущее за системами, которые позволяют ИИ-агенту «рассуждать» прямо над структурой данных, не выходя за пределы БД.
Инструменты работы с данными, оптимизированные для человека-аналитика, перестают быть эффективными в мире, где решения принимают ИИ-агенты. Наступает эра "agent-first" инфраструктуры, где базы данных должны быть перепроектированы вокруг потребностей машин: скорость, работа с векторами, эфемерность и тесная интеграция с логикой ИИ.
Мы входим в эру консолидации🪬. Разработчики устали от сложности "зоопарка" баз данных. Победят те решения, которые предложат ИИ-агентам единую, быструю и "умную" среду обитания, где память, логика и данные не разделены сетевыми барьерами.
Иными словами, разгоняем хайп AI-native баз данных по полной!
Linux Professional Institute (LPI)
Databases for AI: Vectors, Embeddings, and Architecture
Databases for AI: vectors, embeddings, RAG, and how modern data platforms power machine learning and LLMs.
👍2🔥2
Когда прокачал свои навыки на максимум! Но есть нюанс...
С 1-ым апреля!
"В каждой шутке есть доля... " (с)
#mems
С 1-ым апреля!
"В каждой шутке есть доля... " (с)
#mems
❤4
В одной статье про "Перспективы развития баз данных в 2026 году" меня зацепила не AI-native часть (она ожидаемая 😁), а блок про надёжность: автор пишет, что reliability в 2026 измеряется observability-driven engineering", и как базовую практику внезапно достаёт из широких штанин правило "3-2-1".
Кратко напомню о чем оно:
👉 3 копии данных. «Две - это одна, а одна - это ноль» (с). Если у вас всего две копии и одна ломается в процессе восстановления (что бывает часто из-за нагрузки на диск), вы теряете всё.
👉 2 разных носителя. Если хранить всё на двух одинаковых жестких дисках из одной партии, есть риск, что они оба умрут от одного и того же заводского брака в один день.
👉 1 копия вне дома. Чтобы пожар или кража не уничтожили и оригинал навсегда.
Правило 3-2-1 - это не стандарт из лаборатории IBM. Это мем из мира фотографов. Его популяризировал Питер Крог, формулируя простую "памятку выживания" для цифровых архивов в The DAM Book (середина 2000-х).
То есть оригинальная модель защищала в первую очередь от случайных фейлов инфраструктуры. И как "база" она до сих пор красивая 🥹😍.
Но эпоху постоянных хакерских атак, вирусов-вымогателей и активным развитием ИИ-агентов оно начинает "трещать по швам".
👉 Во второй части разберем почему 3-2-1 сегодня не закрывает главный класс угроз, и почему нормой становится 3-2-1-1-0.
Кратко напомню о чем оно:
👉 3 копии данных. «Две - это одна, а одна - это ноль» (с). Если у вас всего две копии и одна ломается в процессе восстановления (что бывает часто из-за нагрузки на диск), вы теряете всё.
👉 2 разных носителя. Если хранить всё на двух одинаковых жестких дисках из одной партии, есть риск, что они оба умрут от одного и того же заводского брака в один день.
👉 1 копия вне дома. Чтобы пожар или кража не уничтожили и оригинал навсегда.
Правило 3-2-1 - это не стандарт из лаборатории IBM. Это мем из мира фотографов. Его популяризировал Питер Крог, формулируя простую "памятку выживания" для цифровых архивов в The DAM Book (середина 2000-х).
То есть оригинальная модель защищала в первую очередь от случайных фейлов инфраструктуры. И как "база" она до сих пор красивая 🥹😍.
Но эпоху постоянных хакерских атак, вирусов-вымогателей и активным развитием ИИ-агентов оно начинает "трещать по швам".
👉 Во второй части разберем почему 3-2-1 сегодня не закрывает главный класс угроз, и почему нормой становится 3-2-1-1-0.
Medium
The 2026 Database Frontier: Architecting for Scalability, Reliability, and AI-Native Performance
A Guide to Modern Data Infrastructure, Emerging Trends, and Engineering Best Practices
❤2😁1
Не прошло и трех лет и наконец-то:
С 7 апреля PostgresPRO запускает профессиональную сертификацию по PostgreSQL 16.
До этого народ сертифицировался только по PostgreSQL 13. Да, был еще курс повышения квалификации с 13 до 16, но это другое.
В общем, обещание сделать сертификацию по 16 версии я слышал еще с 2023 года. Ребята шли к этому событию три года! Причем следует учесть, что над этим проектом задействовано более 10+ человек. Интересно было бы послушать о причинах такой задержки, но это не столь важно сейчас.
Буду думать в этом году по поводу сертификации. Скажу честно, мне она особо не нужна. С другой стороны потешить свое самолюбие хочется 😊
С 7 апреля PostgresPRO запускает профессиональную сертификацию по PostgreSQL 16.
До этого народ сертифицировался только по PostgreSQL 13. Да, был еще курс повышения квалификации с 13 до 16, но это другое.
В общем, обещание сделать сертификацию по 16 версии я слышал еще с 2023 года. Ребята шли к этому событию три года! Причем следует учесть, что над этим проектом задействовано более 10+ человек. Интересно было бы послушать о причинах такой задержки, но это не столь важно сейчас.
Буду думать в этом году по поводу сертификации. Скажу честно, мне она особо не нужна. С другой стороны потешить свое самолюбие хочется 😊
Telegram
Postgres Pro Edu
С 7 апреля запускаем профессиональную сертификацию по PostgreSQL 16.
Сертификация подтверждает знания, помогает получить независимую оценку квалификации и найти работу.
✔️ Расписание уже опубликовано на сайте, записаться на тестирование можно в личном…
Сертификация подтверждает знания, помогает получить независимую оценку квалификации и найти работу.
✔️ Расписание уже опубликовано на сайте, записаться на тестирование можно в личном…
🔥5❤1
❗️Почему 3-2-1 уже мало?
В прошлом посте мы вспомнили классику от Питера Крога. Но если вы строите защиту компании только на ней, то вы в зоне риска.
В чем проблема? Классика 3-2-1 защищает от техногенных катастроф (пожар, сбой железа), но она бессильна против хакеров. Современные вирусы-вымогатели (Ransomware) первым делом ищут бэкапы в сети и удаляют их, прежде чем зашифровать рабочую базу.
Как пишут ребята из «Киберпротекта» и авторы на Хабре, современная норма - это 3-2-1-1-0.
Разбираем «добавки»:
🟢 +1 (Immutable копия): Это «защита от дурака» и хакера. Неизменяемая копия, которую физически нельзя удалить или зашифровать даже с правами админа (технология S3 Object Lock).
🟢 +0 (Zero errors): Бэкап не считается существующим, если он не прошел автоматическую проверку. Ноль ошибок при тестовом восстановлении!
А что сам Питер Крог? Он является активным деятелем, однако менять термин 3-2-1 он не хочет. Он бережет бренд 😎. "3-2-1" - это уже легендарный мем🐉 в мире ИТ. Проще расширять его толкование, чем придумывать новый номер телефона 📱. В его нынешних лекциях «единица» (offsite) всё чаще подразумевает именно неизменяемое облачное хранилище.
Как итог защищаться только от пожаров и игнорировать хакеров в 2026 году - это как поставить бронированную дверь 🦾, но оставить ключ под ковриком 🔑.
Есть ли у вас та самая «неизменяемая» копия и автоматический тест восстановления? 😈
В прошлом посте мы вспомнили классику от Питера Крога. Но если вы строите защиту компании только на ней, то вы в зоне риска.
В чем проблема? Классика 3-2-1 защищает от техногенных катастроф (пожар, сбой железа), но она бессильна против хакеров. Современные вирусы-вымогатели (Ransomware) первым делом ищут бэкапы в сети и удаляют их, прежде чем зашифровать рабочую базу.
Как пишут ребята из «Киберпротекта» и авторы на Хабре, современная норма - это 3-2-1-1-0.
Разбираем «добавки»:
🟢 +1 (Immutable копия): Это «защита от дурака» и хакера. Неизменяемая копия, которую физически нельзя удалить или зашифровать даже с правами админа (технология S3 Object Lock).
🟢 +0 (Zero errors): Бэкап не считается существующим, если он не прошел автоматическую проверку. Ноль ошибок при тестовом восстановлении!
А что сам Питер Крог? Он является активным деятелем, однако менять термин 3-2-1 он не хочет. Он бережет бренд 😎. "3-2-1" - это уже легендарный мем🐉 в мире ИТ. Проще расширять его толкование, чем придумывать новый номер телефона 📱. В его нынешних лекциях «единица» (offsite) всё чаще подразумевает именно неизменяемое облачное хранилище.
Как итог защищаться только от пожаров и игнорировать хакеров в 2026 году - это как поставить бронированную дверь 🦾, но оставить ключ под ковриком 🔑.
Есть ли у вас та самая «неизменяемая» копия и автоматический тест восстановления? 😈
Киберпротект
От «3-2-1» к «3-2-1-1-0»: современная стратегия резервного копирования
Разбираемся, почему правила «3-2-1» недостаточно для полной уверенности в сохранности информации и что такое современная стратегия «3-2-1-1-0»
👍2🔥2
Кому сегодня скучно, то можно глянуть трансляцию ArenaDaY
Конечно ребята делают всё очень пафосно!
Докладов мало, но с другой стороны это же конфа про коммерческие продукты. Это вам не опенсорс.
Надеюсь будет интересно 😎
Конечно ребята делают всё очень пафосно!
Докладов мало, но с другой стороны это же конфа про коммерческие продукты. Это вам не опенсорс.
Надеюсь будет интересно 😎
🎥 Как работает Search Engine под капотом: ранжирование и релевантность | Рауф Алиев #74
Хороший подкаст. Видно, что герой очень мощный специалист своего дела. Мне слушать его было приятно и весьма познавательно. Вообще, темы довольно технические и явно не для всех, поэтому выпишу буквально несколько тезисов, которые тронули моё сердечко ♥️
👉 Разные точки зрения о качестве поиска. Со стороны пользователя он работает чаще всего плохо, а со стороны бизнеса - хорошо.
👉 Автор приводит в пример сайт Amazon. Пользователи часто ругают их систему поиска 🤬. Но ИТ-команда, которая занимается поисков в Амазон одна из самых сильных в индустрии! 💪
👉 Поиск нужен пользователям, но он не нужен бизнесу.
На поиске сложно заработать и уж тем более доказать бизнесу, что многомиллионные инвестиции в это направление действительно нужны порой очень сложно 💸.
👉 Поиск очень близок к рекомендациям.
Мне даже добавить нечего.
👉 Хорошие рекомендации "очень дорого стоят". Пользователь не будет ждать так долго.
Опять выбор, либо качественно, но долго, либо быстро, но кое-как. Разработчикам приходится как-то изворачиваться, что сделать всем хорошо!
Рауф Алиев - человек, который варится в поиске уже четверть века. Он начинал с самописного inverted index в начале 2000-х, когда всё приходилось изобретать руками, и дошёл до современных гибридных систем — с векторным поиском, трансформерами и рекомендациями поверх всего этого.
Хороший подкаст. Видно, что герой очень мощный специалист своего дела. Мне слушать его было приятно и весьма познавательно. Вообще, темы довольно технические и явно не для всех, поэтому выпишу буквально несколько тезисов, которые тронули моё сердечко ♥️
👉 Разные точки зрения о качестве поиска. Со стороны пользователя он работает чаще всего плохо, а со стороны бизнеса - хорошо.
👉 Автор приводит в пример сайт Amazon. Пользователи часто ругают их систему поиска 🤬. Но ИТ-команда, которая занимается поисков в Амазон одна из самых сильных в индустрии! 💪
👉 Поиск нужен пользователям, но он не нужен бизнесу.
На поиске сложно заработать и уж тем более доказать бизнесу, что многомиллионные инвестиции в это направление действительно нужны порой очень сложно 💸.
👉 Поиск очень близок к рекомендациям.
Мне даже добавить нечего.
👉 Хорошие рекомендации "очень дорого стоят". Пользователь не будет ждать так долго.
Опять выбор, либо качественно, но долго, либо быстро, но кое-как. Разработчикам приходится как-то изворачиваться, что сделать всем хорошо!
YouTube
Как работает Search Engine под капотом: ранжирование и релевантность | Рауф Алиев #74
Сегодня у меня в гостях Рауф Алиев — человек, который варится в поиске уже четверть века. Он начинал с самописного inverted index в начале 2000-х, когда всё приходилось изобретать руками, и дошёл до современных гибридных систем — с векторным поиском, трансформерами…
❤4
📚 LSM деревья - описание структуры данных, которая лежит в основе баз данных NoSQL.
Я в своих лекциях очень мало времени уделяю описанию LSM деревьев и прочих интересных инженерных решений в современных СУБД, поэтому решил чуть-чуть закрыть этот пробел своим постом. Тем более вышла соответствующая статья по LSM.
🧠 LSM-деревья: почему NoSQL пишет быстрее, чем вы читаете?
Это структура данных, превращающая хаотичную запись в стройную очередь. Именно на ней "едут" Cassandra, RocksDB, ScyllaDB и даже движки в MongoDB (WiredTiger) и MySQL (MyRocks).
🚫 Проблема B-деревьев (классика SQL)
В PostgreSQL или MySQL изменение даже 1 байта заставляет движок перезаписывать целую страницу (8 КБ) на диске. Это порождает Random I/O и Write Amplification (усиление записи) - под большой нагрузкой диск начинает "захлебываться".
✅ Как работают LSM: Магия Append-only
Здесь ничего не перезаписывается "на месте". Путь данных выглядит так:
👉 WAL (Write Ahead Log): Сначала пишем в лог на диске. Это максимально быстро (просто допись в конец файла), зато гарантирует сохранность при сбое.
👉 MemTable (RAM): Данные попадают в память, где они сортируются.
👉SSTable (Disk): Когда память заполнена, данные сбрасываются на диск одним большим последовательным куском. Эти файлы неизменяемы (immutable).
👀 Чтение: Иголка в стоге сена
Читать из LSM сложнее, чем из B-tree. Нужно проверить память, а потом идти по файлам от новых к старым. Чтобы не «шуршать» диском зря, в RAM держат Фильтры Блума. Они мгновенно говорят: «этого ключа тут точно нет» (пропускаем файл) или "возможно, есть" (лезем на диск).
🗑 Удаление и "надгробия" 🪦
Удалить запись в LSM - значит записать её заново, но с пометкой Tombstone ("надгробие"). Старые данные физически удаляются только во время компакции — фонового слияния файлов.
🛠 Инженерные нюансы:
SSD-friendly: LSM пишет последовательно, что бережет ресурс SSD и идеально ложится на их внутреннюю архитектуру.
👉 Write Amplification никуда не делся: Он просто переехал из синхронного процесса записи в фоновый процесс компакции.
👉 Read Amplification: Чтение - "ахиллесова пята" LSM. Без фильтров Блума и правильной стратегии компакции (Leveled vs Size-Tiered) чтение может превратиться в кошмар.
👉 Tombstones могут "тормозить": Если вы удалили миллион записей, а потом делаете Scan, системе придется продраться через все эти "трупы", прежде чем она найдет живые данные.
Как итог: LSM - это осознанный обмен скорости чтения и места на диске на феноменальную пропускную способность записи.
Я в своих лекциях очень мало времени уделяю описанию LSM деревьев и прочих интересных инженерных решений в современных СУБД, поэтому решил чуть-чуть закрыть этот пробел своим постом. Тем более вышла соответствующая статья по LSM.
🧠 LSM-деревья: почему NoSQL пишет быстрее, чем вы читаете?
Это структура данных, превращающая хаотичную запись в стройную очередь. Именно на ней "едут" Cassandra, RocksDB, ScyllaDB и даже движки в MongoDB (WiredTiger) и MySQL (MyRocks).
🚫 Проблема B-деревьев (классика SQL)
В PostgreSQL или MySQL изменение даже 1 байта заставляет движок перезаписывать целую страницу (8 КБ) на диске. Это порождает Random I/O и Write Amplification (усиление записи) - под большой нагрузкой диск начинает "захлебываться".
✅ Как работают LSM: Магия Append-only
Здесь ничего не перезаписывается "на месте". Путь данных выглядит так:
👉 WAL (Write Ahead Log): Сначала пишем в лог на диске. Это максимально быстро (просто допись в конец файла), зато гарантирует сохранность при сбое.
👉 MemTable (RAM): Данные попадают в память, где они сортируются.
👉SSTable (Disk): Когда память заполнена, данные сбрасываются на диск одним большим последовательным куском. Эти файлы неизменяемы (immutable).
👀 Чтение: Иголка в стоге сена
Читать из LSM сложнее, чем из B-tree. Нужно проверить память, а потом идти по файлам от новых к старым. Чтобы не «шуршать» диском зря, в RAM держат Фильтры Блума. Они мгновенно говорят: «этого ключа тут точно нет» (пропускаем файл) или "возможно, есть" (лезем на диск).
🗑 Удаление и "надгробия" 🪦
Удалить запись в LSM - значит записать её заново, но с пометкой Tombstone ("надгробие"). Старые данные физически удаляются только во время компакции — фонового слияния файлов.
🛠 Инженерные нюансы:
SSD-friendly: LSM пишет последовательно, что бережет ресурс SSD и идеально ложится на их внутреннюю архитектуру.
👉 Write Amplification никуда не делся: Он просто переехал из синхронного процесса записи в фоновый процесс компакции.
👉 Read Amplification: Чтение - "ахиллесова пята" LSM. Без фильтров Блума и правильной стратегии компакции (Leveled vs Size-Tiered) чтение может превратиться в кошмар.
👉 Tombstones могут "тормозить": Если вы удалили миллион записей, а потом делаете Scan, системе придется продраться через все эти "трупы", прежде чем она найдет живые данные.
Как итог: LSM - это осознанный обмен скорости чтения и места на диске на феноменальную пропускную способность записи.
Medium
LSM Trees — Understanding the Data Structure that powers NoSQL databases
While we all know what data structures are used in relational databases (B trees), the implementation of a NoSQL database like Apache…
🔥5❤1
🎊 11 и 12 марта прошла конференция Monster SCALE Summit 2026 в режиме онлайн.
О том, как устроена конференция я писал ранее. Сейчас немного поговорим о докладах.
Я отсмотрел более 70% видео. Вроде бы они интересные, но какие-то скучные 😞. Может просто спикер не запал в мое сердечко, не знаю )) бывает 😁.
Расскажу про видео, которые мне откликнулись.
❇️Monster SCALE Summit 2026 | Designing Data-Intensive Applications Second Edition by Martin and Chris
По сути это небольшое интервью с авторами книги "Кабанчик 2.0". Да, да, оно уже вышло и его заказал. Когда придет, не знаю )
В целом, интервью откровенное слабое. Как журналист ведущий очень слаб. Пару тезисов я всё-таки выцепил
❇️Monster SCALE Summit 2026 | Fast and Simple Analytics on MongoDB with DuckDB by Stephanie Wang
Доклад вроде бы банальный, но меня привлекло то, что пытаются скрестить с DuckDB не РСУБД в виде PostgerSQL, а MongoDB.
1️⃣Вы пишете обычный SQL-запрос в DuckDB.
2️⃣Расширение (extension) для MongoDB «пробрасывает» фильтры и проекции в саму базу (Projection/Filter Pushdown).
3️⃣Из MongoDB извлекаются только нужные данные и передаются в DuckDB.
4️⃣DuckDB выполняет сложные джойны (joins), агрегации и оконные функции локально в памяти, используя векторный движок.
Финальный посыл: используйте подход «Local-first analytics». Начинайте с простого - используйте мощь современных локальных систем и добавляйте сложность (распределенность) только тогда, когда нагрузка этого действительно требует.
❇️Monster SCALE Summit 2026 | The Future of Data Consistency in ScyllaDB by Alex Dathskovsky
ScyllaDB явно движется к унификации вокруг Raft. Раньше для разных задач у них был “зоопарк” механизмов: gossip для cluster state, Paxos для LWT, отдельные схемы репликации и repair. Сейчас Raft уже используется для schema/topology metadata, а дальше, похоже, курс взят на более широкую strong consistency там, где она действительно нужна.
На этом фоне интересно смотреть на Redis/Valkey Cluster. Там gossip отвечает не только за membership, но и за ping/pong, обнаружение узлов, failure suspicion и распространение служебных cluster-сообщений.
Мне кажется, если Redis/Valkey когда-нибудь и пойдут в сторону Raft, то первым шагом будет “не сделать CP-систему”, а перевести на Raft control plane: membership, topology, failover decisions, config metadata. Это дало бы более детерминированное управление кластером, более предсказуемые topology changes и менее двусмысленный failover. А пользовательские данные при этом могли бы ещё долго жить в старой async-модели. Это долгий путь - и не факт, что он вообще нужен. Но как направление эволюции control plane идея выглядит вполне разумной.
❇️What Speedrunning Can Teach Us
Доклад креативный, но визуально скудный. Не хочу его пересказывать, поэтому сведу одну общую мысль:
Лучший доклад всей конференции!💪 Кайфанул очень сильно! 🔥
Сделаю отдельный разбор доклада в следующем посте! 😎
p.s. Из каждого угла сайта конференции активно пиарится книга
Database Performance at Scale: A Practical Guide. Дойдут руки, почитаю её.
О том, как устроена конференция я писал ранее. Сейчас немного поговорим о докладах.
Я отсмотрел более 70% видео. Вроде бы они интересные, но какие-то скучные 😞. Может просто спикер не запал в мое сердечко, не знаю )) бывает 😁.
Расскажу про видео, которые мне откликнулись.
❇️Monster SCALE Summit 2026 | Designing Data-Intensive Applications Second Edition by Martin and Chris
По сути это небольшое интервью с авторами книги "Кабанчик 2.0". Да, да, оно уже вышло и его заказал. Когда придет, не знаю )
В целом, интервью откровенное слабое. Как журналист ведущий очень слаб. Пару тезисов я всё-таки выцепил
👉300 000+ проданных экземпляров первого издания! Для технической книги это очень много.
👉Мартин ушел с головой в академическую деятельность и немного подотстал от техничего прогресса. Наверстать ему помог Крис. Так и получилось 2-ое издание.
👉ИИ меняет мир, но мы пока не понимаем как. То, что сегодня кажется оптимальным решением. Через полгода может стать не актуальным.
👉Мартин: Не позволяйте своим инженерам писать книги. Иначе они могут уйти!
❇️Monster SCALE Summit 2026 | Fast and Simple Analytics on MongoDB with DuckDB by Stephanie Wang
Доклад вроде бы банальный, но меня привлекло то, что пытаются скрестить с DuckDB не РСУБД в виде PostgerSQL, а MongoDB.
👉 Многие компании начинают строить аналитику с огромных стеков: ETL-процессы, хранилища (DWH) и распределенные движки. Это оправдывают «масштабируемостью» и «будущим ростом».Как это работает технологически:
👉 Однако исследования (например, данные AWS Redshift) показывают, что 99% аналитических запросов на самом деле небольшие (сканируют менее 10 ГБ данных).
1️⃣Вы пишете обычный SQL-запрос в DuckDB.
2️⃣Расширение (extension) для MongoDB «пробрасывает» фильтры и проекции в саму базу (Projection/Filter Pushdown).
3️⃣Из MongoDB извлекаются только нужные данные и передаются в DuckDB.
4️⃣DuckDB выполняет сложные джойны (joins), агрегации и оконные функции локально в памяти, используя векторный движок.
Финальный посыл: используйте подход «Local-first analytics». Начинайте с простого - используйте мощь современных локальных систем и добавляйте сложность (распределенность) только тогда, когда нагрузка этого действительно требует.
❇️Monster SCALE Summit 2026 | The Future of Data Consistency in ScyllaDB by Alex Dathskovsky
ScyllaDB явно движется к унификации вокруг Raft. Раньше для разных задач у них был “зоопарк” механизмов: gossip для cluster state, Paxos для LWT, отдельные схемы репликации и repair. Сейчас Raft уже используется для schema/topology metadata, а дальше, похоже, курс взят на более широкую strong consistency там, где она действительно нужна.
На этом фоне интересно смотреть на Redis/Valkey Cluster. Там gossip отвечает не только за membership, но и за ping/pong, обнаружение узлов, failure suspicion и распространение служебных cluster-сообщений.
Мне кажется, если Redis/Valkey когда-нибудь и пойдут в сторону Raft, то первым шагом будет “не сделать CP-систему”, а перевести на Raft control plane: membership, topology, failover decisions, config metadata. Это дало бы более детерминированное управление кластером, более предсказуемые topology changes и менее двусмысленный failover. А пользовательские данные при этом могли бы ещё долго жить в старой async-модели. Это долгий путь - и не факт, что он вообще нужен. Но как направление эволюции control plane идея выглядит вполне разумной.
❇️What Speedrunning Can Teach Us
Доклад креативный, но визуально скудный. Не хочу его пересказывать, поэтому сведу одну общую мысль:
Speedrunning учит тому, что оптимизация - это не набор хитрых трюков, а искусство выбирать маршрут, балансируя выигрыш, риск и стоимость ради лучшего общего результата.❇️You Can’t Scale When You’re Dead
Лучший доклад всей конференции!💪 Кайфанул очень сильно! 🔥
Сделаю отдельный разбор доклада в следующем посте! 😎
p.s. Из каждого угла сайта конференции активно пиарится книга
Database Performance at Scale: A Practical Guide. Дойдут руки, почитаю её.
ScyllaDB
Monster Scale Summit On Demand
Monster Scale Summit Extreme scale engineering Discover the latest trends and best practices impacting data-intensive applications. Register for access to all 60+ sessions available on demand. Featured Sessions All Sessions
❤2
🎦 You Can’t Scale When You’re Dead
Лучший доклад всей конференции по моему мнению! 💪Я слушал, смотрел видео и кайфовал! 😌
Очень много прикольный цитат. Очень здорово сделана презентация и видеоряд 🎥. Мне очень понравилось! Супер! 💥
Автор доклада - Joran Greef, Creator, Tigerbeetle.
В целом, он мне продал свою базу данных 💰. Была бы возможность, то сразу же запросил прайслист и дистриб на тестирование.
Начнем...
🛡 Масштабируемость - это не скорость. Это выживаемость
Многие думают, что масштаб - это про миллионы RPS и бесконечные кластеры. Но на самом деле масштаб - это способность системы не умереть окончательно, когда всё летит в тартарары.
Автор Tiger Beetle (БД для финтеха на языке Zig) выкатил мощный манифест о том, как пережить 1 триллион транзакций.
Вот краткая выжимка того, почему текущий стек может быть "слишком большим, чтобы выжить":
❌ Где все ошибаются?
1️⃣Шардирование (Horizontal Scaling): Оно убивает локальность кэша. Ваша CPU тратит время на ожидание сети, а не на вычисления.
2️⃣Разделение хранения и вычислений (Decoupling): Круто для аналитики, но слишком медленно для транзакций (OLTP) из-за задержек объектных хранилищ (типа S3).
3️⃣Смертельная спираль: Если база на 100 ТБ, то восстанавливается она дольше, чем падает следующий узел. Система ломается быстрее, чем чинится.
7 стадий эволюции баз данных
✅ Решение: "Диагональное масштабирование"
Вместо того чтобы просто добавлять узлы, Tiger Beetle предлагает гибрид: RSM + LSM + Object Storage.
RSM (Replicated State Machine): Обеспечивает отказоустойчивость и строгую последовательность (Strict Serializability).
LSM-деревья: Эффективно работают с иерархией памяти (кэш -> RAM -> NVMe).
Облачное хранилище: Для бесконечного и дешевого хранения исторических данных.
🚀 Результаты Tiger Beetle
800,000 транзакций в секунду на обычном кластере из 3-х узлов.
В демо-ролике система обрабатывает 800,000 транзакций в секунду (TPS) на кластере из 3 узлов (очень красивое видео).
Итог: проектируйте систему не "для работы", а "для восстановления". Если вы научите базу "оживать" за минуты при любом объеме данных, то масштаб станет бесплатным побочным эффектом.
P.s.я понимаю, что в докладе очень много маркетинга, но как же это красиво! ☺️
Лучший доклад всей конференции по моему мнению! 💪Я слушал, смотрел видео и кайфовал! 😌
Очень много прикольный цитат. Очень здорово сделана презентация и видеоряд 🎥. Мне очень понравилось! Супер! 💥
Автор доклада - Joran Greef, Creator, Tigerbeetle.
В целом, он мне продал свою базу данных 💰. Была бы возможность, то сразу же запросил прайслист и дистриб на тестирование.
Начнем...
🛡 Масштабируемость - это не скорость. Это выживаемость
Многие думают, что масштаб - это про миллионы RPS и бесконечные кластеры. Но на самом деле масштаб - это способность системы не умереть окончательно, когда всё летит в тартарары.
Автор Tiger Beetle (БД для финтеха на языке Zig) выкатил мощный манифест о том, как пережить 1 триллион транзакций.
Вот краткая выжимка того, почему текущий стек может быть "слишком большим, чтобы выжить":
❌ Где все ошибаются?
1️⃣Шардирование (Horizontal Scaling): Оно убивает локальность кэша. Ваша CPU тратит время на ожидание сети, а не на вычисления.
2️⃣Разделение хранения и вычислений (Decoupling): Круто для аналитики, но слишком медленно для транзакций (OLTP) из-за задержек объектных хранилищ (типа S3).
3️⃣Смертельная спираль: Если база на 100 ТБ, то восстанавливается она дольше, чем падает следующий узел. Система ломается быстрее, чем чинится.
➖ MTTR > MTBF➖ Масштабировать систему сложно, потому что трудно обеспечить живучесть.➖ Вы больше не являетесь владельцем Системы, Система владеет Вами
7 стадий эволюции баз данных
1. log, журнал
2. Снапшоты
3. LSM-Tree
4. Репликация машины состояние (1988, основа Ver, за 1 год до Рафта)
5. Горизонтальное масштабирование (часть состояния машины)
6. Разделись всё. Отдельно сторадж и отдельно вычисления. Айсберг
7. (диагональное масштабирование (Diagonal Scaling) RSM + LSM + Object Storage
✅ Решение: "Диагональное масштабирование"
Вместо того чтобы просто добавлять узлы, Tiger Beetle предлагает гибрид: RSM + LSM + Object Storage.
RSM (Replicated State Machine): Обеспечивает отказоустойчивость и строгую последовательность (Strict Serializability).
LSM-деревья: Эффективно работают с иерархией памяти (кэш -> RAM -> NVMe).
Облачное хранилище: Для бесконечного и дешевого хранения исторических данных.
🚀 Результаты Tiger Beetle
800,000 транзакций в секунду на обычном кластере из 3-х узлов.
В демо-ролике система обрабатывает 800,000 транзакций в секунду (TPS) на кластере из 3 узлов (очень красивое видео).
Итог: проектируйте систему не "для работы", а "для восстановления". Если вы научите базу "оживать" за минуты при любом объеме данных, то масштаб станет бесплатным побочным эффектом.
P.s.я понимаю, что в докладе очень много маркетинга, но как же это красиво! ☺️
Please open Telegram to view this post
VIEW IN TELEGRAM
ScyllaDB
You Can't Scale When You're Dead - ScyllaDB
Scale is about survivability, not just performance: a system that can't stay alive when things break can't scale at all. This talk examines the limits holding back most OLTP systems, traces database architecture through seven stages of survivability, and…
❤6🤩2🔥1
📚Почему Redis такой быстрый на одном потоке?
Люблю такие статейки про Redis. Вдруг там что-то интересное написано? Или хотя бы подача креативная? 😏
Статья длинная и мне кажется не очень понятная. Думаю стоит её чуть оживить. Краткое "самари" по ней:
Redis быстрей не только потому-то он in-memory, но потому, что он "дружит" с ядром ОС.
1️⃣. I/O Multiplexing (epoll)
Redis не ждет данных от каждого клиента. Он использует системный вызов epoll: ядро само сигнализирует, когда в сокете появились байты. Это позволяет одному потоку обслуживать тысячи соединений без переключения контекста.
2️⃣. Никаких блокировок (Locks)
В многопоточных БД потоки часто стоят в очереди за доступом к данным (lock contention). В Redis один поток, а следовательно, ноль конкуренции, ноль мьютексов, максимальная скорость CPU.
3️⃣. Но он не совсем однопоточный
👉 До v6.0: Вспомогательные потоки (BIO) уже тогда фоном чистили память и сбрасывали логи на диск.
👉 После v6.0: Появились I/O Threads. Они парсят сетевые пакеты параллельно, но команды по-прежнему выполняет только один главный поток, сохраняя атомарность.
⚠️ Нюанс:
В однопоточной среде любая команда O(n) (например, KEYS *) — это приговор. Она блокирует весь сервер для всех клиентов, пока не выполнится.
Redis - это пример того, как отказ от сложности (многопоточности) в пользу умного I/O дает предсказуемую и бешеную производительность💪
Люблю такие статейки про Redis. Вдруг там что-то интересное написано? Или хотя бы подача креативная? 😏
Статья длинная и мне кажется не очень понятная. Думаю стоит её чуть оживить. Краткое "самари" по ней:
Redis быстрей не только потому-то он in-memory, но потому, что он "дружит" с ядром ОС.
1️⃣. I/O Multiplexing (epoll)
Redis не ждет данных от каждого клиента. Он использует системный вызов epoll: ядро само сигнализирует, когда в сокете появились байты. Это позволяет одному потоку обслуживать тысячи соединений без переключения контекста.
2️⃣. Никаких блокировок (Locks)
В многопоточных БД потоки часто стоят в очереди за доступом к данным (lock contention). В Redis один поток, а следовательно, ноль конкуренции, ноль мьютексов, максимальная скорость CPU.
3️⃣. Но он не совсем однопоточный
👉 До v6.0: Вспомогательные потоки (BIO) уже тогда фоном чистили память и сбрасывали логи на диск.
👉 После v6.0: Появились I/O Threads. Они парсят сетевые пакеты параллельно, но команды по-прежнему выполняет только один главный поток, сохраняя атомарность.
⚠️ Нюанс:
В однопоточной среде любая команда O(n) (например, KEYS *) — это приговор. Она блокирует весь сервер для всех клиентов, пока не выполнится.
Redis - это пример того, как отказ от сложности (многопоточности) в пользу умного I/O дает предсказуемую и бешеную производительность💪
Medium
Redis Is Single-Threaded… So Why Is It So Fast?
Understanding Redis Internals: From Event Loops to I/O Threading
🤪3👍1
📚 Database Trends and Applications Magazine: February/March 2026
❗️Тема номера: Кто присматривает за СУБД? Как меняются роли DBA и специалистов по данным.
Дисклеймер: традиционно разбираю только небольшой набор статей.
➡️SURVEY: DATA INFRASTRUCTURE IS NOT READY FOR THE AI AGE
Традиционно 1-ая статья про ИИ. Забавно, что в этот раз она основана не на опросе компаний, а на результатах исследования компании Cockroach Labs, которое выявило серьезный разрыв между амбициями компаний в сфере ИИ и готовностью их ИТ-инфраструктуры.
1️⃣ Разрыв между амбициями и реальностью. Бизнес находится в состоянии эйфории от возможностей ИИ, но технические специалисты не могут заставить его работать 😏. Классическая ситуация, когда софт (модели ИИ) на десятилетие опередил железо и методы управления данными.
2️⃣ База данных - новое "узкое горлышко". Традиционные архитектуры просто не рассчитаны на ту интенсивность и непредсказуемость, которую создают автономные ИИ-агенты. Это всё к тому, что зарождается маркетинговый термин AI-native базы данных.
3️⃣ Управленческая слепота: Компании инвестируют в ИИ, но не получают отдачи, так как система постоянно "падает" или тормозит под нагрузкой 😞.
Мы сами сейчас внедряем свой "карманный" ИИ и сталкиваюсь с описанными проблемами. Тормозит жестко...
4️⃣ Необходимость новой архитектуры. Авторы подводят к мысли, что для эпохи ИИ нужны принципиально другие системы, например, облачно-ориентированные, способные к мгновенному масштабированию и сверхбыстрой обработке транзакций.
Кто бы сомневался 🤔 Опять облака всех спасут💭 . Ну-ну... я вижу как страны персидского залива кайфуют после выхода из строя уже двух ЦОД Amazon😶🌫️ .
➡️ Who’s Minding the Database? The Changing Role of DBAs and Data Professionals
❗️Главная статья номера.
Это явно продолжение статьи из прошлого номера.
Фу...😠 Наймите вы отдельных людей для этого. Почему все мучают бедных DBA? Не понятно... 😔
В крупных компаниях часто я слышу в адрес коллег такое:
И очень часто народ тупит над этим вопрос😵💫. Мне кажется это проверка на ЧСВ 🤴. Надо растить это чувство, чтобы народ понимал, что ты самый ох**нный специалист на свете 💪!
➡️Harnessing the Potential of CXL for Cloud-Native Databases
Статья и новой технологии CXL (Compute Express Link).
Главная идея статьи - переход от традиционного разделения ресурсов к дизагрегации памяти, что позволяет базам данных работать быстрее, надежнее и дешевле.
RDMA для disaggregated memory уже недостаточно хороша для будущих cloud-native БД, а CXL может дать более тонкий доступ к памяти, лучшую когерентность, более быстрое recovery и лучшую экономику инфраструктуры.
Технология решает главную проблему облачных БД — неэффективное использование дорогой оперативной памяти и долгие простои при сбоях.
❗️Тема номера: Кто присматривает за СУБД? Как меняются роли DBA и специалистов по данным.
Дисклеймер: традиционно разбираю только небольшой набор статей.
➡️SURVEY: DATA INFRASTRUCTURE IS NOT READY FOR THE AI AGE
Традиционно 1-ая статья про ИИ. Забавно, что в этот раз она основана не на опросе компаний, а на результатах исследования компании Cockroach Labs, которое выявило серьезный разрыв между амбициями компаний в сфере ИИ и готовностью их ИТ-инфраструктуры.
Мы сами сейчас внедряем свой "карманный" ИИ и сталкиваюсь с описанными проблемами. Тормозит жестко...
Кто бы сомневался 🤔 Опять облака всех спасут
➡️ Who’s Minding the Database? The Changing Role of DBAs and Data Professionals
❗️Главная статья номера.
Это явно продолжение статьи из прошлого номера.
Современный DBA перестает быть просто "хранителем2 серверов и становится стратегическим партнером бизнеса.
Фу...😠 Наймите вы отдельных людей для этого. Почему все мучают бедных DBA? Не понятно... 😔
DBA как «Стюард платформы данных»
Вместо того чтобы быть изолированным «контролером» (gatekeeper), специалист по данным теперь:
👉Определяет правила и стандарты (governance), по которым разработчики могут сами изменять схемы данных.
👉Отвечает за надежность и скорость данных, которые питают аналитику и ИИ.
👉Управляет стоимостью облачных ресурсов и соблюдением законодательных норм.
Роль администратора баз данных не исчезает, но радикально меняется. Она становится менее технически-рутинной и более стратегической, интересной и влиятельной для успеха всей организации. Это переход от "обслуживания инфраструктуры" к "управлению интеллектуальным капиталом компании".
В крупных компаниях часто я слышу в адрес коллег такое:
"Как твоя работа влияет на наш Бизнес? Как ты приносишь деньги?"
И очень часто народ тупит над этим вопрос😵💫. Мне кажется это проверка на ЧСВ 🤴. Надо растить это чувство, чтобы народ понимал, что ты самый ох**нный специалист на свете 💪!
➡️Harnessing the Potential of CXL for Cloud-Native Databases
Статья и новой технологии CXL (Compute Express Link).
CXL - это высокоскоростной открытый стандарт интерконнекта для когерентной связи CPU-устройств (например, ускорителей, GPU, SSD) и CPU-памяти (позволяя процессору использовать память устройств как свою собственную и наоборот).
Главная идея статьи - переход от традиционного разделения ресурсов к дизагрегации памяти, что позволяет базам данных работать быстрее, надежнее и дешевле.
RDMA для disaggregated memory уже недостаточно хороша для будущих cloud-native БД, а CXL может дать более тонкий доступ к памяти, лучшую когерентность, более быстрое recovery и лучшую экономику инфраструктуры.
Технология решает главную проблему облачных БД — неэффективное использование дорогой оперативной памяти и долгие простои при сбоях.
Lifelong Learners
...
In short, the great DBA of 2026 is a hybrid: part technologist, part strategist, part businessperson, part diplomat. They’re not just managing databases, they’re managing complexity, risk, and opportunity.
Please open Telegram to view this post
VIEW IN TELEGRAM
Database Trends and Applications
Database Trends and Applications Magazine: February/March 2026 Issue
The February/March issue of Database Trends and Applications magazine includes a special MultiValue database technology report.
📚 "дезинтермедиации" (disintermediation) баз данных
Пора почитать блоги других исследователей в области ИТ-технологий 🔎.
И так, товарищ из аналитической компании RedMonk написал статью о том, что эпоха «баз-посредников» подходит к концу. Наступает дезинтермедиация.
😵💫 Что происходит?
👉 Хранение ушло в свободное плавание. Раньше данные принадлежали базе. Теперь они лежат в дешевых облаках и открытых форматах типа Apache Iceberg, что позволяет придать «бесформенным» блобам свойства таблиц (схемы, ACID-транзакции). Это отделяет логику хранения данных от вычислительных движков.
👉 Движки запросов стали расходным материалом. Инструменты для выполнения запросов (query engines) становятся отделяемыми от уровня хранения. Это означает, что "сложность их переноса" больше не является таким серьезным барьером для смены технологий, как раньше. Привязка к вендору (Vendor Lock-in) ломается прямо на глазах.
👉 ИИ крадет интерфейс (AI-native). Зачем учить диалекты SQL, если можно спросить ИИ-агента человеческим языком? База данных превращается в «черный ящик» где-то глубоко под капотом, до которого пользователю нет дела.
👉 Стирание границ между транзакциями (OLTP) и аналитикой (OLAP). HTAP в кадым дом! Транзакционные базы (например, PostgreSQL) все чаще используются для аналитики. OLAP и OLTP системы движутся к друг другу
Конечно, старый добрый PostgreSQL не умрет завтра, можете расслабиться (он переживет нас всех). Но для новых проектов база перестает быть "священным граалем"🏆. Теперь это просто конструктор: здесь храним, там считаем, а ИИ объясняет, почему всё тормозит 🤗.
Зановес
Пора почитать блоги других исследователей в области ИТ-технологий 🔎.
База Данных традиционно является центром притяжения для ИТ-архитектуры. Мы выбирали СУБД как спутника жизни, один раз, по любви или расчету, и на всю жизнь! ❤️💋
И так, товарищ из аналитической компании RedMonk написал статью о том, что эпоха «баз-посредников» подходит к концу. Наступает дезинтермедиация.
😵💫 Что происходит?
👉 Хранение ушло в свободное плавание. Раньше данные принадлежали базе. Теперь они лежат в дешевых облаках и открытых форматах типа Apache Iceberg, что позволяет придать «бесформенным» блобам свойства таблиц (схемы, ACID-транзакции). Это отделяет логику хранения данных от вычислительных движков.
👉 Движки запросов стали расходным материалом. Инструменты для выполнения запросов (query engines) становятся отделяемыми от уровня хранения. Это означает, что "сложность их переноса" больше не является таким серьезным барьером для смены технологий, как раньше. Привязка к вендору (Vendor Lock-in) ломается прямо на глазах.
👉 ИИ крадет интерфейс (AI-native). Зачем учить диалекты SQL, если можно спросить ИИ-агента человеческим языком? База данных превращается в «черный ящик» где-то глубоко под капотом, до которого пользователю нет дела.
👉 Стирание границ между транзакциями (OLTP) и аналитикой (OLAP). HTAP в кадым дом! Транзакционные базы (например, PostgreSQL) все чаще используются для аналитики. OLAP и OLTP системы движутся к друг другу
Конечно, старый добрый PostgreSQL не умрет завтра, можете расслабиться (он переживет нас всех). Но для новых проектов база перестает быть "священным граалем"🏆. Теперь это просто конструктор: здесь храним, там считаем, а ИИ объясняет, почему всё тормозит 🤗.
Зановес
Alt + E S V
The Disintermediation of Databases
The database has been the center of gravity in data architecture for decades. It owned the storage, the query layer, and the interface. That center of gravity is changing. We’re seeing this structural erosion happening from multiple directions at once: cheaper…
🎦 The End of Eventual Consistency | CockroachDB
Кликбейтное название + тайминг в 6:28 = секрет успешного видео! Люблю такое!😍
Понятное дело, что строгая согласованность лучше согласованности в конечном счета. Это понятно 👌
В целом, автор видео это наглядно нам продемонстрировал.
Меня в этом видео зацепил сам эксперимент.
Автор взял кластер из трех нод CockroachDB (3 мастера) и RDS for PostgreSQL (1 мастер + 2 реплика. Причем не понятно, репликация синхронная или асинхронная)
Затем смоделировал нагрузку, а-ля, e-commerce-сценарий в котором агенты (или пользователи) создают и забирают ваучеры.
Тест запускался параллельно для 10 агентов, где каждый создавал по 100 ваучеров.
Результаты очевидны:
В целом, ничего удивительного. Но мне захотелось воспроизвести этот сценарий тестирования. Надо бы написать подобный скрипт с нагрузкой и проверить его на Постгресе с двумя синхронными репликами. Еще можно собрать мастер-мастер кластер из трех нод на PostgresPro дистрибутиве . Мне кажется результаты будут другие.
В общем, отличная тема для открытого урока!
Возьму на заметку 📝
Кликбейтное название + тайминг в 6:28 = секрет успешного видео! Люблю такое!
Понятное дело, что строгая согласованность лучше согласованности в конечном счета. Это понятно 👌
В целом, автор видео это наглядно нам продемонстрировал.
Меня в этом видео зацепил сам эксперимент.
Автор взял кластер из трех нод CockroachDB (3 мастера) и RDS for PostgreSQL (1 мастер + 2 реплика. Причем не понятно, репликация синхронная или асинхронная)
Затем смоделировал нагрузку, а-ля, e-commerce-сценарий в котором агенты (или пользователи) создают и забирают ваучеры.
Тест запускался параллельно для 10 агентов, где каждый создавал по 100 ваучеров.
Результаты очевидны:
🪳 CockroachDB
все ваучеры созданы и захвачены корректно, без дублирования (Strong Consistance всё-таки)🐘 RDS PostgreSQL
В "вежливом" режиме, 36 случаев двойного захвата одного ваучера. В "невежливом" режиме. появились случаи тройного захвата. Причина в том, что агент проверяет статус ваучера на реплике, где данные ещё не обновились, и повторно захватывает уже занятый ресурс.
В целом, ничего удивительного. Но мне захотелось воспроизвести этот сценарий тестирования. Надо бы написать подобный скрипт с нагрузкой и проверить его на Постгресе с двумя синхронными репликами. Еще можно собрать мастер-мастер кластер из трех нод на PostgresPro дистрибутиве . Мне кажется результаты будут другие.
В общем, отличная тема для открытого урока!
Возьму на заметку 📝
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
The End of Eventual Consistency | CockroachDB
This video demonstrates why eventual consistency in databases is becoming increasingly problematic with the rise of AI agents. Rob Reid explains why choosing a database built for strong consistency reduces the complexity and potential for error in rapidly…