SQL *

Уже совсем немного осталось до выхода релиза СУБД Tantor Postgres 18, и мы хотим наперед рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE, и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли.

В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL-запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре.

Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

Запутались в многоэтажных SQL‑запросах? Обобщённые табличные выражения (CTE) — тот инструмент, который превращает лапшу из JOIN и подзапросов в читаемый, модульный код.

Разберем на реальных примерах из FinTech и e‑commerce, как разбивать сложную логику на цепочку простых шагов, использовать CTE в UPDATE/DELETE, строить рекурсии для иерархий и избегать ловушек оптимизатора в PostgreSQL.

В логистике проблема часто не в том, что нет данных.

Проблема в том, что данные разбросаны по разным местам.

Одни заявки лежат во внутренней системе, другие — в закрытых кабинетах грузоотправителей, третьи — на тендерных площадках, четвёртые приходят через Excel‑выгрузки, пятые доступны только через веб‑интерфейс. Где‑то есть нормальный HTTP‑обмен, где‑то данные спрятаны за фронтендом, где‑то приходится читать DOM‑таблицу, а где‑то сначала кажется, что всё просто, пока не выясняется, что цена приходит в копейках, маршрут состоит из трёх точек, а тип кузова записан как «тент 20т, верхняя загрузка».

Для менеджера всё это выглядит не как единый рынок грузов, а как набор вкладок в браузере.

Открыть один кабинет. Потом второй. Потом третий. Проверить направление. Сравнить цену. Посмотреть дату. Понять, где реф, где тент, где просто «20 тонн». Не забыть про аукцион, у которого скоро истекает время. Потом всё равно перенести результат в таблицу или открыть внутреннюю панель.

В какой‑то момент стало понятно: нам нужен не ещё один парсер, а единая витрина.

Так появился внутренний агрегатор заявок — условный «Авиасейлз для логистики».

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

У всех «хранилище». А правильный технический ответ зависит от условий задачи.

За годы работы в банках, ритейле и системной интеграции мы пришли к простой картине: для среднего и крупного бизнеса большинство DWH-проектов сводится к четырёхзонной архитектуре поверх двух специализированных движков. Не Inmon, не Kimball-star-schema, не Data Vault 2.0 - и при этом не «modern data stack как у Databricks один-в-один».

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

Всем доброго времени суток!

Недавно пережитый опыт работы с отчетом хочу выставить на всеобщее обозрение, вдруг кому‑то будет полезен. Чтобы не томить и сохранить более технический подход, давайте сразу начнем «разбор полёта».

В какой‑то момент у нас появился вот такой запрос:

EXPLAIN ANALYZE отлично справляется с диагностикой конкретного запроса — но только если вы уже знаете, какой именно запрос виновен. На практике проблемный запрос нужно сначала найти среди тысяч других. Ждать жалоб пользователей или вручную мониторить дашборды — путь, который не масштабируется.

В этой статье разберём три инструмента PostgreSQL для автоматического поиска медленных запросов: pg_stat_statements, auto_explain и log_min_duration_statement. Для каждого — настройка, ключевые параметры и когда что использовать.

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

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

Необходимо найти, какой тип файлов вызывает загрузку процессора, применив машинное обучение.

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

С версии 23.0.0 Manticore может делать так, чтобы запрос xt850 находил xt 850, используя bigram_delimiter вместе с режимами bigram_index , учитывающими цифры.

Это решает типичную проблему токенизации в поиске по товарам: пользователи убирают пробелы из названий моделей, а данные в индексе хранятся как отдельные токены.

Небольшая команда сделала мод-социальную-сеть для Minecraft, который объединяет в общий граф друзей игроков на любых поддерживаемых версиях клиента — от 1.7.10 до 1.21.1. Поддерживаются три популярных загрузчика модов и любые клиенты Minecraft, как лицензионные, так и офлайн. Серверная часть, веб-админка, обвязка и документация — всё своё.

Главное, что хотелось рассказать: дисциплина (не скорость) была решающим ресурсом, и категория продукта изменила правила игры настолько, что классическая формула «MVP на одной версии — потом расширяемся» оказалась контрпродуктивной.

/В последней версии HQBird Server 5.0.4 появились так называемые материализованные представления. В данном вебинаре мы поговорим о том, что это такое, как с ними работать, как вы можете использовать их у себя для ускорения некоторых аналитических выборок. Будет представлен небольшой бенчмарк, который показывает, как материализованные представления могут ускорять некоторые аналитические выборки.

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.

Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой.

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

bigram_index можно использовать для разных задач, но в этой статье мы говорим именно о производительности поиска фраз: в приведённом ниже бенчмарке на 1 млн документов bigram_index='all' повысил QPS примерно в 2.9x и сократил среднее время ответа фразовых запросов примерно в 3.2x.

Если ваша основная проблема — сопоставление xt850 с xt 850, а не ускорение поиска фраз, см. Как заставить xt850 совпадать с xt 850 .

Поиск по фразам бывает дорогим. Даже если запрос короткий, движку всё равно нужно проверять порядок слов и стоят ли они рядом, и это особенно заметно, когда:

Хочу рассказать про баг, который я искал полтора дня и который оказался опечаткой длиной в одну инструкцию. Если коротко: PostgreSQL (16.4 в моём случае, но воспроизводится начиная с 12-й) не разрешает UNION ALL сразу после ORDER BY ... LIMIT N без круглых скобок. И самое неприятное - ошибку об этом я узнал последним, потому что между моим SQL-запросом и логами стояло пять промежуточных слоёв, каждый из которых её по-своему проглотил.

