Forwarded from LEFT JOIN
СУБД made in China
Пополнение в копилку необычных СУБД — AliSQL от Alibaba Group, которая владеет известным китайским маркетплейсом. Это форк от MySQL со всевозможными улучшениями производительности и стабильности. Полный список поддерживаемых фич в официальной документации выглядит очень внушительно.
🔵 На Githab отдельно подсветили то, что AliSQL использует аналитическую DuckDB в качестве подсистемы хранения и поддерживает векторный поиск. За счет этого подходит для аналитических задач и работы с ИИ.
🔵 В роадмапе — оптимизация DDL, RTP и репликации.
В Alibaba Group AliSQL использовали для своих внутренних нужд, но в конце 2025 поделились исходным кодом. Так что вы можете стать контрибьютором или просто потестить, как она работает.
Пополнение в копилку необычных СУБД — AliSQL от Alibaba Group, которая владеет известным китайским маркетплейсом. Это форк от MySQL со всевозможными улучшениями производительности и стабильности. Полный список поддерживаемых фич в официальной документации выглядит очень внушительно.
В Alibaba Group AliSQL использовали для своих внутренних нужд, но в конце 2025 поделились исходным кодом. Так что вы можете стать контрибьютором или просто потестить, как она работает.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from MyDB
🚀 Новые игроки в мире storage-движков для MySQL и MariaDB
В конце прошлого года на сцене storage-движков для MySQL и MariaDB появились новые претенденты: TideDB и его SQL-оболочка TideSQL.
🔍 Что это такое?
Это полностью самостоятельная реализация LSM-дерева, созданная с нуля. TideDB не является форком или модификацией RocksDB, а представляет собой независимый проект, цель которого — предложить альтернативную, более эффективную архитектуру хранения данных.
⚡ Ключевые отличия от RocksDB и MyRocks
Главное архитектурное преимущество TideDB — его оптимизация для работы в режиме строгой гарантированной записи (sync), где каждая операция подтверждается сбросом на диск. В этом сценарии он показывает значительный прирост:
• Случайная запись: производительность на 22% выше, чем у актуальной версии RocksDB.
• Эффективность хранения: использование дискового пространства в 10+ раз ниже за счет глубокой переработки процессов компрессии.
• Работа с «горячими» данными: скорость итераций по ключам с неравномерным распределением (Zipfian) в 6 раз выше.
📊 Текущий статус
• RocksDB/MyRocks — это устоявшийся промышленный стандарт с огромной экосистемой, интеграцией в MySQL (MyRocks) и проверенной надёжностью. RocksDB — эталонный встраиваемый key-value storage на основе LSM-дерева. Его сила — высокая производительность на быстрых накопителях (SSD) и гибкость. Он стал основой для многих распределенных баз данных.
• TideDB/TideSQL — это свежий, амбициозный проект, который предлагает лучшую производительность в специфических, но критически важных сценариях. Это потенциальный выбор для систем, где предельно важны задержки гарантированной записи и плотность хранения данных.
🔗 Ссылки
• Официальный сайт проекта с описанием, документацией и последними релизами: tidesdb.com
• Бенчмарки от разработчиков, сравнивающие производительность TidesDB, RocksDB и LMDB: ссылка на статью
• Бенчмарк TideSQL против InnoDB в MariaDB — MariaDB: Benchmark Analysis on TideSQL v1.0.0 & InnoDB
В конце прошлого года на сцене storage-движков для MySQL и MariaDB появились новые претенденты: TideDB и его SQL-оболочка TideSQL.
🔍 Что это такое?
Это полностью самостоятельная реализация LSM-дерева, созданная с нуля. TideDB не является форком или модификацией RocksDB, а представляет собой независимый проект, цель которого — предложить альтернативную, более эффективную архитектуру хранения данных.
⚡ Ключевые отличия от RocksDB и MyRocks
Главное архитектурное преимущество TideDB — его оптимизация для работы в режиме строгой гарантированной записи (sync), где каждая операция подтверждается сбросом на диск. В этом сценарии он показывает значительный прирост:
• Случайная запись: производительность на 22% выше, чем у актуальной версии RocksDB.
• Эффективность хранения: использование дискового пространства в 10+ раз ниже за счет глубокой переработки процессов компрессии.
• Работа с «горячими» данными: скорость итераций по ключам с неравномерным распределением (Zipfian) в 6 раз выше.
📊 Текущий статус
• RocksDB/MyRocks — это устоявшийся промышленный стандарт с огромной экосистемой, интеграцией в MySQL (MyRocks) и проверенной надёжностью. RocksDB — эталонный встраиваемый key-value storage на основе LSM-дерева. Его сила — высокая производительность на быстрых накопителях (SSD) и гибкость. Он стал основой для многих распределенных баз данных.
• TideDB/TideSQL — это свежий, амбициозный проект, который предлагает лучшую производительность в специфических, но критически важных сценариях. Это потенциальный выбор для систем, где предельно важны задержки гарантированной записи и плотность хранения данных.
🔗 Ссылки
• Официальный сайт проекта с описанием, документацией и последними релизами: tidesdb.com
• Бенчмарки от разработчиков, сравнивающие производительность TidesDB, RocksDB и LMDB: ссылка на статью
• Бенчмарк TideSQL против InnoDB в MariaDB — MariaDB: Benchmark Analysis on TideSQL v1.0.0 & InnoDB
TidesDB
Fast, embeddable key-value storage
A high-performance LSM-tree based key-value storage engine library written in C. Build databases or use directly as a standalone store.
Forwarded from LEFT JOIN
Нестандартные способы оптимизировать PostgreSQL
Стандартные вы и так знаете — переписать запросы, добавить индексы, пройтись по базе VACUUM’ом. Но есть и менее очевидные подходы, которые могут дать прирост производительности. Принесли вам шпаргалку с 3 такими приемами (с примерами), которые особенно пригодятся в аналитике.
У автора все написано подробно, ниже — главное, чтобы понять, стоит ли читать целиком.
1️⃣ Использовать constraint_exclusion, чтобы PostgreSQL не читал всю таблицу, если запрос заведомо не может вернуть данные.
Допустим, у вас есть столбец, в котором указан тарифный план, на который подписан каждый пользователь — free или pro. Если аналитик опечатается в запросе и напишет SELECT * FROM users WHERE plan = 'Pro', то он получит 0 результатов, но PostreSQL все равно старательно пройдется по всей таблице и потратит время. Чтобы он так не делал, нужно настроить параметр constraint_exclusion, чтобы он не пропускал такие запросы.
2️⃣ Создавать функциональные индексы.
Например, если у вас есть данные о дате и времени, когда была совершена продажа. Если в компании дела идут хорошо, то продаж будет много, а значит надо это дело как-то оптимизировать.
Бизнесу, как правило, не нужна точность до минуты и достаточно данных за день — зная это, можно проиндексировать только даты. Такой индекс будет меньше, чем если бы индексировали и дату, и время.
3️⃣ Использовать хеш-индексы для длинных строк.
Если нужно хранить уникальные длинные строки (например, URL), обычный индекс может разрастись до неприличных размеров. В таком случае можно использовать хеш-индекс, который хранит не сами значения, а короткие хеш-значения.
Стандартные вы и так знаете — переписать запросы, добавить индексы, пройтись по базе VACUUM’ом. Но есть и менее очевидные подходы, которые могут дать прирост производительности. Принесли вам шпаргалку с 3 такими приемами (с примерами), которые особенно пригодятся в аналитике.
У автора все написано подробно, ниже — главное, чтобы понять, стоит ли читать целиком.
Допустим, у вас есть столбец, в котором указан тарифный план, на который подписан каждый пользователь — free или pro. Если аналитик опечатается в запросе и напишет SELECT * FROM users WHERE plan = 'Pro', то он получит 0 результатов, но PostreSQL все равно старательно пройдется по всей таблице и потратит время. Чтобы он так не делал, нужно настроить параметр constraint_exclusion, чтобы он не пропускал такие запросы.
Например, если у вас есть данные о дате и времени, когда была совершена продажа. Если в компании дела идут хорошо, то продаж будет много, а значит надо это дело как-то оптимизировать.
Бизнесу, как правило, не нужна точность до минуты и достаточно данных за день — зная это, можно проиндексировать только даты. Такой индекс будет меньше, чем если бы индексировали и дату, и время.
Если нужно хранить уникальные длинные строки (например, URL), обычный индекс может разрастись до неприличных размеров. В таком случае можно использовать хеш-индекс, который хранит не сами значения, а короткие хеш-значения.
Please open Telegram to view this post
VIEW IN TELEGRAM
Hakibenita
Unconventional PostgreSQL Optimizations
Creative ideas for speeding up queries in PostgreSQL
🌭1
Forwarded from MyDB
🚨 Исправлена извечная проблема MySQL! В выпущенном 9.6 внешние ключи стали «видимыми» и полноправными.
MySQL 9.6, релиз которого состоялся в конце января, устраняет давний архитектурный недостаток: каскадные операции внешних ключей (
Чем это было плохо раньше? Было две ключевые проблемы:
🔴 Скрытые изменения: Каскадные удаления/обновления не попадали в бинарные логи. Это приводило к расхождению данных в гетерогенных средах (например, если на репликах использовались движки, отличные от InnoDB). Системы CDC и аналитики теряли часть данных.
🔴 Триггеры не работали: Триггеры, созданные на дочерних таблицах, не вызывались при каскадных операциях, так как они происходили в обход SQL-слоя. Это ломало бизнес-логику приложений.
Что изменилось в MySQL 9.6:
✅ Полная видимость: Все каскадные изменения теперь видны, логируются и точно реплицируются, в том числе в гетерогенных топологиях.
✅ Надежность: Триггеры будут отрабатывать корректно (это следующий шаг на roadmap).
✅ Безопасное обновление: Для плавного перехода введена переменная
✅ Основа для будущего: Поддержка FK в других движках и новые возможности.
✅ Без потерь в скорости: Производительность осталась на уровне прежней реализации.
Это долгожданное и фундаментальное улучшение для всех, кто строит отказоустойчивые и согласованные системы на MySQL.
👉 Подробный разбор от инженера Oracle: https://blogs.oracle.com/mysql/no-more-hidden-changes-how-mysql-9-6-transforms-foreign-key-management
MySQL 9.6, релиз которого состоялся в конце января, устраняет давний архитектурный недостаток: каскадные операции внешних ключей (
ON DELETE/UPDATE CASCADE ) теперь выполняются на уровне SQL-движка, а не скрытно внутри InnoDB.Чем это было плохо раньше? Было две ключевые проблемы:
🔴 Скрытые изменения: Каскадные удаления/обновления не попадали в бинарные логи. Это приводило к расхождению данных в гетерогенных средах (например, если на репликах использовались движки, отличные от InnoDB). Системы CDC и аналитики теряли часть данных.
🔴 Триггеры не работали: Триггеры, созданные на дочерних таблицах, не вызывались при каскадных операциях, так как они происходили в обход SQL-слоя. Это ломало бизнес-логику приложений.
Что изменилось в MySQL 9.6:
✅ Полная видимость: Все каскадные изменения теперь видны, логируются и точно реплицируются, в том числе в гетерогенных топологиях.
✅ Надежность: Триггеры будут отрабатывать корректно (это следующий шаг на roadmap).
✅ Безопасное обновление: Для плавного перехода введена переменная
innodb_native_foreign_keys. По умолчанию она имеет значение FALSE (новое поведение), но её можно установить в TRUE, чтобы временно вернуть старое поведение InnoDB. Обратите внимание, что эта переменная считается устаревшей с момента выпуска и будет удалена в будущем.✅ Основа для будущего: Поддержка FK в других движках и новые возможности.
✅ Без потерь в скорости: Производительность осталась на уровне прежней реализации.
Это долгожданное и фундаментальное улучшение для всех, кто строит отказоустойчивые и согласованные системы на MySQL.
👉 Подробный разбор от инженера Oracle: https://blogs.oracle.com/mysql/no-more-hidden-changes-how-mysql-9-6-transforms-foreign-key-management
Oracle
No More Hidden Changes: How MySQL 9.6 Transforms Foreign Key Management
Forwarded from MyDB
🎭 «В Computer Science есть только две сложные вещи: инвалидация кэша, придумывание имён и ошибки на единицу.»
Благодаря ReadySet теперь можно беспокоиться только о придумывании имён.
🧠 Это не очередной Redis. Это технология, которая переворачивает то, как мы кэшируем SQL
ReadySet — проект с корнями в MIT CSAIL (докторская Аланы Марзоев, соавтора Noria). Вместо того чтобы мучиться с TTL, писать костыли для инвалидации или сносить кэш целиком при каждом UPDATE, ReadySet делает гениально простую вещь: подключается к репликационному стриму MySQL и обновляет кэшированные результаты запросов построчно, инкрементально, в реальном времени.
Никакой ручной инвалидации. Никаких «а не пора ли сбросить Redis». Кэш просто всегда точен, потому что он синхронизирован с источником на уровне бинарных логов.
🐬 MySQL — родная стихия ReadySet
Хотя формально поддерживается и PostgreSQL, именно с MySQL ReadySet раскрывается полностью: binlog, снапшоты, мгновенное отслеживание изменений. Это не обёртка, а полноценный SQL-прокси, который понимает JOIN'ы, GROUP BY и подзапросы, превращая их в миллисекундные lookup'ы без единой строки кода в приложении.
📊 Независимые бенчмарки подтверждают: ReadySet с MySQL — это другой порядок чисел
Тест 1. AWS RDS MySQL + ReadySet (март 2025)
Рональд Брэдфорд, эксперт по MySQL и экс-консультант MySQL AB, провёл серию тестов с реальной базой IMDb (20 ГБ в InnoDB). Результаты говорят сами за себя:
- Транзакции в секунду: RDS MySQL (8 vCPU) — 5.2k, ReadySet (4 vCPU) — 17.2k (рост в 3.3 раза)
- Среднее время отклика: RDS — 12.2 мс, ReadySet — 0.93 мс (ускорение в 13 раз)
- Время отклика (95-й перцентиль): RDS — 21.9 мс, ReadySet — 1.3 мс (ускорение в 17 раз)
- При 16 потоках на 8 vCPU ReadySet выдал 19.5k транзакций/сек (3.75×) со средним временем отклика 0.82 мс (15×)
Тест 2. Вертикальное масштабирование против горизонтального с ReadySet
Инженеры ReadySet сравнили апгрейд инстанса MySQL с добавлением кэширующего слоя:
- Вертикальное масштабирование: удвоение ресурсов (t2.2xlarge за $134.61/мес) → +14% QPS
- ReadySet: базовый MySQL (t2.xlarge) + ReadySet на t2.medium ($84.17/мес) → +250% QPS
- Cost efficiency: стоимость за 1 QPS у ReadySet — $0.036, у вертикального масштабирования — $0.128 (ReadySet в 3.6 раза эффективнее)
Тест 3. perf stat: холодный кэш, тёплый кэш, ReadySet
Детальный анализ на уровне CPU и системных вызовов:
- Холодный кэш (диск): 10.44 сек, 181M циклов CPU
- Тёплый кэш (InnoDB): 5.40 сек, 149M циклов
- ReadySet: 0.12 сек, 113M циклов — ускорение в 45 раз против тёплого кэша, 43% меньше инструкций CPU
🇷🇺 Но вот что удивительно: в российском IT про ReadySet почти никто не знает
На «Хабре» — ноль публикаций. Ноль обзоров, ноль кейсов, даже переводов нет. При том что технология существует с 2021 года.
Видимо, все слишком заняты выбором между Redis, KeyDB, Dragonfly и Valkey — и сравнением их TTL-стратегий в сорок восьмой раз.
📚 Что почитать:
1. AWS RDS MySQL + ReadySet: независимый бенчмарк (март 2025)
Рональд Брэдфорд, эксперт по MySQL, детально разбирает нагрузочное тестирование с IMDb dataset. Цифры, графики, воспроизводимый код.
2. Вертикальное масштабирование MySQL vs горизонтальное с ReadySet
Сравнение T2.xlarge → T2.2xlarge против добавления ReadySet. Стоимость, QPS, ROI.
3. Когда оптимизации запросов уже недостаточно: MySQL под нагрузкой
Глубокий системный анализ с perf stat: холодный диск, InnoDB Buffer Pool, ReadySet.
4. InfoQ — доклад CEO ReadySet «Улучшение пользовательского опыта с помощью потоковой обработки данных»
Глубочайший разбор того, как работают dataflow-графы и почему частичная материализация убивает проблему инвалидации на корню.
5. GitHub репозиторий
9.7к коммитов, Rust, активный контрибьютинг, BSL-лицензия с конвертацией в Apache 2.0.
Благодаря ReadySet теперь можно беспокоиться только о придумывании имён.
🧠 Это не очередной Redis. Это технология, которая переворачивает то, как мы кэшируем SQL
ReadySet — проект с корнями в MIT CSAIL (докторская Аланы Марзоев, соавтора Noria). Вместо того чтобы мучиться с TTL, писать костыли для инвалидации или сносить кэш целиком при каждом UPDATE, ReadySet делает гениально простую вещь: подключается к репликационному стриму MySQL и обновляет кэшированные результаты запросов построчно, инкрементально, в реальном времени.
Никакой ручной инвалидации. Никаких «а не пора ли сбросить Redis». Кэш просто всегда точен, потому что он синхронизирован с источником на уровне бинарных логов.
🐬 MySQL — родная стихия ReadySet
Хотя формально поддерживается и PostgreSQL, именно с MySQL ReadySet раскрывается полностью: binlog, снапшоты, мгновенное отслеживание изменений. Это не обёртка, а полноценный SQL-прокси, который понимает JOIN'ы, GROUP BY и подзапросы, превращая их в миллисекундные lookup'ы без единой строки кода в приложении.
📊 Независимые бенчмарки подтверждают: ReadySet с MySQL — это другой порядок чисел
Тест 1. AWS RDS MySQL + ReadySet (март 2025)
Рональд Брэдфорд, эксперт по MySQL и экс-консультант MySQL AB, провёл серию тестов с реальной базой IMDb (20 ГБ в InnoDB). Результаты говорят сами за себя:
- Транзакции в секунду: RDS MySQL (8 vCPU) — 5.2k, ReadySet (4 vCPU) — 17.2k (рост в 3.3 раза)
- Среднее время отклика: RDS — 12.2 мс, ReadySet — 0.93 мс (ускорение в 13 раз)
- Время отклика (95-й перцентиль): RDS — 21.9 мс, ReadySet — 1.3 мс (ускорение в 17 раз)
- При 16 потоках на 8 vCPU ReadySet выдал 19.5k транзакций/сек (3.75×) со средним временем отклика 0.82 мс (15×)
Тест 2. Вертикальное масштабирование против горизонтального с ReadySet
Инженеры ReadySet сравнили апгрейд инстанса MySQL с добавлением кэширующего слоя:
- Вертикальное масштабирование: удвоение ресурсов (t2.2xlarge за $134.61/мес) → +14% QPS
- ReadySet: базовый MySQL (t2.xlarge) + ReadySet на t2.medium ($84.17/мес) → +250% QPS
- Cost efficiency: стоимость за 1 QPS у ReadySet — $0.036, у вертикального масштабирования — $0.128 (ReadySet в 3.6 раза эффективнее)
Тест 3. perf stat: холодный кэш, тёплый кэш, ReadySet
Детальный анализ на уровне CPU и системных вызовов:
- Холодный кэш (диск): 10.44 сек, 181M циклов CPU
- Тёплый кэш (InnoDB): 5.40 сек, 149M циклов
- ReadySet: 0.12 сек, 113M циклов — ускорение в 45 раз против тёплого кэша, 43% меньше инструкций CPU
🇷🇺 Но вот что удивительно: в российском IT про ReadySet почти никто не знает
На «Хабре» — ноль публикаций. Ноль обзоров, ноль кейсов, даже переводов нет. При том что технология существует с 2021 года.
Видимо, все слишком заняты выбором между Redis, KeyDB, Dragonfly и Valkey — и сравнением их TTL-стратегий в сорок восьмой раз.
📚 Что почитать:
1. AWS RDS MySQL + ReadySet: независимый бенчмарк (март 2025)
Рональд Брэдфорд, эксперт по MySQL, детально разбирает нагрузочное тестирование с IMDb dataset. Цифры, графики, воспроизводимый код.
2. Вертикальное масштабирование MySQL vs горизонтальное с ReadySet
Сравнение T2.xlarge → T2.2xlarge против добавления ReadySet. Стоимость, QPS, ROI.
3. Когда оптимизации запросов уже недостаточно: MySQL под нагрузкой
Глубокий системный анализ с perf stat: холодный диск, InnoDB Buffer Pool, ReadySet.
4. InfoQ — доклад CEO ReadySet «Улучшение пользовательского опыта с помощью потоковой обработки данных»
Глубочайший разбор того, как работают dataflow-графы и почему частичная материализация убивает проблему инвалидации на корню.
5. GitHub репозиторий
9.7к коммитов, Rust, активный контрибьютинг, BSL-лицензия с конвертацией в Apache 2.0.
Ronaldbradford
Using Readyset Caching with AWS RDS MySQL
Readyset is a next-generation database caching solution that offers a drop-in; no application code changes; approach to improve database performance. If you are using a legacy application where it is difficult to modify SQL statements, or the database is…
🔥2😁1
🐬 Новая эра MySQL: Oracle открывает коммерческие функции для сообщества
Друзья, отличные новости пришли из блога Oracle MySQL. Отметив в прошлом году 30-летний юбилей проекта, компания анонсировала кардинальные изменения в стратегии взаимодействия с сообществом.
Главное из анонса:
🚀 Функции Enterprise-версии переходят в Community Edition. Ранее платные возможности теперь будут доступны всем. Уже реализован перенос обработки внешних ключей из InnoDB в SQL-движок, о котором мы рассказывал совсем недавно.
🛠 Прозрачность и Roadmap. Oracle обещает публиковать дорожную карту развития, проводить вебинары с командой разработки и продуктовыми менеджерами, а также принимать Worklog'и от сообщества.
🔮 Что ждет в ближайших релизах (к апрелю 2026):
* Векторные функции для AI (косинусное сходство, евклидово расстояние)
* PGO-оптимизированные сборки Community Edition
* Гиперграфовый оптимизатор запросов
* Поддержка OpenTelemetry для observability
* Улучшения в многопоточной репликации
* Продвинутая HA/DR аналитика
* Улучшения для JSON duality views – достаточно интересной функции, о которой мы скоро обязательно расскажем
Это лишь то, что запланировано к апрелю 2026 года. У Oracle уже есть и дальнейшие планы по развитию MySQL Community Edition – о них обещают объявить дополнительно.
Это действительно важный шаг для MySQL. Подробности и комментарии community-менеджера — в официальном блоге.
👉 Читать полностью: https://blogs.oracle.com/mysql/new-era-of-mysql-community-engagement
👉 Видео-ролик, посвящённый 30-летию MySQL: https://www.youtube.com/watch?v=SqbV2JjnbhA
Друзья, отличные новости пришли из блога Oracle MySQL. Отметив в прошлом году 30-летний юбилей проекта, компания анонсировала кардинальные изменения в стратегии взаимодействия с сообществом.
Главное из анонса:
🚀 Функции Enterprise-версии переходят в Community Edition. Ранее платные возможности теперь будут доступны всем. Уже реализован перенос обработки внешних ключей из InnoDB в SQL-движок, о котором мы рассказывал совсем недавно.
🛠 Прозрачность и Roadmap. Oracle обещает публиковать дорожную карту развития, проводить вебинары с командой разработки и продуктовыми менеджерами, а также принимать Worklog'и от сообщества.
🔮 Что ждет в ближайших релизах (к апрелю 2026):
* Векторные функции для AI (косинусное сходство, евклидово расстояние)
* PGO-оптимизированные сборки Community Edition
* Гиперграфовый оптимизатор запросов
* Поддержка OpenTelemetry для observability
* Улучшения в многопоточной репликации
* Продвинутая HA/DR аналитика
* Улучшения для JSON duality views – достаточно интересной функции, о которой мы скоро обязательно расскажем
Это лишь то, что запланировано к апрелю 2026 года. У Oracle уже есть и дальнейшие планы по развитию MySQL Community Edition – о них обещают объявить дополнительно.
Это действительно важный шаг для MySQL. Подробности и комментарии community-менеджера — в официальном блоге.
👉 Читать полностью: https://blogs.oracle.com/mysql/new-era-of-mysql-community-engagement
👉 Видео-ролик, посвящённый 30-летию MySQL: https://www.youtube.com/watch?v=SqbV2JjnbhA
Oracle
New Era of MySQL Community Engagement
Полезный ежегодный обзор баз данных в тексте Databases in 2025: A Year in Review от Andy Pavlov.
Всем кто работает с данными большого объёма будет полезно, вот ключевые выдержки:
1. Доминирование PostgreSQL продолжается. Многие экспериментируют со многими базами данных, но в продакшен всё равно используется PostgreSQL и совместимые с ним и его протоколом аналоги.
2. MCP для каждой СУБД. Похоже что тренд очевиден, MCP прикручивают к каждой СУБД каждый вендор и в этом нет ничего дурного. Больше универсальных интерфейсов полезных и нужных
3. MongoDB против FerretDB. MongoDB активно давит на FerretDB в том что воспроизведение их API и протокола нарушает их права. Такого в области баз данных ранее не было, самое близкое - это разборки Oracle vs Google из-за Java API. Тогда Oracle не удалось убедить суд в том что их права нарушены
4. Поле битвы форматов файлов. Активно идет появление новых стандартов и форматов дата файлов на замену Parquet. Я также не спроста писал про эту тему так часто, там идет сильная конкуренция и интересные технические решения
В оригинальном обзоре много ссылок и других событий
Всем кто работает с данными большого объёма будет полезно, вот ключевые выдержки:
1. Доминирование PostgreSQL продолжается. Многие экспериментируют со многими базами данных, но в продакшен всё равно используется PostgreSQL и совместимые с ним и его протоколом аналоги.
2. MCP для каждой СУБД. Похоже что тренд очевиден, MCP прикручивают к каждой СУБД каждый вендор и в этом нет ничего дурного. Больше универсальных интерфейсов полезных и нужных
3. MongoDB против FerretDB. MongoDB активно давит на FerretDB в том что воспроизведение их API и протокола нарушает их права. Такого в области баз данных ранее не было, самое близкое - это разборки Oracle vs Google из-за Java API. Тогда Oracle не удалось убедить суд в том что их права нарушены
4. Поле битвы форматов файлов. Активно идет появление новых стандартов и форматов дата файлов на замену Parquet. Я также не спроста писал про эту тему так часто, там идет сильная конкуренция и интересные технические решения
В оригинальном обзоре много ссылок и других событий
Andy Pavlo - Carnegie Mellon University
Databases in 2025: A Year in Review
The world tried to kill Andy off but he had to stay alive to to talk about what happened with databases in 2025.
🤡1
🆕 Zhao Song начинает цикл статей о внутреннем устройстве MySQL и PostgreSQL
Чжао Сун запускает серию материалов, в которой на примерах конкретных механизмов показывает, как схожие задачи решаются в двух популярных СУБД. Первая часть посвящена буферному пулу — ключевому компоненту, отвечающему за кэширование данных в памяти.
В заметке детально разбираются:
🔹 Структура хеш-таблиц для поиска страниц
🔹 Алгоритмы вытеснения старых страниц (LRU с оптимизациями в MySQL и clock sweep в PostgreSQL)
🔹 Стратегии фоновой записи грязных страниц (Page Cleaner в MySQL против bgwriter и checkpointer в PostgreSQL)
Автор наглядно показывает, как теоретически одинаковые задачи приводят к разным инженерным решениям из-за выбранных компромиссов. Материал будет полезен всем, кто хочет глубже понять внутреннее устройство этих СУБД.
🔗 Читать: https://kernelmaker.github.io/mysql-vs-pg-bufferpool
Чжао Сун запускает серию материалов, в которой на примерах конкретных механизмов показывает, как схожие задачи решаются в двух популярных СУБД. Первая часть посвящена буферному пулу — ключевому компоненту, отвечающему за кэширование данных в памяти.
В заметке детально разбираются:
🔹 Структура хеш-таблиц для поиска страниц
🔹 Алгоритмы вытеснения старых страниц (LRU с оптимизациями в MySQL и clock sweep в PostgreSQL)
🔹 Стратегии фоновой записи грязных страниц (Page Cleaner в MySQL против bgwriter и checkpointer в PostgreSQL)
Автор наглядно показывает, как теоретически одинаковые задачи приводят к разным инженерным решениям из-за выбранных компромиссов. Материал будет полезен всем, кто хочет глубже понять внутреннее устройство этих СУБД.
🔗 Читать: https://kernelmaker.github.io/mysql-vs-pg-bufferpool
kernelmaker.github.io
MySQL vs PostgreSQL Internals (Part 1) -- Buffer Pool ·
The debate over “MySQL vs PostgreSQL, which one is better?” has been around for a long time. As two outstanding repre...
Если PostgreSQL занимает важное место в вашей инфре, обратите внимание на новый экстеншен, который сделали в ClickHouse.
Каждый запрос PostgreSQL (SELECT, INSERT, DDL и даже запросы, завершившиеся с ошибкой) фиксируется как событие фиксированного размера с 45 полями: время выполнения, буферный I/O, статистика WAL, CPU, JIT, ошибки и клиентский контекст.
Дальше немного примитивной магии: кольцевой буфер, бэкграунд-стриминг в ClickHouse, и у вас готовая перфоманс-аналитика.
По ссылке прикольная внутрянка: https://lnkd.in/dcwy2g9z.
Каждый запрос PostgreSQL (SELECT, INSERT, DDL и даже запросы, завершившиеся с ошибкой) фиксируется как событие фиксированного размера с 45 полями: время выполнения, буферный I/O, статистика WAL, CPU, JIT, ошибки и клиентский контекст.
Дальше немного примитивной магии: кольцевой буфер, бэкграунд-стриминг в ClickHouse, и у вас готовая перфоманс-аналитика.
По ссылке прикольная внутрянка: https://lnkd.in/dcwy2g9z.
lnkd.in
LinkedIn
This link will take you to a page that’s not on LinkedIn
🤡2
немного здравого смысла от StarRocks
Best Practice #1. Как выбирать Partition Key, сколько Buckets, и когда Colocate. Часть первая — Партиции
Когда создаешь таблицу в StarRocks, три решения определяют ~80% производительности: партиционирование, бакетирование и colocate group. Ошибся — и запросы начинают читать в десятки раз больше данных, чем нужно. Самое обидное, что часто незаметно, пока не заглянешь в EXPLAIN.
Зачем нужны партиции:
Партиция — это физическое разделение данных. Главная цель — partition pruning. Чтобы запрос с фильтром по ключу партиционирования (например, по времени) мог вообще не трогать старые куски данных. Пример: WHERE dt >= '2025-01-01' → не читаем партиции за 2024.
Какие стратегии (методы) партиционирования есть в StarRocks (OLAP):
🔹Expression partitioning (recommended) — партиции задаются выражением, а создаются и поддерживаются автоматически при загрузке данных.
🔹Range partitioning (Legacy) — классический RANGE, диапазоны задаются явно (VALUES LESS THAN ...), управление партициями чаще руками.
🔹List partitioning (Legacy) — LIST по перечисленным значениям (VALUES IN (...)).
С версии 3.4 StarRocks двигается к унификации вокруг expression-подхода и рекомендуют expression вместо range и list.
В документации отлично описаны лучшие практики по партиционированию (ссылки на документации ru, en). Вычленим только самые важные моменты.
Когда партиции НЕ нужны:
🔹Маленькие dimension/lookup таблицы → чаще проще не партиционировать, а ориентироваться на распределение/бакеты. Примеры таблиц: курсы валют, гео-справочники, таблицы для расшифровки кодов.
🔹Нет стабильного фильтра (например, почти никогда не фильтруете по времени/tenant/ключу данных) → pruning не будет, выигрыш сомнительный. Примеры таблиц: каталог товаров или единый реестр клиентов.
Выбор Partition Key:
1️⃣ Если ~80% запросов с фильтром по времени → начинай со времени: PARTITION BY date_trunc('day', dt)
2️⃣ Если нужна retention/TTL → ключ партиции должен совпадать с тем, по чему вы будете чистить данные.
3️⃣ Осторожно с составным ключом типа tenant_id × day: можно попасть в ситуацию, когда создастся большое число партиций (в документации советуют держать общее число в разумных пределах, иначе страдают FE-метаданные и компакшены).
Гранулярность:
DAY → большинство BI/reporting сценариев.
HOUR → IoT/высокая частота записи, изоляция горячих часов, но очень много партиций.
MONTH → исторические архивы, мало метаданных, но грубее pruning.
Правило: держите партицию не больше 100 GB, и не разгоняйте число таблетов на партицию.
Как проверить, что pruning реально работает:
EXPLAIN SELECT * FROM orders WHERE dt = '2025-06-15';
Ищите что-то вроде partitions=1/365 — читается одна партиция из 365.
Если видите partitions=365/365 — pruning не сработал.
docs.starrocks.io
Partitioning | StarRocks
Fast analytics in StarRocks begin with a table layout that matches your query patterns.
🤡1
Худшие фейлы в DE
Наткнулась на тред в реддите, где обсуждались фейлы на работе. Мне больше всего зашли 2 истории, они такие смешные и страшные одновременно🤯
1️⃣ Стриминг писал в то же самое место, откуда и читал. Это все длилось год, поэтому накопилось сотни триллионов миллиардов версий документов. Проблема обнаружилась, только когда к ним пришел AWS и пожаловался на проблемы в своих системах
Неужели за этот год они не заметили, как эти пайплайны работают все медленнее и медленнее, почему такая высокая нагрузка и что в таблицах кучи дублей?
2️⃣ DE понизил уровень логирования до DEBUG, и это привело к расходам в 100к долларов за неделю
Кажется, теперь я знаю способ, как можно уменьшить расходы компании. Ничего не логировать😁
💰 Мы сейчас тоже переходим в эру FinOps. Будем пугать аналитиков, чтобы писали оптимальные запросы 😁
А у вас было что-то супер серьезное?
Ссылка на тред
Наткнулась на тред в реддите, где обсуждались фейлы на работе. Мне больше всего зашли 2 истории, они такие смешные и страшные одновременно
Неужели за этот год они не заметили, как эти пайплайны работают все медленнее и медленнее, почему такая высокая нагрузка и что в таблицах кучи дублей?
Кажется, теперь я знаю способ, как можно уменьшить расходы компании. Ничего не логировать
А у вас было что-то супер серьезное?
Ссылка на тред
Please open Telegram to view this post
VIEW IN TELEGRAM
Reddit
From the dataengineering community on Reddit
Explore this post and more from the dataengineering community
На следующий неделе мы наконец-то выпустим релиз Слайдер Данных для Excel , а пока насладитесь версией для Р7 Офис в Windows
https://data.slider-ai.ru
и
Конечно - Видео Обзор
https://data.slider-ai.ru
и
Конечно - Видео Обзор
data.slider-ai.ru
Автоматизируйте работу с базами данных в Р7-Офис и Excel — Слайдер Данные
Слайдер Данные для Р7-Офис и Excel это отечественная альтернатива Power Query. Подключайтесь к базам данных и выполняйте прямые SQL-запросы к Oracle, PostgreSQL, MS SQL, объединяйте данные из разных источников и автоматизируйте отчетность без ручного копирования.…
🔥3
Статья о кубах и размерностях немного водянистая, но для тех кто только вкатывается в моделирование данных будет полезна
https://habr.com/ru/companies/korus_consulting/articles/990668/
https://habr.com/ru/companies/korus_consulting/articles/990668/
Хабр
Проектирование быстрых кубов: ключевые принципы производительной архитектуры многомерных БД
Кирилл Паршин Ведущий консультант, департамент EPM «КОРУС Консалтинг» Многомерные базы данных (MDB) — это незаметные, но критически важные механизмы практически всех систем корпоративного управления...
Forwarded from MyDB
🧩 Краткая история «binlog-серверов» в экосистеме MySQL: от первопроходцев к современности
🕳️ Самый первый — MySQL с Blackhole
Обычный MySQL в топологии репликации с движком Blackhole: данные «испаряются», но бинарные логи генерируются и уходят дальше. Гениально просто, но на практике масса проблем:
— Лишние расходы на полноценный СУБД.
— Надо следить, что все таблицы используют Blackhole.
— В старых версиях параллельная репликация работала хуже (к 8.0+ проблема не относится).
👻 MySQL Ripple от Google (архивирован)
Проект 2019 года для разгрузки мастера и надёжного хранения binlog. Сейчас репозиторий в read-only и не поддерживается.
🚂 Kingbus от flike (заброшен)
Амбициозный проект на Go с raft-консенсусом, распределённое хранилище binlog, поддержка гео-репликации. Последние коммиты — 2019 год, разработка не ведётся.
🇨🇳 Canal от Alibaba
Зрелый инструмент для CDC (Change Data Capture): забирает binlog и отправляет в Kafka/RocketMQ и др. Ключевая особенность: ориентирован на китайскую аудиторию — документация на китайском, что создаёт барьер для международного сообщества.
🤔 Почему Percona начала свою реализацию?
1. Промышленная поддержка и понятный роадмап.
2. Облака «из коробки» (AWS S3 и S3-совместимые).
3. Универсальность: не только бэкапы и PITR, но и дешёвая замена промежуточному серверу в каскадной репликации (без проблем Blackhole).
4. Живая разработка: поддержка MySQL 8.0, 8.4, 9.x, CI/CD, REST API в планах.
🏁 Вывод
Эволюция: от «костыля» с Blackhole → экспериментальные Ripple и Kingbus → нишевый Canal. Percona строит универсальный инфраструктурный компонент для MySQL-сообщества: бэкапы binlog, PITR, разгрузка мастера и лёгкая замена промежуточному серверу.
Кстати, в экосистеме PostgreSQL аналогов binlog-сервера до сих пор не изобрели — там есть каскадная репликация и архивация WAL, но «сервера логов» для внешних потребителей тоже не хватает.
👉 Ссылки
▶️ Видео доклада: Binary Log Server - the missing MySQL infrastructure component (Yura Sorokin, Percona)
📄 Слайды доклада
📦 Percona Binary Log Server: GitHub
👻 MySQL Ripple: GitHub (архивирован)
🚂 Kingbus: GitHub (заброшен)
🇨🇳 Canal: GitHub
🕳️ Самый первый — MySQL с Blackhole
Обычный MySQL в топологии репликации с движком Blackhole: данные «испаряются», но бинарные логи генерируются и уходят дальше. Гениально просто, но на практике масса проблем:
— Лишние расходы на полноценный СУБД.
— Надо следить, что все таблицы используют Blackhole.
— В старых версиях параллельная репликация работала хуже (к 8.0+ проблема не относится).
👻 MySQL Ripple от Google (архивирован)
Проект 2019 года для разгрузки мастера и надёжного хранения binlog. Сейчас репозиторий в read-only и не поддерживается.
🚂 Kingbus от flike (заброшен)
Амбициозный проект на Go с raft-консенсусом, распределённое хранилище binlog, поддержка гео-репликации. Последние коммиты — 2019 год, разработка не ведётся.
🇨🇳 Canal от Alibaba
Зрелый инструмент для CDC (Change Data Capture): забирает binlog и отправляет в Kafka/RocketMQ и др. Ключевая особенность: ориентирован на китайскую аудиторию — документация на китайском, что создаёт барьер для международного сообщества.
🤔 Почему Percona начала свою реализацию?
1. Промышленная поддержка и понятный роадмап.
2. Облака «из коробки» (AWS S3 и S3-совместимые).
3. Универсальность: не только бэкапы и PITR, но и дешёвая замена промежуточному серверу в каскадной репликации (без проблем Blackhole).
4. Живая разработка: поддержка MySQL 8.0, 8.4, 9.x, CI/CD, REST API в планах.
🏁 Вывод
Эволюция: от «костыля» с Blackhole → экспериментальные Ripple и Kingbus → нишевый Canal. Percona строит универсальный инфраструктурный компонент для MySQL-сообщества: бэкапы binlog, PITR, разгрузка мастера и лёгкая замена промежуточному серверу.
Кстати, в экосистеме PostgreSQL аналогов binlog-сервера до сих пор не изобрели — там есть каскадная репликация и архивация WAL, но «сервера логов» для внешних потребителей тоже не хватает.
👉 Ссылки
▶️ Видео доклада: Binary Log Server - the missing MySQL infrastructure component (Yura Sorokin, Percona)
📄 Слайды доклада
📦 Percona Binary Log Server: GitHub
👻 MySQL Ripple: GitHub (архивирован)
🚂 Kingbus: GitHub (заброшен)
🇨🇳 Canal: GitHub
YouTube
Binary Log Server - the missing MySQL infrastructure component (Yura Sorokin, Percona)
In this session I will give you an introduction to a new open-source tool in the MySQL family – the Binary Log Server from Percona. This tool started as a simple continuous backup solution for Point-in-time Recovery (PITR). The Binary Log Server has a huge…
Forwarded from дата инженеретта
max_by/min_by
Узнала про прикольные функции, они заменяют оконку/CTE на одно поле
Пример - вывести имя сотрудника с максимальным стажем по каждому департаменту
И все! Не надо никаких row_number = 1
В Spark SQL можно еще и фильтр набросить:
А в Trino еще можно собрать массив топ-n в убывающем порядке:
Аналог в ClickHouse - argMax
@data_engineerette
Узнала про прикольные функции, они заменяют оконку/CTE на одно поле
Пример - вывести имя сотрудника с максимальным стажем по каждому департаменту
result = df.groupBy("department").agg(
F.max_by("name", "years")
)
И все! Не надо никаких row_number = 1
В Spark SQL можно еще и фильтр набросить:
spark.sql("""
select
department,
max_by(name, years) filter (where name is not null)
from employees
group by department
""")
А в Trino еще можно собрать массив топ-n в убывающем порядке:
select
department,
max_by(name, years) AS top_employee,
max_by(name, years, 2) AS top_2_employees
from employees
group by department
Аналог в ClickHouse - argMax
@data_engineerette
Forwarded from 🌸Таня и Данные📊
⁉️Зачем мне эта ваша математика?
«Я в аналитику пришел из Excel, зачем мне эта высшая математика: интегралы, пределы, производные и логарифмы?» - частый вопрос новичков, которые меняют сферу деятельности, давайте разбираться на пальцах и реальных задачах.
Спойлер: если вы строите только простые отчеты и не лезете вглубь - матан и правда не пригодится, но если хотите расти и решать нетривиальные аналитические задачи, то без него никуда.
💡 Логарифмы: нужны там, где всё растет слишком быстро
Где встречаются: зарплаты, цены на недвижимость, посещаемость сайта, время в приложении.
Суть: в реальности многие процессы растут не линейно, а экспоненциально, когда вы строите график с огромным разбросом значений, мелкие детали теряются.
❓ Задача: У вас есть 1000 пользователей, которые платят от 100 до 1 000 000 рублей. Если построить обычный график, то 90% людей сгрудятся в одной точке у нуля, и ничего не увидеть.
💡 Решение: Берем логарифм от суммы платежа (log1p в Pandas) и сразу видим распределение: богатые клиенты перестают «зашкаливать», бедные становятся видны. Логарифмическая шкала - это базовая вещь в EDA (разведочном анализе данных).
💡 Производные: скорость изменений
Где встречаются: маркетинговые кампании, AB тесты, анализ динамики.
Суть: производная в переводе с математического - это «скорость изменения функции», в аналитике мы постоянно считаем приросты и темпы роста.
❓ Задача: Вы запустили рекламу. Выручка выросла на 10% за месяц. Это круто? А если в прошлом месяце был рост 30%, а в этом всего 10% - это уже проблема. Тут мы смотрим не только на абсолютные значения, но и на их производные.
💡 Решение: Производная в коде - это просто разница между сегодня и вчера, деленная на вчера (pandas .diff() / .shift()). Но понимание, что вы считаете скорость, помогает не тупить и правильно интерпретировать результаты.
💡 Пределы и асимптоты: потолок роста
Где встречаются: прогнозирование, оценка насыщения рынка, когортный анализ, предел показывает, к чему стремится процесс, но чего никогда не достигнет.
❓ Задача: Вы считаете Retention (возвращаемость пользователей). Она падает и стабилизируется где-то около 20%. Это и есть предел - точка насыщения, дальше удерживать пользователей можно только качественными изменениями продукта.
💡 Решение: Понимание пределов помогает не строить иллюзий. Если retention уже вышел на плато - никакие скидки и пуш-уведомления не поднимут его выше математического предела.
💡 Интегралы: накопленный итог
Где встречаются: LTV (клиентская ценность), когортный анализ, расчеты запасов.
Суть: Интеграл - это площадь под графиком, в аналитике это «накопленный итог» или «суммарный эффект».
❓ Задача: Вы запустили акцию, продажи скачут: сегодня 100, завтра 200, послезавтра 50, чтобы оценить реальный эффект акции, нужно посчитать интеграл - то есть сумму всех продаж за период.
💡 Решение: В SQL это SUM() OVER(ORDER BY date), в математике это называется «определенный интеграл». Когда вы считаете LTV клиента за 12 месяцев, то вы берете интеграл от его платежей по времени.
Коротко и на пальцах:
Если вы умеете в уме переключаться между этими понятиями, вы:
✔️ Не путаете % роста и абсолютный прирост;
✔️ Понимаете, почему логирифмировать распределение зарплат - это ок;
✔️ Можете объяснить бизнесу, почему дальше расти некуда (упретесь в предел);
✔️ Правильно считаете LTV и Retention;
Никто не просит вас брать интегралы в уме или рисовать графики производных от руки, но понимать, что стоит за функциями .log(), .diff() и .cumsum() в Pandas - must have для каждого осознанного аналитика.
❓ А как у вас с математикой?
В комментарии добавлю подборку книг по математике для анализа данных (подходят для разных уровней)🫴 .
#аналитика
«Я в аналитику пришел из Excel, зачем мне эта высшая математика: интегралы, пределы, производные и логарифмы?» - частый вопрос новичков, которые меняют сферу деятельности, давайте разбираться на пальцах и реальных задачах.
Спойлер: если вы строите только простые отчеты и не лезете вглубь - матан и правда не пригодится, но если хотите расти и решать нетривиальные аналитические задачи, то без него никуда.
Где встречаются: зарплаты, цены на недвижимость, посещаемость сайта, время в приложении.
Суть: в реальности многие процессы растут не линейно, а экспоненциально, когда вы строите график с огромным разбросом значений, мелкие детали теряются.
Где встречаются: маркетинговые кампании, AB тесты, анализ динамики.
Суть: производная в переводе с математического - это «скорость изменения функции», в аналитике мы постоянно считаем приросты и темпы роста.
Где встречаются: прогнозирование, оценка насыщения рынка, когортный анализ, предел показывает, к чему стремится процесс, но чего никогда не достигнет.
Где встречаются: LTV (клиентская ценность), когортный анализ, расчеты запасов.
Суть: Интеграл - это площадь под графиком, в аналитике это «накопленный итог» или «суммарный эффект».
Коротко и на пальцах:
Если вы умеете в уме переключаться между этими понятиями, вы:
Никто не просит вас брать интегралы в уме или рисовать графики производных от руки, но понимать, что стоит за функциями .log(), .diff() и .cumsum() в Pandas - must have для каждого осознанного аналитика.
В комментарии добавлю подборку книг по математике для анализа данных (подходят для разных уровней)
#аналитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Forwarded from MyDB
🐳 MySQL 9.6.0: Глубокая интеграция с контейнерами
Релиз MySQL 9.6.0 (конец января) принес важное улучшение для тех, кто использует контейнеризацию. Появилась серверная переменная
Суть изменений:
Ранее MySQL уже умел определять объемы доступной памяти и ядер CPU и использовать эти значения для автоматической подстройки собственных лимитов. Теперь поведение этого кода зависит от нового флага:
🔹 container_aware = ON: Сервер проверяет, запущен ли он в контейнере (cgroup). Если да — он учитывает лимиты контейнера при выделении памяти и настройке всех ресурсозависимых параметров: размер
🔹 container_aware = OFF (по умолчанию): Режим совместимости с предыдущими версиями — сервер игнорирует контейнер и смотрит на ресурсы хоста. При этом в лог пишется предупреждение, если MySQL обнаруживает, что работает в контейнере с ограничениями.
Зачем это нужно: Долгожданная фича для корректной работы MySQL в оркестрации (Kubernetes и т.д.). Позволяет избежать ситуации, когда база данных внутри контейнера думает, что у нее 64 ядра и 512 ГБ RAM, хотя реально выделено только 2 ядра и 4 ГБ. Больше никаких неожиданных OOM и неоптимальных настроек!
Что дальше? В MySQL проведена многолетняя подготовительная работа: большинство серверных параметров уже давно меняются на лету без перезагрузки сервера. Логичным следующим шагом было бы научить MySQL не только учитывать лимиты при старте, но и отслеживать их изменения "на лету". В динамических средах (например, Kubernetes с вертикальным автомасштабированием) лимиты контейнера могут меняться без перезапуска пода — и тогда MySQL мог бы динамически подстраивать buffer_pool_size или количество рабочих потоков без даунтайма.
Релиз MySQL 9.6.0 (конец января) принес важное улучшение для тех, кто использует контейнеризацию. Появилась серверная переменная
container_aware.Суть изменений:
Ранее MySQL уже умел определять объемы доступной памяти и ядер CPU и использовать эти значения для автоматической подстройки собственных лимитов. Теперь поведение этого кода зависит от нового флага:
🔹 container_aware = ON: Сервер проверяет, запущен ли он в контейнере (cgroup). Если да — он учитывает лимиты контейнера при выделении памяти и настройке всех ресурсозависимых параметров: размер
innodb_buffer_pool_size, лимиты для in-memory временных таблиц ( temptable_max_ram ), количество потоков InnoDB ( innodb_read_io_threads, innodb_purge_threads, parallel_read_threads ) и другие. Если лимиты не найдены или сервер запущен не в контейнере — выход с ошибкой.🔹 container_aware = OFF (по умолчанию): Режим совместимости с предыдущими версиями — сервер игнорирует контейнер и смотрит на ресурсы хоста. При этом в лог пишется предупреждение, если MySQL обнаруживает, что работает в контейнере с ограничениями.
Зачем это нужно: Долгожданная фича для корректной работы MySQL в оркестрации (Kubernetes и т.д.). Позволяет избежать ситуации, когда база данных внутри контейнера думает, что у нее 64 ядра и 512 ГБ RAM, хотя реально выделено только 2 ядра и 4 ГБ. Больше никаких неожиданных OOM и неоптимальных настроек!
Что дальше? В MySQL проведена многолетняя подготовительная работа: большинство серверных параметров уже давно меняются на лету без перезагрузки сервера. Логичным следующим шагом было бы научить MySQL не только учитывать лимиты при старте, но и отслеживать их изменения "на лету". В динамических средах (например, Kubernetes с вертикальным автомасштабированием) лимиты контейнера могут меняться без перезапуска пода — и тогда MySQL мог бы динамически подстраивать buffer_pool_size или количество рабочих потоков без даунтайма.
Forwarded from Visiology Official
Российский BI-рынок в 2025 году: кто 💪 усиливается и почему это важно
Вчера в прямом эфире управляющий партнер Visiology Иван Вахмянин представил исследование «Пульс BI 2026: анализ Business Intelligence в России».
По итогам вебинара мы подготовили для вас ключевые выводы в формате карточек. Листайте, чтобы почувствовать пульс BI🟡
Для тех, кто хочет погрузиться глубже, мы уже загрузили запись эфира на наши площадки VK Видео | Rutube | YouTube
Visiology в мессенджере MAX
Вчера в прямом эфире управляющий партнер Visiology Иван Вахмянин представил исследование «Пульс BI 2026: анализ Business Intelligence в России».
Понимание реальной картины, объема рынка, структуры, долей и найма, становится отправной точкой для стратегических решений: во что инвестировать, как развивать продукт и какую BI-платформу выбирать в условиях новой конкуренции.
По итогам вебинара мы подготовили для вас ключевые выводы в формате карточек. Листайте, чтобы почувствовать пульс BI
Для тех, кто хочет погрузиться глубже, мы уже загрузили запись эфира на наши площадки VK Видео | Rutube | YouTube
Visiology в мессенджере MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1