SQL *

Postgres Pro Enterprise 18.1.1

До Нового Года успела выйти 18-я версия Postgres Pro Enterprise - Postgres Pro Enterprise 18.1.1. Версии Postgres Pro Standard 18.1.1 и - до неё - Postgres Pro Standard 18.0.1 следовали за соответственно. А - как видно из номера - Postgres Pro Enterprise 18.1.1 - перепрыгнула через ступеньку. Поэтому, если будет желание отследить изменения, унаследованные от Standard и PostgreSQL, надо сравнивать сразу с 2 версиями каждой. Мы же здесь не будем фокусироваться на формальностях и просто приведём (неполный, конечно - полный слишком велик для нашего жанра) список нового.

Добавлена возможность создавать таблицы, которые разделяются на секции при помощи внешнего ключа. Внешний ключ используется как ссылка на родительскую секционированную таблицу и определяется в предложении PARTITION BY REFERENCE.

Обновлены модули, в том числе BiHA. В ней много важных изменений:

Предельная унификация a.k.a. IDEAV — хранение вообще всего как список Entity — Attribute — Value с дополнительным полем ID. Звучит пугающе, но реализация скрыта под капотом, а снаружи нам доступен максимально родной и дружественный интерфейс.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Типовые сценарии на базе StarRocks + DeepSeek. DeepSeek: генерация качественных эмбеддингов и ответов, StarRocks: высокоэффективный векторный поиск и хранение.Вместе они образуют основу для точных и масштабируемых AI‑решений.

В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии.

В статье — пошаговый разбор создания и обновления материализованных представлений (MV) в StarRocks: от парсинга SQL (ANTLR) и инициализации свойств до сериализации метаданных (edit log, checkpoint, image) и планирования refresh. Разбираем синхронизацию партиций (range‑партиционирование), параметр partition_refresh_number и оптимизацию обновлений. Отдельный блок — поддержка нескольких выражений в UNION ALL и механизм VirtualPartitions из PR #60035, позволяющий корректно обновлять сдвинутые временными функциями (date_add/date_sub) диапазоны без пропусков. Материал будет полезен инженерам данных и тем, кто проектирует OLAP‑модели и MV под высокую нагрузку.

Материализованные представления (MV) в StarRocks — это не просто кэш агрегатов, а полноценный механизм ускорения запросов с автоматическим переписыванием (query rewrite). На практических примерах разбираем, как движок сопоставляет поддеревья плана запроса со SPJG‑MV, как работают join/aggregate/nested/union rewrite, как обеспечивается строгая согласованность и настраиваемая устарелость данных (staleness), и за счёт чего достигается ускорение на SSB и TPC‑H.

Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

В современных data-процессах ключевую роль играет обеспечение качества данных. Рассмотрим четыре популярных подхода: DBT, SQL, Python (Pandas/SQLAlchemy) и Great Expectations, оценив их эффективность для различных сценариев проверки данных. 

Эта статья будет интересна и полезна Data-инженерам, аналитикам данных и специалистам Data Quality для выбора оптимального метода валидации данных в зависимости от стека технологий и сложности бизнес-логики. Материал ориентирован на начинающий уровень подготовки: тем, кто еще не сталкивался системно с инструментами управления качеством данных.

Привет, Хабр! Меня зовут Мария, я Data-инженер в SimbirSoft, и предлагаю для начала немного познакомиться с каждым из вышеперечисленных инструментов.

Хотелось бы сразу сделать небольшой дисклеймер. Это не супер‑экспертная статья. Скажем так — это мой инсайд о том, как еще можно работать с SQL запросами в Go проекте. В этой статье я расскажу о том как удобно хранить запросы в embeded sql файлах. Решение о котором я буду писать — лишь один из инструментов в арсенале разработчика, а не универсальное решение призванное вылечить все болезни. Надеюсь тебе это будет полезно.

Всем привет, меня зовут Игорь Горбенко, и я системный аналитик в компании М2.
Отчёты, которые обновляются раз в сутки, хорошо подходят для стратегической аналитики. Но в какой-то момент бизнесу становится важно понимать, что происходит в течение дня, а не только по итогам ночной загрузки.

В М2 мы столкнулись с этим, когда от продуктовых команд и службы поддержки начали приходить запросы на внутридневную отчётность и почти real-time метрики. Наш основной подход — ежедневная батчевая загрузка данных — перестал закрывать такие сценарии, и нам понадобился другой способ работы с изменениями в продуктовых базах.

