Полезный ежегодный обзор баз данных в тексте 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
Forwarded from Клуб CDO
Дайджест статей
📰: Путь в аналитику данных: базовый минимум для старта
Ссылка: https://habr.com/ru/articles/1003704/
Вывод одной строкой: Для успешного входа в аналитику данных необходимо освоить SQL, Python/R, основы статистики и визуализации данных, а также развивать навыки работы с бизнес-задачами и критического мышления, постепенно наращивая экспертизу через практические проекты и непрерывное обучение.
📰: BI-аналитик: стартовый пакет необходимых навыков
Ссылка: https://habr.com/ru/articles/1004298/
Вывод одной строкой: Для успешной работы BI-аналитиком необходимо освоить SQL для работы с базами данных, инструменты визуализации данных (Tableau, Power BI), основы статистики и аналитического мышления, а также развить навыки коммуникации для эффективного представления результатов анализа бизнес-заказчикам.
📰: Как мы улучшили рекомендации для пользователей Авито с помощью трансформенной персонализации
Ссылка: https://habr.com/ru/companies/avito/articles/1004694/
Вывод одной строкой: Трансформерная архитектура с механизмом внимания позволяет значительно повысить качество рекомендательных систем за счет более точного моделирования последовательности действий пользователя и учета долгосрочных зависимостей в его поведении.
📰: Data Mesh, Data Fabric, Lakehouse: разбираем модные термины
Ссылка: https://habr.com/ru/articles/1005062/
Вывод одной строкой: Современные архитектурные подходы Data Mesh, Data Fabric и Lakehouse решают разные задачи управления данными: децентрализацию и демократизацию доступа, интеллектуальную интеграцию разрозненных источников и унификацию аналитических и транзакционных нагрузок соответственно, поэтому выбор конкретного решения должен основываться на организационной структуре компании, существующей инфраструктуре и бизнес-целях.
📰: Data catalog есть, а пользы нет: Частые ошибки внедрения
Ссылка: https://habr.com/ru/articles/1003158/
Вывод одной строкой: Успешное внедрение каталога данных требует не только технической реализации, но и активного вовлечения пользователей, четкого определения процессов управления метаданными и постоянной поддержки культуры работы с данными в организации.
📰: Путь в аналитику данных: базовый минимум для старта
Ссылка: https://habr.com/ru/articles/1003704/
Вывод одной строкой: Для успешного входа в аналитику данных необходимо освоить SQL, Python/R, основы статистики и визуализации данных, а также развивать навыки работы с бизнес-задачами и критического мышления, постепенно наращивая экспертизу через практические проекты и непрерывное обучение.
📰: BI-аналитик: стартовый пакет необходимых навыков
Ссылка: https://habr.com/ru/articles/1004298/
Вывод одной строкой: Для успешной работы BI-аналитиком необходимо освоить SQL для работы с базами данных, инструменты визуализации данных (Tableau, Power BI), основы статистики и аналитического мышления, а также развить навыки коммуникации для эффективного представления результатов анализа бизнес-заказчикам.
📰: Как мы улучшили рекомендации для пользователей Авито с помощью трансформенной персонализации
Ссылка: https://habr.com/ru/companies/avito/articles/1004694/
Вывод одной строкой: Трансформерная архитектура с механизмом внимания позволяет значительно повысить качество рекомендательных систем за счет более точного моделирования последовательности действий пользователя и учета долгосрочных зависимостей в его поведении.
📰: Data Mesh, Data Fabric, Lakehouse: разбираем модные термины
Ссылка: https://habr.com/ru/articles/1005062/
Вывод одной строкой: Современные архитектурные подходы Data Mesh, Data Fabric и Lakehouse решают разные задачи управления данными: децентрализацию и демократизацию доступа, интеллектуальную интеграцию разрозненных источников и унификацию аналитических и транзакционных нагрузок соответственно, поэтому выбор конкретного решения должен основываться на организационной структуре компании, существующей инфраструктуре и бизнес-целях.
📰: Data catalog есть, а пользы нет: Частые ошибки внедрения
Ссылка: https://habr.com/ru/articles/1003158/
Вывод одной строкой: Успешное внедрение каталога данных требует не только технической реализации, но и активного вовлечения пользователей, четкого определения процессов управления метаданными и постоянной поддержки культуры работы с данными в организации.
Хабр
Путь в аналитику данных: базовый минимум для старта
❓Кто такой аналитик данных и зачем он нужен Аналитик данных — это специалист, который умеет доставать данные, очищать и фильтровать их, проводить исследование, визуализировать и интерпретировать...