Оптимизация скорости поиска номенклатуры запросом по наименованию. #780206

Справочник номенклатура относительно не большой 255 000 товаров. Заметил, что поиск по наименованию запросом составляет от 1 до 2 секунд. Поиск производим по справочнику списку номенклатуры. Вот запрос (время выполнения 1-2 секунды): Этот запрос (время выполнения 2-3 секунды, еще дольше, но это и было понятно, просто пишу для анализа): ВЫБРАТЬ     мНоменклатура.Ссылка КАК Ссылка,     мНоменклатура.Наименование КАК Номенклатура ИЗ И мНоменклатура.Ссылка В ИЕРАРХИИ(&Ссылка) Вопрос почему так долго ищет по наименованию? Нет даже мысли как это можно оптимизировать.

Планируем 500 000 товаров, скорость еще думаю раза в 2 упадет при таком раскладе.

Причем у нас есть сайт 50 000 товаров, скорость самого запроса MySQL по наименованию десятые или сотые секунды.

А что если через черный запрос?

Это как?

Запрос через com-объект СКЛ

Извиняюсь что вопрос в чужой теме, но можно ссылку на статью как это использовать?

Пока не рассматривали.

Интересный вариант конечно.

Провел эксперимент. Попробовал поможет ли менеджер временных таблиц. Загнал туда весь справочник номенклатуры, а потом искал по нему. Скорость одинаковая, я удивлен. Вот весь код из обработки:

Вот обработка сама:

"подобно" никак не соптимизируешь, если в начале стоит "%"

за исключением формирования специфического индекса по лексемам, как это сделано в механизме полнотекстового поиска

Как то так:

А смысл переносить на прямые запросы? Узкое место тут - seq scan по таблице без индекса, ибо like начинается с "%".

ищи не каждую номенклатуру по отдельности, а весь список скопом.

Как понять весь список?

ты каждый раз ищешь по 1 номенклатуре? Надо искать сразу много?

Операторы ищут, например по названию книги, в отбор может попасть несколько книг.

Вопрос про менеджер временных таблиц. Когда делаешь ПОМЕСТИТЬ, данные где хранятся в памяти сервера или во временной таблице? Вроде помню что во временной таблице в SQL, но не уверен. Если во временной таблице, то понятно, почему скорость не увеличивается.

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

Спасибо, полнотекстовый поиск тоже рассмотрим.

Я бы делал так. Создал регистр сведений с двумя измерениями - Лексема и Ссылка. В подписке на событие "при записи" справочника Номенклатура создаю записи в этом регистре по каждому слову из наименования и ссылке на элемент справочника. Ну и первично обработкой заполнить этот регистр по существующим данным. А дальше, при подборе по слову делаем запрос по измерению регистра, и вытаскиваем ссылку.

Отличный велосипед реализации полнотекстового поиска :-)

Классный вариант, спасибо ))

Эх 19 августа ИТС закончился, только наверно в конце сентября новый оформим.

а вообще вся информация по полнотекстовому поиску есть в СП

Собственно да, почему для полнотекстового поиска не использовать механизм полнотекстового поиска? И еще - 1с умеет сама по части строки искать (даже без полнотекстового поиска), попробуй в свойствах справочника на закладке "Поле ввода" установить способ поиска строки "Любая часть". Может 1с при этом какой-то более оптимальный запрос сгенерирует.

"Может 1с при этом какой-то более оптимальный запрос сгенерирует." *facepalm

У нас обычные формы, способ поиска строки "Любая часть" это для управляемых по-моему.

Запрос написал топикастер. 1С не будет переписывать запрос, да и что тут перепишешь в like? Правильно подсказывают механизм полнотекстового поиска платформы использовать. На мой взгляд это самый оптимальный вариант.

ну почему сразу facepalm, 1с должна хотя бы ограничение на количество записей поставить. Плюс есть тот же CONTAINS, который вроде бы побыстрее LIKE работает.

Кому должна?

а насчёт contains мНоменклатура.Наименование ПОДОБНО "%Тщес%лави%"

Ты наверно и планы этих запросов смотрел?

чудес не бывает. Это физика этого мира, ничего больше

like %ЗначениеПоиска - это один в один аналог ситуации пропущенного поля поиска в составном индексе.

