Относно PATH в FTS заявки на открито

Използвам 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 свойства, всички индексирани, за търсене. Тези обединени търсения имат по-високи разходи от едно? Може би е по-добре да търсите само по един имот, а не по 3-те? Или може би да използвате ИЛИ, а не И за бързи резултати? Как работи SOLR?

Благодаря!


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)


Първо нека започна с това, не съм сигурен какво искате от този въпрос, защото е неясен. Вие не питате как да направите вашата заявка по-добра, вие питате защо една лоша практика (лоша производителност) работи зле за вас.

Направете проучване как да структурирате вашата ECM система, първото нещо, което прави вашия ECM добър е правилният модел на съдържание. Има книги, които ще ви помогнат.

Ако структурирате съдържанието си с папки (Path) и те са важни за вас, трябва да ги добавите като метаданни към вашето съдържание. Ако не сте го направили, тогава трябва да започнете с това.

Добрият модел на съдържание ще може да намира съдържание, където и да е поставено във вашата ECM система. Разбира се, че е лесно да мигрирате файлова система към ECM система и просто да я оставите там, но сте свършили само половината работа.

Заявките за пътя са бавни като цяло, защото използва модел на цикъл и е скъпо. Той е значително подобрен в новия SOLR, но все още не е толкова бърз, колкото нормалното запитване за метаданни.

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