Что быстрее? Поиск в таблице значений, соответствии или прямой поиск в базе? #625065

при загрузке из сторонней ИБ последовательно получаются ИД документы и ИД номенклатуры. в 1с в базе приемнике у справочника Номенклатура есть индексируемый реквизит ИД. Сейчас поиск происходит через НайтиПоРеквизиту. (засунуть все ид из источника в тз и сделать в запросе соединение со справочником нет возможности). Замер производительности показал что НайтиПоРеквизиту - самый длительный по времени. Вопрос. Будет ли быстрее, если предварительно ссылки на номенклатуру и их ИД помесить в таблицу значений и в дальнейшем заместо НайтиПоРеквизиту использовать НайтиСтроку? Или допустим все поместить в соответствие (ИД - ключ) и так же получать из соответствия? поидее в случае с коллекциями - работа будет происходить с памятью, а не с многократными считыванием данных из ИБ? размер справочника примерно 50т. элементов оперативной памяти вагон.

может и быстрее... хотя если строк в загрузке немного то простая загрузка 50К элементов в ТЗ/соответствие займет больше времени чем поиск по реквизиту (засунуть все ид из источника в тз и сделать в запросе соединение со справочником нет возможности - почему? - даже если например дважды источник прочитать?)

У меня в соответствии. В регистре соответствия ИБ приемника и ИБ источника хранится, первый раз идет поиск по регистру и потом в соответствие.

нет бы юзать РС, как все делают...

Делай через кэш, если в кэши не  нашел, тогда НайтиПоРеквизиту + добавить в кэш

а какая разница?

в РС тупо меньше данных и индексировать его можно только по колонке ИД из дальней базы. да и делать доп реквизит в типовой я б не стал (кстати в типовых, ЕМНИП регистр и так есть). А искать лучше получив целиком ТЗ из той базы, а потом подцепив к ней левым соединением данные этой (не важно, в РС они или реквизитом в справочнике). НайтиПоеквизиту или по коллекции в цикле - не лучший вариант.

а как добавить в кэш? З.Ы. не факт что у меня товары по несколько раз считываются. вполне возможно что все ИД встречаются по одному разу за весь обмен... и тогда поидее этот вариант выхлопа не особо даст

да я понимаю что тз и соединение самое оптимальное, но идет считывание хмл, и предварительно я получить ТЗ не могу.

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

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

что мешает преобразовать XML в ТЗ?

в группу ТЗ, если идет загрузка документов с их таб частями...

делай, как я говорю - будет профит

Разумеется, поиск в соответствии самый быстрый. Вроде даже быстрее чем в индексированной таблице значений, не говоря уже об обращении к бд. Но тут долгий процесс как раз инициализация этого соотвествия

к вопросу о кэше - в 8.2 можно сделать общий модуль, который будет автоматом кэшировать возвращаемые значения функций для набора параметров и если там поместить функцию, которая бы искала через НайтиПоРеквизиту или лучше через запрос в таком модуле - то поиск будет осуществляться 1 раз, а потом будет сразу отдаваться резуьлтат. Причем вполне возможно это будет быстрее, чем использование 1совских коллекций для кэширования

Не факт. Каждый раз параметры разные, а значит и кэша не будет

т.е. первый раз пробежаться по хмл и получить номенклатуру в ТЗ, а потом снова пробежать по хмл и выполнить уже стандартный механизм? аха, попробую затестить время инициализации соответствия. О! а ведь точно! Но опять же, это сработает если большая часть ИД будет повторяться. Если же они будут уникальны - то выхлопа не даст

переделал недавно поиск через соответствие... когда его размер достиг 200К элементов и все это дело надо было переезжать на клиента еще - документ в 10 строк грузился 5 минут

ну, хочешь - помести справочник в индексированную ТЗ заранее. только это помещение будет сотни времени съедать. Правильнее сделать вообще без циклов, через

.1 нет, загрузить весь XML в ТЗ или несколько (по количеству ТЧ документов + шапка) (грубо - то, что ты получить должен в итоге), потом эти ТЗ загрузить в запрос и в нем к ним массово прилепить данные из своей базы. Если что-то не нашлось - там да, надо будет подцепить отдельно. .3 будет не медленнее, чем просто поиск по реквизиту, но без начальной инициализации... Надо смотреть, насколько данные будут повторяться в любом случае

Аха, спасибо за подсказки. Сейчас попробую для начала запрос к справочнику с полями ИД и Ссылка выгрузить в ТЗ и проиндексировать, и уже в ней искать через Найти. следующий будет НайтиПоРеквизиту в хешируемом модуле

Даже не в тз а в масссив. И делай запрос на вхождение реквизита в этот массив. Запихивай в соответствие.

я пробовал и так и эдак. Искал по коду, SQL2005, платформа была 8.1. Таблица значений дала прирост в овер 700%. Причем я даже так сделал: у меня был набор ТЗ, в которых хранились индексированные ссылки. Я сначала искал в ТЗ, если не находит уже делал НайтиПоКоду.

Лепил через соответствие. Ускорение было заметно даже на глаз. А Свин меня удвиляет... Это не флейта...

чем удивляю?

тем, что эта тема поднималась на форуме неоднократно. И мной в том числе. А поиск вроде как ещё работает.

ну да. чет ступил. обычно 90% поиском нахожу. а тут чет не догадался.

Не понимаю, чем вас так удивил Вполне нормальный вопрос с ЕГО стороны. Ожидаемый.

твой пост тоже не стал сюрпризом :)

аккумулировал ваши советы, реализовал так: в начале получаю таблицу, индексирую ее, потом при необходимости ищу в ней соответствие по ИД через хешируемый общий модуль :) буду тестить результат

Куевый вывод

Ищем в индексированной ТЗ Нашли - профит Не нашли - ищем в базе Дописываем в ТЗ Профит

если большая часть ИД в обмене уникальна - профита никакого, смотри выше

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

так что извини чувак, поднять свою самооценку тебе сегодня не получится

Со справочником такое катит, а вот если у тебя План обмена ползает - куй. 1) Памяти не хватит 2) Фиг знаешь, что понадобится.

Если совсем прижмет - забаню. Но пока терпит.

если бы у бабки были яйца, она была бы дедкой

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

+ в основном для того, чтобы не становиться объектом удовлетворения для других

на практике профиту было, хоть *опой жуй

а ты ТЗ сразу инициализировал? или накапливал походу работы обработки через НайтиПоКоду?

Девочки, не ссорьтесь

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

ага, тока из всех собравшихся женский ник только у тебя, еслихчо...

"у меня был набор ТЗ, в которых хранились индексированные ссылки", у меня как бы тоже набор в ТЗ :) только сразу

пробовал сразу всасывать всё в ТЗ, на всасывание и индексирование чуть больше времени уходило в итоге, а памяти при этом уходило в разы больше - меня жаба задавила

почему сразу ко всем данным не прилепить ИДы?

вернее ссылки?

Я вот сейчас сам озадачился переносом из семерки в восьмерку и решил сделать в 7 ке поле ref в каждом переносимом виде справочников и документов записывая в это поле УникальныйИдентификатор получая например по оле. И создав описание Схемы опять же через Оле записывать в объекты в XML файл. При этом подходе не нужно ничего искать когда в документах нужно прописывать ref справочников, документов