|
06.04.2021, 11:44 | #1 |
Модератор
|
А не подойдет ли для этой задачи очередь сообщений (RabbitMQ или даже Debezium) + пакетная обработка?
1 мастер система или 2? Т.е. если справочники вбиваются в систему 1, и они должны точно отображаться в системе 2 - это один вариант. Если и в системе 1, и в системе 2 ведутся справочники, которые должны быть синхронизированы, включая контроль совпадений - это уже другой вариант, посложнее. Просто Change Data Capture не подойдет, так как разные системы и разные RecID. Тогда просто кроликом гоняем изменения во временную таблицу. А раз в час или в 5 минут запускаем пакет, в котором делаем импорт средствами системы и удаляем (помечаем) обработанную запись. Надо предусмотреть не только добавление, но и изменение / удаление данные, что тоже возможно посредством передачи пакетов. Вопрос в гарантированной доставке. Возможно, раз в неделю / месяц стоит полностью синхронизировать справочники. С Уважением, Георгий |
|
06.04.2021, 12:03 | #2 |
Участник
|
Цитата:
и ты конечно имеешь в виду, что пакетная обработка в обеих конечных точках (ax2012, ax2009). но тут возникает вопрос следующего уровня - а как правильно обращаться к этим брокерам сообщений из Аксапты? причем и с брокерами нужно как-то решать тот же вопрос про 100500 элементов коллекции. или где-то решен вопрос как передавать коллекции через брокер? или в брокер можно передавать элементы по одному и не париться о накладных расходах? Последний раз редактировалось mazzy; 06.04.2021 в 12:08. |
|
06.04.2021, 12:24 | #3 |
Модератор
|
Цитата:
Цитата:
Цитата:
Цитата:
С Уважением, Георгий |
|
06.04.2021, 13:35 | #4 |
Участник
|
Цитата:
Цитата:
таблица - это права на той стороне понятно, что можно. но является ли это правильным подходом? а как правильнее? Цитата:
Цитата:
мне кажется, что "по одному" - будут слишком большие накладные расходы с любым брокером сообщений. либо я чего-то не знаю. да, знаю, что для решения задачи все нормальные инструментарии обзавелись стримами. но в вопросе указано, что обсуждаем Аксапты или правильным является "сделать собственные dll'ки, которые снаружи работают со стримами, а аксапте отдают объекты по одному"? и чтобы эти собственные dll'ки работали в адресном пространстве аксапты... https://coub.com/view/12jn53 Цитата:
я не стал акцентировать, когда увидел прошлый твой ответ, но обрати внимание, что в вопросе было "передавать", а ты постоянно отвечаешь "запрашивать" ты считаешь, что это одинаковые действия? почему? и понятно, что регулярно раз в 5 минут 100500 элементов передаваться не будут. но при пиковых нагрузках элементов будет много. собственно об этом и вопрос: как правильно передавать много элементов коллекции? Последний раз редактировалось mazzy; 06.04.2021 в 13:42. |
|
06.04.2021, 13:59 | #5 |
Модератор
|
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир к Informatica PEC, Oracle GoldenGate, Qlik Data Integration и Debezeum. Вариантов, увы, нет.
Все эти продукты могут в режиме, близко к реальному, переносить данные из таблицы А в одной среде к таблицы В в другой. Не все могут переносить структуру таблиц - обычно только поля (только Qlik Attuniy умеет, кстати). Почти все (кроме, кажется, Debezeum) умеют маскировать выбранные поля. Ни одна не умеет генерить локальный RecId из другой системы. Это означает одно - синхронизировать-то мы можем, а вот доп. обвязку в виде тех же RecID необходимо будет делать силами интегрируемой системы, такой как Аксапта. Я знаю про пакетную обработку, возможно, если и другие пути добавления необходимой служебной информации, но я про них не наслышан. С Уважением, Георгий |
|
06.04.2021, 17:29 | #6 |
Участник
|
Цитата:
Сообщение от George Nordic
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир к Informatica PEC, Oracle GoldenGate, Qlik Data Integration и Debezeum. Вариантов, увы, нет.
мы уже давно во взрослом мире. и как я говорил, решение уже есть. давай лучше поговорим как правильно? и как правильно делают упомянутые тобой решения? |
|
06.04.2021, 17:56 | #7 |
Модератор
|
Не только. Более того, продажами софта я не занимаюсь. Я за всеобщую цифровую грамотность.
упомянутые мною решения, как платные так и open source, делают одно - он реплицируют данные из системы А в систему В. В режиме, близком в режиму реального времени, хотя временной лаг все равно есть. Да, и это требует включения режима расширенного логирования, так как они читают логи, что BDA не всегда по нраву. И, некоторые, установки агента, что уже не по нраву и безопасникам.
Какое именно решение считать "правильным" зависит от задачи и от критичности скорости изменений. Да, еще есть критерий гарантированной доставки сообщений и двухсторонней репликации / разруливания конфликтов репликации, но это за рамками обсуждения, иначе еще про шины данных придется рассказывать, такие как IBM WebSphere. С Уважением, Георгий |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
06.04.2021, 15:58 | #8 |
Участник
|
В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.
Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа. При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке) Возвращаясь к вопросу. 100500 сообщений по 1Мб (например) это почти 100Гб сырых данных. За какое время их передавать надо и как далеко?. Если проблема в размере сообщений, можно попробовать их сжать при отправке. Или вообще, Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV Или более современно, в parquet Может оказаться вполне быстро и автоматизировать не сложно. Через WCF можно управляющие команды подать, с метаданными файла |
|
06.04.2021, 17:36 | #9 |
Участник
|
Цитата:
Сообщение от AlexMoskvichev
В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.
Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа. При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке) Цитата:
я вроде написал "коллекция - список/массив/мап/контейнер/таблица" В мире аксапты элементы коллекций это максимум размер страницы MS SQL = 8Кб Очень-очень редко мемо поля до 4Гб. Но про это я бы обязательно сказал. все-таки для мира аксапты хорошие допущения: = размер элемента до 8кб = размер буфера рабочего окна 64Кб (максимальный размер XML в WCF по умолчанию) = размер коллекции более 100500 элементов Цитата:
вопрос про количество элементов, которое гарантировано не помещается в одно сообщение. Цитата:
Сообщение от AlexMoskvichev
Или вообще,
Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV Или более современно, в parquet Может оказаться вполне быстро и автоматизировать не сложно. Через WCF можно управляющие команды подать, с метаданными файла Последний раз редактировалось mazzy; 06.04.2021 в 18:13. |
|
06.04.2021, 16:18 | #10 |
Модератор
|
Цитата:
Цитата:
А как ты представляешь себе синхронизацию таблиц?
Цитата:
Что с RecId делать?
Цитата:
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир
__________________
-ТСЯ или -ТЬСЯ ? |
|
06.04.2021, 16:46 | #11 |
Модератор
|
Дело в том, что сторонние решения реплицируют таблицу или частично (часть полей), но тогда с системе B поле RecId будет пустое, или целиком, но тогда в системе B поле RecId будет такое же, как и в системе А, что некорректно.
Если можно использовать стандартный транспорт силами DAX, тот же AIF, который возьмет часть данных в А и выгрузить их в В, добавив и заполнив все обязательные системные поля, это круто. Есть такие способы? С Уважеинием, Георгий |
|
06.04.2021, 17:44 | #12 |
Участник
|
Цитата:
Сообщение от Vadik
Нет, не считаю, действия действительно разные. Я считаю что это не царское (издателя) дело пихать (передавать) данные во всех подписчиков число которых в общем случае может превышать единицу. Иногда может быть оправдано, но в общем предпочел бы чтобы этим сам подписчик или брокер занимался.
Нет, я не имел в виду транспортный уровень. Да, надо было использовать глагол "отправить" вопрос звучал бы "как правильно отправить". Я имел в виду, что Аксапта (как endpoint) инициирует процесс подготовки и отправки данных в другую Аксапту (другой endpoint). В WCF это означает Аксапта должна заполнить коллекцию с элементами и вызвать какой-нибудь осмысленный метод для этой коллекции. для какого-нибудь другого брокера это будет нечто похожее. Аксапта готовит данные в специальном формате и вызывает что-нибудь осмысленное для этих данных. И WCF, и другие брокеры, насколько я знаю, все имеют ограничение на размер сообщения. Размер сообщения меньше, чем размер всех элементов. вопрос - как правильно готовить, чтобы отправить (передать) свои данные другому endpoint. современный правильный ответ - использовать потоки. но в Аксапте нет потоков. какой способ отправить много элементов коллекции является правильным для Аксапты? |
|
21.04.2021, 22:47 | #13 |
Участник
|
Цитата:
Сообщение от mazzy
Я имел в виду, что Аксапта (как endpoint) инициирует процесс подготовки и отправки данных в другую Аксапту (другой endpoint). В WCF это означает Аксапта должна заполнить коллекцию с элементами и вызвать какой-нибудь осмысленный метод для этой коллекции.
для какого-нибудь другого брокера это будет нечто похожее. Аксапта готовит данные в специальном формате и вызывает что-нибудь осмысленное для этих данных. И WCF, и другие брокеры, насколько я знаю, все имеют ограничение на размер сообщения. Размер сообщения меньше, чем размер всех элементов. вопрос - как правильно готовить, чтобы отправить (передать) свои данные другому endpoint. современный правильный ответ - использовать потоки. но в Аксапте нет потоков. какой способ отправить много элементов коллекции является правильным для Аксапты? - Как из первой аксапты писать сообщения в исходящий поток WCF? - Как во второй аксапте читать сообщения из входящего потока WCF? Как эта задача решается на .net: https://weblogs.asp.net/cibrax/strea...rred-execution Если непосредственно из аксапты нельзя это повторить, то наверняка можно сделать сборку-адаптер, который будет удобно использвать из аксапты. Нет? |
|
|
|