Каталог разрезов и измеренный род агрегации
- род метрики выводится сверкой минутного слоя с часовым: часовое значение сходится с суммой минутных — накопительная, со средним — мгновенная, иначе `unknown` и свёртка не предлагается вовсе. На живом архиве (123 доставки, 31 метрика) 7 накопительных, 9 мгновенных, противоречащих часов ноль - `GET /api/v1/metrics` под токеном чтения отдаёт единицы, слои с границами и род вместе с основанием измерения; род нигде не хранится — он функция витрины, а витрина функция журнала, устаревать в нём нечему - миграция 00009: покрывающий индекс, чтобы каталог отвечал по учётным колонкам, не разжимая содержимое объектов
This commit is contained in:
@@ -1009,3 +1009,51 @@ SHALL: сегодня ровно этот случай даёт ноль и мо
|
||||
пор не пересворачивалась
|
||||
- **THEN** её число пропущенных сущностей отсутствует, а не равно нулю
|
||||
|
||||
### Requirement: Перечисление разрезов не читает содержимое объектов
|
||||
|
||||
Хранилище SHALL отвечать на вопрос «какие слои есть у метрики, за какой период и
|
||||
сколько в них точек» по учётным колонкам объекта, не разжимая `payload` и не
|
||||
затрагивая страниц с содержимым. Тот же запрет действует на поиск часов, за
|
||||
которые у метрики есть объекты сразу в двух слоях.
|
||||
|
||||
Запрет ограничен именно этими двумя выборками. Измерение рода обязано прочитать
|
||||
значения точек, то есть разжать содержимое объектов окна, и требование его не
|
||||
касается — иначе оно запрещало бы то, ради чего каталог существует.
|
||||
|
||||
Причина в форме таблицы: `bucket` объявлена `WITHOUT ROWID`, то есть строка
|
||||
целиком, вместе со сжатым содержимым, живёт в дереве первичного ключа. Обход
|
||||
всех строк ради агрегата тащил бы за собой страницы содержимого — при 260 тысячах
|
||||
объектов за год это сотни мегабайт на каждый запрос каталога, притом что сам
|
||||
ответ несёт три десятка строк.
|
||||
|
||||
Поэтому колонки, по которым отвечают эти выборки, MUST быть покрыты индексом, и
|
||||
новая колонка, попадающая в ответ каталога, входит в него тем же изменением.
|
||||
|
||||
#### Scenario: Разрезы метрики за длинную историю
|
||||
|
||||
- **GIVEN** в витрине объекты за многие месяцы
|
||||
- **WHEN** запрашиваются слои метрики с границами и числом точек
|
||||
- **THEN** запрос отвечает по индексу, не читая содержимого объектов
|
||||
|
||||
#### Scenario: Общие часы двух слоёв
|
||||
|
||||
- **WHEN** запрашиваются самые свежие часы, за которые у метрики есть объекты и
|
||||
в минутном, и в часовом слое
|
||||
- **THEN** запрос отвечает по индексу и читает не больше запрошенного числа
|
||||
часов
|
||||
|
||||
### Requirement: Объекты перечисленных часов читаются пакетом
|
||||
|
||||
Хранилище SHALL уметь отдать объекты двух слоёв за перечисленные часы одной
|
||||
метрики **одним запросом**, а не по объекту за раз.
|
||||
|
||||
Чтение по одному даёт число обращений, растущее вместе с окном измерения, и
|
||||
делает каждое обращение собственной транзакцией — то есть ответ, собранный из
|
||||
разных снимков витрины под непрерывным приёмом.
|
||||
|
||||
#### Scenario: Окно из многих часов
|
||||
|
||||
- **GIVEN** запрошены объекты двух слоёв за сорок восемь часов
|
||||
- **WHEN** выполняется выборка
|
||||
- **THEN** число обращений к базе не зависит от числа часов
|
||||
|
||||
|
||||
Reference in New Issue
Block a user