📚 Database Trends and Applications Magazine: April/May 2026
❗️Тема номера: Рост "AI-Ready" современных платформ данных
Дисклеймер: тема AI меня начинает бесить больше и больше. Такое ощущение, что кроме AI нет ничего важного мире данных. Ладно, не буду дальше ныть, а просто расскажу про несколько статей из номер.
➡️Survey: AI Is Boosting Enterprise Data Leaders’ Influence
AI усиливает не только спрос на модели, но и спрос на зрелое управление данными. Без качественных данных, governance и понятной инфраструктуры AI быстро превращается в дорогую демонстрацию без бизнес-эффекта
➡️The Rise of the AI-Ready Modern Data Platforms
AI-ready data platform - это не "прикрутили LLM к DWH". Это зрелая платформа с governance, качеством данных, наблюдаемостью, автоматизацией изменений и понятным бизнес-контекстом. Без этого AI будет не ускорителем бизнеса, а генератором дорогих ошибок. Короче, нужно расширятьи углублять навыки System Design для работы AI-сервисов вашей компании.
➡️ Database Virtualization is the Key to Agile DevOps
По мне все эти методики с генерацией prodution-like баз очень сильно заточены под конкретного клиента. Я не верю, что можно сделать универсальный генератор, который всем подойдет. Я с этим рынком не знаком, поэтому не буду возводить свой тезис в абсолют❤️ 🌟 .
➡️ Stop Leaks in Your Cloud Bill with Quest Software
"Плохие" данные стоят денег дважды - сначала за хранение, потом за каждый лишний пересчёт, обновление и кривых пайплайнов.
➡️The Great Security Culture Shift: Building a Proactive Defense in an Era of Advanced Threat and Social Engineering
Главный тезис:
Утопия. Я это все это читаю и думаю, для кого это говорится и пишется? 🤷♂️ В банковской сфере обучение ИБ проводится каждый год и на протяжении года случаются 100500 инцидентов из-за... назовем это "глупости людей". А тут автор говорит о развитии понимания людей современных схем атак. Оййй... Благая идея, но не осуществимая .
➡️ The Two Most Important ‘Things’ for Database Performance
Мне кажется это прекрасный финальный аккорд для текущего номера журнала 😎
❗️Тема номера: Рост "AI-Ready" современных платформ данных
Дисклеймер: тема AI меня начинает бесить больше и больше. Такое ощущение, что кроме AI нет ничего важного мире данных. Ладно, не буду дальше ныть, а просто расскажу про несколько статей из номер.
➡️Survey: AI Is Boosting Enterprise Data Leaders’ Influence
AI усиливает не только спрос на модели, но и спрос на зрелое управление данными. Без качественных данных, governance и понятной инфраструктуры AI быстро превращается в дорогую демонстрацию без бизнес-эффекта
➡️The Rise of the AI-Ready Modern Data Platforms
Все хотят внедрять ИИ, но их существующие инфраструктуры и данные к этому не готовы.
AI-ready data platform - это не "прикрутили LLM к DWH". Это зрелая платформа с governance, качеством данных, наблюдаемостью, автоматизацией изменений и понятным бизнес-контекстом. Без этого AI будет не ускорителем бизнеса, а генератором дорогих ошибок. Короче, нужно расширять
➡️ Database Virtualization is the Key to Agile DevOps
Виртуализация баз данных. Вместо долгого копирования production-баз для тестов создаются быстрые, lightweight, self-service копии/окружения с production-like данными. Это позволяет разработчикам быстрее поднимать тестовые стенды, воспроизводить баги, обновлять данные и т.д.
По мне все эти методики с генерацией prodution-like баз очень сильно заточены под конкретного клиента. Я не верю, что можно сделать универсальный генератор, который всем подойдет. Я с этим рынком не знаком, поэтому не буду возводить свой тезис в абсолют
➡️ Stop Leaks in Your Cloud Bill with Quest Software
Компании незаметно теряют деньги в облачных data platforms, особенно в Snowflake. Основные “утечки”:
👉 дублирование датасетов и витрин;
👉 повторная сборка того, что уже существует;
👉 плохое качество данных;
👉 отсутствие владельцев, SLA и lineage;
👉 shadow datasets, которые аналитики создают, потому что не доверяют существующим источникам
"Плохие" данные стоят денег дважды - сначала за хранение, потом за каждый лишний пересчёт, обновление и кривых пайплайнов.
➡️The Great Security Culture Shift: Building a Proactive Defense in an Era of Advanced Threat and Social Engineering
Главный тезис:
Безопасность больше нельзя строить только на антивирусах и реагировании на инциденты. Нужна культура, где пользователи понимают современные схемы атак, а инфраструктура заранее ограничивает возможность вредоносного кода получить привилегии.
Утопия. Я это все это читаю и думаю, для кого это говорится и пишется? 🤷♂️ В банковской сфере обучение ИБ проводится каждый год и на протяжении года случаются 100500 инцидентов из-за... назовем это "глупости людей". А тут автор говорит о развитии понимания людей современных схем атак. Оййй... Благая идея, но не осуществимая .
➡️ The Two Most Important ‘Things’ for Database Performance
Перед тем как искать сложные причины медленных запросов - железо, параметры СУБД, кеши, параллелизм, - стоит проверить два фундаментальных пункта: актуальна ли статистика и есть ли адекватные индексы под вашу нагрузку.
Мне кажется это прекрасный финальный аккорд для текущего номера журнала 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Database Trends and Applications
Database Trends and Applications Magazine: April/May 2026 Issue
This issue features cover story, 'The Rise of the AI-Ready Modern Data Platforms.'
💬 Возврат к автономным базам данных
Как только СУБД стали сложными промышленными системами, возникло естественное желание, а нельзя ли научить базу самой подстраиваться под нагрузку, выбирать настройки, диагностировать проблемы, чинить себя и снижать зависимость от ручной работы DBA? 🧐
На практике путь оказался не простым. До полноценной "автономной базы" индустрия шла через отдельные self-managing-функции: автоматический сбор статистики, advisors, tuning tools, автоматическое управление памятью, хранилищем, индексами и планами запросов. То есть шаги были, но чаще это были отдельные подсистемы, а не цельная автономная СУБД.
В 2017 году Oracle громко объявила Autonomous Database Cloud на Oracle OpenWorld, а в 2018 начала активно продвигать Autonomous Database как self-driving, self-securing и self-repairing cloud-сервис. Но автономные БД так и не стали универсальным стандартом рынка 😞. Скорее они остались важным направлением автоматизации, а не полной заменой DBA.
Почему создать по-настоящему автономную базу сложно? 🧐
Во-первых, нет простого критерия "сделай хорошо". Для одной нагрузки важнее latency, для другой throughput, для третьей стоимость, для четвёртой предсказуемость и отказоустойчивость.
Во-вторых, есть проблема "холодного" старта. Чтобы хорошо настраиваться, база должна понимать workload, данные, сезонность, пики, бизнес-критичность операций и ограничения инфраструктуры.
В-третьих, автоматизация не отменяет скрытые затраты и vendor lock-in. Чем умнее managed-сервис, тем сложнее понять, что именно он делает внутри и насколько легко будет уйти на другую платформу.
В-четвёртых, передача контроля автоматике требует пересмотра модели безопасности и ответственности. Кто виноват, если AI-рекомендация сломала производительность? Кто отвечает, если автоматика выбрала не тот план, не тот индекс или не ту стратегию восстановления?
И главное:
Однако тема снова оживает на фоне Kubernetes, managed services, autonomous databases и AI-агентов. Но вывод получается не в том, что DBA исчезает. Скорее наоборот: меняется сама роль DBA. Надсмотрщик за СУБД никуда не девается 😊
Раньше значительная часть работы была про ручную операционку: установить СУБД, настроить бэкапы, обновить версию, следить за мониторингом, чинить инциденты, подкрутить параметры. Сейчас всё больше этой рутины уходит в Kubernetes-операторы, облачные managed-сервисы и автоматизированные платформы.
Но база данных остаётся сложной системой. AI-агент может помочь написать код, подсказать настройку или найти подозрительный паттерн в логах. Но он пока не несёт ответственности за корректность данных, архитектурные компромиссы и последствия сбоя.
Ценность DBA всё меньше в том, чтобы руками выполнять повторяемые операции, и всё больше - в том, чтобы понимать, что именно автоматизируется, какие риски остаются и где автоматика может ошибиться.
Хороший DBA будущего - это уже не просто "администратор базы". Это database architect / data infrastructure engineer: человек, который понимает СУБД, облака, Kubernetes, надёжность, производительность, стоимость и бизнес-критичность данных.
1️⃣ Why the need for humans won’t disappear in the age of autonomous databases
2️⃣ Autonomous agents have met their biggest challenge yet: The database
Как только СУБД стали сложными промышленными системами, возникло естественное желание, а нельзя ли научить базу самой подстраиваться под нагрузку, выбирать настройки, диагностировать проблемы, чинить себя и снижать зависимость от ручной работы DBA? 🧐
На практике путь оказался не простым. До полноценной "автономной базы" индустрия шла через отдельные self-managing-функции: автоматический сбор статистики, advisors, tuning tools, автоматическое управление памятью, хранилищем, индексами и планами запросов. То есть шаги были, но чаще это были отдельные подсистемы, а не цельная автономная СУБД.
В 2017 году Oracle громко объявила Autonomous Database Cloud на Oracle OpenWorld, а в 2018 начала активно продвигать Autonomous Database как self-driving, self-securing и self-repairing cloud-сервис. Но автономные БД так и не стали универсальным стандартом рынка 😞. Скорее они остались важным направлением автоматизации, а не полной заменой DBA.
Почему создать по-настоящему автономную базу сложно? 🧐
Во-первых, нет простого критерия "сделай хорошо". Для одной нагрузки важнее latency, для другой throughput, для третьей стоимость, для четвёртой предсказуемость и отказоустойчивость.
Во-вторых, есть проблема "холодного" старта. Чтобы хорошо настраиваться, база должна понимать workload, данные, сезонность, пики, бизнес-критичность операций и ограничения инфраструктуры.
В-третьих, автоматизация не отменяет скрытые затраты и vendor lock-in. Чем умнее managed-сервис, тем сложнее понять, что именно он делает внутри и насколько легко будет уйти на другую платформу.
В-четвёртых, передача контроля автоматике требует пересмотра модели безопасности и ответственности. Кто виноват, если AI-рекомендация сломала производительность? Кто отвечает, если автоматика выбрала не тот план, не тот индекс или не ту стратегию восстановления?
И главное:
Как обучить базу данных мыслить?
Однако тема снова оживает на фоне Kubernetes, managed services, autonomous databases и AI-агентов. Но вывод получается не в том, что DBA исчезает. Скорее наоборот: меняется сама роль DBA. Надсмотрщик за СУБД никуда не девается 😊
Раньше значительная часть работы была про ручную операционку: установить СУБД, настроить бэкапы, обновить версию, следить за мониторингом, чинить инциденты, подкрутить параметры. Сейчас всё больше этой рутины уходит в Kubernetes-операторы, облачные managed-сервисы и автоматизированные платформы.
Но база данных остаётся сложной системой. AI-агент может помочь написать код, подсказать настройку или найти подозрительный паттерн в логах. Но он пока не несёт ответственности за корректность данных, архитектурные компромиссы и последствия сбоя.
Ценность DBA всё меньше в том, чтобы руками выполнять повторяемые операции, и всё больше - в том, чтобы понимать, что именно автоматизируется, какие риски остаются и где автоматика может ошибиться.
Хороший DBA будущего - это уже не просто "администратор базы". Это database architect / data infrastructure engineer: человек, который понимает СУБД, облака, Kubernetes, надёжность, производительность, стоимость и бизнес-критичность данных.
1️⃣ Why the need for humans won’t disappear in the age of autonomous databases
2️⃣ Autonomous agents have met their biggest challenge yet: The database
The New Stack
Why the need for humans won’t disappear in the age of autonomous databases
Percona co-founder Vadim Tkachenko says the DBA role isn't dying — it's evolving into data architecture as AI and Kubernetes reshape database management.
🤔2👍1
📚 Не хочу писать отдельные посты, поэтому просто разберу несколько интересных статей с Хабра 🙂
Масштабируй! Почему Cassandra 5 стала спасением, а FoundationDB прилегла в чулан
Спусти 3 месяца товарищи из Авито решили выпустить текстовую версию своего доклада с митапа от 1 апреля.
Статья набрала 9 лайков, поэтому можно смело сказать, что она так се. Если кому-то интересно освежить её в памяти, то можно пролистать... 🎩
«Лягут все», или почему у российских компаний проблемы с disaster recovery
Самая "вкусняшка" в комментариях к статье ☺️.
По сути одним из драйверов роста распределенные системы является страх отказа ЦОД. Поэтому все стараются распределить свою инфраструктуру на 2, 3 или даже больше ЦОДов. Люди тестируют миграцию, восстановление после отказа одного из ЦОД и т.д. Все это считается Disaster Recovery Plan. ✨
Как подметили в комментах зафиксирована масса случаев, когда сервисы крупных компаний не работали днями, неделями или даже месяцами 😨😱! И...ни чё, пережили как-то . Да, было грустно, но не смертельно🤪. Возникает мысль не слишком ли переоцениваем нужду в DR-сайте? Возможно стоит пересмотреть систему рисков. 🥸
Разбираемся с лицензией Redis. И что выбрать продуктовой команде
Как надоели люди, которые вспоминают KeyDB и пытаются его сунуть в какие-то сравнения. Ну, всё уже. Это мертвый проект ☠️. Ни будет ничего ⚰️. Забудьте уже о нем. Нет, автор опять что-то пытается доказать....
Короче, для РФ можно использовать и Redis и Valkey. Кому, что нравится больше. Я за Valkey конечно 😬
ObjectId против UUID: как выбор _id в MongoDB влияет на API, индексы и миграции
Прочел статью 2 раза и ничего не понял 🤨
"что такое хорошо и что такое плохо..."
Даже ИИшка не помогла 🙃
Единственное, что можно уловить:
Если кто-то что-то полезно из статьи извлечет, напишите мне
Масштабируй! Почему Cassandra 5 стала спасением, а FoundationDB прилегла в чулан
Спусти 3 месяца товарищи из Авито решили выпустить текстовую версию своего доклада с митапа от 1 апреля.
Статья набрала 9 лайков, поэтому можно смело сказать, что она так се. Если кому-то интересно освежить её в памяти, то можно пролистать... 🎩
«Лягут все», или почему у российских компаний проблемы с disaster recovery
Самая "вкусняшка" в комментариях к статье ☺️.
По сути одним из драйверов роста распределенные системы является страх отказа ЦОД. Поэтому все стараются распределить свою инфраструктуру на 2, 3 или даже больше ЦОДов. Люди тестируют миграцию, восстановление после отказа одного из ЦОД и т.д. Все это считается Disaster Recovery Plan. ✨
Как подметили в комментах зафиксирована масса случаев, когда сервисы крупных компаний не работали днями, неделями или даже месяцами 😨😱! И...ни чё, пережили как-то . Да, было грустно, но не смертельно🤪. Возникает мысль не слишком ли переоцениваем нужду в DR-сайте? Возможно стоит пересмотреть систему рисков. 🥸
Разбираемся с лицензией Redis. И что выбрать продуктовой команде
Как надоели люди, которые вспоминают KeyDB и пытаются его сунуть в какие-то сравнения. Ну, всё уже. Это мертвый проект ☠️. Ни будет ничего ⚰️. Забудьте уже о нем. Нет, автор опять что-то пытается доказать....
Короче, для РФ можно использовать и Redis и Valkey. Кому, что нравится больше. Я за Valkey конечно 😬
ObjectId против UUID: как выбор _id в MongoDB влияет на API, индексы и миграции
Прочел статью 2 раза и ничего не понял 🤨
"что такое хорошо и что такое плохо..."
Даже ИИшка не помогла 🙃
Единственное, что можно уловить:
"разработчики Монги придумали ObjectId. Какие молодцы эти ребята! Класс! "
Если кто-то что-то полезно из статьи извлечет, напишите мне
😁5👍3
📚 We Deleted Redis And Saved Thousands Per Month
❇️Кратенько по статье.
В проекте используется Redis как кэш к основной СУБД PostgreSQL. После детального оценки потоки данных и нагрузки поняли, что Redis в основном ничего толком не делает. Бездельничает.
По итогу неиспользуемый session store удалили, неэффективный кэш отключили, а очередь перенесли в PostgreSQL. И всё стало хорошо.
❇️В целом, идея здравая. Вообще тема аудита и выявление неиспользуемых или редко используемых ресурсов крайне объемна! Наверняка в вашей компании есть сервера, которые просто включены в розетку и ничего не делают. Наверняка из-за каких-то ваших внутренних правил сервис, которым пользуется "1.5 калеки" нужно обязательно резервировать, бэкапить и даже в DR-план его включать. Что непременно бьёт по бюджету на поддержку этого монстра.
Аудит проводить нужно и делать это следует грамотно! Но сколько я за всю жизнь участвовать в подобных инициативах в конце всегда всем ставится пофигу 🥱. Просто потому-то это ОЧЕНЬ долго, муторно и скучно.
Провели аудит, чуть оптимизировали ресурсы и ладно! Сойдёт... 🤓
❇️Кратенько по статье.
В проекте используется Redis как кэш к основной СУБД PostgreSQL. После детального оценки потоки данных и нагрузки поняли, что Redis в основном ничего толком не делает. Бездельничает.
По итогу неиспользуемый session store удалили, неэффективный кэш отключили, а очередь перенесли в PostgreSQL. И всё стало хорошо.
Вывод такой: нужно периодически проверять, действительно ли инфраструктурный компонент всё ещё необходим.
❇️В целом, идея здравая. Вообще тема аудита и выявление неиспользуемых или редко используемых ресурсов крайне объемна! Наверняка в вашей компании есть сервера, которые просто включены в розетку и ничего не делают. Наверняка из-за каких-то ваших внутренних правил сервис, которым пользуется "1.5 калеки" нужно обязательно резервировать, бэкапить и даже в DR-план его включать. Что непременно бьёт по бюджету на поддержку этого монстра.
Аудит проводить нужно и делать это следует грамотно! Но сколько я за всю жизнь участвовать в подобных инициативах в конце всегда всем ставится пофигу 🥱. Просто потому-то это ОЧЕНЬ долго, муторно и скучно.
Провели аудит, чуть оптимизировали ресурсы и ладно! Сойдёт... 🤓
Medium
We Deleted Redis And Saved Thousands Per Month
We Deleted Redis And Saved Thousands Per Month The room did not go quiet because it was a bad question. It went quiet because it was a devastating one. How We Got Here We inherited a Node.js monolith …
👍3
📚 We Replaced Redis, Elasticsearch, And Kafka With PostgreSQL — Here’s What Happened
Изначально использовались четыре системы:
А теперь так
Всё больше в умах людей поселяется мысль, что PostgreSQL - это комбайн, который может делать всё! Да, не идеально, но в большинстве случаев это более, чем достаточно!
Мне кажется начинает упрощаться System Design. Ставишь везде Постгрес, затем его тюнишь под нужные требования. Готото! 🫨
Вряд ли кто-то сможет доказать, что ты не прав 😎
Изначально использовались четыре системы:
PostgreSQL — основная база;
Redis — кэш и Pub/Sub;
Kafka — передача событий;
Elasticsearch — полнотекстовый поиск.
А теперь так
👉 поиск — на встроенный Full Text Search, tsvector и GIN-индексы;
👉 уведомления и простой Pub/Sub — на LISTEN/NOTIFY;
👉 обработку событий и фоновых заданий на таблицы очередей и транзакционные механизмы PostgreSQL;
👉 часть кэширования на оптимизированные запросы или временные данные в самой базе.
Всё больше в умах людей поселяется мысль, что PostgreSQL - это комбайн, который может делать всё! Да, не идеально, но в большинстве случаев это более, чем достаточно!
Мне кажется начинает упрощаться System Design. Ставишь везде Постгрес, затем его тюнишь под нужные требования. Готото! 🫨
Вряд ли кто-то сможет доказать, что ты не прав 😎
Medium
We Replaced Redis, Elasticsearch, And Kafka With PostgreSQL — Here’s What Happened
We Replaced Redis, Elasticsearch, And Kafka With PostgreSQL — Here’s What Happened Your infrastructure is not a resume. It does not need Redis, Kafka, and Elasticsearch listed on it to be …
🔥2😁2
📚 Neo4j for Engineers Who Already Know Databases
Редко попадается что-то стоящие и это как раз случай найти что-то блестящие на в горе песка.
Это вводная статья по Neo4j, но с опорой на то, что вы уже знакомы с реляционной теорией. Автор не объясняет графы «с нуля», а показывает, чем меняются проектирование, запросы, оптимизация и масштабирование системы после перехода от таблиц к графовой модели.
Весь материал построен вокруг условного интернет-магазина
Я как раз хотел переписать свою лекцию по Neo4j в курсе. Думаю многие идеи из статьи возьму для курса.
Редко попадается что-то стоящие и это как раз случай найти что-то блестящие на в горе песка.
Это вводная статья по Neo4j, но с опорой на то, что вы уже знакомы с реляционной теорией. Автор не объясняет графы «с нуля», а показывает, чем меняются проектирование, запросы, оптимизация и масштабирование системы после перехода от таблиц к графовой модели.
Весь материал построен вокруг условного интернет-магазина
Shopgraph: пользователи подписываются друг на друга, создают заказы и покупают товары. На этом примере автор сравнивает SQL-запрос с несколькими JOIN и Cypher-запрос, непосредственно описывающий путь:пользователь → знакомый → заказ → товар.
Я как раз хотел переписать свою лекцию по Neo4j в курсе. Думаю многие идеи из статьи возьму для курса.
❤1
📚 Предзаказ на книгу: «Высоконагруженные приложения. Программирование, масштабирование, поддержка. 2-е изд.»
Оформил предзаказ. Жду конца сентября⏳ .
Я уверен на ВСЕХ ИТ-конференциях осени-зимы это будет ТОП лидеров продаж! 💪 Я даже задумываюсь в подарок пару экземпляров взять 🤔.
Оформил предзаказ. Жду конца сентября
Я уверен на ВСЕХ ИТ-конференциях осени-зимы это будет ТОП лидеров продаж! 💪 Я даже задумываюсь в подарок пару экземпляров взять 🤔.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
📚 Я протестировал TerraMaster F4-425 Pro. Зачем современному NAS одновременно HDD и NVMe
Меня очень привлекает идея домашнего NAS хранилища. Много изучал в свое время, но так не и не решился купить.
Сейчас опять задумался на эту тему, но не могу себя убедить в его необходимости. Текущих ресурсов ноутбука мне хватает. Каких-то огромных фильмотек/фототек у меня нет. Всё вполне укладываться в 50/100 ГБ. Облачное хранилища мне выше крыши. Но почему-то очень хочется его купить...
Прикинул, по деньгам получается 100 000+ рубликов. Можно что-то дешевле взять, но если мы говорим о тандеме NAS сервер + ИБП + 1 NVMe + 2 HDD (5 TB) - то меньше не получается 😊
Может к новому году созрею или проект какой-то денежный подвернется и на эти деньги куплю NAS, не знаю.
Если у кого-то есть опыт активной работы с NAS, то напишите. Интересно почитать...
Например, на нем могут работать:➖ Docker-контейнеры;➖ виртуальные машины;➖ Plex или Jellyfin;➖ Nextcloud;➖ системы резервного копирования;➖ менеджеры фотографий;➖ базы данных;➖ Git-сервер;➖ домашняя автоматизация.
Меня очень привлекает идея домашнего NAS хранилища. Много изучал в свое время, но так не и не решился купить.
Сейчас опять задумался на эту тему, но не могу себя убедить в его необходимости. Текущих ресурсов ноутбука мне хватает. Каких-то огромных фильмотек/фототек у меня нет. Всё вполне укладываться в 50/100 ГБ. Облачное хранилища мне выше крыши. Но почему-то очень хочется его купить...
Прикинул, по деньгам получается 100 000+ рубликов. Можно что-то дешевле взять, но если мы говорим о тандеме NAS сервер + ИБП + 1 NVMe + 2 HDD (5 TB) - то меньше не получается 😊
Может к новому году созрею или проект какой-то денежный подвернется и на эти деньги куплю NAS, не знаю.
Если у кого-то есть опыт активной работы с NAS, то напишите. Интересно почитать...
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1
Решил глянуть 👀 несколько выступлений кое-как связанных с базами данных.
1️⃣ DWH‑инженер на стероидах: прокачиваем продуктивность с ИИ
Никита Бурковский, Data Engineer, BI Consult
Преза
Я ожидал от доклада каких-то откровений, но... получил что-то другое 🙃. Если кратко описать доклад, то автор открыл для себя ИИ-помощника. Затем скормил ему данные своего проекта/ов. И всё. Теперь все типовые инженерные задачи выполняются в разы проще 🤓. Даже ревью. Попутно дописал несколько ботов/роботов для еще большего упрощения задач 💪.
Об этом весь доклад 🤨.
Из интересного я бы отметил секцию, где автор совместно с ИИ пытались доработать схему данных. Почему-то ИИ показал себя слабее, чем ожидалось. Почему? Загадка... 🤷♂️
2️⃣ Ломаем PostgreSQL Jepsen’ом и верифицируем локи в TLA+: два подхода к надёжности распределённых систем
Евгений Дюков, Ведущий разработчик Managed Databases, Yandex Cloud
Преза
Евгений довольно опытный спикер от Яндекса💪. Очень часто выступает на различных конференциях и рассказывает об интересных вещах. Поэтому я
Фактически он рассказал о том, как использовал Jepsen, что-то там дописа/переписал. Попробовал TLA+ и PlusCal снова что-то там недополучил и собственно, конец🤨. Каких-то выводов нет.
Наверное цель была донести, что Яндекс использует популярные фреймворки для тестирования распределенных систем и пишет свои🥸. Пытается сделать фреймворк для тестирования устойчивость распределенных систем на выбранном участке кода. QA-фреймворк с кучей заглушек.
Откровений нет. Что-то в этом году уровень докладов низковат.🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
Мероприятия | Yandex Infrastructure
infra.conf 2026. Конференция Yandex Infrastructure.
Всё про создание инфраструктуры и высоконагруженные системы, инструменты разработки, базы данных и стораджи, построение и особенности эксплуатации инфраструктуры в эпоху ML.
👀1
📚 Новая СУБД «СберТеха» включена в реестр российского ПО
Нежданно негаданно СБТ анонсировали новую СУБД О.К.Е.А.Н. На оф сайте звучит как, Platform V Ocean DB. Даже в реестре отечественно ПО успели засветиться. Запись №33689 датирована 21 мая 2026 года.
❇️ Что это "зверь" такой?
Это наш отечественный форк опенсорс проекта OceanBase.
Как я понял, это пополнение в рядах DistributedSQL СУБД.
Её ключевая комбинация:
То есть это потенциальная замена сложной связке из MySQL/PostgreSQL, шардирующего middleware, CDC и отдельного ClickHouse.
Ближайшие аналоги: TiDB, PolarDB-X, YugabyteDB, CockroachDB и YDB.
К сожалению никаких публичных внедрений, независимых тестов нет - поэтому судить о какой-то зрелости продукта затруднительно.
Буду следить на анонсами СБТ. Я думаю осенью на ИТ-конференциях расскажут побольше о новинке. Ждемс...
Нежданно негаданно СБТ анонсировали новую СУБД О.К.Е.А.Н. На оф сайте звучит как, Platform V Ocean DB. Даже в реестре отечественно ПО успели засветиться. Запись №33689 датирована 21 мая 2026 года.
❇️ Что это "зверь" такой?
Это наш отечественный форк опенсорс проекта OceanBase.
Как я понял, это пополнение в рядах DistributedSQL СУБД.
Её ключевая комбинация:
👉 горизонтальное масштабирование записи;
👉 автоматический шардинг и ребалансировка;
👉 ACID-транзакции между узлами;
👉 отказоустойчивость без переключения всей базы;
👉 HTAP: транзакции и аналитика на одних данных;
👉 MySQL-совместимый интерфейс.
То есть это потенциальная замена сложной связке из MySQL/PostgreSQL, шардирующего middleware, CDC и отдельного ClickHouse.
Ближайшие аналоги: TiDB, PolarDB-X, YugabyteDB, CockroachDB и YDB.
К сожалению никаких публичных внедрений, независимых тестов нет - поэтому судить о какой-то зрелости продукта затруднительно.
Буду следить на анонсами СБТ. Я думаю осенью на ИТ-конференциях расскажут побольше о новинке. Ждемс...
😁2👍1
⚡️⚡️⚡️ClickHouse launches ClickHouse Labs with Andy Pavlo as VP of Database Research
Алексей Миловидов открывает исследовательскую лабораторию ClickHouse Labs. Его вице-президентом назначается один из самых известных исследователей по базам данных Энди Павло из университета Карнеги‑Меллона (CMU).
Очень мощная коллаборация💪! У Энди богатый опыт во множестве проектов и здорово, что он наконец-то нашел спонсора💰💰💰
Ждем крутых открытий в 2027 году ✨
Алексей Миловидов открывает исследовательскую лабораторию ClickHouse Labs. Его вице-президентом назначается один из самых известных исследователей по базам данных Энди Павло из университета Карнеги‑Меллона (CMU).
Очень мощная коллаборация💪! У Энди богатый опыт во множестве проектов и здорово, что он наконец-то нашел спонсора💰💰💰
Ждем крутых открытий в 2027 году ✨
ClickHouse
ClickHouse launches ClickHouse Labs with Andy Pavlo as VP of Database Research | ClickHouse
Renowned database researcher will lead a new group dedicated to advancing foundational database technology and sharing its work openly with the broader community.
🔥6
📚 Почти 7% компаний вернулись с российских СУБД на иностранные
Люблю провокационные статьи до жути 😊
Давайте чуть порассуждаем об обратной стороне импортозамещения СУБД
Общий тренд понятен: компании уходят с Oracle и Microsoft SQL Server на российские решения. Но миграция не всегда заканчивается промышленным запуском.
Иногда проект останавливают ещё на пилоте или откладывают на неопределённый срок. Причины могут быть следующие:
В результате компания может продолжать использовать зарубежную СУБД без официальной поддержки в России. DBA самостоятельно устанавливают обновления. Сами патчи можно получить через друзей-знакомых. В крайнем случае закупать поддержку через посредников. Банальная "заморозка" версии ПО тоже работает.
Публичных примеров окончательного возврата немного. Ладно, их почти нет. Кто в здравом уме будет писать, что проект перехода на отечественно ПО провалился? Никто.
Компании не любят рассказывать о неудачных проектах.
Поэтому все рассуждения и выводы строятся на инсайдах бесед с коллегами "по цеху".
Мое мнение остается прежним. Кто хотел мигрировать на отечественные СУБД уже мигрировал или находится на в финишной прямой по закрытию проекта. Остальным это просто не нужно.
Недавнее сообщения от PostgresPro о массовых сокращениях лишь подтверждают это. Проектом стало мало, а народу много. Закрыли проект, спасибо, всем пока👋
Люблю провокационные статьи до жути 😊
Импортозамещение - фуфло! Оно провалится рано или поздно! Западные решения лучше!! И бла-бла-бла... Кайф 😋
Давайте чуть порассуждаем об обратной стороне импортозамещения СУБД
Общий тренд понятен: компании уходят с Oracle и Microsoft SQL Server на российские решения. Но миграция не всегда заканчивается промышленным запуском.
Иногда проект останавливают ещё на пилоте или откладывают на неопределённый срок. Причины могут быть следующие:
👉 производительность на реальной нагрузке оказалась ниже ожидаемой;
👉 приложение слишком сильно зависит от PL/SQL и других функций Oracle;
👉 стоимость переделки превышает экономический эффект;
👉 не хватает специалистов и зрелых инструментов миграции;
👉 бизнес не готов принять риск простоя критической системы.
В результате компания может продолжать использовать зарубежную СУБД без официальной поддержки в России. DBA самостоятельно устанавливают обновления. Сами патчи можно получить через друзей-знакомых. В крайнем случае закупать поддержку через посредников. Банальная "заморозка" версии ПО тоже работает.
Публичных примеров окончательного возврата немного. Ладно, их почти нет. Кто в здравом уме будет писать, что проект перехода на отечественно ПО провалился? Никто.
Компании не любят рассказывать о неудачных проектах.
Поэтому все рассуждения и выводы строятся на инсайдах бесед с коллегами "по цеху".
Мое мнение остается прежним. Кто хотел мигрировать на отечественные СУБД уже мигрировал или находится на в финишной прямой по закрытию проекта. Остальным это просто не нужно.
Недавнее сообщения от PostgresPro о массовых сокращениях лишь подтверждают это. Проектом стало мало, а народу много. Закрыли проект, спасибо, всем пока
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
📚 Роман Севрук (К2Тех): «Рынок СУБД вышел из режима экстренного импортозамещения и переходит к проверке на зрелость»
В продолжении темы импортозамещения.
Какой-то "хрен с горы" решил порассуждать на тему импортозамещения СУБД (Простите, что-то игривое сегодня настроение). Я об этом менеджере по развитию ничего не знаю и сама компания К2Тех не то, чтобы "на слуху".
Как делается эта оценка? Меня всегда это удивляло. Как аналитики придумывают такие цифры? Загадка. Опрос по телефону? Анкетирование? В общем, цифры из головы.
Насколько мне известно общий для импортозамещения срок 1 января 2028 года! И только для некоторой категории предприятий срок продлили до 2036 года. Таких компаний, немного. Поэтому вряд компании "расслабили булки" из-за этого.
Такое ощущение, что весь западный мир уже тогда мог обрабатывать OLTP и OLAP нагрузки, а мы даже сейчас в 2026 году до сих пор этого не умеем. OracleDB больше не купить. Мир рухнул.
Oracle конечно универсальная СУБД, но далеко не все её использовали для аналитики. Это коммерческая продукт, который стоит как "самолёт". Были стандартные DWH решения в виде Greenplum, про ClickHouse не забываем, SAP, Vertica и многие другие. Мне кажется наши СЕО, CIO были вполне осведомлены о разнообразии рынка СУБД тогда и тем более сейчас.
Я соглашусь, что привлечение интеграторов к проекту миграции даст больший профит, чем попытка сделать всё силами внутренних команд. Взгляд со стороны может подсвятить то, на что вы никогда не обращали внимание, а самое главное это 100% улучшит внутреннюю документацию по системам.
Мы все пониманием, что интеграторы нужны в качестве "козлов отпущения" если что-то пойдёт не так. Классика 😊
У меня какое-то двоякое чувство. С одной стороны сейчас все требования к специалисту по СУБД свелись к знанию PostgreSQL и его экосистемы. Найти спеца не так уж и сложно, даже вырастить не проблема, т.к. обучающих материалов и курсов очень много!
С другой стороны мир СУБД огромен! Даже в РФ не все сидят на одном лишь PostgreSQL. Вырастить специалиста даже по MySQL, YDB, Tarantool, Valkey и прочим решениям очень тяжело.
В продолжении темы импортозамещения.
Какой-то "хрен с горы" решил порассуждать на тему импортозамещения СУБД (Простите, что-то игривое сегодня настроение). Я об этом менеджере по развитию ничего не знаю и сама компания К2Тех не то, чтобы "на слуху".
При этом около 70% компаний всё ещё используют решения западных производителей.
Как делается эта оценка? Меня всегда это удивляло. Как аналитики придумывают такие цифры? Загадка. Опрос по телефону? Анкетирование? В общем, цифры из головы.
Одним из драйверов рынка вы назвали импортозамещение. На ЦИПРе было заявлено, что его сроки сдвигаются до 2036 года.
Насколько мне известно общий для импортозамещения срок 1 января 2028 года! И только для некоторой категории предприятий срок продлили до 2036 года. Таких компаний, немного. Поэтому вряд компании "расслабили булки" из-за этого.
Да, действительно, после 2022 года универсальных СУБД «на все случаи жизни» на рынке не осталось. У каждого российского решения есть свои сильные стороны: одно лучше подходит для хранения, другое – для высоких нагрузок, третье – для аналитики.
Такое ощущение, что весь западный мир уже тогда мог обрабатывать OLTP и OLAP нагрузки, а мы даже сейчас в 2026 году до сих пор этого не умеем. OracleDB больше не купить. Мир рухнул.
Oracle конечно универсальная СУБД, но далеко не все её использовали для аналитики. Это коммерческая продукт, который стоит как "самолёт". Были стандартные DWH решения в виде Greenplum, про ClickHouse не забываем, SAP, Vertica и многие другие. Мне кажется наши СЕО, CIO были вполне осведомлены о разнообразии рынка СУБД тогда и тем более сейчас.
Самая большая проблема миграции сегодня уже даже не выбор конкретной СУБД. Главное — оценить влияние миграции на всю ИТ-архитектуру. Пытаться сделать всё своими силами — значит держать лишних FTE или постоянно переучивать людей. У интегратора выше насмотренность...
Я соглашусь, что привлечение интеграторов к проекту миграции даст больший профит, чем попытка сделать всё силами внутренних команд. Взгляд со стороны может подсвятить то, на что вы никогда не обращали внимание, а самое главное это 100% улучшит внутреннюю документацию по системам.
Мы все пониманием, что интеграторы нужны в качестве "козлов отпущения" если что-то пойдёт не так. Классика 😊
На рынке заметен дефицит сильных экспертов, особенно senior-уровня, способных разрабатывать и дорабатывать сами СУБД. Подготовка специалиста до уровня middle или senior занимает до трех лет
У меня какое-то двоякое чувство. С одной стороны сейчас все требования к специалисту по СУБД свелись к знанию PostgreSQL и его экосистемы. Найти спеца не так уж и сложно, даже вырастить не проблема, т.к. обучающих материалов и курсов очень много!
С другой стороны мир СУБД огромен! Даже в РФ не все сидят на одном лишь PostgreSQL. Вырастить специалиста даже по MySQL, YDB, Tarantool, Valkey и прочим решениям очень тяжело.
📚 Создатель знаменитого российского Linux купил полсотни разработчиков суверенной СУБД «Персей»
Рынок СУБД продолжает консолидацию. Еще один форк-postgres был успешно поглощен. В прошлом году Аренадата купила OrionDB у Orionsoft. Странно, что PostgresPro никого не покупает. Хотя, зачем им еще кто-то? 🤔
В общем, товарищи из Тантор Лабс наверняка счастливы до безумия! Их продукт точно будет развиваться и будут вваливаться еще больше денег в различные проекты. Еще лет 5 можно горя не знать!
Как там дела у Pangolin, Jatoba, Квант-Гибрид? Тихо пока. Может ждут чего-то? или кого-то... 😉
«Группа Астра» - разработчик Astra Linux - усиливает свой бизнес систем управления базами данных.
Компания через дочернюю «Тантор Лабс» получила:
👉 исключительные права на разработки, связанные с российской СУБД «Персей»;
👉 команду примерно из 50 инженеров, которая перейдёт из «МТ-Интеграции» и продолжит развивать продукт.
Рынок СУБД продолжает консолидацию. Еще один форк-postgres был успешно поглощен. В прошлом году Аренадата купила OrionDB у Orionsoft. Странно, что PostgresPro никого не покупает. Хотя, зачем им еще кто-то? 🤔
В общем, товарищи из Тантор Лабс наверняка счастливы до безумия! Их продукт точно будет развиваться и будут вваливаться еще больше денег в различные проекты. Еще лет 5 можно горя не знать!
Как там дела у Pangolin, Jatoba, Квант-Гибрид? Тихо пока. Может ждут чего-то? или кого-то... 😉
❤2
📚 Проблема с хранением данных в базе решена. Вот что будет дальше
В этом смысле ETL можно рассматривать как разновидность архитектурного техдолга. Долгое время мы компенсировали несовместимость систем всё более сложными конвейерами передачи данных. Теперь пора уменьшать количество посредников и развивать механизмы обмена непосредственно на уровне платформы данных.
Задел уже есть:
Хочется верить, что следующий этап развития архитектуры данных будет связан не с появлением очередного адаптера, а с постепенным исчезновением самих границ между системами 🆓.
Данные должны не переезжать из одного изолированного хранилища в другое, а свободно и безопасно становиться доступными там, где они нужны.
Добро пожаловать в светлое радужное будущее! 🌈
p.s. свежо предание, а верится с трудом (с) 😎
PostgreSQL часто остаётся основным источником операционных данных, но затем информация копируется в DWH, поисковые системы, ML-платформы и векторные базы. Каждый новый контур означает ещё один ETL/CDC-пайплайн, задержки, дублирование и риск рассинхронизации.
Поэтому будущее Postgres — не обязательно в том, чтобы заменить все специализированные СУБД. Скорее он должен стать центром экосистемы данных: надёжным system of record с удобной репликацией, доступом к внешним источникам и расширениями для аналитики и ИИ.
В этом смысле ETL можно рассматривать как разновидность архитектурного техдолга. Долгое время мы компенсировали несовместимость систем всё более сложными конвейерами передачи данных. Теперь пора уменьшать количество посредников и развивать механизмы обмена непосредственно на уровне платформы данных.
Задел уже есть:
logical replication, CDC, foreign data wrappers, расширения и открытые форматы хранения. Но пока это скорее отдельные строительные блоки, чем единая модель взаимодействия.Хочется верить, что следующий этап развития архитектуры данных будет связан не с появлением очередного адаптера, а с постепенным исчезновением самих границ между системами 🆓.
Данные должны не переезжать из одного изолированного хранилища в другое, а свободно и безопасно становиться доступными там, где они нужны.
Добро пожаловать в светлое радужное будущее! 🌈
p.s. свежо предание, а верится с трудом (с) 😎
The New Stack
The database storage problem is solved. Here’s what comes next.
Postgres is evolving from a system of record into a hub for data movement. Here's how interoperability and AI are reshaping its future.
❤1
🎦 Unlocked Conference, часть 1. Кеш ускоряет систему, а потом случается это...
На youtube вышли в публичный доступ видео с конференции Unlocked Conference от сообщества Valkey. Думаю стоит их разобрать.
Я не буду обозревать каждое видео в отдельности. Это долго и скучно. Поэтому просто выскажу здесь несколько "умных мыслей", которые меня зацепили.
Главный вывод можно сформулировать такой:
Несколько забавных историй:
🔹 100% CPU не всегда означает 100% загрузки.
В Valkey часть CPU могла уходить на busy polling. Метрики показывали полное насыщение уже при 300 тыс. QPS, хотя узел был способен обработать почти вдвое больше.
🔹 Отличный SLO может скрывать полный отказ клиента.
У Valkey средняя доступность по всему парку была прекрасной. Но отдельная partition могла лежать на 100%, полностью ломая workflow конкретного клиента. Средняя температура по дата-центру снова победила реальность.
🔹 Fail fast иногда означает fail catastrophically.
Одна неисправная нода очень быстро возвращала код
🔹 Retry может пережить причину аварии.
Нагрузка вызвала ошибки, ошибки породили retries, а retries удержали систему выше capacity. Исходный spike уже закончился, но система продолжала гореть самостоятельно 🔥.
Production обычно ломается не при нормальной эксплуатации, а во время переходов - failover, resharding, cache flush, восстановления соединений и массового запуска клиентов. Поэтому проверять нужно не только максимальный QPS.
Нужно проверять, умеет ли система вернуться в норму после того, как всё пошло не по плану.
На мой взгляд один из самых больнючих кейсов. Проблема ушла, а система не смогла восстановиться. Только всемогущий 💪 рестарт помог оживить prod. Мне кажется это одна их самых популярных проблем всех распределенных систем. В продолжении...
🔹 В биллинге кеш способен материализовать деньги из воздуха.
Независимая запись в основную БД и Redis привела к cache drift, двойным списаниям и неправильным балансам. Для финансовых данных кеш не может быть вторым источником истины.
Добавить Redis как кэширующий слой - это стандартный паттерн. Это частая практика. Вопрос, как данные синхронизировать между основной БД и кешем?
Самый очевидный вариант, это делать запись в БД и кеш в одной транзакции. А что если это невозможно? То как быть?
Предлагайте варианты 😎
На youtube вышли в публичный доступ видео с конференции Unlocked Conference от сообщества Valkey. Думаю стоит их разобрать.
Я не буду обозревать каждое видео в отдельности. Это долго и скучно. Поэтому просто выскажу здесь несколько "умных мыслей", которые меня зацепили.
Главный вывод можно сформулировать такой:
Кэш - это не ускоритель базы данных. Это ещё одна распределённая система со своими способами сломать ваш прод 😁
Несколько забавных историй:
В Valkey часть CPU могла уходить на busy polling. Метрики показывали полное насыщение уже при 300 тыс. QPS, хотя узел был способен обработать почти вдвое больше.
У Valkey средняя доступность по всему парку была прекрасной. Но отдельная partition могла лежать на 100%, полностью ломая workflow конкретного клиента. Средняя температура по дата-центру снова победила реальность.
Одна неисправная нода очень быстро возвращала код
500. Алгоритм least-connections балансировщика решил, что она самая свободная, и направил на неё ещё больше запросов. Чем быстрее нода падала, тем больше трафика получала. Идеальная производительность, просто результат немного не тот. "Чутулю" совсем 😜Нагрузка вызвала ошибки, ошибки породили retries, а retries удержали систему выше capacity. Исходный spike уже закончился, но система продолжала гореть самостоятельно 🔥.
Production обычно ломается не при нормальной эксплуатации, а во время переходов - failover, resharding, cache flush, восстановления соединений и массового запуска клиентов. Поэтому проверять нужно не только максимальный QPS.
Нужно проверять, умеет ли система вернуться в норму после того, как всё пошло не по плану.
На мой взгляд один из самых больнючих кейсов. Проблема ушла, а система не смогла восстановиться. Только всемогущий 💪 рестарт помог оживить prod. Мне кажется это одна их самых популярных проблем всех распределенных систем. В продолжении...
Независимая запись в основную БД и Redis привела к cache drift, двойным списаниям и неправильным балансам. Для финансовых данных кеш не может быть вторым источником истины.
Добавить Redis как кэширующий слой - это стандартный паттерн. Это частая практика. Вопрос, как данные синхронизировать между основной БД и кешем?
Самый очевидный вариант, это делать запись в БД и кеш в одной транзакции. А что если это невозможно? То как быть?
Предлагайте варианты 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Unlocked Conference
Unlocked 2026 | Valkey Conference | May 7, Seattle
Learn how to build robust and scalable systems from industry leaders like Amazon, Apple, Google, Momento, Netflix, Snap and Uber!
❤4🤪1
🎦 Unlocked Conference, часть 2. Почему Valkey должен стать скучным 🥱
Самое важное слово на конференции про высокопроизводительный кеш неожиданно было не про
В инженерном смысле скучная система - это система, которая не преподносит сюрпризов в три часа ночи.
Что для этого делают в Valkey и вокруг него?
🔹 Превращают клиента в полноценную часть распределённой системы.
Production-grade клиент должен переживать failover, resharding,
Клиент Valkey - это не просто библиотека с командами
🔹 Убирают зависимость от
Фича Valkey 10. Forkless Save снижает риск стартовых пауз и почти двукратного роста памяти из-за Copy-on-Write. Правда, цена переносится в latency некоторых записей.
Некий обмен. Меньше требований к RAM - больше внимания к write latency.
Забавно, что Amazon эту фичу у себя сделали еще в 2020 году!😱 Спустя 6 лет AWS расщедрились и заопенсорсили её. Нууууу, спасибо конечно. Но какое-то неприятное чувство внутри осталось. Могли бы и раньше озаботиться ☹️
🔹 Netflix предлагает версионировать данные как код.
Новая версия кеша заранее строится, проверяется и затем атомарно включается. При проблемах - быстрый rollback. Никакого постепенного заполнения, частично обновлённого состояния и философских дискуссий о том, кто опять забыл инвалидировать кеш.
Интересная проприетарная фича. Доклад был короткий, поэтому оценить всю её пользу сложновато. Хотя задумка интересная 🧐.
🔹 Reddit экономит память не закупкой новых серверов, а моделью данных.
Hash field expiration позволил сократить один кластер с 44 до 25 Тбайт памяти. А Cuckoo filter помог отсеять запросы к заведомо отсутствующим ключам. Потому что самый быстрый и дешёвый запрос к Valkey это тот, который не пришлось отправлять 😊
🔹 Valkey становится частью AI-инфраструктуры.
Semantic cache может повторно использовать ответы LLM для похожих запросов. Но слишком мягкий similarity threshold способен вернуть Париж как столицу Германии.
TTL отвечает за временную актуальность. Threshold - за смысловую. Ошибиться можно по обеим координатам.
Общий вектор конференции такой:
Максимальный QPS хорошо выглядит на слайде.
Но настоящая зрелость начинается там, где resharding, restart или сетевой сбой перестают быть событием для всей компании.
Нас ждёт утопичное будущее 🤤 Но это не точно 🫠
Самое важное слово на конференции про высокопроизводительный кеш неожиданно было не про
performance. Это было слово boring .В инженерном смысле скучная система - это система, которая не преподносит сюрпризов в три часа ночи.
Что для этого делают в Valkey и вокруг него?
Production-grade клиент должен переживать failover, resharding,
MOVED, сетевые сбои и изменение топологии. А ещё - не устраивать retry storm, использовать backoff, jitter и circuit breaker.Клиент Valkey - это не просто библиотека с командами
GET и SET. Иногда это последняя линия обороны между небольшим сбоем и большим инцидентом.fork() при сохранении данных.Фича Valkey 10. Forkless Save снижает риск стартовых пауз и почти двукратного роста памяти из-за Copy-on-Write. Правда, цена переносится в latency некоторых записей.
Некий обмен. Меньше требований к RAM - больше внимания к write latency.
Забавно, что Amazon эту фичу у себя сделали еще в 2020 году!😱 Спустя 6 лет AWS расщедрились и заопенсорсили её. Нууууу, спасибо конечно. Но какое-то неприятное чувство внутри осталось. Могли бы и раньше озаботиться ☹️
Новая версия кеша заранее строится, проверяется и затем атомарно включается. При проблемах - быстрый rollback. Никакого постепенного заполнения, частично обновлённого состояния и философских дискуссий о том, кто опять забыл инвалидировать кеш.
Интересная проприетарная фича. Доклад был короткий, поэтому оценить всю её пользу сложновато. Хотя задумка интересная 🧐.
Hash field expiration позволил сократить один кластер с 44 до 25 Тбайт памяти. А Cuckoo filter помог отсеять запросы к заведомо отсутствующим ключам. Потому что самый быстрый и дешёвый запрос к Valkey это тот, который не пришлось отправлять 😊
Semantic cache может повторно использовать ответы LLM для похожих запросов. Но слишком мягкий similarity threshold способен вернуть Париж как столицу Германии.
TTL отвечает за временную актуальность. Threshold - за смысловую. Ошибиться можно по обеим координатам.
Общий вектор конференции такой:
Valkey развивается не как "Redis с ещё большим количеством функций", а как открытая и предсказуемая инфраструктурная платформа.
Максимальный QPS хорошо выглядит на слайде.
Но настоящая зрелость начинается там, где resharding, restart или сетевой сбой перестают быть событием для всей компании.
Нас ждёт утопичное будущее 🤤 Но это не точно 🫠
Please open Telegram to view this post
VIEW IN TELEGRAM
Unlocked Conference
Unlocked 2026 | Valkey Conference | May 7, Seattle
Learn how to build robust and scalable systems from industry leaders like Amazon, Apple, Google, Momento, Netflix, Snap and Uber!
❤4👍1