В этой статье я расскажу, как мы внедряли Change Data Capture (CDC) с использованием Apache Flink, какие задачи это помогло решить, с какими ограничениями мы столкнулись и почему CDC — полезный, но не универсальный инструмент.

CDC и Apache Flink: кратко о технологии и нашем подходе

Давайте начнем разбираться. Некоторые из вас наверняка знакомы с понятием CDC, Change Data Capture — техника захвата изменений в базах данных.

Для контекста стоит отметить Apache Flink — движок для загрузки и обработки батчей и стриминговых данных в реальном времени. В статье речь пойдет про Flink CDC —   фреймворк с открытым исходным кодом для отслеживания изменений данных в базах данных в реальном времени.

В проектах нашего отдела в М2 основной метод загрузки — это ежедневное ночное
копирование продуктовых баз данных (PostgreSQL, MongoDB) в аналитическое хранилище на базе Apache Iceberg и последующая их обработка с помощью движка Trino.

На SQL-собеседованиях интервьюер часто формулирует условия устно, просит рассуждать вслух и быстро писать запрос в реальном времени. Это непривычный формат — и именно поэтому он становится испытанием даже для тех, кто много практиковался.

Введение: почему запросы вдруг тормозят?

Представьте ситуацию: вчера приложение работало нормально, сегодня получили звонок – «Сайт грузит 10 секунд!». Заглядываете в логи, видите, что SQL-запрос выполняется 8 секунд вместо обычных 0.2 секунды. Но база данных, таблицы – всё то же самое. Что изменилось?

Дело в том, что PostgreSQL Query Planner – оптимизатор запросов – принимает решения на основе статистики. Когда статистика устаревает или таблица растёт в 10 раз, планировщик может выбрать неэффективный план выполнения. Например, вместо быстрого Index Scan он выберет медленный Seq Scan всей таблицы. Это не баг – это следствие неправильной информации о данных.

Статья полезна:

- Новичкам в SQL: разберётесь, как работают запросы

- Разработчикам на Symfony/Doctrine, Go с pgx: увидите интеграцию с вашим кодом

- Опытным DBA: найдёте оптимизации для таблиц в миллионы строк

Не требуется: специального опыта. Нужны базовые знания SQL и доступ к PostgreSQL.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition. Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с.

Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит.

Искусственный интеллект резко ворвался в нашу жизнь. Для кого-то это возможность смотреть или генерировать прикольные и не очень картинки и видео, которые многим уже надоели.

А для нас, коллеги, это мощный инструмент, позволяющий быстрее решать различные задачи. Многие кто уже успел попробовать Cursor и подобные инструменты, восхищаются как ИИ способен писать код.

В этой статье речь пойдёт о менее заезженной, но не менее актуальной теме – как ИИ уже сейчас помогает проектировать базы данных.

Всем привет! Меня зовут Александр Гаврилов, я архитектор баз данных и аналитических систем в GRI. Если вы когда-нибудь пытались выполнить одну и ту же операцию с похожими таблицами в разных базах, да ещё и на разных серверах, то знаете, насколько это может быть мучительно.

В этой статье я покажу один из рабочих вариантов, как упростить такую задачу, и заодно расскажу про интересную функцию XQuery, которая может неожиданно помочь.

Многие команды сейчас меняют проприетарное ПО на открытые аналоги. Под «открытостью» мы понимаем не только миграцию с платного софта на бесплатный, но и новый подход к построению data-платформ, где каждый продукт развивает свой сегмент платформы с помощью релевантного стека технологий. 

Полноценных open-source-альтернатив, которые закрыли бы все наши потребности, не нашлось. Поэтому мы решили создать свой «мультитул» — low-code-фреймворк для генерации гетерогенных Airflow DAG с незамысловатым названием dag_generator.

Цель этой статьи — поделиться опытом внедрения подобного инструмента. Генерация выполняется по старинке, так что про ИИ здесь пока ничего не найдете.

Привет, Хабр!

Мы много работаем с компаниями, которым необходимо использовать отечественное ПО для баз данных. В таких проектах часто уже есть инфраструктура на MS SQL Server, PostgreSQL или Oracle Database. Основной конфликт — требования регуляторов и высокая стоимость миграции логики приложений на другую СУБД.

Мы создали продукт, который нативно понимает диалекты и позволяет работать с существующими базами без переписывания кода. В статье расскажем, как развернуть Digital Q.DataBase для начала работы с базами без долгой и затратной миграции.