Глобальный поиск, не ищет штрихкоды

[Favor82]

Такова проблема что при включении глобального поиска (Ctrl+F1) товары ищутся только по ИД товаров, по штрихкодам не ищет. В настроке таблиц для агента данных стоят 2 таблицы для индексации это InventTable i InventItemBarcode. Запускаю индексацию агента данных он индексирует только одну таблицу с товарами а со штрихкодами не индексирует. Дата последней индексации неизменяется. Подскажите что можно сделать или где еще что то наза запустить для полной индексации по штрихкодам.

Axapta 2009 SP1 RL7

[glibs]

Только что проверил. Индексация работает. Номенклатура находится.

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

Ну или у вас кастомизации...

[Favor82]

Где вы имеете ввиду включить индекс? В настройке таблиц я указал 2 таблицы с Товарами и Таблицу со штрих кодами и указал поля.. Запускаю агент данных, нажимаю сохранить и в статусе пишется что Выполняется индексация. После индексации захожу в Таблицы смотрю Таблицу с товарами там стоит сегодняшнее число Обновлено, а в Таблице со штрихкодами ничего. Как еще можно запустить тогда индексацию? Я все делаю через Администрирование/Настройка/Агент данных

[glibs]

Я имел в виду поле "Индекс по тексту".

Я так понимаю вы запустили индексацию в фоновом режиме и не останавливали. А как давно? Или пробовали останавливать? И сколько у вас записей в таблице с номенклатурой?

Вообще индексация работает небыстро. Алгоритм перебирает все записи в таблице последовательно, анализирует указанные текстовые поля (разбирает текст на слова по определенному алгоритму), для каждого из найденных слов вставляет минимум одну запись в таблицу + для каждой записи в индексируемой таблице сохраняется по одной записи для каждого слова в названии таблицы + еще одна строчка с указанием на запись + если находится новое слово, то еще одна запись вставляется.

Если у вас есть представление насколько медленные Аксаптовские функции парсинга текстовых переменных, и насколько быстро в принципе может происходить вставка данных в реляционной СУБД, то можете себе это представить. У меня полная реиндексация порядка 25 тысяч записей в двух таблицах занимала около 20 часов. Правда, алгоритм индексации был насильственно принужден индексировать Memo-поля со средней длинной текста около 500 байт, кажется.

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

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

И если у вас в индексацию попадут таблицы, данные в которых массово добавляются/удаляются/обновляются, то скорость подхвата изменений движком индексации может вас не устраивать или он вообще не будет успевать их индексировать.

Короче возможности движка ограничены. Он не всемогуч. И это не Яндекс.

Скорость индексации в вашем конкретном случае можете попробовать оценить запуская джобы, которые будут подсчитывать количество записей в таблицах SysSearchName, SysSearchPath, SysSearchRef. В первой уникальный список индексированных слов и прочих комбинаций символов, во второй список ссылок на записи, которые индексированы, в третьей связь какие слова в каких записях встречаются.

[dn]

Цитата:

Сообщение от glibs

Правда, алгоритм индексации был насильственно принужден индексировать Memo-поля со средней длинной текста около 500 байт, кажется

Т.е. этот механизм можно использовать для поиска по мемо-полям?

[glibs]

Если в одном месте закомментировать одну строчку кода — то можно.

Но если в мемо-поях вы храните большие объемы данных, то индексация просто заглохнет. Скорость индексаци низкая. Глобальный поиск может быть применен на сравнительно небольшом и относительно постоянном (не изменяемом и не обновляемом) объеме данных. Это не Яндекс, который может искать все и везде.

[Ivanhoe]

