This media is not supported in your browser
VIEW IN TELEGRAM
Немного нецензурное видео, но очень полезное! 👍
Я бы этим видео подытожил первые 2 курса любого технического ВУЗа или 3 курса колледжа.
Если по прошествии этого времени вы не освоили те компетенции о которых говорится в видео, то у вас огромные пробелы в знаниях.
Советую их закрыть 😉
Я бы этим видео подытожил первые 2 курса любого технического ВУЗа или 3 курса колледжа.
Если по прошествии этого времени вы не освоили те компетенции о которых говорится в видео, то у вас огромные пробелы в знаниях.
Советую их закрыть 😉
😁6
📚 Percona celebrates 20th birthday with new foundation — and a goat cake
Percona на 20-летии, похоже, решила вернуться к своей главной идее - это экспертной поддержке open source СУБД.
Компания раньше инвестировала в собственную DBaaS-платформу Everest, которая теперь стала open source, но основная выручка и репутация Percona всё равно строились вокруг консалтинга, т.е. сопровождения сложных database-инфраструктур, миграций, обновлений, бэкапов, производительности и отказоустойчивости.
❇️ Новый слоган Percona - "The Way Is Open". Это не только про open source как идеологию, а про вполне практичную вещь, борьбу с vendor lock-in. Открытые СУБД дают компаниям больше свободы, можно менять инфраструктуру, уходить из облака, мигрировать между платформами и не зависеть полностью от одного вендора.
❇️ Отсюда же поддержка Valkey. Кстати, Percona единственная компания, которая оказывают техподдержку по этой СУБД, а так же много инвестирует в развитие экосистемы Valkey. Для Percona это способ показать позицию, что если технология остаётся открытой и совместимой, её можно безопасно брать в production при наличии нормальной экспертизы и поддержки.
❇️ Интересен и их подход к AI: без попытки переименовать всё в "что-то + AI". AI рассматривается как инструмент для инженеров: быстрее анализировать тикеты, находить контекст, помогать с root cause analysis, мониторингом и аварийным восстановлением.
Базы данных становятся всё более критичными, гибридными и дорогими в сопровождении. И здесь ценность не только в продукте, а в экспертизе: кто поможет, когда PostgreSQL, MySQL, MongoDB или Valkey в production начинают вести себя не так, как в документации? 🥺
Percona на 20-летии, похоже, решила вернуться к своей главной идее - это экспертной поддержке open source СУБД.
Компания раньше инвестировала в собственную DBaaS-платформу Everest, которая теперь стала open source, но основная выручка и репутация Percona всё равно строились вокруг консалтинга, т.е. сопровождения сложных database-инфраструктур, миграций, обновлений, бэкапов, производительности и отказоустойчивости.
❇️ Новый слоган Percona - "The Way Is Open". Это не только про open source как идеологию, а про вполне практичную вещь, борьбу с vendor lock-in. Открытые СУБД дают компаниям больше свободы, можно менять инфраструктуру, уходить из облака, мигрировать между платформами и не зависеть полностью от одного вендора.
❇️ Отсюда же поддержка Valkey. Кстати, Percona единственная компания, которая оказывают техподдержку по этой СУБД, а так же много инвестирует в развитие экосистемы Valkey. Для Percona это способ показать позицию, что если технология остаётся открытой и совместимой, её можно безопасно брать в production при наличии нормальной экспертизы и поддержки.
❇️ Интересен и их подход к AI: без попытки переименовать всё в "что-то + AI". AI рассматривается как инструмент для инженеров: быстрее анализировать тикеты, находить контекст, помогать с root cause analysis, мониторингом и аварийным восстановлением.
Базы данных становятся всё более критичными, гибридными и дорогими в сопровождении. И здесь ценность не только в продукте, а в экспертизе: кто поможет, когда PostgreSQL, MySQL, MongoDB или Valkey в production начинают вести себя не так, как в документации? 🥺
The New Stack
Percona celebrates 20th birthday with new foundation — and a goat cake
Percona turns 20 with a rebrand, a new MySQL nonprofit called OurSQL Foundation, and a strategic pivot back to database services over DBaaS platform ambitions.
❤2
📚 MotherDuck, DuckDB и вечная проблема open source-бизнеса
The New Stack пишет о связке MotherDuck и DuckDB. Суть простая: DuckDB остаётся open source-движком для локальной аналитики, а MotherDuck строит вокруг него коммерческий облачный слой.
MotherDuck старается не форкать DuckDB и не превращать его в закрытый продукт. Вместо этого компания пытается жить рядом с upstream-проектом и зарабатывать не на «закрытом DuckDB», а на удобстве, облаке, коллаборации и enterprise-функциях.
Но самая интересная фраза в статье:
И в этом, по-моему, вся суть. Open source-проект и коммерческая компания вокруг него почти всегда живут в напряжении. У них может быть общий код, общие инженеры и общая аудитория, но разные KPI.
У open source-команды главный вопрос: как сохранить качество, независимость, доверие сообщества и архитектурную чистоту проекта 💪.
У коммерческой компании другой вопрос: как заработать, удержать клиентов, добавить enterprise-функции, встроиться в облако, AI-стек и продажи 💪.
На этом и зарождается конфликт☹️ .
Примеры мы уже видели. Elastic изменила лицензию Elasticsearch, после чего AWS и сообщество пошли в OpenSearch. Redis ушёл от BSD-лицензии к source-available модели, и появился Valkey под Linux Foundation. В мире data lakehouse тоже есть похожее напряжение: Delta Lake, Iceberg, Hudi, Databricks, Snowflake - все говорят про открытые форматы, но каждый хочет, чтобы именно его платформа стала центром экосистемы.
Поэтому история MotherDuck/DuckDB интересна не только как новость про MCP и AI-аналитику. Это ещё один пример главного вопроса современного open source: можно ли построить сильный коммерческий бизнес вокруг открытой СУБД так, чтобы не сломать доверие к самой открытой технологии?
PostgreSQL, говорит, что, да, можно.
Для пользователей СУБД главный урок простой: важно смотреть не только на лицензию и GitHub-звёзды, но и на governance. Кто контролирует roadmap? Кто принимает архитектурные решения? Можно ли уйти к другому провайдеру? И что будет, если интересы сообщества и бизнеса разойдутся?
Словил себя на мысли, что такими вопросами должна задаваться служба безопасности вашей организации. CISO (Chief Information Security Officer) принимают решения.
The New Stack пишет о связке MotherDuck и DuckDB. Суть простая: DuckDB остаётся open source-движком для локальной аналитики, а MotherDuck строит вокруг него коммерческий облачный слой.
MotherDuck старается не форкать DuckDB и не превращать его в закрытый продукт. Вместо этого компания пытается жить рядом с upstream-проектом и зарабатывать не на «закрытом DuckDB», а на удобстве, облаке, коллаборации и enterprise-функциях.
Но самая интересная фраза в статье:
It’s a partnership, a dance between two groups with very different bosses
(Это партнерство, танец двух групп с очень разными боссами)
И в этом, по-моему, вся суть. Open source-проект и коммерческая компания вокруг него почти всегда живут в напряжении. У них может быть общий код, общие инженеры и общая аудитория, но разные KPI.
У open source-команды главный вопрос: как сохранить качество, независимость, доверие сообщества и архитектурную чистоту проекта 💪.
У коммерческой компании другой вопрос: как заработать, удержать клиентов, добавить enterprise-функции, встроиться в облако, AI-стек и продажи 💪.
На этом и зарождается конфликт
Примеры мы уже видели. Elastic изменила лицензию Elasticsearch, после чего AWS и сообщество пошли в OpenSearch. Redis ушёл от BSD-лицензии к source-available модели, и появился Valkey под Linux Foundation. В мире data lakehouse тоже есть похожее напряжение: Delta Lake, Iceberg, Hudi, Databricks, Snowflake - все говорят про открытые форматы, но каждый хочет, чтобы именно его платформа стала центром экосистемы.
Поэтому история MotherDuck/DuckDB интересна не только как новость про MCP и AI-аналитику. Это ещё один пример главного вопроса современного open source: можно ли построить сильный коммерческий бизнес вокруг открытой СУБД так, чтобы не сломать доверие к самой открытой технологии?
PostgreSQL, говорит, что, да, можно.
Для пользователей СУБД главный урок простой: важно смотреть не только на лицензию и GitHub-звёзды, но и на governance. Кто контролирует roadmap? Кто принимает архитектурные решения? Можно ли уйти к другому провайдеру? И что будет, если интересы сообщества и бизнеса разойдутся?
Словил себя на мысли, что такими вопросами должна задаваться служба безопасности вашей организации. CISO (Chief Information Security Officer) принимают решения.
Please open Telegram to view this post
VIEW IN TELEGRAM
The New Stack
Why MotherDuck refuses to fork DuckDB
MotherDuck's AI lead Till Döhmen explains how the startup collaborates with DuckDB Labs, runs the world's largest DuckDB fleet, and avoids forking.
❤2
📚 На чем зарабатывает MongoDB Inc ?
Люблю считать чужие деньги 😊 Хоть я и не бухгалтер.
Короче, Монга зарабатывает на своем Атласе огромные деньги! Просто гигантские! Все остальное - не важно.
Хочешь делать бабки - пили облачный сервис😶🌫️
Очередное подтверждение того, что MongoDB будет всё больше и больше развиваться как облачный провайдер и on-prem варианты скоро канут в небытие.
А может и нет 😊
MongoDB показала выручку $687,6 млн, рост 25% год к году; скорректированная прибыль составила $1,32 на акцию, выше ожиданий аналитиков; компания даже вышла в небольшой GAAP-профит - $4,4 млн против убытка годом ранее.
Люблю считать чужие деньги 😊 Хоть я и не бухгалтер.
Главный драйвер - MongoDB Atlas, облачная managed-версия MongoDB. Atlas вырос примерно на 29% год к году, и именно его рынок воспринимает как основной двигатель бизнеса MongoDB.
Короче, Монга зарабатывает на своем Атласе огромные деньги! Просто гигантские! Все остальное - не важно.
Хочешь делать бабки - пили облачный сервис
Очередное подтверждение того, что MongoDB будет всё больше и больше развиваться как облачный провайдер и on-prem варианты скоро канут в небытие.
А может и нет 😊
Please open Telegram to view this post
VIEW IN TELEGRAM
SiliconANGLE
MongoDB posts stellar earnings and revenue beat as software rebound accelerates
Shares of the database company MongoDB Inc. shot up both before and after the close of the regular trading session today following a solid first-quarter financial report that saw it blow past analysts
👀2
📚 Redis резко повернул в сторону AI-инфраструктуры.
Честно, не хотел делать про это пост, но почему-то многие новостные паблики это расфорсили по не понятной мне причине. Ладно, я тоже выскажу свое "диванное мнение".
Сначала Redis анонсирует Vector Sets - новую структуру данных для хранения embeddings и similarity search прямо внутри Redis. Затем LangCache - semantic cache для LLM-ответов, чтобы похожие запросы не гонять каждый раз в модель. А дальше всё это собирается в более крупную историю: Redis Iris / Context Engine - слой памяти, контекста и свежих данных для AI-агентов.
На первый взгляд выглядит логично. Redis всегда был быстрым in-memory слоем для приложений. Теперь эта же роль переупаковывается под LLM-приложения с доступ к актуальным бизнес-данным.
Но есть и вопрос: откуда такая внезапная щедрость?
Redis годами развивал экосистему довольно осторожно. А тут сразу целый набор AI-продуктов: Vector Sets, LangCache, Agent Memory, Context Retriever, Iris. Похоже, после изменения лицензии и появления Valkey Redis нужно заново доказать рынку, что коммерческий Redis - это не просто знакомый key-value store с другой лицензией, а новая платформа для AI-приложений.
Ах, да, все новые инструменты - коммерческие, т.е. платные 💰
Стратегически это попытка заново занять место в головах разработчиков. Раньше Redis был «быстрым кешем для приложений». Теперь он хочет стать "памятью для AI-агентов".
Вопрос только в том, поверит ли рынок, что это эволюция Redis, а не срочная AI-переупаковка чтобы успеть занять нишу в новых инфраструктурных проектах...
Честно, не хотел делать про это пост, но почему-то многие новостные паблики это расфорсили по не понятной мне причине. Ладно, я тоже выскажу свое "диванное мнение".
Сначала Redis анонсирует Vector Sets - новую структуру данных для хранения embeddings и similarity search прямо внутри Redis. Затем LangCache - semantic cache для LLM-ответов, чтобы похожие запросы не гонять каждый раз в модель. А дальше всё это собирается в более крупную историю: Redis Iris / Context Engine - слой памяти, контекста и свежих данных для AI-агентов.
На первый взгляд выглядит логично. Redis всегда был быстрым in-memory слоем для приложений. Теперь эта же роль переупаковывается под LLM-приложения с доступ к актуальным бизнес-данным.
Но есть и вопрос: откуда такая внезапная щедрость?
Redis годами развивал экосистему довольно осторожно. А тут сразу целый набор AI-продуктов: Vector Sets, LangCache, Agent Memory, Context Retriever, Iris. Похоже, после изменения лицензии и появления Valkey Redis нужно заново доказать рынку, что коммерческий Redis - это не просто знакомый key-value store с другой лицензией, а новая платформа для AI-приложений.
Ах, да, все новые инструменты - коммерческие, т.е. платные 💰
Стратегически это попытка заново занять место в головах разработчиков. Раньше Redis был «быстрым кешем для приложений». Теперь он хочет стать "памятью для AI-агентов".
Вопрос только в том, поверит ли рынок, что это эволюция Redis, а не срочная AI-переупаковка чтобы успеть занять нишу в новых инфраструктурных проектах...
SiliconANGLE
Redis debuts the much-needed memory layer for enterprise AI agents
Redis debuts the much-needed memory layer for enterprise AI agents - SiliconANGLE
❤2
📚 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