Простой способ индексирования интервалов

28.09.16

Разработка - Математика и алгоритмы

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

Скачать файлы

Наименование Файл Версия Размер
Каркасная конфигурация "Статусы заявок"
.cf 26,74Kb
25
.cf 26,74Kb 25 Скачать
Каркасная конфигурация "Индексация интервалов"
.cf 21,88Kb
19
.cf 21,88Kb 19 Скачать

Общая задача поиска интервалов, включающих заданное значение.

Рассмотрим следующую, достаточно общую задачу:

Пусть имеется таблица с колонками: "ключ", "начало интервала", "конец интервала", "значение". 

Таблица "Дано":

Ключ Начало интервала Конец интервала Значение
1 D11 D12 X1
2 D21 D22 X2
... ... ... ...
N DN1 DN2 XN

Требуется выбрать записи, актуальные на заданный момент времени.

Запрос, решающий данную задачу, имеет вид

ВЫБРАТЬ * ИЗ Дано 
ГДЕ &МоментВремени МЕЖДУ НачалоИнтервала И КонецИнтервала

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

Теоретически для решения подобных задач в разных СУБД обычно применяются spatial индексы или R-деревья. Spatial индексы предполагают введение некоторой сетки, а R-деревья - использование специальной структуры данных. Хотя и то и другое возможно смоделировать имеющимися в 1С средствами, предлагается несколько другой путь.

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

Практически "рассмотреть отрезок издалека, чтобы он превратился в точку" означает изменить масштаб представления данных отрезка: разделить все данные нацело на число, не меньшее размера отрезка. Поскольку интервалы имеют, как правило, разные размеры, предлагается использовать двоичный ряд: в зависимости от размера отрезка делить его нацело на наименьшее подходящее число (наименьшее не меньшее) из ряда степеней двойки: 1, 2, 4, 8, 16 и так далее.

В итоге получается, что нужно последовательно делить обе границы интервала на одно и то же число из ряда 1, 2, 4, 8, 16 и так далее, пока округленные значения результатов деления в конце концов не совпадут. Этот одинаковый для двух границ результат деления и будет значением специального реквизита "проекция", который можно проиндексировать и затем использовать для поиска.

Для поиска интервала по заданному значению момента времени потребуется представить его во всех возможных масштабах и выполнить проверку совпадения этих представлений со значением реквизита "проекция". Число всех возможных масштабов для диапазона 1.01.0001 - 31.12.3999 равно 36-ти. Совпадение не означает однозначного вхождения точки в интервал, а говорит только о возможности такого вхождения. Потребуется дополнительная проверка. Но эта проверка выполняется для очень небольшого количества записей, что и дает ускорение.

В результате вместо исходного запроса становится возможным использовать его более быструю версию, которая будет выглядеть следующим образом:

ВЫБРАТЬ * ИЗ РегистрСведений.Дано 
ГДЕ Проекция В (&МассивПроекций) И &МоментВремени МЕЖДУ НачалоИнтервала И КонецИнтервала

Предполагается, что поле "проекция" будет проиндексировано. 

Для реализации данного метода потребуется две небольших функции. 

Функция ПроекцияИнтервала(От, До) Экспорт
	Если Мин(От, До) = '00010101' ИЛИ Макс(От, До) = '39991231235959' Тогда
		Возврат 0
	КонецЕсли;
	Масштаб = pow(2, 99 - Цел(99 - Окр(log(Макс(До - От, От - До)) / log(2), 10)));
	Пока Окр((От - '00010101') / Масштаб) <> Окр((До - '00010101') / Масштаб) Цикл
		Масштаб = Масштаб * 2
	КонецЦикла;
	Возврат Окр((От - '00010101') / Масштаб)
КонецФункции

Функция МассивПроекций(Дата) Экспорт
	Ответ = Новый Массив;
	Проекция = Дата - '00010101';
	Пока  Проекция >= 0.25 Цикл
		Ответ.Вставить(0, Окр(Проекция));
		Проекция = Проекция / 2
	КонецЦикла;
	Возврат Ответ
КонецФункции

Первая функция вычисляет значение спецреквизита "проекция" по началу и концу интервала, а вторая создает массив проекций по выбранному моменту времени, который затем будет использоваться для поиска.

К тексту функций необходимы небольшие пояснения:

Кажущееся сложным выражение:

Масштаб = pow(2, 99 - Цел(99 - Окр(log(Макс(До - От, От - До)) / log(2), 10)));

