Собственно задачка почистить справочник ДоговорыКонтрагентов в котором уже десятки тысяч элементов

НайтиПоСсылкам() сильно медленноо пашет

Какие есть способы ускорить? Например прямые запросы sql к базе (у нас не MSSQL а PostgreSQL :()
Кто делал подобное?

Многопоточность интересно поможет? Чтобы не одним фоновым (как сча) а пулом.

у меня справочник банковских счетов около 100к, типовая довольно шустро удаляет если транзакция не очень большая, примерно 1000 элементов обрабатывает до 5 минут

Напиши свой запрос и ищи отдельпо таблицам в несколько потоков

(0)+ Причем надо уточнить что нужны не только без ссылок совсем.
Но и надо отбирать для обработки объекты с "почти пустыми" ссылками, на разную бесполезную/ненужную хрень типа служебных РС и непроведенных документов.

(1) В смысле предлагаешь пометить все на удаление а затем попытаться запустить типовое "Удаление помеченных объектов"?

(3) добавь в конфу "критерии отбора" и будет реально быстро

(5) это будет доп индекс по договору везде

(4)+ Пробовал, виснет если помеченных на удаление больше некоторого кол-ва.
Вариант только порциями.
Но тут дурдом что без многопоточности и потом обратно пометку снимать и т.д. короче неудобно.

(6) да, но тут или крестик или труселя

Гм.

Вопрос то был конкретный!

Как по какому критерию параллелить (разбивать на обрабатываемые в одном потоке порции) весь справочник?

Думаю, простым запросом можно сузить список всех элементов справочника до приемлемого числа подозреваемых

(9)+ Тупо реквизит (можно и доп) в который номер потока предварительно записать?

Для ускорения можно не писать туда номер (флаг/признак) если запрос по наиболее частому виду доков выдает результаты например

Еще как можно это дело оптимизировать и ускорить?

(9) по таблице например

(0) Отобрать те, договоры, которых нет в 4 основных видах документов (деньги+, деньги-, товар+, товар-). И уже этот список прогонять через НайтиПоСсылкам()

Я в свое время делал предварительные отборы по шапке документов (там есть индексы и работает быстро) и уже работал с теми кто не попал в тот отбор (остаются к примеру из ТЧ, или РС)

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

(11) делаешь план обмена, каждый узел - это отдельный поток.

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

а в рег заданиях работай по узлам

(13) Ты понимаешь что это не лучше?
Потому что документы перебирать которых под 100к ежемесячно гм

(17) это доли секунды, ибо там уже есть критерий отбора "документы по договорам", попробуй запрос сделай с использование его....

(18) ОК, согласен
Даже если выбрать один вид документов и прогнать за пару месяцев то список для проверки сильно сократится

ВЫБРАТЬ РАЗЛИЧНЫЕ ПЕРВЫЕ 10
    ДокументыПоДоговоруКонтрагента.Ссылка КАК Ссылка
ИЗ
    КритерийОтбора.ДокументыПоДоговоруКонтрагента(&ДоговорНаПроверку) КАК ДокументыПоДоговоруКонтрагента


выполняется 0.125 сек у меня на базе в 80 гигов

(20) а теперь такое нужно для всех договоров

(20) интересно

(20)+ жаль только не все доки в критерий попадают из имеющих реквизит Договор

(20) ты понимаешь как работает критерий отбора?
Это просто составной селект по всем перечисленным метаданным

(23) так я тебе в (3) написал - сделай свой критерий отбора и потом летай :)

(23) но это отсеет весомый кусок - точно заюзанных договоров. и заюзанных многократно, что сильно облегчает работу НайтиПоСсылкам (оно дольше всего работает над построением таблицы всех найденных ссылок).

(23) проще самому запрос составить. И никакие ссылки не искать

НЕ СпрДоговоры.Ссылка в (выбрать договор из всех нужных таблиц)

есть уже обработка на инфостарте, проверил, рили раз в 100 быстрее почистила некоторые справочники, не помню точно, эта или нет
https://infostart.ru/public/557217/

(29) древняя ОФшная штук, где не нашел требуемого функционала

Мне не удалить помеченные, а найти какие бы пометить на удаление ненужные

так все пометить, что осталось - вернуть

(31) издеваешься?

(0) Вроде очевидно: сначала выбрать те, которые используются в основных таблицах запросом (например по таблицам субконто/заказам/взаимоорасчетам).
А потом оставшиеся проверять поиском ссылок порциями. Если во второй части встретятся новые частоиспользуемые таблицы - добавляем их запрос первого шага

(32)+ Хотя тут не типовой удаление помеченных, может и отработает
Типовое виснет о чем писал в (7)

(33) Да уже воткнул КритерийОтбора из (20) и прогресс аж на глазах, так что этого хватит
Только добавил Проведен = Истина

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

это после того, как надыбал эту обработку )

(30) В ИР можно инструментом "Удаление объектов с контролем ссылок". Закидываешь туда весь справочник. Запускаешь контроль и занимаешься своими делами. Через Х минут получишь результат.

