Как сделать обмен данными через универсальный формат быстрее? Реализация многопоточного обмена данными
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) С Наступающим, Коллеги!
Многопоточные обмен и обработки в продукте 2is:Интеграция появились в 2015 году и тогда же были обкатаны на ряде весьма крупных проектах. Т.е. сам подход к многопоточности (распараллеливанию) универсален и его можно применять в любых обработках. Готовые примеры распараллеливания из 2iS: замена дублей в базах, удаление объектов по условиям, проведение документов и формирование проводок (где нет завязки на последовательность), обмены по разным сценариям и т.д.
Таким образом, многопоточность, как инструмент применяют все кто используют продукт с 2015 года (замечу, что при обмене данными, многопоточность включается автоматически при достижении заданного размера очереди, по умолчанию это 1000 объектов).
В настоящей статье, Дмитрий описал пилотный проект (т.е. первый:-) по применению данного подхода к обмену в универсальном формате EnterpriseData (КД3) и раскрыл имеющиеся подводные камни на пути к его реализации.
Поддержка многопоточного обмена в формате EnterpriseData (КД3) была включена в один из последних релизов 2is:Интеграции и, таким образом, уже доступна в тиражном решении. Статья будет полезна также тем, кто собирается внедрять данную функциональность.
Многопоточные обмен и обработки в продукте 2is:Интеграция появились в 2015 году и тогда же были обкатаны на ряде весьма крупных проектах. Т.е. сам подход к многопоточности (распараллеливанию) универсален и его можно применять в любых обработках. Готовые примеры распараллеливания из 2iS: замена дублей в базах, удаление объектов по условиям, проведение документов и формирование проводок (где нет завязки на последовательность), обмены по разным сценариям и т.д.
Таким образом, многопоточность, как инструмент применяют все кто используют продукт с 2015 года (замечу, что при обмене данными, многопоточность включается автоматически при достижении заданного размера очереди, по умолчанию это 1000 объектов).
В настоящей статье, Дмитрий описал пилотный проект (т.е. первый:-) по применению данного подхода к обмену в универсальном формате EnterpriseData (КД3) и раскрыл имеющиеся подводные камни на пути к его реализации.
Поддержка многопоточного обмена в формате EnterpriseData (КД3) была включена в один из последних релизов 2is:Интеграции и, таким образом, уже доступна в тиражном решении. Статья будет полезна также тем, кто собирается внедрять данную функциональность.
С наступающим!
Данные в плане обмена регистрируются же порциями, соответственно так же можно разбивать на порции при обмене.
Ещё как вариант - анализировать данные - связанные документы и справочники направлять в один поток.
Ещё полезно было бы организовать очередь. В числе первых обмениваться справочниками, потом документами.
По поводу сравнения скорости обмена КД2 и КД3. Где-то была статья с замерами. КД3 на 20% была быстрее. Сам пока не проверял. Субъективные ощущения, что разницы почти нет. А файл с универсальным форматом выглядит лаконичнее и читабельнее. И с учетом ограничения формата, реквизитов на каждый объект минимальное достаточное количество.
В типовом обмене, если использовать ручной запуск кнопкой Синхронизировать. Время обмена увеличивается в 2 раза. Первый - предварительно прочитать файл и выдать диалог синхронизации, второй раз данные читаются для непосредственной загрузки в базу.
Данные в плане обмена регистрируются же порциями, соответственно так же можно разбивать на порции при обмене.
Ещё как вариант - анализировать данные - связанные документы и справочники направлять в один поток.
Ещё полезно было бы организовать очередь. В числе первых обмениваться справочниками, потом документами.
По поводу сравнения скорости обмена КД2 и КД3. Где-то была статья с замерами. КД3 на 20% была быстрее. Сам пока не проверял. Субъективные ощущения, что разницы почти нет. А файл с универсальным форматом выглядит лаконичнее и читабельнее. И с учетом ограничения формата, реквизитов на каждый объект минимальное достаточное количество.
В типовом обмене, если использовать ручной запуск кнопкой Синхронизировать. Время обмена увеличивается в 2 раза. Первый - предварительно прочитать файл и выдать диалог синхронизации, второй раз данные читаются для непосредственной загрузки в базу.
Я вот только одного не понимаю. Сначала всё усложнили, а потом героически боремся с этими сложностями. Зачем вообще использовать для больших объёмов с ограничениями времени типовой обмен? Пишем свой и живём спокойно, не завися от блажи создателей БСП в очередном релизе и степени их криворукости. А так - ну подсчитайте накладные расходы на извращения вокруг БСП и на написание своего с чистого листа, и увидите: своё побыстрее и попроще будет.
(5)Да, свой безусловно быстрее будет.
Но если много документов и справочников, то это трудоемкий процесс получится.
Решением может стать перенос нескольких особо тяжелых документов с помощью не типового спец. обмена, а остальное типовым делать.
У меня была еще мысль вообще отказаться от XDTO. Зашить описание формата в общий модуль и использовать JSON. Уже собрался делать, но результаты тестов показали, что больше всего времени уходит не на работу с XDTO, а на обработку правил конвертации, от которых все равно никуда не денешься. Ускорение если и получится, то незначительное. Так что отказался от этой идеи.
Может быть разработчики со временем сделают возможность опционально использовать или XDTO или JSON.
Но если много документов и справочников, то это трудоемкий процесс получится.
Решением может стать перенос нескольких особо тяжелых документов с помощью не типового спец. обмена, а остальное типовым делать.
У меня была еще мысль вообще отказаться от XDTO. Зашить описание формата в общий модуль и использовать JSON. Уже собрался делать, но результаты тестов показали, что больше всего времени уходит не на работу с XDTO, а на обработку правил конвертации, от которых все равно никуда не денешься. Ускорение если и получится, то незначительное. Так что отказался от этой идеи.
Может быть разработчики со временем сделают возможность опционально использовать или XDTO или JSON.
(6) Я делал замеры, когда JSON только появился в платформе - разницы с xml \ xdto сериализацией практически не было (места меньше, но читабельность сильно хуже) и да - это менее 2% от процесса, далее, по-нормальному, 48% занимает конвертация по правилам, и наконец 50% - обработка данных после загрузки (дозаполнение, проведение и т.п.). Последняя, очевидно, должна быть вынесена в отдельный асинхронный поток, дабы не замедлять обмен данными...
Напишите ваше сообщение
(5) Если под "своим обменом" понимать разработку правил с нуля на КД2, с заточкой под конкретную бизнес-логику (читай, сильно доработанными типовыми), то согласен - будет и работать быстрее и разработка займет меньше времени...
Выше описан реалистичный и наиболее частый из практики случай - "когда-то было типовым" и "так исторически сложилось"))
(5) Если под "своим обменом" понимать разработку правил с нуля на КД2, с заточкой под конкретную бизнес-логику (читай, сильно доработанными типовыми), то согласен - будет и работать быстрее и разработка займет меньше времени...
Выше описан реалистичный и наиболее частый из практики случай - "когда-то было типовым" и "так исторически сложилось"))
Люди добрые, да зачем вам КД вообще, хоть 2, хоть 3? Своё от начала до конца, и это вовсе не столь трудоёмко, как кажется! Меня тоже запугивали на одном проекте, мол, без КД вилы, а там засчёт отказа от кд-шных принципов обработки данных и скорость повысить удалось (точные проценты не скажу, уже не помню), и надёжность, и ресурсоёмкость. Ясное дело, при небольших задачах КД наше всё, но не делайте из неё панацею)
(11)
Но еще нужно не забывать о дальнейшей поддержке рабочей системы. Понятности что происходит и простоты модернизации.
А то один такой умник внедренец (это не оскорбление, а реальная оценка), а после ищи кто сможет это сопровождать.
ость. Ясное дело, при небольших задачах КД наше всё, но не делайте из неё панацею)
Но еще нужно не забывать о дальнейшей поддержке рабочей системы. Понятности что происходит и простоты модернизации.
А то один такой умник внедренец (это не оскорбление, а реальная оценка), а после ищи кто сможет это сопровождать.
(12) Делать надо нормально, структурированно и прозрачно. По-умному делать. И инструкции да схемы после себя оставлять, документировать нормально. Тогда любой грамотный спец за пару дней вникнет и сможет сопровождать.
А то есть такие умники, например, бсп накатали, а внутри хрен разберёшься, и описаний внятных нет, несмотря на раскрутку и типа универсальность. И ищи, кто сможет это сопровождать. Да ещё загибающееся от собственных наворотов и переделок.
Я это к чему - если спец хороший и объёмы адские, то, разумеется, свой обмен выигрышнее. В том числе по дальнейшей поддержке и доработке. А если пионэры, то они и в КД так наколбасят, что чёрт ногу сломит.
А то есть такие умники, например, бсп накатали, а внутри хрен разберёшься, и описаний внятных нет, несмотря на раскрутку и типа универсальность. И ищи, кто сможет это сопровождать. Да ещё загибающееся от собственных наворотов и переделок.
Я это к чему - если спец хороший и объёмы адские, то, разумеется, свой обмен выигрышнее. В том числе по дальнейшей поддержке и доработке. А если пионэры, то они и в КД так наколбасят, что чёрт ногу сломит.
(13) Поддержу Вас! Если спец, то он и в КД разберётся и в чужом коде. У нас так, если стандартный обмен, то он и есть стандартный, что тут рожать, а если с закавыками, то проще заложить в обработку. С JSON трафик меньше, читабельность лучше, преобразование проще(на мой взгляд быстрее). А львиная доля времени затрачивается на проверки, поиски, сравнения, особенно, если бухгалтера не понимают, что чем безалабернее ведутся справочники, тем дольше ищется (с доп проверками)
К большому сожалению, разработчики типового обмена данными, сделали его достаточно сложным. В типовых правилах очень активно используется создание виртуальных объектов при выгрузке, создание объектов «на лету» при загрузке, сохранение большого числа коллекций с объектами и их последующая обработка. По всей видимости они не задумывались над возможным использованием этого механизма в многопоточном режиме, а очень зря.
имхо: Они походу ВООБЩЕ НЕ ДУМАЛИ. Думали только чтоб целостность данных была.
Чуть больше объем и даже хорошее железо не спасает.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|