Ақша сомасы: 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.