Data Ingestion Patterns: When to Use Push, Pull, and Poll (With Real Examples)
Полезный пост в блоге Dagster о трёх фундаментальных паттернах ingest, которые должен знать каждый data engineer:
Push: Когда source-системы сами присылают данные тебе
Pull: Когда ты контролируешь извлечение
Poll: Когда нужно near real-time без полноценного стриминга
У каждого свои trade-offs по контролю, сложности и операционным нагрузкам.
В посте разбирают, когда какой использовать, с рабочими примерами кода на Dagster.
Также есть проект, где все три паттерна работают вживую.
Полезный пост в блоге Dagster о трёх фундаментальных паттернах ingest, которые должен знать каждый data engineer:
Push: Когда source-системы сами присылают данные тебе
Pull: Когда ты контролируешь извлечение
Poll: Когда нужно near real-time без полноценного стриминга
У каждого свои trade-offs по контролю, сложности и операционным нагрузкам.
В посте разбирают, когда какой использовать, с рабочими примерами кода на Dagster.
Также есть проект, где все три паттерна работают вживую.
dagster.io
Data Ingestion Patterns: Push, Pull & Poll Explained | Dagster
Learn when to use push, pull, and poll data ingestion patterns with practical code examples in Dagster. Build reliable, scalable data pipelines with the right pattern for your use case.
Всем привет !
Небольшой анонс (я знаю вам давно не хватало очередного BI 😂😇)
Есть очень интересный повод для того что бы попробовать табличный редактор Р7- Офис , сейчас только для него существует решение , которое реализует концепцию не SelfBi, a Personal Bi
- Слайдер Данные
Здесь есть сочетания функциональных возможностей, которые обычно можно встретить только для серверных решений
и в различных продуктах
видео
windows trial
Небольшой анонс (я знаю вам давно не хватало очередного BI 😂😇)
Есть очень интересный повод для того что бы попробовать табличный редактор Р7- Офис , сейчас только для него существует решение , которое реализует концепцию не SelfBi, a Personal Bi
- Слайдер Данные
Здесь есть сочетания функциональных возможностей, которые обычно можно встретить только для серверных решений
и в различных продуктах
Подключаться и выполнять запросы / выгрузки и к реляционным и многомерным базам данных
Консолидировать информацию из различнх файлов табличного формата (от CSV до Avro )
Создавать OLAP модели данных над реляционными источниками c поддержкой MDX
Организовывать виртуальную федеративную базу данных для гетерогенных объединяющих SQL запросов
Анализировать потоки данных (Data Linage) между подзапросами
Создавать SQL запросы , используя визуальные конструктуры
Параметризовать SQL и MDX/DAX выгрузки
Выгружать данные во внешние файлы , минуя табличный редактор
Сравнивать и анализировать XLS файлы
* а вы еще не видели наш роадмап )
видео
windows trial
Rosetta DBT Studio
The Open Source IDE for dbt Core
Создавайте, тестируйте и управляйте проектами dbt Core с лёгкостью.
Rosetta DBT Studio предлагает мощный графический интерфейс для запуска трансформаций, интеграции с Git и поддержки нескольких баз данных — всё в одном месте.
The Open Source IDE for dbt Core
Создавайте, тестируйте и управляйте проектами dbt Core с лёгкостью.
Rosetta DBT Studio предлагает мощный графический интерфейс для запуска трансформаций, интеграции с Git и поддержки нескольких баз данных — всё в одном месте.
rosettadb.io
RosettaDB - Software company
RosettaDB The open source bridge for data migration and warehousing.
В чем устройство LakeHouse и отличие от баз данных?
В этом году чаще слышу о LakeHouse и мыслях его внедрить.
В чем основная суть:
1. Слой хранения выносим отдельно от слоя вычисления -> в s3
2. Формат хранения - универсальный (parquet например)
3. Поверх одного хранилища запускаем разные табличные движки
Похожее произошло с вычислениями пару лет назад с приходом связки kubernetes/s3. Компании смогли динамически аллоцировать ресурсы и за счет этого снизить требования к индивидуальным серверам (правда потом LLM все опять перевернули с ног на голову из-за требований к nvlink и infiniband)
Решил написать пост, наткнувшись на видео от сооснователя DuckLake (для нас интересно до 24 минуты, дальше про DuckLake).
Об естественных особенностях такого решения:
➕ Удобно и гибко
1. Много движков, да и свой обработчик легко написать
2. Если движок поддерживает s3/parquet - не нужно писать коннекторы
3. Вычислительные ресурсы можно переиспользовать в рамках кластера (serverless для вычислений)
4. Наверное, будет устаревать плавнее, за счет модульности. То есть заменили движок/инструмент и вроде снова в тренде, не выкидывая всю систему целиком.
➕ Дешевле
1. Не нужно закупать вычислительные сервера под хранение
2. Ниже цена ошибки. Можно заранее думать только о серверах хранения, а для вычислений переиспользовать общие пулы ресурсов
3. Если движок поддерживает s3/parquet - не нужно перекладывать и дублировать данные между инструментами команд
➖ Сильно медленнее чем классические базы данных
Да, именно так, а что вы хотели?
1. Ходите всегда по сети за данными*, у вас буквально абстракция s3 и нет возможностей выполнить условный map локально на сервере хранения. А значит всегда ограничены 10-20Gbit/s сети.
2. Вынуждены каждый раз парсить файл заново. А обычная база может хранить на диске layout как в памяти и просто делать memmap.
➖ Тяжело
Раньше вы поднимали один продукт и настраивали. Тут продукт растащили на несколько независимых инструментов. На масштабе выгодно, для старта - тяжело (тут ситуация на kubernetes похожа)
*Да, вы можете оптимизировать формат хранения (parquet -> Vortex, F3, FastLanes, Nimble) и минимизировать s3 чтения.
Да, вы можете придумать кэши, но тогда появится база под метаданные. Туда в итоге и движемся. Но, повторю, это не то же самое, что прочитать с локального диска и пройтись по файлу. Джордан в видео заявляет х2-10 замедление от баз.
В этом году чаще слышу о LakeHouse и мыслях его внедрить.
В чем основная суть:
1. Слой хранения выносим отдельно от слоя вычисления -> в s3
2. Формат хранения - универсальный (parquet например)
3. Поверх одного хранилища запускаем разные табличные движки
Похожее произошло с вычислениями пару лет назад с приходом связки kubernetes/s3. Компании смогли динамически аллоцировать ресурсы и за счет этого снизить требования к индивидуальным серверам (правда потом LLM все опять перевернули с ног на голову из-за требований к nvlink и infiniband)
Решил написать пост, наткнувшись на видео от сооснователя DuckLake (для нас интересно до 24 минуты, дальше про DuckLake).
Об естественных особенностях такого решения:
1. Много движков, да и свой обработчик легко написать
2. Если движок поддерживает s3/parquet - не нужно писать коннекторы
3. Вычислительные ресурсы можно переиспользовать в рамках кластера (serverless для вычислений)
4. Наверное, будет устаревать плавнее, за счет модульности. То есть заменили движок/инструмент и вроде снова в тренде, не выкидывая всю систему целиком.
1. Не нужно закупать вычислительные сервера под хранение
2. Ниже цена ошибки. Можно заранее думать только о серверах хранения, а для вычислений переиспользовать общие пулы ресурсов
3. Если движок поддерживает s3/parquet - не нужно перекладывать и дублировать данные между инструментами команд
Да, именно так, а что вы хотели?
1. Ходите всегда по сети за данными*, у вас буквально абстракция s3 и нет возможностей выполнить условный map локально на сервере хранения. А значит всегда ограничены 10-20Gbit/s сети.
2. Вынуждены каждый раз парсить файл заново. А обычная база может хранить на диске layout как в памяти и просто делать memmap.
Раньше вы поднимали один продукт и настраивали. Тут продукт растащили на несколько независимых инструментов. На масштабе выгодно, для старта - тяжело (тут ситуация на kubernetes похожа)
*Да, вы можете оптимизировать формат хранения (parquet -> Vortex, F3, FastLanes, Nimble) и минимизировать s3 чтения.
Да, вы можете придумать кэши, но тогда появится база под метаданные. Туда в итоге и движемся. Но, повторю, это не то же самое, что прочитать с локального диска и пройтись по файлу. Джордан в видео заявляет х2-10 замедление от баз.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
DuckLake: Learning from Cloud Data Warehouses to Build a Robust “Lakehouse” (Jordan Tigani)
CMU Database Group - Future Data Systems Seminar Series (Fall 2025)
Speaker: Jordan Tigani (https://www.linkedin.com/in/jordantigani)
October 6, 2025
https://db.cs.cmu.edu/seminars/fall2025/#db3
Sponsors: Google DAPA Team (https://google.com)
Speaker: Jordan Tigani (https://www.linkedin.com/in/jordantigani)
October 6, 2025
https://db.cs.cmu.edu/seminars/fall2025/#db3
Sponsors: Google DAPA Team (https://google.com)
Что такое большие данные, а что такое маленькие данные?
Каждый год это понятие меняется. Для аналитических систем это важно, ведь мы строим инженерные системы, чтобы обрабатывать большие данные! (Но непонятно, что значит большие данные).
Самое простое определение - данные, которые не помещаются на локальном компьютере и которые мы не можем загрузить в оперативную память, даже если они сжаты.
Мы начинаем смотреть на 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