SQL *

Clickhouse никогда не удаляет ваши данные, главное помнить об этом и знать где искать. Наш кейс миграции на Clickhouse Keeper, история потери и восстановления данных

Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито. Мы развиваем платформу объявлений и их характеристики.

В предыдущей статье я рассказал, как мы строим отказоустойчивые системы при работе с многомиллионным трафиком.

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

Многие опытные разработчики недооценивают мощь инструментария БД при работе с микросервисами. По каким-то причинам в IT-сообществе приняты эмпирические правила - сервис маленький, значит и база маленькая. Но это не совсем так.

Скорее всего, при проектировании архитектуры у нас в голове чаще всего возникает паттерн database-per-service. И когда мы начинаем рисовать схемы, то возникает соблазн покрутить кирпичики модулей так, чтобы красиво их соединить стрелочками с цилиндриками, обозначающими БД.

С другой стороны, все знают, что много микросервисов, взаимодействующих через одну общую монструозную базу как Oracle, ElasticSearch и другие - это антипаттерн.

Поэтому выбирают маленькие(!) Postgres или MySQL.

Однажды при мониторинге мы обратили внимание на запрос, который занимал первое место по длительности: 40+ секунд на выполнение при 657 вызовах за день. Причина состояла в том, что из-за неточной статистики распределения данных выбирался неподходящий индекс. В статье расскажем о том, как с помощью параметра STATMULTIPLIER в СУБД Tantor Postgres этот проблемный запрос удалось ускорить примерно в миллион раз — до 0.042 миллисекунды, — просто повысив точность статистики без изменения кода или структуры базы данных.

За годы разработки приходит понимание, что происходит в тех или иных сервисах, когда они тормозят, лагают, выдают «неожидаемое» поведение. В данной статье хочу рассмотреть проблему неправильного использования алгоритмов и архитектурных решений с бытовой, общечеловеческой стороны.

Привет, Хабр! С каждым годом ИИ способен решать более сложные задачи, одной из задач является понимание DAX, связанных предметных областей и генерация кода. Можно выделить несколько задач, которые не являются первостепенными, тем не менее актуальны для анализа или работы в Power BI, например, от простейших — создание клиента для выполнения DAX запросов в Power BI из произвольной среды (например, из .NET приложения) и импорт метаданных TOM модели, до более сложных задач — экспорта схемы данных и самих данных из Power BI в произвольную СУБД (понятно, что такая задача не всегда актуальна с точки зрения ETL, т.к. проще взять данные из исходных источников, а не из Power BI, но польза решения задачи «интуитивно понятна» пользователю) и задач генерации SQL запросов на основе DAX для заданной СУБД, причем результаты сгенерированного SQL должны совпадать с результатами DAX запросов.

Интересующимся применением ИИ на примере DAX из Power BI — добро пожаловать под кат :)

Начинаем новый цикл статей с обзором изменений 19 версии. И первая статья о событиях летнего июльского коммитфеста прошлого года.

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

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

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

В PostgreSQL и Oracle Database команда UPDATE, столкнувшаяся с заблокированной строкой, ведёт себя по-разному. В статье рассматривается, как выполняется UPDATE в этих базах данных. Это может быть полезно при миграции кода приложения мжду этими базами данных.

Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито. Мы занимаемся тем, что обрабатываем формы от пользователей: от 5 млн до 15 млн форм в минуту, а это более 150 тысяч в секунду. 

В этой статье на примере Авито я рассказываю, зачем мы стремимся к SLI 99.99%. Внутри — обзор и сравнение решений по доставке неизменных данных, учитывая специфику нашего сервиса. Показываю на примере форм, какие интересные доработки мы придумали, чтобы достичь этих четырёх девяток, и какие ошибки совершали по пути.

Статья будет полезна всем, кто хочет погрузиться в проблему раздачи и обработки редко изменяемых данных. 

За 5 лет работы в B2B и B2C сегментах у телеком‑провайдеров я столкнулся с одной из проблем: абоненты годами сидят на архивных дорогих тарифах или пользуются услугами операторов, которые не идут на уступки, не снижают цены на тарифы, пользователи просто не знают, что в их же доме есть альтернативные провайдеры с тарифами более выгодными для них.

Я решил объединить свой опыт в телекоме с навыками в программировании. Так появилась идея по парсенгу тарифов. Цель — создать инструмент, который автоматически мониторит провайдеров, избавляя пользователей от ручного сравнения и помогая им находить оптимальные условия по тарифу.

Сейчас я работаю аналитиком БД, параллельно изучаю архитектуру, построение данных. Решил начать проект с проектирования структуру на PostgreSQL по схеме «Звезда». Таблицей фактов у меня будет таблица со связью города с провайдером, таблицы измерений — таблица с информацией о тарифах, городами и провайдерами.

Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.

DAX содержит гибкие возможности фильтрации, и важными функциями являются ALL и REMOVEFILTERS. При использовании ALL и REMOVEFILTERS в качестве модификатора CALCULATE они ведут себя одинаково, т.к. в этом случае REMOVEFILTERS является псевдонимом ALL, однако ALL в FILTER возвращает «новую таблицу» и очищает влияние всех фильтров, что важно учитывать с точки зрения производительности и результатов.

Интересующимся особенностями ALL и сравнением ALL и REMOVEFILTERS  — добро пожаловать под кат :)

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.