Вход | Регистрация
 

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

Быстрое сравнение больших таблиц двух баз
Я
   vi0
 
23.01.21 - 15:19
Коллеги, поделитесь, кто чем пользуется для сравнения больших объемов данных двух баз 1с при сверках, для регрессионного тестирования и т.д,
Интересны быстрые реализации, например когда представления ссылок извлекаются только для результата сравнения, а сама сверка выполняется по уидам и т.п.
   GANR
 
1 - 23.01.21 - 15:28
(0) Простые самопальные обработки, запросы в консоли, ХМЛ-ки сравниваю как текстовики, чтобы проводки сравнить в 2 базах. От случая к случаю надо проверять разные вещи - универсального инструмента нет и быть не может.
   mistеr
 
2 - 23.01.21 - 17:20
(0) Для сверки нужно сравнивать не таблицы БД, а отчеты.
Для регрессионного тестирования не нужны большие объемы.

Давай твой конкретный сценарий, найдется конкретное решение. А натягивать сову на глобус не надо.
   Вафель
 
3 - 23.01.21 - 17:31
так мердж ведь
   Вафель
 
4 - 23.01.21 - 17:31
берёшь 2 таблицы , сортируешь по ключу и вперёд
   vi0
 
5 - 23.01.21 - 21:06
(4) вопрос каким инструментом, чтобы сверить _к примеру_ обороты регистра в двух базах
   H A D G E H O G s
 
6 - 23.01.21 - 21:19
(5) Делай регистр копию в базе, в него через XML заливай движуху из 2 базы через XML обмен и потом запросик.
   H A D G E H O G s
 
7 - 23.01.21 - 21:20
Ну или ВнешниеИсточникиДанных
   RomanYS
 
8 - 23.01.21 - 21:47
(5) отчет - mxl - сравнить файлы
Это если надо быстро различия глазками увидеть
   Garykom
 
9 - 23.01.21 - 22:02
(5) выкидываешь нужные поля из своих регистров своих двух баз во внешнюю sql базу (1С на чтение шустра достаточно)
внешнюю sql можно использовать sqlite, mssql и прочие на свой вкус
   Базис
 
10 - 24.01.21 - 15:08
1С, Файл - сравнить файлы.
   vde69
 
11 - 24.01.21 - 15:19
что значит "большие"? это 10 тыс или 10 лямов или больше?
   vi0
 
12 - 24.01.21 - 19:03
(11) сотни мегабайт
если на 32 клиенте выбирать то запрос падает по нехватке памяти
   1CnikPetya
 
13 - 24.01.21 - 20:05
(0) У нас есть такая система регресс-тестов. Тупо выгружаем в текстовые файлы и их сравниваем автоматом. Если есть расхождения, то уже смотрим их суть глазками.

Но это реально тупик в развитии тестов, так как с таким подходом 99% ресурсов и времени уходит впустую. Лучше все же переходить на конкретные сценарии с той же Vanessa. Но это дорого в части ресурсов на разработку тестов и сопровождение.
   Bigbro
 
14 - 25.01.21 - 04:31
если таблицы действительно большие и идентичные - можно хэшировать и сравнивать только хэш.
у нас только в таком режиме получилось сравнить таблицы в сотни гигабайт между разными городами.
   GANR
 
15 - 25.01.21 - 11:06
(10) Использую иногда, но выложить файл в ГИТ, а потом поверх него другую версию положить мне больше нравится
   GANR
 
16 - 25.01.21 - 11:07
потому что в рамках одной строчки последовательности анализируются, а не тупо различающиеся строки выводятся
   Timon1405
 
17 - 25.01.21 - 11:42
(5) пару раз пользовались http://catalog.mista.ru/public/276275/ от ildarovich, отлично работает
   vi0
 
18 - 25.01.21 - 15:10
(13) как всегда, ресурсы либо там тратятся либо тут
   vi0
 
19 - 25.01.21 - 15:12
(17) сейчас не могу скачать, там по уидам сравнение идет?
   TormozIT
 
20 - 25.01.21 - 16:23
Для сравнения таблиц еще есть инструмент в ИР "Сравнение таблиц"

http://devtool1c.ucoz.ru/index/sravnenie_tablic/0-62 (свежий скриншот https://i.imgur.com/TThTRLs.png )
Не знаю насколько он быстр относительно аналогов, но гибкость большая.
Сотни гигибайт через него не сравнивал, но сотни гигабайт вполне комфортно сравнивать.
   TormozIT
 
21 - 25.01.21 - 16:24
(20) Сотни мегабайт сравнивал. В нем НЕ потоковое сравнение.
   Timon1405
 