всего лишь вычисляет нужный элемент ряда степеней двойки, не меньший размера интервала. То есть для числа 42, например, это выражение будет равно 64, а для 73 будет равно128. Вычисление приближения масштаба в одном выражении позволяет избавиться от многих итераций цикла при его последовательном подборе.

Сравнение

Окр((От - '00010101') / Масштаб) <> Окр((До - '00010101') / Масштаб)

 только на первый взгляд можно заменить выражением

Цел((От - '00010101') / Масштаб) <> Цел((До - '00010101') / Масштаб)

Дело в том, что в последнем случае интервал в две переходящих "новогодних" секунды 20151231235959 - 201601010000 (упрощенно), приходящиеся на момент переноса разряда при двоичной нумерации интервалов, будет требовать большого масштаба уменьшения и получать при таком подходе незаслуженно маленькое значение проекции. То есть произойдет "эскалация" уровня некоторых "несчастливых" интервалов. В результате они будут болтаться на верхних, не своих уровнях, отбираясь по проекции с большой, а по дополнительной проверке - с очень малой вероятностью.
Чтобы этого не происходило, потребуется при построении системы координат каждый раз сдвигать начало следующего, более нижнего уровня разметки границ интервалов на половину масштабного деления.
Это гарантирует равномерность плотности границ интервалов разного масштаба при проекции на общую ось времени. И снижение вероятности того, что интервал, переходящий через границу на нижнем уровне, тоже попадет на границу уровнем выше. Использование округления вместо расчета целого как раз и решает таким образом указанную проблему.

Та же самая мысль иллюстрируется сравнением кодовых линеек обычного двоичного позиционного кода и кода Грэя, представленных на фиг.1 и 2 соответственно. 

Кодовая линейка двоичного позиционного кода

Фиг.2

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

Используя линейку кода на фиг.2, можно еще раз объяснить принцип работы метода:
Интервал каждой записи прикладывается к кодовой линейке последовательно на нулевой (нижний), первый, второй и так далее уровни пока он не войдет целиком в область, окрашенную в один цвет. Адрес этой области определяется порядковым номером области на соответствующем уровне. Этот "адрес" записывается в колонку "проекция". Для поиска интервалов, содержащих заданный период, просматриваются только интервалы, входящие в области разных уровней, в которые также входит период.

Построение фиг.2 также наглядно иллюстрирует факт отсутствия пересечений диапазонов изменений значений проекций разных уровней. Очевидно, что это может произойти только в том случае, когда нижняя граница рабочего диапазона дат меньше верхней более чем вдвое. Например, при использовании рабочего диапазона 01.01.1007 - 01.01.2016. Такой диапазон  в реальных применениях не встречается. Впрочем, даже наличие пересечения не было бы фатальным, а  приводило всего лишь к небольшому снижению избирательности отбора по полю "проекция". 

Если есть сомнения в селективности индекса по полю "проекция", то для проверки можно сгенерировать таблицу случайных интервалов с колонками: начало интервала, конец интервала и рассчитать энтропию поля "проекция". Для этого возьмем, например, 1 000 000 интервалов, равномерно распределенных на промежутке времени длинной один год, средней длиной один день с экспоненциальным распределением длины. Просматривая полученные значение поля, можно увидеть большое разнообразие записанных в нем значений. Вычисления показывают, что энтропия поля префикс равна примерно 8,5.
Это можно было бы предсказать и теоретическими вычислениями.

Достаточная энтропия показывает, что расчет на то, что план выполнения запроса будет использовать индекс, включающий поле "проекция", имеет надежное основание. Энтропия может снизиться до недостаточных значений только когда средняя длина интервала станет сравнима с длиной истории, но в этом случае не поможет (будет не нужен) ни один метод.
Вот план выполнения улучшенной версии запроса:

А вот данные тестирования времени его выполнения в зависимости от количества записей: 


Результаты сравнительного тестирования методов
Видно, что время выполнения запроса от количества записей практически не зависит, хотя в теории логарифмическая зависимость определенно имеется. Она связана с выполнением поиска на Log(n) уровнях.
Для сравнения на том же графике приведено время выполнения обычного запроса, которое имеет видимую на графике зависимость от количества записей.

