Там похожий принцип
https://ru.wikipedia.org/wiki/Rsync#Алгоритм Принимающий компьютер разделяет свою копию файла на неперекрывающиеся куски фиксированного размера S и вычисляет контрольную сумму для каждого куска: MD4-хеш и более слабый кольцевой хеш, и отправляет их серверу, с которым синхронизируется.

Сервер, с которым синхронизируются, вычисляет контрольные суммы для каждого кусочка размера S в своей версии файла, в том числе перекрывающиеся куски. Вычисления производятся эффективно ввиду особого свойства кольцевого хеша: если кольцевой хеш байт от n до n + S − 1 равняется R, то кольцевой хеш байт от n + 1 до n + S может быть посчитан, исходя из R, байта n и байта n + S без необходимости учитывать байты, лежащие внутри этого интервала. Таким образом, если уже подсчитан кольцевой хеш байт 1—25, то для подсчета кольцевого хеша байт 2—26 используется предыдущее значение и байты 1 и 26.


insert не мешает, он в конец дописывается, а вот delete мешает, это сдвиг всего что после удаляемого.

Только я не вижу смысла это использовать тут. Сам же говоришь база посторонняя и дерево тебе каждый раз с нуля придется строить. Чем тебе не понравился мой вариант 22075934 получения изменений по локальной копии ?

Еще есть diff , можно им локально получать разницу и ее раздавать.

Да, надо будет ORDER BY ID, т.е. сортировка по первичному ключу, я так и предлагал 22075921 . Чем тебе это не нравится? По ID всегда есть индекс, т.е. получение записей в нужном порядке сервер не нагрузит, в MSSQL по дефолту кластерный индекс по ID, т.е. записи физически упорядочены по ID.

И без разницы в каком месте появится/исчезнет запись, суть в том что из обеих баз будет идти чтение в одном и том же порядке.

Может ты не понял мысль, пример ниже:
Параллельная обработка "select * from MyTable order by id" из оригинала и вчерашней копии
ID Хэш оригиналIDХэш копииСостояние11231123Не менялась2345Удалена36783789Изменена4567Добавлена
Далее все записи с изменившимся состоянием пишешь в файлик, и раздаешь его слэйвам. В файле только изменения, по сути почти журнал транзакций.

Я тоже, но ты же сам написал

для CSV-файлов diff вполне подойдет.

При выполнении ограничений:
1. ID это счетчик
2. delete происходит редко, т.е. дырок в последовательности ID немного, т.е. нет такого 1, 2, 3, 100500, 100501, ...
Т.е. имеем обычный справочник набиваемый руками.

В этом случае удаленные записи можно считать как записи с каким-то конкретным хэшем, например 0, тогда никаких смещений записей не будет, но повторюсь, при больших "дырах" будут кучи нулей в дереве.

PS Этот пост и два выше - это три разных независимых направления, просьба не связывать их меж собой.

Верно

Копия локальная. И это не полная копия, а только (id, hash).

PS Что это за справочники такие что держать их копии дороговато?

Верно, по этой копии расчет изменений и по сети рассылка только изменений

PS Можно еще заархивировать, например в zip