Только РК

Сумма: 0

Количество заявок: 0

Прием решений до

22.12.25

Форма награждения

денежная

Статус продукта

MVP

Тип задачи

Задачи ИКТ

Сфера применения

IT

Область задачи

Информационные системы Smart Field

Тех задание
Тип продукта

Мобильное приложение

Описание проблемы

В терминах теории оптимизации задача выглядит как поиск алгоритма A, который для произвольной функции стоимости f (описывающей профиль запросов, распределение данных, ограничения по памяти и т. д.) выдаёт решение не хуже, чем любой другой алгоритм, на всех возможных f. Ряд результатов, известных как теоремы «об отсутствии бесплатного обеда», показывают, что такого универсального алгоритма не существует: алгоритм, который хорошо работает на одних классах функций, неизбежно проигрывает на других. Практически это означает, что нельзя написать единый "вечный" оптимизатор, который гарантированно близок к оптимуму для всех мыслимых workloads. В рамках эксперимента мы создали типичную схему событий трекинга: CREATE TABLE events ( event_id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL, event_name TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL, props JSONB ); CREATE INDEX ON events (user_id, created_at); CREATE INDEX ON events (event_name, created_at); CREATE INDEX ON events USING GIN (props); Далее мы сгенерировали два противоположных workloads: • W₁ — длинные диапазонные запросы по user_id с агрегацией; • W₂ — точечные выборки по event_name с фильтрацией по JSON‑полю. Оптимальная конфигурация индексов для W₁ и W₂ различается: индексы, ускоряющие один набор запросов, ухудшают кэш‑поведение и планы для другого. Если добавить сюда будущие неизвестные workloads, становится видно, что универсальная конфигурация, гарантирующая близость к оптимуму для всех сценариев, недостижима.

Ожидаемый эффект

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

ФИО ответственного лица

Сергеев И.А.

Цель и описание задачи (проекта)

Заказчик использует PostgreSQL 16 как основной хранилище для аналитики мобильных событий. Нагрузочный профиль меняется ежемесячно: добавляются новые отчёты, меняются паттерны фильтрации. Заказчик сформулировал амбициозное требование: построить систему, которая автоматически подбирает схему, индексы и подсказки оптимизатору так, чтобы **для любого текущего и будущего набора запросов** средняя задержка была не хуже некоторого теоретического минимума (например, не более чем на 5 % хуже оптимального плана). Система должна быть универсальной — не под конкретный набор запросов, а под любые возможные workloads.