Ну а собственно ускорение для твоего частного случая включается флажком "Минимальный поиск".

(38) (39) Для РС Документы по требованию ФНС в БП3 оно правильно отработает?

(40) Она знает ничего о смысле хранимых в регистрах данных. Ты сам должен указать, какие регистры являются мусором (неблокирующие).
Забыл ссылку на фичу (39) указать https://www.hostedredmine.com/issues/938392

Если напишешь отчет с замерами о своем испытании с обозначением наиболее долгих таблиц, то подумаю над добавлением многопоточности.

(41) ОФ в толстом запускать проблематично

(43) Ого. Я думал ты тут серьезную задачу решать надумал. А ты даже запустить и проверить готовый инструмент ленишься - ищешь любое оправдание чтобы не проверять.
Ну тогда тебе точно надо писать свой велосипед.

некоторые (типовые) конфы могут хранить ссылочные данные в хранилище значения

(44) Нет, просто не интересует неподходящий инструмент
Не спорю что ИР штука неплохая но в данном случае она недостаточно гибкая

(45) Мне надо пометить на удаление, чтобы затем типовое удаление помеченных запустить
Так что пофиг

(46) В каком месте ее гибкости не хватает в твоей задаче, ты забыл объяснить, либо я не понял твое объяснение.

(48) Куда там свой код вставлять?
Как сделать многопоточно?

Вот эту штуку что я сча разово делаю массово надо будет в обработку/расширение и в регламентное, чтобы в фоне по расписанию выполнялось
Зачем мне ИР?

(49)+ При загрузке например из клиент-банка создаются куча "Основной договор"
Затем когда у менагеров руки и документы доходят из внешней системы падает (автоматически создается нормальный договор)
Доки на него и бухи затем переносят поступления/списания денег на правильный договор с этого "Основного"
А эти "Основной договор" надо грохать

И таких много каждый месяц

(49) Про регламентное задание (регулярное автоматическое выполнение) ты первый раз упомянул в этой теме. Я не телепат.
Про многопоточность я уже написал, что ее пока нет в (42).
> Зачем мне ИР?
Затем что там есть готовый инструмент для интерактивного решения твоей задачи. Ты его пробуешь. Убеждаешь, подходит он или нет.
Если подходит, то как опытный программист, уверен без особого труда сумеешь сделать на основе него регламентное задание, т.к. код в ИР уже почти весь двусторонний (может выполняться на клиенте и на сервере).

(51) Я не очень любитель тянуть ненужные монструозные библиотеки/фреймворки/сторонние решения для задачи.
Предпочитаю алгоритмы и конкретные какие то решения/наработки брать, понимая что там внутри и как оно работает.
И в любой момент могу переписать как надо, не матерясь на чужой непривычный код.

(49) нету смысла в многопоточно на стороне 1с ибо скуль сам многопоточно сделает

(0) >>Многопоточность интересно поможет? Чтобы не одним фоновым (как сча) а пулом

Поможет, я делал так. Одно фоновое обрабатывает один объект метаданных (чтобы избежать конфилктов блокировок). Общее время замены ссылок определяется временем замены в самой большой таблице. Пока пыхтит замена на большой таблице, в других фоновых заданиях проскакивает замена по меньшим объектам

Самыми тормозными местами окажутся самые здоровые регистры накопления и регистр бухгалтерии. Ибо для каждого набора записей будут толкать итоги

(53) ты представляешь себе трудозатраты на реализацию универсальной скульной замены ссылок в таблицах? "Внезапно" выяснится, что есть всякие там итоги, планы обмена, какие-то особые случаи по данным, которые тоже нужно аккуратно обыграть. Овчинка выделки не стоит, потратишь месяцы на написание скульной замены (с реализацией всех нюансов), а выигрыша по производительности особого не получишь

(56) тс не нужна замена ссылок вроде.
Задача стоит найти неиспользуемые

(57) и решается она 1 запросом

(57) "Собственно задачка почистить справочник ДоговорыКонтрагентов"

Запрлс из (28) максимум мин за 10 отработает
(59) а где тут замена? Ветку то почитай дальше заголовка

(60) >>Запрлс из (28) максимум мин за 10 отработает

Разве что на карликовой базе.

>>а где тут замена? Ветку то почитай дальше заголовка

И что по-твоему будет делать ТС с найденными ссылками? Любоваться на них?

(0)1.мочи порционно... сегодня сколько-то, завтра ещё сколько-то...
2. параллельно? -  да! если проца ресурсов хватает - параллель! тем более что задача прекрасно параллелится.

Если задача тупо проверить, используется ли где-либо ссылка на договор, то тем более не нужно заморачиваться с прямыми запросами. НайтиПоСсылкам() умеет работать по конкретным объектам метаданных. По каждому нужному объекту метаданных можно запустить отдельное фоновое задание

(63) ты опять ничего не прочитал. Найти по ссылкам работает слишком медленно и таки ищет связные ссылки, что в данной задаче совершенно излишне

