Дано: Источник - Приемник , транзакционная репликация(поин то поинт). Необходимо обеспечить минимальное отставание в данных при приемника относительно источника. Транзакционная репликация предполагает строгий порядок применения транзакций. В лоб многопоточную загрузку данных не применить, нужно писать координатор, сортировщик и т.д и т.п.

Обсуждаю с коллегами вопрос относительно доработки многопоточной загрузки(применения данных на приемнике) данных для транзакционной репликации. Понятно что плюсы всего этого значительное ускорение за счет многопоточной загрузки данных.(есть варианты даже для систем с естественным низким уровнем параллелизма) Но возникает вопрос, а нужно ли это кому либо , есть ли вообще такие потоки данных? Понятно один из кейсов когда были простои и накопились большие очереди. Ну а кроме этого в обычном режиме бывает ли так, что один поток не справляется с загрузкой из источника в приемник? То есть по сути в одной системе многопоточно пишут данные , но пишут их в транзакциях с чтениями(то есть не непрерывно, биллинг не в счет) и не всегда многопоточно а с другой стороны агент из очереди непрерывно в один поток применяет данные на приемнике.

Dimitry Sibiryakov, а если конкретней?

invm, ну че то там написано, про потоки:) Как они обеспечивают последовательность применения версий при многопоточности? Надо видимо развернуть завтра и самому проверить, раньше точно не было.

Владислав Колосов, область применения в локальных сетях с хорошими каналами, сеть точно не станет узким местом. Приведу сразу пример - возможность итерационной обрезки БД, обслуживание индексов и статистик на реплике с последующим переключением.(и да я знаю про индексы онлайн и т.п.)

Хм, неужели все так грустно. Для своей репликации мы уже написали. По сути необходим координатор сортировщик.Концептуально нужно в транзакциях проверять ключи на пересечение, далее их сортировать и ставить как можно ниже(именно пересекающиеся, но сортировать все равно нужно что бы деадлоков не было) в транзакции а потом комитить транзакции в порядке как было в источнике. Но есть не заморачиваться с транзакционной целостностью в каждый конкретный момент времени то еще все проще. Рассмотрю пример для 10-и потоков. Берешь например 10 транзакций, объединяешь в одну. Потом сортируешь по признаку Table,UK,Version(TranId) , далее группируешь равномерно по потокам в таком порядке, главное что бы один UK со всеми версиями попадал в один поток гарантированно. И запускаешь в 10-и потоках. В этом случае основное правило не должно быть пересечение между потоками - в таком случае их гарантированно не будет. Единственный момент что в таком случае нельзя запускать новые потоки пока все не отработают, в противном случае возможно пересечение и нарушение хронологии.

Вообщем вот пример примитивной реализации достижение максимального параллелизма(даже естественный равен 1-е) например для задачи ускорения перекачки накопившейся очереди.

Подумываю может сделать примочку реализующий правильный параллелизм для типовой транзакционной репликации?
Но впрочем надо будет проверить, может в новых версиях все сделано правильно.

Добавлю от себя что правильно реализованная процедура сортировки и группировки в потоки ничтожно мала относительно самого времени применения изменений.

Я же написал , про то что данный вариант, самый простой и не предполагает транзакционную целостность до тех пор пока все потоки не выполнятся. Если нужна хронология, необходим вариант описанный ранее.