Тестирование проводилось при следующих параметрах: Для файлового варианта: 500 тысяч интервалов в год (случайно-равномерно по году), длина каждого интервала случайная (экспоненциальный закон), со средним 86400 секунд (сутки). Замеры за один, два, три и четыре года. Выбранный момент времени помещался в середине диапазона. Для MS SQL 1,6 миллиона заявок в год, диапазон от одного года до 11 лет, средний размер и положение интервала такие же как в варианте для файловой базы.

Для удобства проверки полученных результатов к статье прилагается каркасная конфигурация, содержащая обработки заполнения базы тестовыми данными и отчеты для сравнительного тестирования базового метода "0" и предлагаемого метода "1".

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

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

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

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

Задача о статусах заявок

В обсуждении статьи "Регистры сведений 1С. Как это устроено" в комментарии (40) была очень подробно сформулирована простая задача, подчеркивающая врожденный недостаток периодических регистров сведений. Он заключается в том, что при хранении в периодическом регистре сведений статусов заявок, затраты времени на выборку заявок с конкретным статусом неизбежно растут вместе с ростом глубины истории статусов заявок.

То есть речь идет о деградации производительности вот такого запроса:

ВЫБРАТЬ * ИЗ РегистрСведений.СтатусыЗаявок.СрезПоследних(&Т0, ) 
ГДЕ Статус В (&Новый, &ВРаботе)

к регистру сведений вот такой структуры:

Например, если заявки поступают каждые десять секунд, то через три года их станет десять миллионов и время выполнения этого запроса возрастет (учтены конкретные условия задачи) до 16,4 секунд. Анализ показывает, что данная проблема имеет общую природу с той, которая решается методом, приведенным в данной статье.

Поэтому предлагается добавить к структуре регистра два реквизита: "проекция" типа Число (15, 0) и "дата смены статуса" типа "Дата".

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

ВЫБРАТЬ *
ИЗ РегистрСведений.СтатусыЗаявок
ГДЕ Проекция В(&МассивПроекций) И Период <= &Т0 И ДатаСменыСтатуса > &Т0

Чтобы не ломать структуру регистра и учитывая то, что стандартные индексы регистра сведений не могут одновременно включать два реквизита или реквизит и ресурс, пришлось пойти на небольшую хитрость: при расчете поля "проекция" добавлять к результату номер статуса, умноженный на миллион миллионов. То есть фактически поле "проекция" объединило в предлагаемом решении в себе значение двух полей "статус" и "проекция". Что и позволило использовать в запросе стандартное  индексирование реквизита "проекция".

В результате время выборки заявок с нужным статусом уменьшилось до 0,57 секунды и практически перестало зависеть от числа заявок в базе!

Вот новый план выполнения запроса:

Каркасную конфигурацию "СтатусыЗаявок" с запросами "Задача1" и "Задача2" можно также скачать из приложений к статье.

P.S.: Хочу поблагодарить Александра Спешилова (speshuric) за интересную задачу, благодаря которой было найдено описанное решение, а  Сергея Носкова (Sergey.Noskov) за статью о регистрах сведений, пробудившую интерес к данной теме.

.

Ускорение запросов интервалы индексы

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    1715    stopa85    12    

33

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    4320    user1959478    50    

34

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    7350    4    SpaceOfMyHead    17    

56

Модель распределения суммы по базе

Математика и алгоритмы Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022    7820    7    kalyaka    11    

44

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021    4415    fishca    13    

36

Интересная задача на Yandex cup 2021

Математика и алгоритмы Бесплатно (free)

Мое решение задачи на Yandex cup 2021 (frontend). Лабиринт. JavaScript.

12.10.2021    8795    John_d    73    

46

Механизм анализа данных. Кластеризация.

Математика и алгоритмы Анализ учета Платформа 1С v8.3 Анализ и прогнозирование Бесплатно (free)

Подробный разбор, с примером использования, встроенного механизма кластеризации 1С.

31.08.2021    7721    dusha0020    8    