Коллеги, а какие задачи вы решаете этим поиском? С тех пор как он появился ни на одном проекте он так и не понадобился (разве что при продаже его можно красиво показать

[AndyD]

Цитата:

Сообщение от glibs

Если у вас есть представление насколько медленные Аксаптовские функции парсинга текстовых переменных, и насколько быстро в принципе может происходить вставка данных в реляционной СУБД, то можете себе это представить.

По-моему, здесь как раз тот случай, когда на сколько бы ни был тормозным x++, но соединение с базой - еще тормознутее

Помимо непосредственно операций вставки в коде еще много поисковых запросов и запросов на удаление.

К примеру, удаление из таблицы sysSearchPath

    delete_from sysSearchPath
        where sysSearchPath.Design     == design     &&
              sysSearchPath.LanguageId == languageId &&
              sysSearchPath.URL        == URL;

Вроде бы, выглядит все хорошо - один запрос, индексы используются.
Но вот только на таблице висит DeleteAction Cascade для sysSearchRef. И тут же дополнительно появляется неявный запрос на выборку из sysSearchPath с последующим удалением из sysSearchRef.

Или запрос

sysSearchName = SysSearchName::findRecId(word, design, languageId);

который вызывается для каждого слова, входящего в индексируемые поля
Опять-же - поиск по индексу, на таблице включено кэширование (Found).
Но если количество слов окажется больше размера кэша (2000 записей для сервера, чего при построении индекса по большим таблицам слишком мало), то запросы уже будут идти не в кэш, а на сиквел. И есть подозрение, что при этом кэш начнет активно обновляться.

В общем, регулярные выражения в Аксапте конечно неторопливы, но основные тормоза, в данном случае, не в них

Что бы убедиться, что проблема действительно в количестве обращений к базе данных, переписал код на использование класса System.Text.RegularExpressions.Regex. По тестам чистого разделения строки на слова производительность этого класса раз в 20 была выше на моей системе, чем TextBuffer, плюс еще сделал кое-какую оптимизацию кода.
Но на итоговую скорость выполнения это сказалось крайне слабо - время выполнения улучшилось максимум процентов на 10

Цитата:

Сообщение от glibs

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

Галка показывает, есть на индексируемой таблице поле ModifiedDateTime или нет. Это дисплейный метод и влиять на него мы может только включением/выключением ModifiedDateTime на таблице
(Просто уточняю на всякий случай)

[glibs]

Честно говоря, от AndyD ожидал бы пост с конкретикой и рекомендациями практика (как ускорить, как сделать лучше), а не вот так вот... Несколько разочарован в этом плане. Например, отказался от URL, перешел на ссылки по RecId — удалось добиться такого-то прироста.

Что касается запросов на удаление и поиск сова, интересным аргументом была бы статистика по затраченному времени на реальной БД в сравнении с той же вставкой. 1 процент, 10 процентов, 50, 90 или 99? А так... даже непонятно это аргумент за или против.

Если предположить что поиск отбирает малую часть измененных записей, которые должны быть переиндексированы, и для каждой переиндексируемой записи одним запросом удаляет все ранее проиндексированные по ней данные используя при этом каскадное удаление, а затем для каждого слова ищет не встречалось ли оно ранее в словаре — довольно оптимально в рамках той реализации, которую выбрали авторы. Даже если словарь не влезет в кэш Аксапты — будет работать кэш на уровне СУБД. У меня при индексировании в данном коде узкого места не было. Да и сколько слов уникальных окажется в одной записи во всех текстовых полях? Несколько десятков? Даже если взять мемо-поля, то несколько сотен. Я ради любопытства книжку целую индексировал когда оценивал производительность. Получилось менее 10 тысяч слов, а точнее комбинаций символов (переносы слов порождали новые слова-половинки, цифры шли за слова, и т.п.). В общем по моему опыту слов в записи не много. Сам был удивлен такому результату. Мног очего познал пока экспериментировал, в общем.

Что касается парсинга текстовых переменных — по моему опыту ощутимо тормозит на строках порядка мегабайтах и более (на очень длинных текстах). Я лишь хотел сказать что если будут индексироваться данные с очень длинным текстом — то проблема может появиться и отсюдова (чтобы те кто не пробовал не имели неоправданных ожиданий). В посте же даже намека нет на размер тестируемой строки или независимость от размера. На мой взгляд 10 процентов — это совсем не "крайне слабо". Там-сям по 10 процентов — так и 50-60 набежит. Впрочем, дело вкуса.

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

[AndyD]

Хм

Мне показались любопытым противопоставление: медленная скорость поиска в Аксапте vs быстрая скорость вставки в базу. Я, кстати, первоначально думал, что дело в этом. По-этому и начал пробовать менять алгоритм поиска. И при этом наткнулся на, в общем-то, небольшое влияние этого фактора на общую скорость индексации.
Прошу прощения, если неправильно понял выделенную фразу, но результат, по-моему, стоил того, что бы об этом сообщить

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

Последнее предложение, честно сказать, вообще не понял Что не так?

[glibs]

Теперь понял. Спасибо.

Фразу "насколько быстро в принципе может происходить вставка данных в реляционной СУБД" нужно понимать так: в реляционной (да и в индексно-последовательной думаю тоже) СУБД вставка данных быстро происходить не может в принципе. По крайней мере если записи вставлять по одной.

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