Одна проблема с вашей схемой состоит в том, что любые повторяющиеся строки будут иметь повторяющийся хеш; Вы никогда не сможете определить, когда одна из этих строк была добавлена или удалена
Очень хороший момент, но не проблема. Повторяющаяся строка является дубликатом, и все дубликаты удаляются на следующем этапе обработки. Так что да, вы правы, но это не проблема.
Ссылка "diff" выводит меня на страницу с описанием того, что я предполагаю, является приложением?
Нет ссылки на скачивание, нет кода на любом языке ... Что мне здесь не хватает?
Некоторые из вас говорили о гранулярности уровня байтов. Это не нужно. требуется только гранулярность на уровне строки, потому что если что-либо в строке было изменено, вся строка (запись) должна быть обработана повторно, так как любое изменение в строке влияет на всю строку.
Таким образом, мы сравниваем строки размером около 1000 символов (без двоичного кода) в двух файлах (текущий снимок и вчерашний снимок), каждый из которых составляет примерно 1 метр.
Таким образом, используя безопасный хеш, такой как SHA256 (MD5 имеет коллизии и по сравнению с ним медленнее), я могу обрабатывать около 30 МБ / с на своем ноутбуке HO. Сервер, конечно, будет проходить через него намного быстрее.
Таким образом, если файл имеет 1 ГБ, создание всех файлов занимает около 33 секунд, а чтение файла 1 ГБ с использованием памяти страниц Windows занимает около 30 секунд. Не ужасно
Теперь у нас есть два массива хэшей, представляющих строки в каждом файле.
Если мы сортируем их, мы можем теперь использовать бинарный поиск, поэтому мы перебираем наш путь по новым хэшам файлов, ища совпадения в хешах старых файлов. Если мы не найдем его, эта строка будет добавлена в файл изменений.
Имейте в виду, что книга строк (устаревшая база данных) неизвестна во всех аспектах. Нет гарантии порядка строк, местоположения изменений, типа изменений.
Рекомендации по чтению вперед за страницей хороши, но предполагают, что два файла находятся в порядке smae до первого изменения. Это не может быть предположено. Линии (строки) могут быть в любом порядке. Также выбор произвольного размера блока нарушает гранулярность строки. Для выполнения этой задачи строки неизменны.
Из этой превосходной ссылки на загрузку invrementa:
Захват сравнения файлов: этот метод также известен как метод дифференциальных снимков. Этот метод работает, сохраняя до и после изображений файлов, которые имеют отношение к хранилищу данных. Записи сравниваются для поиска изменений, а ключи записей сравниваются для поиска вставок и удалений. Этот метод наиболее подходит в случае унаследованных систем из-за того, что триггеры обычно не существуют, а журналы транзакций либо отсутствуют, либо находятся в собственном формате. Поскольку большинство устаревших баз данных имеют некоторый механизм для выгрузки данных в файлы, этот метод создает периодические моментальные снимки, а затем сравнивает результаты для создания записей изменений. Конечно, все проблемы статического захвата присутствуют здесь. Дополнительная сложность связана с проблемой сравнения целых строк информации, а также идентификации и сопоставления ключей. Этот метод сложен по своей природе и, как правило, нежелателен, но в некоторых случаях может быть единственным решением.
Это наиболее актуально здесь:
По мере того, как мы переходим в область хранения терабайтных данных, возможность перестраивать хранилище данных с нуля по ночам пойдет по пути динозавра. Логический и эффективный подход к обновлению хранилища данных включает некоторую форму стратегии постепенного обновления.
Так что, я думаю, я на правильном пути? Индекс btree не позволил бы получить преимущество?