Расскажу как нашёл, как фиксил, и что в итоге добавил в pre-deploy чек-лист.

Книги по SQL — стабильные бестселлеры в мире компьютерной литературы. Они нужны начинающим аналитикам, бэкэнд-разработчикам, тестировщикам, инженерам по автоматизации и всем, кто работает с данными. Но при этом у большинства таких книг есть одна проблема: они либо слишком академические, либо слишком фрагментарные. В итоге новичок вроде бы читает про операторы SELECT, JOIN и GROUP BY, но не чувствует, что может уверенно применять язык SQL в реальной работе.

1. Введение. Trino: ключевые задачи и главные преимущества

В современной архитектуре управления данными ETL‑процессы рассматриваются не как вспомогательный инструмент, а как базовый механизм интеграции, трансформации и подготовки данных, поступающих из множества гетерогенных источников. Ключевая цель этих процессов — избавиться от хаоса и разрозненности данных, которые почти всегда появляются в больших распределенных компаниях [1].

В рамках ETL‑конвейера выполняется автоматизированное извлечение данных из различных источников, их очистка, нормализация и приведение к единой модели, после чего подготовленные данные загружаются в централизованное аналитическое хранилище. Это даёт три главных преимущества: обеспечивает высокое качество и согласованность данных, структурирует информацию под нужды бизнес‑отчетности, а также отделяет аналитическую нагрузку от операционных систем, повышая таким образом производительность системы в целом.

ETL возник как вынужденная мера, так как во время его появления (1970–1990-е) не было ни высокоскоростных сетей, ни мощных распределенных движков аналитики, ни концепции Data Lake. Единственным надёжным способом построить аналитическую отчетность было физически извлекать данные из операционных систем и копировать их в отдельную специализированную базу. Именно поэтому ETL закрепился как основной архитектурный паттерн аналитических систем на долгие десятилетия.

Увы, такой подход породил и массу проблем: это дублирование данных, долгие пайплайны, сложные зависимости, задержки обновления и огромные затраты на поддержку. Традиционным ETL‑процессам становится всё труднее справляться с постоянно растущим объемом поступающих данных. Более того, большие сложности возникают при работе с уже накопленной информацией, ведь её требуется хранить на протяжении многих лет, а значит — сохранять возможность глубокого анализа по всей доступной истории.

Привет, Хабр! Несмотря на то, что Cursor в начале «ИИ революции» условно был впереди, сейчас общепринятым ИИ инструментом во многом можно считать Claude, я также пользуюсь Claude как основным инструментом. Но годовая личная подписка Cursor осталась, и токены каждый месяц обновляются, нужно их потратить :) На остатки токенов за выходные решил заняться вайб-кодингом движка DAX на C# — простейший аналог VertiPaq, причем в режиме Auto в Cursor. В результате получился работоспособный движок DAX, естественно, поддерживающий только подмножество языка, а не весь DAX, но зато не привязанный к Windows — не требуется ни Tabular Server, ни Power BI Desktop, ни облачные сервисы, ни виртуальные машины с Windows — DAX движок работает на всех ОС. Интересующимся экспериментами с ИИ генерацией BI движков — добро пожаловать под кат :)

Объектный построитель SQL-запросов без ORM и моделей. Позволяет писать сложные SQL-запросы в виде цепочек Python-методов (table[‘person’].filter(…).join(…).get()) и получать результат в виде списка словарей. Под капотом — параметризованные запросы для защиты от инъекций, продуманная система кеширования с инвалидацией по таблицам (in-memory и Redis), поддержка синхронного и асинхронного кода из коробки. Для тех случаев, когда ORM избыточна, а сырой SQL небезопасен.

Продолжаем серию публикаций «Адаптивное администрирование Sigla Vision». Часть наших подходов будет полезна и другим ИТ-специалистам, которые развивают или сопровождают аналитические системы — особенно те, что хранят метаданные во внешних СУБД.

В этой статье подробно разберем объектную модель BI-системы. Она помогает лучше понимать работу системы, следить за ее состоянием и контролировать изменения.

В предыдущей статье «Адаптивное администрирование Sigla Vision» мы посмотрели на BI-систему «из коробки» глазами тех, кто ее сопровождает: объяснили, зачем нужны дополнительные данные о работе системы и для чего создавать объектную модель, привели примеры задач, где она используется.

Тема нынешней статьи — основа всего нашего дальнейшего опыта работы с Sigla Vision. 

jsonb легко полюбить. Он даёт гибкую схему, позволяет не плодить десятки мелких колонок, хорошо подходит для полуструктурированных данных и обычно очень удобен на старте проекта. Пока документы маленькие и меняются редко, кажется, что всё отлично.

Проблемы начинаются позже. Данные растут, в документ добавляются новые поля, часть из них начинает часто обновляться, а потом внезапно выясняется, что вроде бы безобидный UPDATE одного ключа внутри jsonb стоит заметно дороже, чем ожидалось.

В этой статье мы не собираемся доказывать, что jsonb плохой тип данных. Наоборот: jsonb – один из самых полезных инструментов PostgreSQL. Хотелось бы разобраться в более узком вопросе:

что именно происходит, когда мы обновляем один ключ внутри большого JSONB-документа, и чем это отличается от обновления обычной колонки рядом с таким же большим документом?