Многопоточное восстановление последовательностей
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) Есть опыт увеличения в 7-8 раз скорости восстановления последовательности в одной из крупнейших энергосетевых организации сибирского федерального округа. Но это была не типовая конфигурация.
На типовых конфигурациях подобный алгоритм ускорял восстановление последовательности расчетов в 4-5 раз (УПП 1.2), но такой "не революционный" результат был больше обусловлен характером данных в учетной системе. Есть также опыт восстановления последовательности партионного учета в УПП с аналогичным результатом.
На типовых конфигурациях подобный алгоритм ускорял восстановление последовательности расчетов в 4-5 раз (УПП 1.2), но такой "не революционный" результат был больше обусловлен характером данных в учетной системе. Есть также опыт восстановления последовательности партионного учета в УПП с аналогичным результатом.
Правильная статья. Эффект от многопоточности пропорционален количеству потоков и обратно пропорционален количеству блокирующих факторов, заставляющих один поток ждать другой поток.
Реальным решением, позволяющим в достаточно большое количество раз увеличить скорость проведения документов, является механизм, позволяющий читать исторические данные одномоментно и хранить их изменения для последующих документов. Дальше полученные записи регистров передаются многопоточному механизму записи. В итоге так и в 100 раз можно скорость восстановления последовательности повысить, т.к. нет конфликтов чтения данных. Но такой подход может быть реализован лишь в монопольном режиме, когда разные пользователи не изменяют данные.
Реальным решением, позволяющим в достаточно большое количество раз увеличить скорость проведения документов, является механизм, позволяющий читать исторические данные одномоментно и хранить их изменения для последующих документов. Дальше полученные записи регистров передаются многопоточному механизму записи. В итоге так и в 100 раз можно скорость восстановления последовательности повысить, т.к. нет конфликтов чтения данных. Но такой подход может быть реализован лишь в монопольном режиме, когда разные пользователи не изменяют данные.
(3) Поддержу.
Отмечу еще, что представленный механизм дает не только ускорение как таковое. Да и вообще ускорение не было целью создания алгоритма. Цель - "забыть" о последовательностях как таковых. Оперативная работа пользователя в любом периоде должна была через 2-3 минуты давать возможность увидеть актуальную учетную картину.
При реализации описанного подхода последовательность восстанавливается самостоятельно. В организациях где это было реализовано, граница последовательности продвигается до максимального уровня сразу после изменения данных без трудозатрат пользователя. В итоге "запущенная" ситуации когда нужно что-то долго восстанавливать не наступает практически никогда.
Отмечу еще, что представленный механизм дает не только ускорение как таковое. Да и вообще ускорение не было целью создания алгоритма. Цель - "забыть" о последовательностях как таковых. Оперативная работа пользователя в любом периоде должна была через 2-3 минуты давать возможность увидеть актуальную учетную картину.
При реализации описанного подхода последовательность восстанавливается самостоятельно. В организациях где это было реализовано, граница последовательности продвигается до максимального уровня сразу после изменения данных без трудозатрат пользователя. В итоге "запущенная" ситуации когда нужно что-то долго восстанавливать не наступает практически никогда.
(4)
В итоге "запущенная" ситуации когда нужно что-то долго восстанавливать не наступает практически никогда.
Основная проблема - это изменение "древних" документов, результаты проведения которых могут влиять на будущие данные. Самое простое и правильное решение - запрет изменения данных в пределах дня (или, как это сделано в серьезных системах - вообще, а все изменения производятся корректирующими операциями). Но уж если политика компании в плане учета позволяет изменять данные в широком диапазоне периодов, то это решить каким-то простым методом, конечно, не получается.
Черезвычайно интересно.
Но я не понял, как Вы решаете следующую проблему :
Допустим, нужно восстановить последовательность за месяц по 1 товару. Но при перепроведении документов получается, что в ТЧ этих документов попадаются и другие товары. Что, в свою очередь, порождает новые "пакеты задач" на восстановление последовательности. И т.д, Для того , чтобы восстановить последовательность по 1 товару, в конечном счете придется перепровести целое дерево документов, которое может по размеру захватить и 100% документов за месяц (зависит от связности товаров в ТЧ)
Чтобы этого избежать, придется переписывать алгоритмы проведения так, чтобы перепроводился не полностью документ, а только 1 товар из документа. А это очень сложно, а иногда даже принципиально невозможно.
Но я не понял, как Вы решаете следующую проблему :
Допустим, нужно восстановить последовательность за месяц по 1 товару. Но при перепроведении документов получается, что в ТЧ этих документов попадаются и другие товары. Что, в свою очередь, порождает новые "пакеты задач" на восстановление последовательности. И т.д, Для того , чтобы восстановить последовательность по 1 товару, в конечном счете придется перепровести целое дерево документов, которое может по размеру захватить и 100% документов за месяц (зависит от связности товаров в ТЧ)
Чтобы этого избежать, придется переписывать алгоритмы проведения так, чтобы перепроводился не полностью документ, а только 1 товар из документа. А это очень сложно, а иногда даже принципиально невозможно.
(6) При выборе примера я намеренно взял ситуацию, когда один документ может проходить по нескольким ключам последовательности. Но такую ситуацию, как Вы описываете я не стал рассматривать в картинках, т.к. это значительно бы усложнило восприятие.
По существу:
Алгоритм генерирует большой объем новых задач и проведение одного документа действительно может приводить к лавинообразному росту заданий и, как следствие, необходимости проведения других документов по другим ключам. Но это происходит ТОЛЬКО когда это следует из логики данных (избыточности нет). Механизм рассчитан на переваривание такой ситуации. Нет необходимости переписывать процедуры проведения документов для реализации возможности проведения только по 1 ключу из нескольких, задетых документом.
Хотя не спорю, если заморочиться и переписать - работать будет быстрее и "лавины" не будет. Но здесь возникает вопрос целесообразности такой работы. Практический опыт показал, что её нет. Если обработка заданий включена онлайн и есть адекватное движение даты запрета редактирования по отношению к точке ввода данных, то критические ситуации маловероятны.
А даже если они случаются - они обрабатываются в фоне практически без влияния на оперативную работу пользователей.
По существу:
Алгоритм генерирует большой объем новых задач и проведение одного документа действительно может приводить к лавинообразному росту заданий и, как следствие, необходимости проведения других документов по другим ключам. Но это происходит ТОЛЬКО когда это следует из логики данных (избыточности нет). Механизм рассчитан на переваривание такой ситуации. Нет необходимости переписывать процедуры проведения документов для реализации возможности проведения только по 1 ключу из нескольких, задетых документом.
Хотя не спорю, если заморочиться и переписать - работать будет быстрее и "лавины" не будет. Но здесь возникает вопрос целесообразности такой работы. Практический опыт показал, что её нет. Если обработка заданий включена онлайн и есть адекватное движение даты запрета редактирования по отношению к точке ввода данных, то критические ситуации маловероятны.
А даже если они случаются - они обрабатываются в фоне практически без влияния на оперативную работу пользователей.
Правильно ли я понял, что по одному картина получается примерно следующая: По каждому прибору учета запускается отдельное ФЗ?
Если да, тогда вопрос:
Предположим, для краткости мы запускаем восстановление в 5 потоков
ФЗ1: (Док1, ключ1) ->(Док2, ключ1)----->
ФЗ2: (Док3, ключ2) ->(Док4, ключ2)----->
ФЗ3: (Док5, ключ3) ->(Док6, ключ3)----->(Док12, Ключ1,Ключ2,Ключ3,Ключ4,Ключ5,Ключ6)
ФЗ4: (Док7, ключ4) ->(Док8, ключ4)----->
ФЗ5: (Док9, ключ5) ->(Док10, ключ5)--->
(Док11, ключ6)----------------------->
Поясню, Каждое ФЗ восстанавливает свой ключ, но у нас ограничение в 5 ФЗ, и дойдя до документа 12 с 6 ключами, все наши ФЗ встали, т.к. ждут восстановления ключа 6, а на него ФЗ не хватило?
Так же вопрос, не понял где происходит сдвиг границы последовательности?
Если да, тогда вопрос:
Предположим, для краткости мы запускаем восстановление в 5 потоков
ФЗ1: (Док1, ключ1) ->(Док2, ключ1)----->
ФЗ2: (Док3, ключ2) ->(Док4, ключ2)----->
ФЗ3: (Док5, ключ3) ->(Док6, ключ3)----->(Док12, Ключ1,Ключ2,Ключ3,Ключ4,Ключ5,Ключ6)
ФЗ4: (Док7, ключ4) ->(Док8, ключ4)----->
ФЗ5: (Док9, ключ5) ->(Док10, ключ5)--->
(Док11, ключ6)----------------------->
Поясню, Каждое ФЗ восстанавливает свой ключ, но у нас ограничение в 5 ФЗ, и дойдя до документа 12 с 6 ключами, все наши ФЗ встали, т.к. ждут восстановления ключа 6, а на него ФЗ не хватило?
Так же вопрос, не понял где происходит сдвиг границы последовательности?
(8) 1. Не верно поняли. Когда ФЗ натыкается на ситуацию ожидания - обработка пакета завершается. ФЗ заканчивает свою работу, освобождая "слот" для других ФЗ. В следующий раз по этому ключу ФЗ стартует только при следующем старте управляющего потока. До этого момента - будут обрабатываться другие ключи.
2. В приведенном примере граница сдвигается автоматически при проведении документа.
2. В приведенном примере граница сдвигается автоматически при проведении документа.
(9)
Есть ли смысл двигать границу каждым документом?
Как быть в типовых решениях, где нет измерений? Двигать каждым документом? Но тогда не будет параллельности. Или встраивать измерение и править типовые механизмы?
В приведенном примере граница сдвигается автоматически при проведении документа.
Есть ли смысл двигать границу каждым документом?
Как быть в типовых решениях, где нет измерений? Двигать каждым документом? Но тогда не будет параллельности. Или встраивать измерение и править типовые механизмы?
(10) Тестовом примере двигать границу каждым документом, как мне кажется, вполне уместно :) Да и не в тестовом - тоже можно (зачастую, так и происходит в типовых конфигурациях от 1С).
По второму вопросу - мне кажется Вам стоит прочитать главу Ограничения в самом конце статьи. Там четко обозначено, что:
2. Последовательность должна корректно разделять данные на независимые ветви., также приведен соответствующий пример.
Ситуация, когда в типовой конфигурации от фирмы 1С последовательность не содержала бы измерений, мне не встречалась.
По второму вопросу - мне кажется Вам стоит прочитать главу Ограничения в самом конце статьи. Там четко обозначено, что:
2. Последовательность должна корректно разделять данные на независимые ветви., также приведен соответствующий пример.
Ситуация, когда в типовой конфигурации от фирмы 1С последовательность не содержала бы измерений, мне не встречалась.
(11)
Да - в типовой УПП при восстановлении партий БУ есть измерение, но это только Организация, а ни как не Организация + Склад + Номенклатура.
Отсюда вопрос, что еще необходимо будет доработать в типовой УПП 1.3 для восстановления последовательности партий?
Что добавить - ясно:
* подсистема "Универсальные механизмы: пакеты данных";
* РС для блокировок;
* Общий модуль с вышеизложенными модулями;
А вот что придется изменить в типовых метаданных?
* последовательность - добавить в нее измерения, да еще и не одно, а несколько (Организация - есть, + Склад + Номенклатура)?
* а так же закомментировать весь код типового движения по этой последовательности?
* еще что-то?
Или я все не так понял?
А как быть с последовательностями, если мы отдаем материалы в производств стороннему контрагенту и на выходе получаем готовую продукцию, которую списываем в производство? Ведь те документы кроме как "Заказом" ни как не связаны?
Т.е. Передача:
Склад1 + Затрата1
Склад1 + Затрата2
Заказ1
Поступление:
Склад5 + Продукция1
Заказ1
Как с учетом и обычного списания материалов со склада и с таким производство доработать последовательность???
Ситуация, когда в типовой конфигурации от фирмы 1С последовательность не содержала бы измерений, мне не встречалась
Да - в типовой УПП при восстановлении партий БУ есть измерение, но это только Организация, а ни как не Организация + Склад + Номенклатура.
Отсюда вопрос, что еще необходимо будет доработать в типовой УПП 1.3 для восстановления последовательности партий?
Что добавить - ясно:
* подсистема "Универсальные механизмы: пакеты данных";
* РС для блокировок;
* Общий модуль с вышеизложенными модулями;
Последовательность должна корректно разделять данные на независимые ветви
А вот что придется изменить в типовых метаданных?
* последовательность - добавить в нее измерения, да еще и не одно, а несколько (Организация - есть, + Склад + Номенклатура)?
* а так же закомментировать весь код типового движения по этой последовательности?
* еще что-то?
Или я все не так понял?
А как быть с последовательностями, если мы отдаем материалы в производств стороннему контрагенту и на выходе получаем готовую продукцию, которую списываем в производство? Ведь те документы кроме как "Заказом" ни как не связаны?
Т.е. Передача:
Склад1 + Затрата1
Склад1 + Затрата2
Заказ1
Поступление:
Склад5 + Продукция1
Заказ1
Как с учетом и обычного списания материалов со склада и с таким производство доработать последовательность???
(12) Если последовательность не разделяет данные на независимые ветви, то такую последовательность нужно дорабатывать. В противном случае о многопоточной обработке можно забыть.
С решением прикладной задачи я думаю Вы сможете справится самостоятельно.
P.s.: про поблемы в УПП я знаю. И если вы посмотрите внимательно, на ситуацию, которой я демонстрирую ограничение №2, возможно вы узнаете свою проблему :).
P.p.s.: эту проблему я решал на УПП 1.2 путем доработки последовательности, но приводить описание своих действий здесь не считаю целесообразным.
С решением прикладной задачи я думаю Вы сможете справится самостоятельно.
P.s.: про поблемы в УПП я знаю. И если вы посмотрите внимательно, на ситуацию, которой я демонстрирую ограничение №2, возможно вы узнаете свою проблему :).
P.p.s.: эту проблему я решал на УПП 1.2 путем доработки последовательности, но приводить описание своих действий здесь не считаю целесообразным.
(13)
Так в этом и вопрос, что на простом примере, где четко можно разделить по "приборам учета" - все просто и даже понятно, но в реальной задаче уже сложности. Получается как с картинкой про "Сову"
(13)
Зачем забывать?
- позволяет решить вопрос восстановления без доработок последовательности, без добавления "фиктивных" объектов метаданных.
С решением прикладной задачи я думаю Вы сможете справится самостоятельно.
Так в этом и вопрос, что на простом примере, где четко можно разделить по "приборам учета" - все просто и даже понятно, но в реальной задаче уже сложности. Получается как с картинкой про "Сову"
(13)
Если последовательность не разделяет данные на независимые ветви, то такую последовательность нужно дорабатывать. В противном случае о многопоточной обработке можно забыть.
Зачем забывать?
- позволяет решить вопрос восстановления без доработок последовательности, без добавления "фиктивных" объектов метаданных.
(15)
Вопрос не только в продвижении.
Мне действительно интересны статьи и разработки связанные с многопоточностью.
В предложном Вами я так же нашел массу интересных направлений натолкнувших меня на ряд идей :).
Я рад, что Вы нашли место для его продвижения здесь.
Вопрос не только в продвижении.
Мне действительно интересны статьи и разработки связанные с многопоточностью.
В предложном Вами я так же нашел массу интересных направлений натолкнувших меня на ряд идей :).
Ну все это хорошо. Вот тут вопрос к 1С скажите, а почему зная о колосальной проблеме в типовых решениях не сделать многопоточность в качестве инструментария типовых решений, почему люди пилят вот такие собственные "костыли" ?...
К сожалению 1С этот вопрос никогда не увидит и точно ответа не дадут. Но из ряда вон у меня есть масса претензий к этим умным людям. Вместо того чтобы разрабатывать действительно требовательные механизмы затрагивающие область оптимизации (это не только многопоточность), а вообще маштабированность кластеров и стабильность их. Вот вместо этого мы на зазеркалье читаем (мы вот тут добавляем чат в 1С назвав это крутым словом ВЗАИМОДЕЙСТВИЕ).
А потом через некоторое время еще: мы тут такую крутую штуку придумали к этому чату, теперь вы можете через нее файлы передевать.
К сожалению 1С этот вопрос никогда не увидит и точно ответа не дадут. Но из ряда вон у меня есть масса претензий к этим умным людям. Вместо того чтобы разрабатывать действительно требовательные механизмы затрагивающие область оптимизации (это не только многопоточность), а вообще маштабированность кластеров и стабильность их. Вот вместо этого мы на зазеркалье читаем (мы вот тут добавляем чат в 1С назвав это крутым словом ВЗАИМОДЕЙСТВИЕ).
А потом через некоторое время еще: мы тут такую крутую штуку придумали к этому чату, теперь вы можете через нее файлы передевать.
Потому что для файловой базы это работать не должно, а конфигурация та же. Тот кто покупает серверную версию должен понимать, что конфигурация у него все равно для файловой базы с некоторыми встренными готовыми костылями.
Причем здесь предприятие мы говорим об архитектуре тиражных решений. Либо все предприятия до 10 пользователей будут работать на системе для серверных версий, либо всем серверным придется мириться с принципами работы небольших баз. Как по вашему, чьими интересами пожертвуют?
(24) В КЭО практически нет нового функционала. Последний год мы только переписываем/рефакторим КЭО. В частности переписали полностью пофидерный анализ. Старые документы и всю подсистему приборов учета выкорчевали, т.к. она оказалась нежизнеспособной. Создали новые объекты/регистры и пр.
Сейчас занимаемся внедрением 1С:ТОиР. Уже введено более 1 млн объектов ремонта, формируются полностью заполненные паспорта ВЛ. Запустили геоинформационную систему, которая позволяет визуализировать сеть и топологию на Яндекс картах.
Сейчас занимаемся внедрением 1С:ТОиР. Уже введено более 1 млн объектов ремонта, формируются полностью заполненные паспорта ВЛ. Запустили геоинформационную систему, которая позволяет визуализировать сеть и топологию на Яндекс картах.
Сейчас как раз пытаюсь реализовать подобное у бухгалтерии 3.0, за пример взял статью с ИТС (, то есть добавил в последовательности "ДокументыОрганизаций" измерение "ДоговорКонтрагента". Казалось, что всё довольно просто, но как оказалось проблема не в том, как распараллелить, а в том, что далеко не во всех документам последовательности есть такой реквизит и не каждый документ можно отнести к конкретному договору (требования-накладные, операция, перемещение товаров, передача ОС и т. п.). В итоге оказалось, что документов с договорами совсем немного больше, чем документов без договоров. Результат получился следующий:
Формируется таблица документов из последовательности, документы без договора проводятся последовательно, когда доходит до документов с договорами, такие документы разбиваются на 5 потоков и проводятся параллельно
Количество документов: 32585
Время проведения: 8:32:57 (6:31:52)
Количество документов: 38958 (документов с договорами стало гораздо больше)
Время проведения: 11:06:13 (8:27:17)
Как видно, выгода по времени есть, но нельзя сказать, что у меня она получилась особо впечатляющей
Формируется таблица документов из последовательности, документы без договора проводятся последовательно, когда доходит до документов с договорами, такие документы разбиваются на 5 потоков и проводятся параллельно
Количество документов: 32585
Время проведения: 8:32:57 (6:31:52)
Количество документов: 38958 (документов с договорами стало гораздо больше)
Время проведения: 11:06:13 (8:27:17)
Как видно, выгода по времени есть, но нельзя сказать, что у меня она получилась особо впечатляющей
(27) Вашу ситуацию можно также можно попробовать решить с помощью предложенного алгоритма. Вы вводите в последовательность измерение Договор. Те документы, которые не имеют договора - также должны в эту последовательность попадать (Договор = ПустаяСсылка).
Нужно будет запрос в обработчике пакета доработать следующим образом: если в текущем ключе договор - пустая ссылка, то мы не ищем корреспондирующие ключи, а смотрим есть ли в последовательности документы (вообще без отбора по измерениям) , которые нужно проводить ранее нашего. В этом случае текущее задание будет ждать пока все документы, ранее текущего будут проведены в нужной последовательности.
Нужно будет запрос в обработчике пакета доработать следующим образом: если в текущем ключе договор - пустая ссылка, то мы не ищем корреспондирующие ключи, а смотрим есть ли в последовательности документы (вообще без отбора по измерениям) , которые нужно проводить ранее нашего. В этом случае текущее задание будет ждать пока все документы, ранее текущего будут проведены в нужной последовательности.
Насколько я понял задания создаются по документам проведенным "задним числом". Мы использовали иной подход: выявляли ошибки в партиях (это можно сделать одним запросом и достаточно быстро) за период и перепроводили только документы с ошибками. Далее проверяли следующий период. И чем меньше ошибок, тем быстрее восстановление. Штатно на УПП 1.3 тратили несколько дней, теперь для предварительной оценки месяца достаточно полчаса-час. На чистовую побольше.
Скажите по опыту, если вот такая ситуация.
Дали добро открыть дату запрета редактирования, чтобы человек мог залезть задним числом в документ и сделать ювелирное изменение документа и при этом не надо никаких порождать заданий на восстановление последовательностей. Если ваш пример брать , например, решили откорректировать дату установки/монтажа прибора учета, при этом показания не меняется, т.е. разница показаний не меняется в последующих документах.
Есть какие-то "заградительные" меры, чтобы задания не порождались? Какие подходы?
Дали добро открыть дату запрета редактирования, чтобы человек мог залезть задним числом в документ и сделать ювелирное изменение документа и при этом не надо никаких порождать заданий на восстановление последовательностей. Если ваш пример брать , например, решили откорректировать дату установки/монтажа прибора учета, при этом показания не меняется, т.е. разница показаний не меняется в последующих документах.
Есть какие-то "заградительные" меры, чтобы задания не порождались? Какие подходы?
(32) А тут кто во что горазд... Я обычно при генерации пакета в комментарий к пакету записываю информацию о том, кто и в каких обстоятельствах создал пакет. В вашем случае достаточно указать "Иванова Иванна Ивановна - Док №6 от 01.01.80".
В тот момент, когда я Иванову запускаю руками "ювелирить" - просто отключаю активность способа обработки пакетов. Пакеты будут генерироваться, но обрабатываться не будут. После того, как она сделала свои дела - удаляю еще не обработанные пакеты и программно двигаю последовательность на дату запрета.
В тот момент, когда я Иванову запускаю руками "ювелирить" - просто отключаю активность способа обработки пакетов. Пакеты будут генерироваться, но обрабатываться не будут. После того, как она сделала свои дела - удаляю еще не обработанные пакеты и программно двигаю последовательность на дату запрета.