22 - 25.01.21 - 16:36
(19) там кейс использования(описан в статье) например в сравнении с вчерашней копией чтобы узнать что изменилось, быстрота реализации достигается не за счет упаковки ссылок.
какой смысл сразу тащить все ссылки, если по факту нужны только ссылки по расхождениям в ресурсах, нужно сначала найти их. ссылки извлекаются (ЗначениеИзСтрокиВнутр) только на этапе когда найдено расхождение в количестве.
   TormozIT
 
23 - 25.01.21 - 16:44
Когда требовалось сравнивать огромные идентичные регистры бухгалтерии, выгружал его в файл в одной базе и использовал автоматизированное потоковое сравнение с БД в другой базе. Если процесс сравнения прерывался по какой то причине, то регламент его восстанавливал и он шел дальше. Конечно это далеко не секунды, как у знаменитого Ильдаровича, но работало надежно и без прямого соединения между базами.
   vi0
 
24 - 25.01.21 - 16:55
(22) интересно, наверное как первичный фильтр, на наличие ошибок, т.к. суммы могу все таки меняться не изменяя итогов
напомнило эту публикацию  http://catalog.mista.ru/public/1109393/
   vi0
 
25 - 25.01.21 - 16:56
(23) выгружал как отчет mxl?
что подразумеваешь под потоковым?
   vi0
 
26 - 25.01.21 - 16:57
(14) хэширвали все поля записи?
   TormozIT
 
27 - 25.01.21 - 16:57
(25) Нет. Выгружал собственной выгрузкой результат запроса в XML в оптимизированном для сравнения виде. Потоковое - когда файл целиком не загружается в память и читаем его через скользящее окно.
   vi0
 
28 - 25.01.21 - 16:58
(8) идеально конечно когда на выходе разница, 1сники недокрутили маленько
   TormozIT
 
29 - 25.01.21 - 16:59
При наличии соединения между базами соглашусь - удобнее всего будет использовать механизм внешних источников данных.
   vi0
 
30 - 25.01.21 - 17:00
(27) а как же ты сравнивал если окно скользит? там индекс нужен получается во втором файле
 
 Рекламное место пустует
   Timon1405
 
31 - 25.01.21 - 17:01
(24) там не используются итоги, метод делит КАЖДЫЙ отрезок из получающихся пополам и находит ВСЕ расхождения на любом интервале за O(n*log2(n)) время. в общем, лучше один раз увидеть.
   TormozIT
 
32 - 25.01.21 - 17:04
(30) Позицию в XML отслеживал по номеру считанного элемента верхнего уровня. Файл повторяюсь был только один. Во второй баз считанная из файла порция сравнивалась с БД.
   TormozIT
 
33 - 25.01.21 - 17:06
(32) Элемент верхнего уровня в XML - порция строк таблицы БД, размер которой задавался в настройках.
   TormozIT
 
34 - 25.01.21 - 17:11
Метод половинного поиска, который применяет Ильдарович, кажется эффективен только при малом числе отличий. Если же нужно устранить/выявить различия при ощутимом количестве расхождений, то он будет проигрывать лобовым методам.
   Bigbro
 
35 - 26.01.21 - 06:07
(26) да, хэш по всем полям, размер около 5% от исходных данных для прокачки итоговый составил.
это без отсылки к 1с, SQL программеры делали, вроде нашли где-то расхождение в итоге.
   TormozIT
 
36 - 26.01.21 - 07:49
(35) И что вы делали с хешами, по которым не нашлось пары?
   Bigbro
 
37 - 26.01.21 - 08:25
(36) по расхождению хэшей смотрели исходные данные, для этого и затевалось, чтобы весь объем не анализировать 1 в 1, было критично по времени.
   vi0
 
38 - 26.01.21 - 15:42
(15) зачем так делаешь?
   vde69
 
39 - 26.01.21 - 15:57
не уверен, что по теме, но все-же оставлю https://wiki.mista.ru/doku.php?id=1c:v8:howto:algoritm_sravnenija_dvux_tablic_po_tekstovomu_polju

разумеется вместо таблиц надо использовать файлы а вместо ключей хеш значимых полей строки
   TormozIT
 
40 - 31.01.21 - 20:00
Добавил в инструменте "Сравнение таблиц (ИР)" режим для сравнения больших таблиц https://www.hostedredmine.com/issues/918476
   vi0
 
41 - 18.02.21 - 07:22
(40) да, интересно
а можно выгрузку и потом сравнение вызвать программно без формы?
   TormozIT
 
42 - 18.02.21 - 08:43
(41) Можно. Там опционально все делается на сервере. Как именно вызывать, думаю довольно быстро поймешь по обработчику нажатия кнопки.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.