70
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Makushimo 160 28.09.16 11:31 Сейчас в теме
абалдеть !
Как всегда прочитал с удовольствием и обязательно буду применять в работе.
2. Alias 176 28.09.16 12:21 Сейчас в теме
Очень красиво, спасибо большое. И вдобавок ещё и полезно. :)
3. igormiro 714 28.09.16 14:22 Сейчас в теме
Очередная статья мастера. По заголовку статьи знаешь, чья статься. Спасибо.
AlX0id; Kinestetik; wowik; Evil Beaver; webester; soulsteps; Liris; Noxie41; +8 Ответить
4. Sergey.Noskov 1375 28.09.16 14:23 Сейчас в теме
Очень интересно и наглядно.
Вопрос, Не пытались архитектуру регистра заточить под использование кластерного индекса? Судя по последнему плану запроса основную часть ресурсов потребляет операция "Поиск ключа", судя по всему это проверка части условия "..ДатаСменыСтатуса > &Т0.." + получение ресурса "Статус", сделав ДатаСменыСтатуса в составе измерений, уже можно получить профит, а если кластерным будет ключ [Проекция, Период, ДатаСменыСтатуса...], то должны получить максимальную скорость.
5. ildarovich 7846 28.09.16 15:16 Сейчас в теме
(4) Sergey.Noskov, такая мысль была.
Не стал этого делать, поскольку попробовал этот вариант на основной задаче: поиске интервалов. Первый план ему как раз и соответствует. Ощутимого прироста это не дало, поэтому на задаче о статусах пробовать уже не стал.
12. Sergey.Noskov 1375 29.09.16 16:58 Сейчас в теме
(5) а в диаграмме значения "Без индексирования" и "С индексированием" это сравнение каких запросов? Можно план запроса для "Без индексирования" увидеть?
13. ildarovich 7846 30.09.16 09:55 Сейчас в теме
(12) Sergey.Noskov, "с индексированием" это запрос с отбором по проекции:
ВЫБРАТЬ * ИЗ РегистрСведений.Дано 
ГДЕ Проекция В (&МассивПроекций) И &МоментВремени МЕЖДУ НачалоИнтервала И КонецИнтервала


Без индексирования - исходный запрос без такого отбора:
ВЫБРАТЬ * ИЗ Дано 
ГДЕ &МоментВремени МЕЖДУ НачалоИнтервала И КонецИнтервала

Вот его план (в двух видах в приложенных файлах):
Не увидел там ничего интересного, поэтому не стал приводить в статье.
Прикрепленные файлы:
ПланЗапросаБезИндексирования.txt
6. vspl 28.09.16 15:20 Сейчас в теме
Не хочу придираться к сути самой статьи, там все, наверное, правильно,
но для чистоты эксперимента в "Задаче о статусах заявок" нужно все-таки сравнивать быстродействие вот с этим запросом:

ВЫБРАТЬ * ИЗ РегистрСведений.СтатусыЗаявок.СрезПоследних(&Т0, Статус В (&Новый, &ВРаботе))

При условии, конечно, что Статус - индексированный

В этом случае результаты будут ИМХО не такие радужные
7. ildarovich 7846 28.09.16 15:25 Сейчас в теме
(6) vspl, это не эквивалентные запросы.
LordKim; ImHunter; Silenser; +3 Ответить
9. speshuric 1326 28.09.16 16:14 Сейчас в теме
(6) При небольшом количестве статусов (я думаю, до 50, могу проверить) СрезПоследних без явного отбора по заявкам всегда будет уходить в скан. Про это и была исходная задача. Задача описанная в этой статье - это вторая часть той задачи и она не эквивалентна срезу да и не решается только через срез.
ildarovich на самом деле молодец, сразу увидел главную граблю задачи по интервалам.
8. akR00b 22 28.09.16 15:26 Сейчас в теме
10. bulpi 215 28.09.16 21:21 Сейчас в теме
Задача со статусами , ИМХО, проще решается путем ввода условия
РегистрСведений.СтатусыЗаявок.СрезПоследних(&Т0, Период>=&ДатаПотериИнтереса)
, где ДатаПотериИнтереса =Т0- ИнтервалИнтересаВСекундах

, где ИнтервалИнтересаВСекундах - интервал, дальше которого пофиг на все незакрытые статусы. Такой интервал в реальных задачах всегда есть. Пусть даже большой. Например, год или два.
11. speshuric 1326 28.09.16 22:37 Сейчас в теме
(10) bulpi, Если этот интервал больше 10% от общего времени жизни - будут сканы. Точнее так: в 8.2 будет сканирование большого диапазона кластеризованного индекса, в 8.3 скорее всего будет полный скан (судя по освещённым в Sergey.Noskov изменениям).
14. user614720_vinzax 30.09.16 10:00 Сейчас в теме
Правда есть один забавный момент - есть такая константа "НеИспользоватьРазделениеПоОбластямДанных", так вот чтобы был доступен пункт с дополнительными отчетами и обработками она должна быть установлена в "Истина". Устанавливаться она должна, по идее, автоматически, но, видимо, разработчики БСП где-то что-то упустили и по умолчанию установлено значение "Ложь".
Можно зайти через "все функции", найти эту константу и установив значение "Истина" получить доступ к настройке внешних отчетов и обработок.
15. Serg O. 224 15.06.17 11:12 Сейчас в теме
крутатень! Ещё одно доказательство, что Правильная архитектура - очень важна!