(61) ссылки не используются - можно удалять

(64) какие ещё связные ссылки? НайтиПоСсылкам() можно ограничить конкретными объектами

(66) А смысл? Оно станет работать чем запрос к одному полю одной таблицы?

(66) а что по твоему делает метод найти по ссылкам?

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

(67) смысл в меньшем количестве кода

(68) примерно то же, что будешь делать ты вручную: генерирует селекты по полям таблиц, в типах которых есть искомый тип

(70) вот только оно все ссылки выберет, а они не нужны
И на это съест и времени и памяти

(71) ты уж определись. То ты в (28) предлагаешь резмотать к чертям все ресурсы сервера БД, то начинаешь экономить на спичках

(72) Ты утверждаешь, что найтипоссылкам будет менее ресурсоемко? На примере одной таблице, допустим регистр бухгалтерии

(72) я предлагаю не тащить их на клиент.

НайтиПоСсылкам сделает тоже что и (28) плюс все найденные ссвлки вытащит на клиента

(73) менее ресурсоемко чем что? Профит от НайтиПоСсылкам в простоте использования. Не надо кидаться писать много кода и заниматься оптимизацией там, где это явно не требуется

(74) найти по ссылкам ничего не тащит на клиент, этим занимаетя резработчик

(75) совсем не то же

(76) профиь в скорости на пару порядков наверное

(77) абсолютно голословное утверждение

(76)  >> Не надо кидаться писать много кода и заниматься оптимизацией там, где это явно не требуется
Мы сейчас про задачу в (0) говорим? В ней требуется оптимизация? Много кода это запрос к 1 полю одной таблице?

(79) кода конечно много будет ибо запрос нужно собирать

(79) да, НайтиПоСсылкам гораздо проще использовать, чем врукопашную собирать запросы

(80) Если база бухгалтерская - бери таблицу субконто, если нет - пара таблиц взаиморасчетов + заказы. 99% договоров будут здесь отсеяны.
(81) Проще когда не знаешь где искать, но ты предлагаешь ограничивать по таблицам и тут разницы в сложности уже никакой

(82) разница в сложности кода будет большая

(83) написать составной запрос не сложная задача

Но и вообще задачи оптимизации не бывают простыми.
Написать многопоточную штуку будет далеко не просто

(84) ну, в 500 строк кода может быть уложишься. Когда через НайтиПоСсылкам и 50 строк кода было бы за глаза

(86) Ну запросы - это много строк. Никакой сложности там нет.

(87) и ради чего ты собрался делать лишнюю работу?

(88) десяток нажатий в конструкторе? Очевидно чтобы не ждать недели, когда отработаю стандартные механизмы с поиском всех ссылок, которые мне собственно и не нужны.

(89) ты собрался писать универсальный многокилометровый запрос? Там десятком нажатий в конструкторе не обойдёшься. И откуда у вас вообще страх, что поиск по ссылкам работает медленно?

(90) в (0) это прямым текстом сказано

(91) уверен, в (0) речь про поиск вообще по всей БД, без ограничений

(90) ты собрался писать универсальный многокилометровый запрос?
нет, речь конкретно про (0) и мой запрос описан в (82)

(93) а остальные как проверять?

(94) найти по ссылкам без ограничения метаданных

Накидал обработку по поиску одним запросом.
Получилось всего 170 строк. Отрабатывает примерно 1 мин на номенклатуре. База среднего размера
https://drive.google.com/file/d/1CBzki0Hqn2GyxgyXvf7IxmEcf38XYGyA/view?usp=sharing

не ищет по регистру бухгалтерии и исключает ведущие измерения в рег. сведений

(96) мысль хорошая, да. сам так делаю.
но вот структура запроса не достаточно оптимальна, имхо.

(98) планы обмена нет смысла проверять

(99) а что можно оптимизировать?

(102) согласен, требуется полировка.
Но лучше день потерять, потом за 5 мин долететь

(103) для начала убрать слово ВСЁ из инструкции объединить (чтобы раздублить список).
во вторых, сложить найденное в ВТ, а потом использовать ВТ как фильтр. индексировать ВТ.
подозреваю, инструкция "НЕ В ()" будет медленнее, чем если таблицу справочника левым соединить с ВТ и взять ВТ.Номенклатура ЕСТЬ NULL

это умозрительно пока, но есть такая чуйка.

(104) запрос без все аналогичен запросу со вме + операция группировки

Гм товарищи вы какую то сферическую фу в вакууме начали обсуждать
У меня просто реквизита заведена в которые я пишу проверено ли и какой результат
И да никаких ВТ и прочих соединений, простейшие запросы идут по уменьшению вероятности
Когда вероятность (ссылка в очень редком документе) становится уже совсем тупо НайтиПоСсылкам()

(96) базу положить само то! Оно на раз-два положит сервер БД, и не учитывает множество нюансов при поиске ссылок. Поздравляю, ты "всего за 170 строк кода" изобрел нелепое подобие НайтиПоСсылкам()

(101) для начала стоит изучить, как работают запросы