Коллеги, поделитесь, кто чем пользуется для сравнения больших объемов данных двух баз 1с при сверках, для регрессионного тестирования и т.д,
Интересны быстрые реализации, например когда представления ссылок извлекаются только для результата сравнения, а сама сверка выполняется по уидам и т.п.

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

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

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

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

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

(4) вопрос каким инструментом, чтобы сверить _к примеру_ обороты регистра в двух базах

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

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

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

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

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

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

(11) сотни мегабайт
если на 32 клиенте выбирать то запрос падает по нехватке памяти

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

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

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

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

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

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

(13) как всегда, ресурсы либо там тратятся либо тут

(17) сейчас не могу скачать, там по уидам сравнение идет?

Для сравнения таблиц еще есть инструмент в ИР "Сравнение таблиц"
http://devtool1c.ucoz.ru/index/sravnenie_tablic/0-62 (свежий скриншот https://i.imgur.com/TThTRLs.png )
Не знаю насколько он быстр относительно аналогов, но гибкость большая.
Сотни гигибайт через него не сравнивал, но сотни гигабайт вполне комфортно сравнивать.

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

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

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

(22) интересно, наверное как первичный фильтр, на наличие ошибок, т.к. суммы могу все таки меняться не изменяя итогов
напомнило эту публикацию  http://catalog.mista.ru/public/1109393/

(23) выгружал как отчет mxl?
что подразумеваешь под потоковым?

(14) хэширвали все поля записи?

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

(8) идеально конечно когда на выходе разница, 1сники недокрутили маленько

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

(27) а как же ты сравнивал если окно скользит? там индекс нужен получается во втором файле

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

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

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

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

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

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

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

(15) зачем так делаешь?

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

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

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

(40) да, интересно
а можно выгрузку и потом сравнение вызвать программно без формы?

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

Кстати, а я как раз на днях разбирался в целом с быстрыми ссылками уже для SEO проекта. Они полезны для того, чтобы быстро и максимально компактно ознакомить целевого потребителя с сайтом, товаром или услугами. Потому их использование достаточно популярно и не зря. Кстати, если тоже будет нужно, то я здесь https://seranking.ru/blog/seo/bystrye-ssylki/ о них впервые прочел и теперь использую эти знания на практике. Потому надеюсь, что это было полезно.