Что такое большие данные, а что такое маленькие данные?
Каждый год это понятие меняется. Для аналитических систем это важно, ведь мы строим инженерные системы, чтобы обрабатывать большие данные! (Но непонятно, что значит большие данные).
Самое простое определение - данные, которые не помещаются на локальном компьютере и которые мы не можем загрузить в оперативную память, даже если они сжаты.
Мы начинаем смотреть на distributed computing engines - Greenplum, Spark, Snowflake, Trino и т. п. Такие системы умеют обрабатывать данные параллельно.
Часто мы выбираем дорогую систему (distributed) для наших будущих объемов, а кто-то вообще ни разу в жизни ничего не выбирал и работает на legacy всю свою карьеру.
А ведь времена меняются, и теперь мы можем читать 1 ТБ данных с помощью одной машины, если использовать DuckDB. Можете посмотреть подробности в статье -
Processing 1 TB with DuckDB in less than 30 seconds
Товарищ сначала сгенерировал 1 ТБ данных на внешнем SSD, а потом написал к ним запрос. Если использовать MotherDuck и читать данные с S3, будет еще удобнее и быстрее.
В новом году хочу попробовать сократить расходы на Snowflake за счет использования DuckDB.
Каждый год это понятие меняется. Для аналитических систем это важно, ведь мы строим инженерные системы, чтобы обрабатывать большие данные! (Но непонятно, что значит большие данные).
Самое простое определение - данные, которые не помещаются на локальном компьютере и которые мы не можем загрузить в оперативную память, даже если они сжаты.
Мы начинаем смотреть на distributed computing engines - Greenplum, Spark, Snowflake, Trino и т. п. Такие системы умеют обрабатывать данные параллельно.
Часто мы выбираем дорогую систему (distributed) для наших будущих объемов, а кто-то вообще ни разу в жизни ничего не выбирал и работает на legacy всю свою карьеру.
А ведь времена меняются, и теперь мы можем читать 1 ТБ данных с помощью одной машины, если использовать DuckDB. Можете посмотреть подробности в статье -
Processing 1 TB with DuckDB in less than 30 seconds
Товарищ сначала сгенерировал 1 ТБ данных на внешнем SSD, а потом написал к ним запрос. Если использовать MotherDuck и читать данные с S3, будет еще удобнее и быстрее.
В новом году хочу попробовать сократить расходы на Snowflake за счет использования DuckDB.
blog.dataexpert.io
Processing 1 TB with DuckDB in less than 30 seconds
And so can you
Forwarded from Архитектор Данных
Закончил читать курс по DLH, Iceberg, Modern Data Stack. Полагаю, что несколько человек (и я точно в их числе) продвинулись в понимании этого стека.
Курс показал себя востребованным. В нашей небольшой группе наступил SOLD-OUT за неделю до старта самих занятий. Хочу сказать огромное спасибо слушателям! За то, что помогли этому курсу случиться. За терпение к неизбежным косяками первого запуска. За то, что занесли в процессе много полезных сервисов и статей. За то что огромное количество раз заставили задуматься: «Хмм, а почему это вот так?», или «Блин, а действительно, почему бы не попробовать сделать вот эдак!»
Что хочется сказать о самой технологии Lakehouse+Iceberg - несколько пунктов, в которые я верю и вижу подтверждения своей веры.
📈 Она точно рано или поздно будет во всех местах, где есть 100+ ТБайт полезных реально используемых данных.
🔬 С нее точно удобнее сразу начинать, если вы амбициозная команда, и ищете способ продолжить технологическую экспансию в точке, где 1 ТБайт данных на Postgres начинают уже скрипеть.
📈 Мы точно увидим активное развитие экосистемы в ближайшие годы. А сервисы, которые делают стек более удобным, безопасным, быстрым точно будут востребованы рынком.
Ссылка на запись та же. Второй поток стартует в феврале. До встречи в новом году!
Курс показал себя востребованным. В нашей небольшой группе наступил SOLD-OUT за неделю до старта самих занятий. Хочу сказать огромное спасибо слушателям! За то, что помогли этому курсу случиться. За терпение к неизбежным косяками первого запуска. За то, что занесли в процессе много полезных сервисов и статей. За то что огромное количество раз заставили задуматься: «Хмм, а почему это вот так?», или «Блин, а действительно, почему бы не попробовать сделать вот эдак!»
Что хочется сказать о самой технологии Lakehouse+Iceberg - несколько пунктов, в которые я верю и вижу подтверждения своей веры.
Ссылка на запись та же. Второй поток стартует в феврале. До встречи в новом году!
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Запускаю курс по Lakehouse, Iceberg, Modern Data Stack.
В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов.
Все это время мне много пишут в личку с техническими и организацонными…
В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов.
Все это время мне много пишут в личку с техническими и организацонными…
GizmoSQL — High-Performance SQL Server for the Cloud
GizmoSQL — это open-source SQL database engine, работающий на базе DuckDB и Apache Arrow Flight SQL.
По бенчмаркам Gizmo опережает Trino и DataFusion.
Есть адаптеры к DBT и PySpark DataFrame API.
Есть как open-source вариант так и платная версия в облаке.
Выполняйте запросы к терабайтам данных за секунды при затратах на 90% ниже, чем у традиционных платформ.
GizmoSQL — это open-source SQL database engine, работающий на базе DuckDB и Apache Arrow Flight SQL.
По бенчмаркам Gizmo опережает Trino и DataFusion.
Есть адаптеры к DBT и PySpark DataFrame API.
Есть как open-source вариант так и платная версия в облаке.
Выполняйте запросы к терабайтам данных за секунды при затратах на 90% ниже, чем у традиционных платформ.
GitHub
GitHub - gizmodata/gizmosql: 🚀 GizmoSQL — High-Performance Database Server
🚀 GizmoSQL — High-Performance Database Server. Contribute to gizmodata/gizmosql development by creating an account on GitHub.
В Spark 4.1 появлся ... Airflow
В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)
На борту:
1️⃣ Несколько видов датасетов: Материализованные, Стриминговые, Временные
2️⃣ Пайплайн как объект. Описывается через YAML файл с SQL, Python кодом и необходимыми конфигами Спарка. Также объявляется каталог (Hive, Iceberg), с которым можно взаимодействовать и в который складывать результаты.
3️⃣ Команда spark-pipelines init с интерфейлом и аргементами как у Spark Submit. Отдельная команда spark-pipelines run.
Удобство
Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.
К объявленной таким способом таблице можно обращаться дальше по пайплайну.
На SQL и того проще
Или пример с несколькими синками
Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.
Но ясно, что в четвертом Спарке сделать такую операцию как стриминг подхват из топиков Кафки в таблицы Айсберга будет сильно проще, чем сейчас. А то и вовсе - декларативно. Что не может не радовать.
Насладиться примерами можно в офф доке превью версии
В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)
На борту:
Удобство
Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.
from pyspark import pipelines as sdp
@sdp.table
def ingestion_st():
return (
spark.readStream.format("kafka")
.option("kafka.bootstrap.servers", "localhost:9092")
.option("subscribe", "orders")
.load()
)
К объявленной таким способом таблице можно обращаться дальше по пайплайну.
На SQL и того проще
CREATE STREAMING TABLE basic_st
AS SELECT * FROM STREAM samples.nyctaxi.trips;
Или пример с несколькими синками
-- create a streaming table
CREATE STREAMING TABLE customers_us;
-- add the first append flow
CREATE FLOW append1
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_west);
-- add the second append flow
CREATE FLOW append2
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_east);
Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.
Но ясно, что в четвертом Спарке сделать такую операцию как стриминг подхват из топиков Кафки в таблицы Айсберга будет сильно проще, чем сейчас. А то и вовсе - декларативно. Что не может не радовать.
Насладиться примерами можно в офф доке превью версии
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from StarRocks and modern data stack
Ехал метастор через метастор, видит метастор в метасторе метастор...
Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.
А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.
Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно.
Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.
Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.
Видите пльзу для себя, затеялись бы внедрять? :)
Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.
А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.
Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно.
Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.
Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.
Видите пльзу для себя, затеялись бы внедрять? :)
Forwarded from Data Engineering / Инженерия данных / Data Engineer / DWH
deruiter_Astronomer_Final.pdf
28 MB
Data Pipelines with Apache Airflow
Orchestration for Data and AI Second Edition 2026
Второе издание (скачено с сайта astronomer бесплатно)
Orchestration for Data and AI Second Edition 2026
Второе издание (скачено с сайта astronomer бесплатно)
😁1
Forwarded from Архитектор Данных
Forwarded from MyDB
🔥 Alibaba представила open-source интеграцию DuckDB — AP-движок для аналитических запросов прямо в MySQL
Крупнейший китайский облачный вендор Alibaba открыл исходный код глубокой интеграции аналитической СУБД DuckDB в AliSQL (форк MySQL). Это позволяет запускать аналитические запросы (OLAP) в тысячи раз быстрее, чем на InnoDB, с полным сохранением MySQL-синтаксиса.
Проект доступен полностью в open source — разработчики и компании могут использовать, модифицировать и внедрять эту технологию самостоятельно, без привязки к облачным сервисам.
🛠 Как это работает:
DuckDB встроен как плагинный storage-движок в архитектуру MySQL. Аналитические реплики синхронизируются через бинарный лог (binlog), что обеспечивает согласованность данных и отказоустойчивость. Под капотом реализованы оптимизации:
- Пакетное выполнение транзакций
- Поддержка DDL через
- Многопоточная конвертация таблиц
📊 Производительность:
На тестах TPC-H SF100 DuckDB показал впечатляющие результаты — общее время выполнения 22 запросов:
• DuckDB: 15.31 сек (в 1648 раз быстрее!)
• InnoDB: 25 234.31 сек
🌐 Исходный код и документация:
Решение полностью открыто и доступно в репозитории AliSQL. Сообщество может изучать, использовать и развивать эту интеграцию.
👉 Репозиторий и подробная документация
#OpenSource #AliSQL #DuckDB #MySQL #OLAP #Database #Analytics #Alibaba #GitHub
Крупнейший китайский облачный вендор Alibaba открыл исходный код глубокой интеграции аналитической СУБД DuckDB в AliSQL (форк MySQL). Это позволяет запускать аналитические запросы (OLAP) в тысячи раз быстрее, чем на InnoDB, с полным сохранением MySQL-синтаксиса.
Проект доступен полностью в open source — разработчики и компании могут использовать, модифицировать и внедрять эту технологию самостоятельно, без привязки к облачным сервисам.
🛠 Как это работает:
DuckDB встроен как плагинный storage-движок в архитектуру MySQL. Аналитические реплики синхронизируются через бинарный лог (binlog), что обеспечивает согласованность данных и отказоустойчивость. Под капотом реализованы оптимизации:
- Пакетное выполнение транзакций
- Поддержка DDL через
INPLACE / INSTANT или COPY - механизмы- Многопоточная конвертация таблиц
📊 Производительность:
На тестах TPC-H SF100 DuckDB показал впечатляющие результаты — общее время выполнения 22 запросов:
• DuckDB: 15.31 сек (в 1648 раз быстрее!)
• InnoDB: 25 234.31 сек
🌐 Исходный код и документация:
Решение полностью открыто и доступно в репозитории AliSQL. Сообщество может изучать, использовать и развивать эту интеграцию.
👉 Репозиторий и подробная документация
#OpenSource #AliSQL #DuckDB #MySQL #OLAP #Database #Analytics #Alibaba #GitHub
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) — это незаметные, но критически важные механизмы практически всех систем корпоративного управления...