Быстрое сравнение больших таблиц двух баз

(0) Простые самопальные обработки, запросы в консоли, ХМЛ-ки сравниваю как текстовики, чтобы проводки сравнить в 2 базах. От случая к случаю надо проверять разные вещи - универсального инструмента нет и быть не может.

(0) Для сверки нужно сравнивать не таблицы БД, а отчеты.
Для регрессионного тестирования не нужны большие объемы.

Давай твой конкретный сценарий, найдется конкретное решение. А натягивать сову на глобус не надо.

так мердж ведь

берёшь 2 таблицы , сортируешь по ключу и вперёд

(5) Делай регистр копию в базе, в него через XML заливай движуху из 2 базы через XML обмен и потом запросик.

Ну или ВнешниеИсточникиДанных

(5) отчет - mxl - сравнить файлы
Это если надо быстро различия глазками увидеть

(5) выкидываешь нужные поля из своих регистров своих двух баз во внешнюю sql базу (1С на чтение шустра достаточно)
внешнюю sql можно использовать sqlite, mssql и прочие на свой вкус

1С, Файл - сравнить файлы.

что значит "большие"? это 10 тыс или 10 лямов или больше?

(0) У нас есть такая система регресс-тестов. Тупо выгружаем в текстовые файлы и их сравниваем автоматом. Если есть расхождения, то уже смотрим их суть глазками.

Но это реально тупик в развитии тестов, так как с таким подходом 99% ресурсов и времени уходит впустую. Лучше все же переходить на конкретные сценарии с той же Vanessa. Но это дорого в части ресурсов на разработку тестов и сопровождение.

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

(10) Использую иногда, но выложить файл в ГИТ, а потом поверх него другую версию положить мне больше нравится

потому что в рамках одной строчки последовательности анализируются, а не тупо различающиеся строки выводятся

(5) пару раз пользовались http://catalog.mista.ru/public/276275/ от ildarovich, отлично работает

Для сравнения таблиц еще есть инструмент в ИР "Сравнение таблиц"

http://devtool1c.ucoz.ru/index/sravnenie_tablic/0-62 (свежий скриншот https://i.imgur.com/TThTRLs.png )

Не знаю насколько он быстр относительно аналогов, но гибкость большая.
Сотни гигибайт через него не сравнивал, но сотни гигабайт вполне комфортно сравнивать.

(20) Сотни мегабайт сравнивал. В нем НЕ потоковое сравнение.

(19) там кейс использования(описан в статье) например в сравнении с вчерашней копией чтобы узнать что изменилось, быстрота реализации достигается не за счет упаковки ссылок.
какой смысл сразу тащить все ссылки, если по факту нужны только ссылки по расхождениям в ресурсах, нужно сначала найти их. ссылки извлекаются (ЗначениеИзСтрокиВнутр) только на этапе когда найдено расхождение в количестве.

Когда требовалось сравнивать огромные идентичные регистры бухгалтерии, выгружал его в файл в одной базе и использовал автоматизированное потоковое сравнение с БД в другой базе. Если процесс сравнения прерывался по какой то причине, то регламент его восстанавливал и он шел дальше. Конечно это далеко не секунды, как у знаменитого Ильдаровича, но работало надежно и без прямого соединения между базами.

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

При наличии соединения между базами соглашусь - удобнее всего будет использовать механизм внешних источников данных.

(24) там не используются итоги, метод делит КАЖДЫЙ отрезок из получающихся пополам и находит ВСЕ расхождения на любом интервале за O(n*log2(n)) время. в общем, лучше один раз увидеть.

(30) Позицию в XML отслеживал по номеру считанного элемента верхнего уровня. Файл повторяюсь был только один. Во второй баз считанная из файла порция сравнивалась с БД.

(32) Элемент верхнего уровня в XML - порция строк таблицы БД, размер которой задавался в настройках.

Метод половинного поиска, который применяет Ильдарович, кажется эффективен только при малом числе отличий. Если же нужно устранить/выявить различия при ощутимом количестве расхождений, то он будет проигрывать лобовым методам.

(26) да, хэш по всем полям, размер около 5% от исходных данных для прокачки итоговый составил.
это без отсылки к 1с, SQL программеры делали, вроде нашли где-то расхождение в итоге.

(35) И что вы делали с хешами, по которым не нашлось пары?

(36) по расхождению хэшей смотрели исходные данные, для этого и затевалось, чтобы весь объем не анализировать 1 в 1, было критично по времени.

не уверен, что по теме, но все-же оставлю https://wiki.mista.ru/doku.php?id=1c:v8:howto:algoritm_sravnenija_dvux_tablic_po_tekstovomu_polju

разумеется вместо таблиц надо использовать файлы а вместо ключей хеш значимых полей строки

Добавил в инструменте "Сравнение таблиц (ИР)" режим для сравнения больших таблиц https://www.hostedredmine.com/issues/918476

(41) Можно. Там опционально все делается на сервере. Как именно вызывать, думаю довольно быстро поймешь по обработчику нажатия кнопки.