там план проще некуда <1C> Index Seek(         OBJECT:(             [db].[dbo].Справочник.Номенклатура.[Индекс по Наименование, Ссылка] AS [T1]), </1C> в нем нечего совершенствовать и ускорять. Если надо быстрее, придумывайте что-то с аппаратной частью. Ну, или еще лучше - глубоко-глубоко задумываться, а надо ли на самом деле часто такой лайк на сервер отправлять.

Сделать маленький регистр, где будет измерение - Ссылка на товар, и ресурс - Наименование. По меньшей таблице быстрее отработает.

Еще можно добавить "ПЕРВЫЕ 10". А остальные результаты - выдавать по требованию через отдельную кнопку "Показать еще".

Это поможет, если первые 10 найдутся быстро, а если в самом конце, то нет

если у ресурса не включить индексирование, то будет только дольше. А, если включить, то будет так же

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

Запрос из сабжа генерит index seek по индексу, в котором только два поля. У справочника по индекс (наименование+Ссылка) генерится платформой автоматом, если наименование длиннее нуля. А вот ресурсы в индекс РС попадают только после включения у них индексирования. Соответственно, если у твоего РС будет индекс (Наименование+Ссылка), то в лучшем случае он даст точно такой же план и точно такую же производительность. В худшем - это будет table scan без производительности вообще.

Можно реализовать алгоритм с разбиением слова на буквы, с ссылками и указанием позиции в слове, и простым сгенерированным запросом вытаскивать нужную ссылку путём подсчёта их количества, но таблица будет очень большая

Да, наверное ты прав :) Только наверное index scan ?

В рабочем запросе у нас стоит Первые 10, только цифра другая, я об этом в писать не стал, так как на производительность это не влияет. Пробовали по всякому. Подобный вариант описан в , но я понял он работать не будет. Так как ускорение можно добиться если использовать "=", а там тоже придется использовать ПОДОБНО.

Индекс скан - это вообще не использование индекса. Просто этот индекс оказался кластерным

можно пойти не прием: переименовать все номенклатуру в стиле магистра йоду. Ключевые слова в начало

Подобный эксперимент я проводил, Если брать 2 реквизита Ссылка и Наименование, то от количества колонок в таблице из которой идет выборка, время выполнения запроса не сильно зависит. Время выполнения запроса увеличивается если выбирать не 2 поля Ссылка и Наименование, а допустим еще 10 других.

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

Смотрю туда очень редко, так как примерно представляю какой 1с для SQL запрос подготовила. Повторюсь примерно.

Чисто фантазия: все наименования склеить в большую  хранящуюся в памяти строку, разделенную на блоки спецсимволом, и на неё натравить: или просто поиск подстроки, а если недостаточно - регулярные выражения. Но чтобы они возвращали номер блока. Но при изменении наименования надо строку перестраивать.

если  ресурс не индексировать, то будет table scan, т.к. не будет индекса, по которому можно было бы искать

В памяти в каком месте? У нас еще есть сайт на 1С Битрикс, там технологии позволяют хранить кэш в памяти. В 1с даже не слышал о таких возможностях. Временные таблице, хранятся на диске.

"Так как ускорение можно добиться если использовать "=", а там тоже придется использовать ПОДОБНО" ПОДОБНО тоже использует индекс, если искать с начала слова.

То есть с начала поля, не ставить в начале выражения %

Понял, спасибо, проверил, быстро работает. Тогда да это вариант хороший.

любые оптимизаяйца должны начинаться с вопроса: "назачем это, что нуждается в оптимизации, вообще нужно?" Т.к. идеальная оптимизация объекта будет тогда, когда объекта вообще исчезнет , а функция его будет выполняться

Обычно ищут части слов - соответственно - наименование разбит на слова и уже искать по таблице слов, потом полученную выборку из таблицы слов (там ссылки на номенклатуру) выбрать из таблицы номенклатуры. Проблемы будут начинаться, если кто-то сокращает слова - но это уже никакой поиск не найдёт. Также можно повыкидывать из поиска все знаки препинания - и проверять на них уже полученную предварительным поиском номенклатуру. Если пользователь указывает несколько слов, разделённых пробелом - то сначала можно искать каждое слово, а потом по результату выбрать те, где первое идёт перед вторым (если, конечно, пользователю это важно).