Statistics and ANALYZE

В этом разделе описывается работа с подсистемой сбора статистики в AngaraBase.

ANALYZE

Команда ANALYZE собирает статистику о распределении данных в таблицах, которая используется оптимизатором для построения эффективных планов выполнения запросов.

Drift Detection

При выполнении ANALYZE AngaraBase использует механизм drift detection для минимизации лишних записей в системный каталог. Если новое значение distinct_estimate изменилось менее чем на 10% по сравнению с текущим сохраненным значением, обновление статистики для этой колонки пропускается.

Это позволяет избежать лишнего I/O и инвалидации планов в кэше при незначительных изменениях данных.

Column Statistics и distinct_estimate

Основной метрикой для оценки селективности является distinct_estimate (аналог n_distinct в PostgreSQL). Это оценка количества уникальных значений в колонке.

• Если distinct_estimate равен общему количеству строк, колонка уникальна.
• Если distinct_estimate мал по сравнению с количеством строк, колонка имеет низкую кардинальность (low cardinality).

Оптимизатор (CBO) использует эти данные для расчета селективности (selectivity) предикатов.

Cardinality-Aware Index Scan

Начиная с версии 0.6.5.2, AngaraBase использует улучшенный алгоритм выбора между IndexScan и SeqScan, учитывающий кардинальность колонок.

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

Как это работает:

1. Планировщик вычисляет селективность фильтра на основе distinct_estimate.
2. Если селективность превышает порог [execution].index_cardinality_threshold (по умолчанию 0.15), планировщик предпочитает SeqScan для соответствующего гейта («low cardinality» в EXPLAIN; см. также порог index_scan_selectivity_threshold для причины «low selectivity»).
3. В EXPLAIN выводится причина выбора: seq scan chosen: low cardinality (0.1328).

Пример: Если в таблице на 1 000 000 строк колонка status имеет всего 3 значения, селективность фильтра status = 'ACTIVE' будет около 0.33. Поскольку 0.33 > 0.15, база выберет последовательное сканирование, так как чтение трети таблицы через индекс будет медленнее из-за случайного I/O.

Multicolumn Statistics

Multicolumn statistics позволяют оптимизатору учитывать корреляцию между несколькими колонками, что критично для сложных предикатов.

New in 0.6.4.18: Multicolumn statistics collected by ANALYZE are now persisted to disk (sys_catalog snapshot protocol v4). Statistics survive server restarts. To force a fresh collection, run ANALYZE <table> again.

Просмотр статистики

Статистика доступна через системные представления (sys_catalog).

Real-Time Statistics (RM-0.6.7.2)

AngaraBase поддерживает инлайн-обновление счётчиков строк непосредственно на фазе COMMIT транзакции (без I/O overhead). При каждом COMMIT атомарно обновляется row_count_live в памяти для всех затронутых таблиц.

Фоновый воркер (Lock-free Dirty Set)

Фоновый воркер статистики использует lock-free AtomicBool флаг (needs_histogram_recalc) вместо очереди задач. При превышении порога staleness таблица помечается в Dirty Set. Воркер периодически сканирует Dirty Set и запускает micro-rescan только для помеченных таблиц.

Преимущества: устранение queue congestion при массовых DML; нет блокировок при записи в dirty set.

QoS-управление фоновым воркером

Воркер статистики работает с приоритетом IoPriority::Low (BACKGROUND class). При высокой нагрузке I/O (foreground pressure) воркер добавляет паузу 50мс (статический backpressure). Это защищает OLTP latency от деградации при интенсивном ANALYZE.

Snapshot Age Dampening (CBO)

При использовании старого снапшота транзакции (более ANGARABASE_STATS_DRIFT_MAX_AGE_MS миллисекунд, по умолчанию 30 сек) планировщик запросов отказывается от использования HashJoin и переходит на spill-safe операторы. Это предотвращает OOM при устаревшей статистике.

Диагностика: метрика angarabase_optimizer_drift_fallback_total показывает количество случаев когда HashJoin был пропущен из-за snapshot age dampening.

Конфигурация: