Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
maxythewolf
Member

Откуда: (Ере)ваново, 37
Сообщений: 243
Доброго. Давно сюда не писал...
SQL Server 2008R2.
Таблица с файлстримом в поле varbinary(max) и полнотекстовым индексом.
В ней прилично файлов (полмиллиона размером с полтеррабайта).
Использую поиск contains(field,'"слово*"'). Так вот, заметил, что чем короче слово,
тем медленнее идет поиск, например, "'1с*'" завешивает железяку на минуты, по трем буквам
ищет секунд 10, больше 3-ех уже в пределах секунды.
Вопрос, ограничивать ввод слов пользователю 4 и более буквами или есть чего подкрутить?
Спасибо.
15 июл 13, 12:39    [14566929]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
SergeyPK
Member

Откуда:
Сообщений: 44
maxythewolf
Доброго. Давно сюда не писал...
SQL Server 2008R2.
Таблица с файлстримом в поле varbinary(max) и полнотекстовым индексом.
В ней прилично файлов (полмиллиона размером с полтеррабайта).
Использую поиск contains(field,'"слово*"'). Так вот, заметил, что чем короче слово,
тем медленнее идет поиск, например, "'1с*'" завешивает железяку на минуты, по трем буквам
ищет секунд 10, больше 3-ех уже в пределах секунды.
Вопрос, ограничивать ввод слов пользователю 4 и более буквами или есть чего подкрутить?
Спасибо.

Up.
Тот же самый вопрос. Небольшая вариация + SQL Server 2012.
select * from containstable (table, column, 'link')

(7404 row(s) affected)

SQL Server Execution Times:
CPU time = 47 ms, elapsed time = 211 ms.
Красота!!!
select * from containstable (table, column, '("co*")&link')

(6886 row(s) affected)

SQL Server Execution Times:
CPU time = 49920 ms, elapsed time = 50403 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.

Наплевательски сервер относится ко второму условию в поиске (link).
18 июл 13, 14:23    [14583908]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
SergeyPK
Member

Откуда:
Сообщений: 44
maxythewolf, уважаемый, не нашли способ решить проблему?
Может кто нибудь из форумчан натолкнет на верный путь?
19 июл 13, 12:57    [14589234]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
Glory
Member

Откуда:
Сообщений: 104760
SergeyPK
Наплевательски сервер относится ко второму условию в поиске (link).

Почему это ? У вас же два условия поиска через &. Вы считаете, что если сервер нашел link, то искать ("co*") ему уже необязательно ?
19 июл 13, 13:51    [14589674]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
SergeyPK
Member

Откуда:
Сообщений: 44
Glory
SergeyPK
Наплевательски сервер относится ко второму условию в поиске (link).

Почему это ? У вас же два условия поиска через &. Вы считаете, что если сервер нашел link, то искать ("co*") ему уже необязательно ?

Glory, уважаемый, вопрос в том, что link находится очень быстро. Логично было бы искать "co*" среди найденых. Я готов даже запустить эти селекты как нибудь отдельно. Например 'link' отдельно, а потом среди них искать "co*". Но это не сильно поможет.
19 июл 13, 19:38    [14591680]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31442
SergeyPK
Glory, уважаемый, вопрос в том, что link находится очень быстро. Логично было бы искать "co*" среди найденых.
ИМХО полнотекстовый индекс не строит статистику по словам, не настолько он умный. Так что он ищет соответственно оба множества записей, а потом ищет пересечение.

Если вы точно сами знаете такую статистику, то можно искать только по link, а "co*" среди них искать не с помощью FTS, а обычным WHERE-LIKE
19 июл 13, 19:49    [14591724]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31442
alexeyvg
Так что он ищет соответственно оба множества записей, а потом ищет пересечение.
Ну и тут в поиске есть баг, который я заводил в коннекте, и по поводу которого долго с микрософтом переписывались - слова с * ищутся медленно, там какие то проблемы с транзакциями внутри механизма FTS. Сказали, что не будут фиксить, посколку это будет поправлено в следующих версиях. Вот пока руки не дошли проверить в 2012 :-)

Full-text search slows down dramatically because of the writing into the transaction log when using a prefix term search condition
19 июл 13, 19:55    [14591746]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31442
alexeyvg
Вот пока руки не дошли проверить в 2012 :-)
А, ну да, вы же пишите, что у вас 2012.

То есть забили, как обычно.
Конечно, полнотекстовуму поиску всего 8 лет, разве можно убрать баг, делающий на практике невозможным полнотекстовый поиск по началу слов, это же наверняка программисту чуть ли не день работы!!!
:-)
19 июл 13, 20:03    [14591770]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
SergeyPKHome
Guest
alexeyvg
SergeyPK
Glory, уважаемый, вопрос в том, что link находится очень быстро. Логично было бы искать "co*" среди найденых.
ИМХО полнотекстовый индекс не строит статистику по словам, не настолько он умный. Так что он ищет соответственно оба множества записей, а потом ищет пересечение.

Если вы точно сами знаете такую статистику, то можно искать только по link, а "co*" среди них искать не с помощью FTS, а обычным WHERE-LIKE

WHERE-LIKE не подходит. Поведение должно быть как у FTS т.е. "co*" именно начало слова. Писать свой минипарсер да еще с особенностями некоторых языков? А вот на счет статистики я не уверен 3-х буквенный поиск у нас идет в 10 -20 раз быстрее "coa*", "com*". Да и такой "zx*" быстрее раз в 10.
20 июл 13, 09:42    [14592848]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
SergeyPKHome
Guest
alexeyvg
alexeyvg
Так что он ищет соответственно оба множества записей, а потом ищет пересечение.
Ну и тут в поиске есть баг, который я заводил в коннекте, и по поводу которого долго с микрософтом переписывались - слова с * ищутся медленно, там какие то проблемы с транзакциями внутри механизма FTS. Сказали, что не будут фиксить, посколку это будет поправлено в следующих версиях. Вот пока руки не дошли проверить в 2012 :-)

Full-text search slows down dramatically because of the writing into the transaction log when using a prefix term search condition

As we discussed personaly, Sundaram is investigating this issue..
Не сочтите за расизм :D
20 июл 13, 09:49    [14592854]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
SergeyPKHome
alexeyvg
пропущено...
Ну и тут в поиске есть баг, который я заводил в коннекте, и по поводу которого долго с микрософтом переписывались - слова с * ищутся медленно, там какие то проблемы с транзакциями внутри механизма FTS. Сказали, что не будут фиксить, посколку это будет поправлено в следующих версиях. Вот пока руки не дошли проверить в 2012 :-)

Full-text search slows down dramatically because of the writing into the transaction log when using a prefix term search condition

As we discussed personaly, Sundaram is investigating this issue..
Не сочтите за расизм :D


да какой там

в 2009 году Сундарам начал исследовать... а через год(!) Педро снова успокоил Алексея, что все "чики-пики"

автор
Thanks again,
Pedro
20 июл 13, 11:20    [14592900]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31442
SergeyPKHome
alexeyvg
пропущено...
Ну и тут в поиске есть баг, который я заводил в коннекте, и по поводу которого долго с микрософтом переписывались - слова с * ищутся медленно, там какие то проблемы с транзакциями внутри механизма FTS. Сказали, что не будут фиксить, посколку это будет поправлено в следующих версиях. Вот пока руки не дошли проверить в 2012 :-)

Full-text search slows down dramatically because of the writing into the transaction log when using a prefix term search condition

As we discussed personaly, Sundaram is investigating this issue..
Не сочтите за расизм :D
20 июл 13, 11:22    [14592903]     Ответить | Цитировать Сообщить модератору
 Re: Полнотекстовый поиск contains медленно работает по короткому началу слова  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31442
Winnipuh
SergeyPKHome
As we discussed personaly, Sundaram is investigating this issue..
Не сочтите за расизм :D


да какой там

в 2009 году Сундарам начал исследовать... а через год(!) Педро снова успокоил Алексея, что все "чики-пики"
Не, мы попереписывались, они поискали, разобрались, в чём дело, нашли ошибку. Sundaram - хороший специалист, но что от него зависит? Не программист же решает ,что исправлять, а что нет; видимо, какие то маркетологи решили, что выгоднее не исправлять эту ошибку, а добавить какую нибуть новую фичу в сиквел (ресурсы же ограничены, из 10000 найденных багов и предложений по новым фичам нужно выбрать 100, которые пойдёт в работу).

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

У нас сейчас в продакшене (и далее везде) 2008R2, поэтому я с 2012 много не работаю, пока не успел посмотреть, как всё работает в новой версии, и вообще, насколько поменялся механизм FTS.
SergeyPKHome
WHERE-LIKE не подходит. Поведение должно быть как у FTS т.е. "co*" именно начало слова. Писать свой минипарсер да еще с особенностями некоторых языков?
Ну Что поделать, значит, не подходит...

SergeyPKHome
А вот на счет статистики я не уверен 3-х буквенный поиск у нас идет в 10 -20 раз быстрее "coa*", "com*". Да и такой "zx*" быстрее раз в 10.
Ну а "co*" отдельно медленон ищется?

Собственно, это же и называется "использовать статистику". Если для "co*" много результатов, а для "link" мало, то нужно сначала найти "link", а потом из них искать "co*".
Но я плохо представляю, как устроен этот механизм, особенно для 2012
20 июл 13, 11:34    [14592913]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить