О PATH в запросах FTS alfresco

Я использую Alfresco 4.1.6 и SOLR 1.4.

Для поиска я использую fts_alfresco_language и метод searchService.query.

И в моем запросе я ищу по PATH, TYPE и некоторым пользовательским свойствам, таким как направление, телефон, почта и т. Д.

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

Я читал, что в версии 1.4 solr использование PATH в запросе — плохая идея. А лучше избегайте этого и используйте только TYPE и ключ и значение свойства.

Но у меня 2 вопроса...

  1. Почему PATH увеличивает время отклика? Это не помощь? У меня более 1000 основных папок в корне репозитория. Если я укажу папку, в которой solr может искать, почему это не отфильтрует результаты и даст мне худшее время отклика, чем если бы я этого не указывал? Или есть другой способ сказать, чтобы решить основную папку, чтобы уменьшить результаты, а затем выполнить остальную часть запроса?

  2. Когда я ищу по пользовательским свойствам, я использую для поиска 3 или 4 свойства, все проиндексированные. Эти объединенные поиски имеют более высокие накладные расходы, чем один? Может лучше искать только по одному свойству, а не по трем? Или, может быть, использовать ИЛИ, а не И, чтобы быстро получить результаты? Как работает СОЛР?

Спасибо!


solr alfresco
person Jordi    schedule 07.07.2015    source источник
comment
Поскольку вы используете выпуск Alfresco Enterprise, почему бы просто не позвонить в службу поддержки Alfresco и не попросить о помощи? Они специалисты в этом!   -  person Gagravarr    schedule 07.07.2015
comment
Что ж, я предпочитаю спросить здесь и узнать мнение разработчиков, которые встречаются с этой проблемой. Я предполагаю, что есть различные ответы на проблему, и я хочу знать больше точек зрения, и говорить об этом не только для меня, для ведома людей, которые читают этот форум. Я уверен, что многие люди сталкиваются с этой проблемой и нуждаются в поиске по определенному пути, но чтение, которое помещает путь в запрос, не является хорошей идеей. Мне нравится знать причину и альтернативу поиска внутри пути, если это необходимо.   -  person Jordi    schedule 08.07.2015

Ответы (1)


arrow_upward
0
arrow_downward

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

Проведите некоторое исследование того, как структурировать вашу систему ECM. Первое, что делает ваш ECM хорошим, — это правильная модель контента. Есть книги, которые вам помогут.

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

Хорошая модель контента сможет найти контент, где бы он ни находился в вашей ECM-системе. Конечно, легко перенести файловую систему в систему ECM и просто оставить ее там, но вы сделали только половину работы.

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

person Tahir Malik    schedule 08.07.2015
comment
Хорошо, спасибо, Тахир. Ну, на самом деле, я хочу улучшить свой запрос. Это причина, по которой я хочу подтвердить, что использование PATH, TYPE и метаданных в одном и том же запросе является плохой практикой. Я читал, что PATH - плохая идея, но хочу знать только причину. Вы это объясните: используйте петлевые узоры, а это дорого. Я представил себе такой сценарий... Я хочу найти человека в красной рубашке, а он живет на очень большой улице с миллионами домов. Я не понимаю, как возможно, что обыскать человека в красной рубашке на этой улице быстрее, чем обыскать человека в красной рубашке в этом доме. - person Jordi; 09.07.2015
comment
Другими словами... Сказав Альфреско путь, по которому он может искать элемент, можно уменьшить количество мест для поиска с миллиона шансов до сотни. Даже шаблоны циклов, я не могу представить, как это не быстрее. - person Jordi; 09.07.2015
comment
да, но, как я уже сказал, вам нужно исправить вашу модель контента. Просто обновите свою модель контента для человека, добавив дополнительный дом, затем запустите одно исправление в вашей текущей системе, которое прокрутит весь репозиторий и добавит дом в качестве дополнительного поля метаданных для человека. В следующий раз вам просто нужно искать Type:man and shirt:red и house:streetx. Во-вторых, исправить ваше решение, чтобы в следующий раз, когда мужчина войдет в дом, метаданные автоматически добавлялись;) - person Tahir Malik; 09.07.2015
comment
Ок, спасибо! Я понимаю. Я пытаюсь объяснить наш случай. Наш пользователь может положить документы куда хочет, указав путь в параметре. Но с ограничением. Первая часть пути будет userCode/год/месяц, а остальная часть пути свободна, создавая подпапки, которые они хотят. Перед загрузкой документа я ищу, существуют ли определенные уникальные метаданные, а затем проверяю, существует ли этот путь, и создаю его, если нет. Может быть, существует весь путь или его часть. - person Jordi; 09.07.2015
comment
Я ищу метаданные с запросом и без PATH: как мы говорили раньше, нет проблем. Я могу добавить метададу в свою модель контента с помощью этого userCode и использовать эту метададу в своем запросе. Таким образом, результаты становятся более строгими без использования PATH. :) - person Jordi; 09.07.2015
comment
Но для второй задачи создайте путь, если он не существует... Я устанавливаю указатель на узел и спрашиваю каждую папку, существует ли новая папка. И идти к детям или создать его, зависит. Я использую для этого API-интерфейс alfresco, для позиционирования узла и повторения внутри дочерних элементов. Представьте теперь, что я добавляю метаданные в свою модель контента на каждом узле с путем. API работает быстрее, чем если бы я использовал поисковый запрос, или лучше использовать запрос для каждой папки, чтобы узнать, существует ли она с таким же именем? - person Jordi; 09.07.2015
comment
О, и еще один вопрос... Я еще не использую аспекты в своей модели контента. Я читаю, что могу использовать аспекты в запросе. Это даст мне результаты быстрее? Например, если у меня есть в моей модели 3 метадаты: A, B и C. И в моем запросе я ищу по A: значение И B: значение И C: значение, лучше и быстрее, если я сгруппирую эти 3 метадаты по аспекту и я ищу: (@asp\\A:value AND @asp\\B:value @asp\\C:value)? - person Jordi; 09.07.2015