📚 Почти 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
🎦 Давным давно, аж 23 июня прошел Data.Митап от Сбера
Было три доклада:
Хотел туда лично прийти, но это был конец июня. У меня защиты ВКР были расписаны на каждый день с 15 числа до 27 числа. Не смог 😞
Посмотрел доклады в записи. В целом, вроде всё интересно, но ничего такого важно для себя не вынес. Если нет слайда с выводами, то тяжело вычленить что-то важно из моноголога автора 🥲.
Отмечу последний доклад. Про оптимизаторы запросов. Очень глубокий доклад с математической теорией. Автор молодец👍. Презентация крутая. Я далек от алгоритмов и тер-вера в целом, но разработчикам оптимизаторов будет крайне полезно. Если вы этим занимаетесь, то гляньте👀.
Было три доклада:
👉 17:40 - PostgreOnRocks: как превратить PostgreSQL в облачную базу данных на RocksDB и S3
👉 18:10 - Multi-DC кластер DataGrid с синхронной репликацией и сниженным TCO
👉 18:40 - Генетика или игры: новый алгоритм для оптимизации запросов в реляционных СУБД
Хотел туда лично прийти, но это был конец июня. У меня защиты ВКР были расписаны на каждый день с 15 числа до 27 числа. Не смог 😞
Посмотрел доклады в записи. В целом, вроде всё интересно, но ничего такого важно для себя не вынес. Если нет слайда с выводами, то тяжело вычленить что-то важно из моноголога автора 🥲.
Нашли проблему, затем разработали решение - получили профит. Конец 😊
Отмечу последний доклад. Про оптимизаторы запросов. Очень глубокий доклад с математической теорией. Автор молодец👍. Презентация крутая. Я далек от алгоритмов и тер-вера в целом, но разработчикам оптимизаторов будет крайне полезно. Если вы этим занимаетесь, то гляньте👀.
👍1
📚 Как мы работаем со студентами: дипломы, которые становятся частью YDB
Привлекать студентов к написанию кода для opensource продуктам - отличные кейс. Все в выигрыше. У студента есть тема НИР, а у владельца продукта, готовый pull request. Win-Win.
Коллеги из YDB рассказали, как студенческие работы можно делать не «в стол», а на реальных задачах промышленной СУБД: от OpenTelemetry и SDK до интеграций со Spring и инструментов импорта данных.
В результате получается не только ВКР, но и вполне осязаемый инженерный проект для портфолио! Это крайне ценное дополнение.
В общем, хорош пытать бедного преподавателя на предмет тем для НИР. Сами ищите интересные вам открытые проекты и развивайте их 😎
А я отдохну🏖️ 🏖 🌊
Привлекать студентов к написанию кода для opensource продуктам - отличные кейс. Все в выигрыше. У студента есть тема НИР, а у владельца продукта, готовый pull request. Win-Win.
Коллеги из YDB рассказали, как студенческие работы можно делать не «в стол», а на реальных задачах промышленной СУБД: от OpenTelemetry и SDK до интеграций со Spring и инструментов импорта данных.
В результате получается не только ВКР, но и вполне осязаемый инженерный проект для портфолио! Это крайне ценное дополнение.
В общем, хорош пытать бедного преподавателя на предмет тем для НИР. Сами ищите интересные вам открытые проекты и развивайте их 😎
А я отдохну
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🤪1
📚 Redis Restarted in 4 Seconds. Postgres Died for 40 Minutes.
Интересный production-кейс про Redis и PostgreSQL.
Redis перезапустился всего за 4 секунды. Казалось бы, ничего страшного; сервис поднялся, kubernetes считает его здоровым (зелененьким). Но кэш после рестарта оказался пустым и вся нагрузка практически мгновенно пошла в PostgreSQL. Кто-то не позаботился о персистентности кэша 🤨.
Дальше классическая цепочка:
В результате Redis восстановился за секунды, а PostgreSQL пришлось восстанавливать почти 40 минут.
Важная мысль. Если база данных выдерживает production-нагрузку только благодаря высокому cache hit rate, то Redis уже не просто "глупый кэш". Он становится частью capacity planning всей системы.
Помочь могут постепенный "прогрев кэша", ограничение числа одновременных запросов к базе, защита от повторного вычисления одних и тех же данных и запас производительности PostgreSQL.
Вообще терминологии вида "прогрев кластера" или "прогрев кеша" очень привлекательны. По крайне мере подстегивают фантазии в уме🍬 . Но насколько это все применимо в реальных средах, тем более в продакшне, вопрос открытый 🤷♂️.
Надо будет "заИИшить" эту тему 😊
Интересный production-кейс про Redis и PostgreSQL.
Redis перезапустился всего за 4 секунды. Казалось бы, ничего страшного; сервис поднялся, kubernetes считает его здоровым (зелененьким). Но кэш после рестарта оказался пустым и вся нагрузка практически мгновенно пошла в PostgreSQL. Кто-то не позаботился о персистентности кэша 🤨.
Дальше классическая цепочка:
cold cache → cache misses → PostgreSQL → connection pool exhaustion → timeouts → retries → ещё больше нагрузкиВ результате Redis восстановился за секунды, а PostgreSQL пришлось восстанавливать почти 40 минут.
Важная мысль. Если база данных выдерживает production-нагрузку только благодаря высокому cache hit rate, то Redis уже не просто "глупый кэш". Он становится частью capacity planning всей системы.
Помочь могут постепенный "прогрев кэша", ограничение числа одновременных запросов к базе, защита от повторного вычисления одних и тех же данных и запас производительности PostgreSQL.
Вообще терминологии вида "прогрев кластера" или "прогрев кеша" очень привлекательны. По крайне мере подстегивают фантазии в уме
Надо будет "заИИшить" эту тему 😊
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
Redis Restarted in 4 Seconds. Postgres Died for 40 Minutes.
When persistence is off — and a routine deploy becomes a cold-cache stampede.
❤2
📚 SQL injection isn't dead
Очень прикольная статья с неожиданным выводом в конце. Постараюсь кратко разобрать.
SQL Injection (
Главное правило при этом не изменилось:
Поэтому основа защиты - parameterized queries / prepared statements. А code review, SAST, pentest, WAF и runtime protection это уже дополнительные уровни defense in depth.
И самое сладкое:
ИИшка код генерит как сумасшедшая, но насколько этот код безопасен большой вопрос.
Очень прикольная статья с неожиданным выводом в конце. Постараюсь кратко разобрать.
SQL Injection (
SQLi) - это уязвимость, которой уже несколько десятилетий. Казалось бы, ORM, prepared statements и современные фреймворки давно должны были её похоронить. Но SQLi по-прежнему регулярно находят в production-системах. Почему?👉 legacy-код всё ещё собирает SQL через конкатенацию строк;
👉 использование ORM не гарантирует безопасность;
👉 SAST и WAF не способны поймать абсолютно все сценарии;
👉 AI coding assistants тоже могут генерировать небезопасный SQL-код.
Главное правило при этом не изменилось:
Пользовательские данные должны оставаться данными, а не становиться частью SQL-команды.
Поэтому основа защиты - parameterized queries / prepared statements. А code review, SAST, pentest, WAF и runtime protection это уже дополнительные уровни defense in depth.
И самое сладкое:
AI не устраняет старые классы уязвимостей. Он способен масштабировать как хороший, так и плохой код.
ИИшка код генерит как сумасшедшая, но насколько этот код безопасен большой вопрос.
Доверяете ли клоду настолько, что готовы воспринимать его код как "безопасный"? Ммм?
www.aikido.dev
SQL injections (and Little Bobby Tables) aren't dead
The fix for SQL injection is decades old and still works. So why did WordPress core just need an emergency patch for one? The data, and how to defend against it.
❤2
📚 Database Trends and Applications Magazine: June/July 2026 Issue
❗️Тема номера: перестройка корпоративных данных и инфраструктуры под практический AI.
➡️Semantic Layers Are Rising to the Top of the Data Agenda, Survey Shows
Честно, у меня на работе как раз внедряются такие агенты. Всё надо очень подробно описать, чтобы агент тебя понял. Точнее не так, чтобы агент сделал то, что тебе нужно. С одной стороны это отчасти прикольно, но меня почему-то раздражает 😡. Без объяснений 🧐
➡️ The Speed of Insight: Enabling the Next Frontier of Real-Time AI
Такие AI агенты мне почему-то больше нравятся😊. Тоже столкнулся с таким в работе.
1 - Приходит запрос от клиента.
2 - ИИ уже проанализировал его. Может быть даже в логи залез и уже пришел ко мне с некими выводами по проблеме.
3 - От меня "кожаного мешка" осталось только перепроверить за ним и подтвердить выводы или опровергнуть их. Удобненько ☺️.
➡️ The Cost of "Good Enough" SQL in a High-Volume Database Environment
Я как-то работал с софтом одного популярного банковского вендора ПО. Так у него в сервер приложений был встроен механизм генерации отчета обо всех исходящих запросах БД. Можно было выставить фильтр по датам и увидеть очень подробную статистику. Что за запрос, сколько раз за период он выполнялся, какое среднее время выполнения и т.д. Безумного удобная штука 👍! Больше такого не видел ни у кого 😟.
❗️Тема номера: перестройка корпоративных данных и инфраструктуры под практический AI.
➡️Semantic Layers Are Rising to the Top of the Data Agenda, Survey Shows
AI-агентов недостаточно просто дать доступ к данным. Им нужно однозначно понимать (разжевать), что именно означают "выручка", "маржа", "клиент" и другие бизнес-понятия. Поэтому semantic layer постепенно превращается из вспомогательного инструмента BI в инфраструктуру доверия для AI.
Честно, у меня на работе как раз внедряются такие агенты. Всё надо очень подробно описать, чтобы агент тебя понял. Точнее не так, чтобы агент сделал то, что тебе нужно. С одной стороны это отчасти прикольно, но меня почему-то раздражает 😡. Без объяснений 🧐
➡️ The Speed of Insight: Enabling the Next Frontier of Real-Time AI
Real-Time AI - это не отдельная технология, а перестройка всей data-инфраструктуры так, чтобы AI мог реагировать на события практически в момент их возникновения.
Такие AI агенты мне почему-то больше нравятся😊. Тоже столкнулся с таким в работе.
1 - Приходит запрос от клиента.
2 - ИИ уже проанализировал его. Может быть даже в логи залез и уже пришел ко мне с некими выводами по проблеме.
3 - От меня "кожаного мешка" осталось только перепроверить за ним и подтвердить выводы или опровергнуть их. Удобненько ☺️.
➡️ The Cost of "Good Enough" SQL in a High-Volume Database Environment
В больших системах "достаточно хороший" SQL уже недостаточно хорош - небольшая неэффективность запроса умножается на объём и частоту его выполнения и превращается в реальные деньги и проблемы производительности.
Я как-то работал с софтом одного популярного банковского вендора ПО. Так у него в сервер приложений был встроен механизм генерации отчета обо всех исходящих запросах БД. Можно было выставить фильтр по датам и увидеть очень подробную статистику. Что за запрос, сколько раз за период он выполнялся, какое среднее время выполнения и т.д. Безумного удобная штука 👍! Больше такого не видел ни у кого 😟.
Database Trends and Applications
Database Trends and Applications Magazine: June/July 2026 Issue
The June/July 2026 issue of DBTA showcases the annual 'DBTA 100' list.
❤2👍1
📚 Database Per Service vs. Shared Database — A Real Trade-off from Banking Architecture
Классический выбор в микросервисной архитектуре. Одна общая БД или отдельная база на каждый сервис?
Shared Database гораздо проще. Используется обычные JOIN, foreign keys, ACID-транзакции и накладных расходов меньше на инфраструктуру. Но сервисы быстро начинают зависеть от общей схемы, мешают друг другу при изменениях и могут конкурировать за ресурсы.
Database per Service даёт автономность, изоляцию и независимое масштабирование. Сервис владеет своими данными, независимо развивается и масштабируется. Цена - distributed systems во всей красе: eventual consistency, Saga, Outbox, CQRS/read models и отсутствие простых cross-service JOIN.
Итого:
❇️ post scriptum
Отдельно интересно посмотреть на это через призму современных распределённых СУБД. Они позволяют держать несколько сервисов в одном распределённом кластере, сохраняя логические границы данных.
Получается своего рода
Но есть соблазн нарушить святые правила архитектурного паттерна. Если сервисы начинают напрямую ходить в таблицы друг друга, делать cross-domain JOIN и связывать всё глобальными транзакциями, то перед нами снова Shared Database, хоть и распределённая.
Мне это напоминает вечный хейт MongoDB из-за того, что там нет схемы. Вставляй данные какие-то хочешь. Мол это сильно развращает разработчиков. Почему-то никто не вспоминает о том, что в MongoDB есть JSON Schema validation, которая пришла с версии 3.6 в далеком 2017 году.
Но всем как будто пофиг...😔
Классический выбор в микросервисной архитектуре. Одна общая БД или отдельная база на каждый сервис?
Я где-то читал, если ты в микросервисной архитектуре используешь одну общую БД, то это фуууу, позор 🤬. Это нарушение! У каждого сервиса должна быть своя БД 🧐.
Shared Database гораздо проще. Используется обычные JOIN, foreign keys, ACID-транзакции и накладных расходов меньше на инфраструктуру. Но сервисы быстро начинают зависеть от общей схемы, мешают друг другу при изменениях и могут конкурировать за ресурсы.
Database per Service даёт автономность, изоляцию и независимое масштабирование. Сервис владеет своими данными, независимо развивается и масштабируется. Цена - distributed systems во всей красе: eventual consistency, Saga, Outbox, CQRS/read models и отсутствие простых cross-service JOIN.
Итого:
Автор для своего банковского приложения выбрал Database per Service и не пожалел. Да, кодить стало сложнее, но получил сверхгибкое масштабирование, что потенциально избавило команду от множества проблем.
Database per Service — это не бесплатная "правильная архитектура", а обмен связанности на операционную сложность.
❇️ post scriptum
Отдельно интересно посмотреть на это через призму современных распределённых СУБД. Они позволяют держать несколько сервисов в одном распределённом кластере, сохраняя логические границы данных.
Получается своего рода
shared infrastructure + isolated ownership, т.е. попытка получить часть удобства Shared Database и часть автономности Database per Service.Но есть соблазн нарушить святые правила архитектурного паттерна. Если сервисы начинают напрямую ходить в таблицы друг друга, делать cross-domain JOIN и связывать всё глобальными транзакциями, то перед нами снова Shared Database, хоть и распределённая.
Мне это напоминает вечный хейт MongoDB из-за того, что там нет схемы. Вставляй данные какие-то хочешь. Мол это сильно развращает разработчиков. Почему-то никто не вспоминает о том, что в MongoDB есть JSON Schema validation, которая пришла с версии 3.6 в далеком 2017 году.
Но всем как будто пофиг...😔
Medium
Database Per Service vs. Shared Database — A Real Trade-off from Banking Architecture
We debated this for three weeks on a retail banking platform migration. Here’s every argument, every concern, and the decision that shaped…
❤4👍1
⚡️⚡️Amazon покупает DuckDB Labs ⚡️⚡️
Официальная формулировка:
Но давайте будем реалистами. Мы уже проходили это. Никто не мешает через пару лет сменить лицензию, когда проект станет критически важным для инфраструктуры.
И знаете, это идеально иллюстрирует мой главный тезис на курсах:
Раньше корпорации стеснялись пожирать друг друга. Сейчас правила игры просты, если стартап выстрелил, то его покупают. Не выстрелил? Тоже покупают, просто чтобы убрать потенциальную угрозу. Денег у гигантов вагон и маленькая тележка.
А разработчики или фаундеры... Называйте их как хотите. Все любят деньги 💰. Жизнь такая. Хочется проснуться однажды с мыслью, что счет в банке закрывает все вопросы и тревоги🧘♂ . Особенно когда за спиной семья👩👩👧👧
Идея идей, а жизнь нужна, чтобы кайфовать!🏄♂️
Официальная формулировка:
"DuckDB останется Open Source".
Но давайте будем реалистами. Мы уже проходили это. Никто не мешает через пару лет сменить лицензию, когда проект станет критически важным для инфраструктуры.
И знаете, это идеально иллюстрирует мой главный тезис на курсах:
сегодняшний капитализм победил окончательно и бесповоротно.
Раньше корпорации стеснялись пожирать друг друга. Сейчас правила игры просты, если стартап выстрелил, то его покупают. Не выстрелил? Тоже покупают, просто чтобы убрать потенциальную угрозу. Денег у гигантов вагон и маленькая тележка.
А разработчики или фаундеры... Называйте их как хотите. Все любят деньги 💰. Жизнь такая. Хочется проснуться однажды с мыслью, что счет в банке закрывает все вопросы и тревоги
Идея идей, а жизнь нужна, чтобы кайфовать!
Please open Telegram to view this post
VIEW IN TELEGRAM
MotherDuck
DuckDB outgrows its nest | MotherDuck
Today Duck Labs, the developers of DuckDB, announced they are being acquired by Amazon. This is big news in the duck-iverse, and many people are wondering what this will mean for everyone’s favorite duck-powered database, MotherDuck.
🐳4
🎦 Are your agents on ACID? ft. Mike Stonebraker, creator of Postgres, and DBOS CEO Qian Li
Посмотрел колоборационный вебинар Cockroach Labs и DBOS с Майклом Стоунбрейкером, создателем Postgres
Майкл Стоунбрейкер - фактический живой символ всей науки о СУБД в Мире! Приятно было его послушать. Человек-легенда 😊
А значит, возникает классическая проблема: что делать, если агент выполнил 8 шагов из 10, затем вызвал несколько LLM, сходил в API, изменил данные и... упал.⬆️
Начинать всё сначала это дорого и иногда опасно. LLM недетерминированы, а некоторые действия вообще нельзя повторять дважды: например, оплату.
Поэтому каждый шаг нужно делать durable:
👉 сохранять состояние после выполнения
👉 после сбоя продолжать с последнего checkpoint
👉 для отката использовать механизмы компенсации / Saga
👉 для внешних API нужны idempotency keys
Интересная идея DBOS: не поднимать отдельный тяжелый оркестратор, а хранить состояние workflow прямо в транзакционной БД. Тогда сама БД становится фундаментом durable execution.
Майкл топит за то, что сервер баз данных должен превратиться в Workflow Server. Понимайте как хотите 😊
Кажется, архитектура AI-приложений постепенно приходит к довольно знакомым проблемам распределенных систем.
❇️ Послесловие. Перед просмотром видео, у меня в голове засела высказывание одного из спикеров конференции по образованию. Речь шла о предпринимательстве и студенческих стартапах.
Если автор стартапа является студент без опыта, экспертизы и каких-либо достижений в этой области, то для инвестора это повышенный риск. Но если проект запускает, например, преподаватель или исследователь с серьезным научным бэкграундом именно в этой сфере, картина уже совсем другая. Это "зеленый флажок"🏳️ в пользу проекта.
С DBOS у меня возникла похожая ассоциация.
Конечно, громкое имя само по себе не гарантирует успех. Но в данном случае экспертиза людей за проектом это хороший повод как минимум внимательно за ним следить.
Посмотрел колоборационный вебинар Cockroach Labs и DBOS с Майклом Стоунбрейкером, создателем Postgres
Майкл Стоунбрейкер - фактический живой символ всей науки о СУБД в Мире! Приятно было его послушать. Человек-легенда 😊
Главная мысль: современные AI-агенты все больше похожи на долгоживущие transactional workflows.
А значит, возникает классическая проблема: что делать, если агент выполнил 8 шагов из 10, затем вызвал несколько LLM, сходил в API, изменил данные и... упал.
Начинать всё сначала это дорого и иногда опасно. LLM недетерминированы, а некоторые действия вообще нельзя повторять дважды: например, оплату.
Поэтому каждый шаг нужно делать durable:
👉 сохранять состояние после выполнения
👉 после сбоя продолжать с последнего checkpoint
👉 для отката использовать механизмы компенсации / Saga
👉 для внешних API нужны idempotency keys
Интересная идея DBOS: не поднимать отдельный тяжелый оркестратор, а хранить состояние workflow прямо в транзакционной БД. Тогда сама БД становится фундаментом durable execution.
Майкл топит за то, что сервер баз данных должен превратиться в Workflow Server. Понимайте как хотите 😊
Кажется, архитектура AI-приложений постепенно приходит к довольно знакомым проблемам распределенных систем.
❇️ Послесловие. Перед просмотром видео, у меня в голове засела высказывание одного из спикеров конференции по образованию. Речь шла о предпринимательстве и студенческих стартапах.
Вопрос, как инвесторы выбирают стартапы в которые стоит вложиться?
Ответ был довольно простым: важно смотреть не только на идею, но и на то, кто за ней стоит.
Если автор стартапа является студент без опыта, экспертизы и каких-либо достижений в этой области, то для инвестора это повышенный риск. Но если проект запускает, например, преподаватель или исследователь с серьезным научным бэкграундом именно в этой сфере, картина уже совсем другая. Это "зеленый флажок"
С DBOS у меня возникла похожая ассоциация.
Конечно, громкое имя само по себе не гарантирует успех. Но в данном случае экспертиза людей за проектом это хороший повод как минимум внимательно за ним следить.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Are your agents on ACID? ft. Mike Stonebraker, creator of Postgres, and DBOS CEO Qian Li
Modern software is composed of long-running, multi-step workflows spanning AI agents, microservices, databases, APIs, and humans. As applications become more distributed and autonomous, workflow orchestration and durability are becoming dominant architectural…
❤1
В этом году помимо моих двух курсов я написал третий курс "Проектирование распределенных схем базы данных". Пока я его еще полирую, но думаю провести небольшой открытый урок уже в октябре 🍂🍁. Следите на анонсами 😉
Так же начинается новый цикл митапов, форумов и конференций - а это значит нам ждет океан нового контента 🌊, интересный инсайдов
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉9
📚 The Mighty Duck
После покупки AWS компании DuckDB Lab будет выходить еще целый ряд статей, где авторы будут рассуждать о причинах и последствиях данной покупки. Вот одна из них.
Ранее архитектура данных была такая
Современная модная вариация выглядит так
В этой модели Amazon не нравится, что её инфраструктуру используют как S3. Все "дорогие" вычисления проходят на платформах Snowflake, Databricks или еще где-то. Это потеря прибыли 💸.
Как же тут поможет DuckDB🐥 ? Автор предполагает, что Amazon попытается создать следующую модель взаимодействия:
Особенно интересен здесь протокол Quack. Разработчик может управлять запросом локально, но само вычисление выполнять на машине рядом с данными в S3, вместо того чтобы тащить терабайты на ноутбук.
❇️ В целом, идея то интересная. Будет ли так покажет время.
После покупки AWS компании DuckDB Lab будет выходить еще целый ряд статей, где авторы будут рассуждать о причинах и последствиях данной покупки. Вот одна из них.
Ранее архитектура данных была такая
storage➕ query engine➕ interface
Современная модная вариация выглядит так
S3 / object storage🤩 отдельный table format/catalog🤩 отдельный query engine🤩 интерфейс, который всё чаще может быть AI/agent.
В этой модели Amazon не нравится, что её инфраструктуру используют как S3. Все "дорогие" вычисления проходят на платформах Snowflake, Databricks или еще где-то. Это потеря прибыли 💸.
Как же тут поможет DuckDB
ноутбук➡️ DuckDB➡️ S3➡️ вычисления в AWS
Особенно интересен здесь протокол Quack. Разработчик может управлять запросом локально, но само вычисление выполнять на машине рядом с данными в S3, вместо того чтобы тащить терабайты на ноутбук.
Quack - протокол, позволяющий нескольким экземплярам DuckDB взаимодействовать и выносить вычисления ближе к данным.
❇️ В целом, идея то интересная. Будет ли так покажет время.
Please open Telegram to view this post
VIEW IN TELEGRAM
Alt + E S V
The Mighty Duck
DuckLabs, the company behind the beloved developer database DuckDB, is being acquired by Amazon Web Services (AWS). The August 26, 2026 announcement stated DuckLabs will join AWS as a subsidiary in September 2026. There are no planned changes to the MIT license…
❤3
Какие были раньше времена! Что только не делали чтобы заслужить твою преданность и доверие!
С пятницей!
#mems
С пятницей!
#mems
👍3