07.04.2021, 10:22 | #7 |
Модератор
|
Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.
Давай уточню сначала по CDC: из БД 2009 в БД 2012 скорость репликации будет очень высокой, если RecID будет выделяться самой БД. Но если Rec будет выделять AOS, то он станет бутылочным горлышком, а если еще и номерные серии надо заполнять... То же самое и с брокерами. В принципе, за счет распараллеливания и оптимизации размера пакетов - то хоть 1К в секунду, хоть миллион. Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью. Абстрагируясь от DAX, то если мы говорим про надежную доставку, то это - запись на диск. Таким образом надо смотреть на пропускную способность сети и скорость записи на диск. Например, для AWS это 40 000 IOPS составляет при пакете в 16 КБ и 20 000 IOPS при 32 КБ Таким образом, я не вижу проблемы в передаче 100500 сообщений. Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля. Если доверить эту задачу БД, а служебные поля заполнять автоматом по некому шаблону механизмами БД, то данная проблема снимается. Но вряд ли этим снимается проблема последовательной обработки сообщений. С Уважением, Георгий |
|
|
|