29.03.2021, 21:46 | #1 |
Участник
|
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?
Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно для простоты предположим, что есть две аксапты, в которых есть WCF мне кажется, что все равно какой версии, но если для ваших рассуждений важно, то зафиксируйте в своих рассуждениях версию. в одной аксапте (назовем ее клиентом) есть огромная коллекция очень важных данных. коллекция - список/массив/мап/контейнер/таблица как передать эти данные в другую Аксапту (назовем ее сервером) через WCF? передавать по одном элементу - слишком много накладных расходов. кроме того, аксапта-сервер будет создавать неявную транзакцию для каждого элемента. что медленно. передавать всю коллекцию - в момент передачи все это богатство превратится в XML и разрвет все внутренние буфера. делить на чанки и передавать чанками по несколько сотен элементов - надо возиться и тоже никакой гарантии, что не разорвет внутренние буфера. наверное было бы идеально передавать в какой-нибудь метод элементы коллекции, а WCF сам бы делил на чанки исходя из своих внутренних резервов. Но я не знаю такого метода. в общем, как правильно передать 100500 элементов коллекции через WCF? ЗЫ а может где-нибудь еще есть такое? не только в WCF... |
|
29.03.2021, 22:47 | #2 |
Модератор
|
__________________
-ТСЯ или -ТЬСЯ ? |
|
29.03.2021, 22:55 | #3 |
Участник
|
спасибо.
только это и есть разбивать на чанки, насколько я понимаю. только в особо извращенной форме. во-первых, этот сервис только для запросов к базе. во-вторых, нужно указать размер страницы причем в записях. а откуда ж я знаю какой размер оптимальный. в-третьих, query service только слушатель (т.е. кто-то может запросить query service, а query service этому кому-то может вернуть данные в ответ). если же нужно передать данные другому, то нужно как-то организовать callback. что то еще удовольствие. в-четвертых, "другая сторона" будет слишком много знать о деталях реализации, если будет использовать query service. и тут дело даже не в безопасности, а в том, что комплекс из двух систем, которые используют слишком много знаний о деталях реализации друг друга становится слишком мнонлитно-хрупким. Последний раз редактировалось mazzy; 29.03.2021 в 23:03. |
|
02.04.2021, 20:31 | #4 |
Участник
|
Похоже что это вопрос больше для форума разработчиков WCF-сервисов.
Или для stackoverflow, например.
__________________
Дмитрий |
|
06.04.2021, 04:45 | #5 |
NavAx
|
Я бы не ограничивался конкретной технологией. В зависимости от конкретных требований, можно подобрать более подходящие инструменты.
С какой периодичностью нужно данные передавать? Вызовы синхронные? Насколько универсальным и масштабируемым должно быть решение? Используется ли middleware? Кто будет публиковать данные и кто будет подписчиками?
__________________
Isn't it nice when things just work? |
|
06.04.2021, 09:39 | #6 |
Участник
|
Цитата:
Можно разной толщины сообщения послать и точно узнать, разорвет или нет. Если сервер свой, то и с настройками поиграться. По умолчанию вроде 64Кб лимит на сообщение. Кстати не сказано, элементы однородные или размер может варьироваться. Цитата:
наверное было бы идеально передавать в какой-нибудь метод элементы коллекции, а WCF сам бы делил на чанки исходя из своих внутренних резервов. Но я не знаю такого метода.
Для очень больших объемов есть стриминг https://docs.microsoft.com/ru-ru/dot...-and-streaming Стриминг как раз автоматически делит данные на куски, но подойдет ли он в конкретном клиенте? Просто непонятно о чем точно идет речь. Если WCF указан как фреймворк, а не конкретный продукт, тогда можно широко подойти. Или это про AIF? |
|
06.04.2021, 09:54 | #7 |
Участник
|
Цитата:
универсальность - это и есть вопрос для простоты будем считать, что middleware не используется. Но хотелось бы понять как middleware влияет на ответ. а как влияет на ответ кто будет подписчиком? причем 64Кб несжатого xml. что очень немного. Цитата:
Цитата:
Сообщение от AlexMoskvichev
Для очень больших объемов есть стриминг https://docs.microsoft.com/ru-ru/dot...-and-streaming
... Просто непонятно о чем точно идет речь. Если WCF указан как фреймворк, а не конкретный продукт, тогда можно широко подойти. Или это про AIF? но хотелось бы понять как это влияет на ответ. можем и свой middleware сделать Последний раз редактировалось mazzy; 06.04.2021 в 10:00. |
|
06.04.2021, 11:12 | #8 |
NavAx
|
Цитата:
Если интеграция ассинхронная, а издатель и подписчик сидят в одной сети, то вообще можно данные выставить как view и пусть таскает когда и сколько ему нужно. Можно вытягивать данные в DW, поближе к подписчику. Если синхронная, то к предыдущий варант сопровождается сообщением:"данные брать здесь" Обмен данными можно наладить десятками разных способов. Все зависит от конкретики. P.S. Универсальное решение писать дело увлекательное, но неблагодарное. Много я их видел, одни лучше, другие хуже. Но выкупаются те, которые созданы школьными друзьями.
__________________
Isn't it nice when things just work? |
|
06.04.2021, 11:23 | #9 |
Участник
|
Цитата:
предположим, что все под нашим контролем. Собственно в этом и вопрос. как правильно управлять очередью? Цитата:
middlware любой. для начала пустой набор. можно добавлять что угодно. как правильно? Цитата:
в аксапте view скорее для чтения. и уж точно НЕ для удаления. и кроме того, чтобы использовать view конечные точки должны слишком много знать друг о друге. разве не так? точно так же как и в QueryService, которые Vadik предлагал выше. можно я повторю: Цитата:
а зачем? Цитата:
Серьезно?! Ну, дай вводную "я говорю о таких условиях" и расскажи как правильно в этих условиях. собственно тема об этом. Цитата:
Могу только повторить свое первое утверждение в моем первом сообщении в этой ветке: |
|
06.04.2021, 11:44 | #10 |
Модератор
|
А не подойдет ли для этой задачи очередь сообщений (RabbitMQ или даже Debezium) + пакетная обработка?
1 мастер система или 2? Т.е. если справочники вбиваются в систему 1, и они должны точно отображаться в системе 2 - это один вариант. Если и в системе 1, и в системе 2 ведутся справочники, которые должны быть синхронизированы, включая контроль совпадений - это уже другой вариант, посложнее. Просто Change Data Capture не подойдет, так как разные системы и разные RecID. Тогда просто кроликом гоняем изменения во временную таблицу. А раз в час или в 5 минут запускаем пакет, в котором делаем импорт средствами системы и удаляем (помечаем) обработанную запись. Надо предусмотреть не только добавление, но и изменение / удаление данные, что тоже возможно посредством передачи пакетов. Вопрос в гарантированной доставке. Возможно, раз в неделю / месяц стоит полностью синхронизировать справочники. С Уважением, Георгий |
|
06.04.2021, 12:03 | #11 |
Участник
|
Цитата:
и ты конечно имеешь в виду, что пакетная обработка в обеих конечных точках (ax2012, ax2009). но тут возникает вопрос следующего уровня - а как правильно обращаться к этим брокерам сообщений из Аксапты? причем и с брокерами нужно как-то решать тот же вопрос про 100500 элементов коллекции. или где-то решен вопрос как передавать коллекции через брокер? или в брокер можно передавать элементы по одному и не париться о накладных расходах? Последний раз редактировалось mazzy; 06.04.2021 в 12:08. |
|
06.04.2021, 12:24 | #12 |
Модератор
|
Цитата:
Цитата:
Цитата:
Цитата:
С Уважением, Георгий |
|
06.04.2021, 12:43 | #13 |
Модератор
|
Это сугубо мое личное мнение, но по-моему "правильно" было бы не запрашивать "огромную коллекцию из 100500 элементов" "раз в 5 минут" а держать ее в обеих системах, синхронизовывать изменения и работать с ней в обеих системах локально ?
__________________
-ТСЯ или -ТЬСЯ ? |
|
06.04.2021, 12:57 | #14 |
Модератор
|
Вадим, привет! А как ты представляешь себе синхронизацию таблиц? Что с RecId делать? Я потому и предложил через таблицу, и потом пакетной, чтобы она уже добавила все потроха которые будут уникальны для разной инсталляции. Более того, если это разные системы, как указано в исходном сообщении, то и сама структура таблиц может различаться.
С Уважением, Георгий |
|
06.04.2021, 13:35 | #15 |
Участник
|
Цитата:
Цитата:
таблица - это права на той стороне понятно, что можно. но является ли это правильным подходом? а как правильнее? Цитата:
Цитата:
мне кажется, что "по одному" - будут слишком большие накладные расходы с любым брокером сообщений. либо я чего-то не знаю. да, знаю, что для решения задачи все нормальные инструментарии обзавелись стримами. но в вопросе указано, что обсуждаем Аксапты или правильным является "сделать собственные dll'ки, которые снаружи работают со стримами, а аксапте отдают объекты по одному"? и чтобы эти собственные dll'ки работали в адресном пространстве аксапты... https://coub.com/view/12jn53 Цитата:
я не стал акцентировать, когда увидел прошлый твой ответ, но обрати внимание, что в вопросе было "передавать", а ты постоянно отвечаешь "запрашивать" ты считаешь, что это одинаковые действия? почему? и понятно, что регулярно раз в 5 минут 100500 элементов передаваться не будут. но при пиковых нагрузках элементов будет много. собственно об этом и вопрос: как правильно передавать много элементов коллекции? Последний раз редактировалось mazzy; 06.04.2021 в 13:42. |
|
06.04.2021, 13:59 | #16 |
Модератор
|
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир к Informatica PEC, Oracle GoldenGate, Qlik Data Integration и Debezeum. Вариантов, увы, нет.
Все эти продукты могут в режиме, близко к реальному, переносить данные из таблицы А в одной среде к таблицы В в другой. Не все могут переносить структуру таблиц - обычно только поля (только Qlik Attuniy умеет, кстати). Почти все (кроме, кажется, Debezeum) умеют маскировать выбранные поля. Ни одна не умеет генерить локальный RecId из другой системы. Это означает одно - синхронизировать-то мы можем, а вот доп. обвязку в виде тех же RecID необходимо будет делать силами интегрируемой системы, такой как Аксапта. Я знаю про пакетную обработку, возможно, если и другие пути добавления необходимой служебной информации, но я про них не наслышан. С Уважением, Георгий |
|
06.04.2021, 15:58 | #17 |
Участник
|
В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.
Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа. При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке) Возвращаясь к вопросу. 100500 сообщений по 1Мб (например) это почти 100Гб сырых данных. За какое время их передавать надо и как далеко?. Если проблема в размере сообщений, можно попробовать их сжать при отправке. Или вообще, Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV Или более современно, в parquet Может оказаться вполне быстро и автоматизировать не сложно. Через WCF можно управляющие команды подать, с метаданными файла |
|
06.04.2021, 16:18 | #18 |
Модератор
|
Цитата:
Цитата:
А как ты представляешь себе синхронизацию таблиц?
Цитата:
Что с RecId делать?
Цитата:
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир
__________________
-ТСЯ или -ТЬСЯ ? |
|
06.04.2021, 16:46 | #19 |
Модератор
|
Дело в том, что сторонние решения реплицируют таблицу или частично (часть полей), но тогда с системе B поле RecId будет пустое, или целиком, но тогда в системе B поле RecId будет такое же, как и в системе А, что некорректно.
Если можно использовать стандартный транспорт силами DAX, тот же AIF, который возьмет часть данных в А и выгрузить их в В, добавив и заполнив все обязательные системные поля, это круто. Есть такие способы? С Уважеинием, Георгий |
|
06.04.2021, 17:29 | #20 |
Участник
|
Цитата:
Сообщение от George Nordic
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир к Informatica PEC, Oracle GoldenGate, Qlik Data Integration и Debezeum. Вариантов, увы, нет.
мы уже давно во взрослом мире. и как я говорил, решение уже есть. давай лучше поговорим как правильно? и как правильно делают упомянутые тобой решения? |
|
|
|