мат. подход нужен, когда уже не помогает подход с матом
user656955_chel1C; +1 Ответить
16. пользователь 05.07.17 09:25
Сообщение было скрыто модератором.
...
17. kasper076 100 07.07.17 07:58 Сейчас в теме
Решил "реиндексировать" РС "СостоянияСогласованияЗаявок" УПП. При заполнении реквизита "Проекция" периодически возникала ошибка "Неправильное значение аргумента встроенной функции (Log)". Анализ показал, что в случае когда соседние записи в РС идут с одной и той же датой в поле период, то код
log(Макс(До - От, От - До)
выдает ошибку, т.к. log(0) не существует. Как решить эту проблему? Я понимаю, что записи в пределах секунды разнесены, но как учесть это в алгоритме расчета проекции не понимаю.
18. Release 07.07.17 08:01 Сейчас в теме
(17)Почему бы для До, От не использовать МоментВремени()?
19. kasper076 100 07.07.17 08:24 Сейчас в теме
(18) между моментами времени нельзя вычислить разность.
20. ildarovich 7846 07.07.17 09:47 Сейчас в теме
(17) Проще всего заменить выражение
Масштаб = pow(2, 99 - Цел(99 - Окр(log(Макс(До - От, От - До)) / log(2), 10)));
выражением
Масштаб = 1;
Тогда в следующем цикле будет выполняться больше итераций, а результат будет тем же. Ну, а если все же хочется убрать "лишние" итерации, то нужно проверить условие "От = До". Если оно выполняется, то масштаб принять равным единице:
Масштаб = ?(От = До, 1, pow(2, 99 - Цел(99 - Окр(log(Макс(До - От, От - До)) / log(2), 10))));
Кажется, так.
21. kasper076 100 07.07.17 10:06 Сейчас в теме
(20) Спасибо. Сейчас попробую.
Еще такой момент. Возможно обработка "Реиндексация" писалась на скорую руку и предполагалось, что конечный пользователь сам ее оптимизирует. Спасибо и за это. А возможно что-то упускаю и нужно было сделать именно так, как сделано.
Вот что есть сейчас:
	НаборЗаписей = РегистрыСведений.СтатусыЗаявок.СоздатьНаборЗаписей();
	НаборЗаписей.Прочитать();
	Таблица = НаборЗаписей.Выгрузить();
	Таблица.Сортировать("Заявка, Период");

При наличии в ТЗ ~2,5 млн строк Таблица.Сортировать("Заявка, Период") выполняется оч долго. Сделал так:
	Запрос = Новый Запрос(
	"ВЫБРАТЬ *
	|ИЗ
	|	РегистрСведений.СостоянияСогласованияЗаявок КАК СостоянияСогласованияЗаявок
	|
	|УПОРЯДОЧИТЬ ПО
	|	Заявка,
	|	Период
	|АВТОУПОРЯДОЧИВАНИЕ");
	
	Таблица = Запрос.Выполнить().Выгрузить();
Показать
22. ildarovich 7846 07.07.17 11:13 Сейчас в теме
(21) Если вы про обработку "Реиндексация" из примеров к статье, то все так и было.
Если реиндексацию необходимо делать не один раз, а часто, то интервалы лучше находить на основе алгоритма из статьи: Быстрое определение интервалов в запросе. Если постараться, то и проекцию можно сразу в запросе посчитать.
23. Hatson 528 30.07.21 14:27 Сейчас в теме
Скачал CF со статусами и думал, что в задаче удалость сделать регистр сведений НЕпериодическим, а он там всё равно периодический.

я бы сделал так.
Обычно нужен только последний актуальный статус.
Регистр сведений со статусами НЕпериодический - хранит только актуальный статус и документ. Плюс доп регистр "Задания на обновления статуса" неподчиненный - в него при записи документа записывается ссылка на документ. Далее фоновое задание забирает это задание и вычисляет статус документа, записывает его основной регистр. Статусы - это не остатки на складах. Даже если статус обновится с запозданием на 3 минуты, то это ни на что не повлияет.
Оставьте свое сообщение