Почему время поиска зависит от количества найденных результатов?

[hammet]

Почему время поиска зависит от количества найденных результатов?

В самом примитивном варианте выполняем поиск по FULLTEXT полю таблицы, в которой 300 000 записей. Выполняется 2 запроса, первый считает количество найденных результатов, а второй извлекает данные с LIMIT по 10 строк на страницу.
Но наблюдается такая закономерность - при малом количестве найденных результатов время поиска занимает 0,09 секунды, при количестве, допустим, 160 000 результатов - 4-5 секунд.

 

[HraKK]

Читай про реализацию FULLTEXT

 

[hammet]

HraKK да читал я, давно правда, так ты хочешь сказать это нормальное явление для FULLTEXT поиска?

сейчас освежу память.....

-~{}~ 13.11.07 15:45:

EXPLAIN показывает что индекс используется при любом числе результатов....ЗЫ - я когда то слышал что-то про ограничение в 20%....

 

[akd]

правильно слышал.
ни один индекс не будет использоваться при результате 160/300.

 

[hammet]

хм...
напрашивается такой вывод - если у меня в таблице будет 1'000'000 записей, то при каждом поиске будет выполняться проход по всей табилце???

 

[HraKK]

hammet
Нет.
Индексы не используются тогда когда в выборку попадает ~30%(точно не помню посмотрите в мане) от общей суммы рядов.

 

[Gas]

Имхо, при fulltext поиске индекс используется всегда (если это не boolean search без индекса). ~30% - это ограничение для btree (hash ?) индексов, а цифра 50% говорит не об индексах, а о

words that are present in 50% or more of the rows are considered common and do not match

hammet
ну а чего ж ты ожидал, индексы чуда не делают, их эффективность тем выше - чем меньше записей подпадает под условие. Сделай свой stop list слов, в котором будут слова, которые присутствуют в таком большом количестве документов.

 

[hammet]

Gas
сделан stop words list, все слова для поиска собраны в отдельгное поле и обработаны стеммером, как и поисковый запрос. Вырезаны предлоги, спецсимволы, вобщем все что может создатл лишний "вес" для индекса.....

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

 

[Gas]

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

а почему прийдётся менять всю концепцию? всё тот же fulltext, только по отфильтрованным данным. Я ж не говорю что плохой, его релевантность лично мне нравится больше чем у sphinx'а.

 

[hammet]

Gas
менять, потому что уже сейчас при результатах 160 000 из 320 000 записей поиск занимает 2 сек.
И, как я заметил, время поиска растет пропорционально количеству результатов....
Какой есть выход для large data sets в MySQL?
в любом случае будут запросы при которых придеться сканировать все строки....сколько же займет это времени при 30 млн. записей?
ЗЫ разве что производить поиск по нескольким серверам синхронно

 

[Gas]

при 30 млн. записей

не знаю, если планируются такие объёмы, я бы не стал тратить время на mysql fulltext. Тот-же сфинкс, например, имеет нативный Distributed searching. Но я могу ошибаться, с удовольствием послушал бы как "папы" тюнят fulltext под такие объёмы

 

[hammet]

похоже действительно стоит попробовать sphinx, если кому-то еще интересна данная проблема, вот статья от Петра Зайцева
http://peter-zaitsev.livejournal.com/12809.html?thread=41993

 

[Sad Spirit]

Автор оригинала: hammet
насколько я знаю википедия работает на MySQL
а там поиск очень достойный

вот именно потому что они не используют MySQL'евский поиск, он у них и достойный. ЕМНИП, у них там унутрях Lucene.

 

[hammet]

кстати, я выяснил из-за чего тормозил FULLTEXT поиск, после отключения ORDER BY relevance DESC, putdate DESC поиск сократился с 2 сек до 0,0096 сек

я в шоке.....

но нужно теперь что-то делать с сортировкой....
может быть ALTER TABLE t1 ORDER BY putdate DESC?
а на релевантность забить о_О

У кого нибудь есть идеи по поводу оптимизации filesort?

 

[nail]

Re: Почему время поиска зависит от количества найденных результатов?

Автор оригинала: hammet
В самом примитивном варианте выполняем поиск по FULLTEXT полю таблицы, в которой 300 000 записей
... при количестве, допустим, 160 000 результатов - 4-5 секунд.

Такое вряд ли соптимизируешь.
Сфинкс, кстати, в подобных случаях просто урезает результат до N строк (N по умолчанию 1000)

 

[Gas]

hammet
ну ты даёшь, explain же нужно первым делом смотреть.
по существу сказать особо нечего, кроме разве что ссылки об очередных странностях mysql'а.

 

[hammet]

у меня еще один вопрос......
[sql]
SELECT COUNT( * ) AS found
FROM `t1`
WHERE MATCH (
fullsearch
)
AGAINST (
'+объявлен'
IN BOOLEAN
MODE
)
[/sql]

Результат: 161354 из 322271 записей
Время выполнения: 3.4158 сек

EXPLAIN говорит:
id: 1
select_type: SIMPLE
table: t1
type: fulltext
possible_keys: fullsearch
key: fullsearch
key_len: 0
ref:
rows: 1
Extra: Using where

вроде бы индекс используется, но почему key_len=0??? изза чего такая задержка?

ЗЫ Использование SQL_CALC_FOUND_ROWS увеличивает время запроса в 2 раза....

 

[Gas]

hammet
я не уверен что можно как-то ускорить этот запрос. Похоже key_len=0 всегда для fulltext поиска.
То что SQL_CALC_FOUND_ROWS увеличивает время запроса это понятно, а вот что оптимальней SQL_CALC_FOUND_ROWS или ещё один запрос для получения количества - мнения разошлись. У Зайцева есть статья на эту тему, но читал что в разных ситуациях у одних быстрее первый вариант, а у других второй (ссылки сходу не вспомню).

 

[nail]

Нормальный результат, mysql _перебирает_ все эти 161354 строчки. Могло быть еще хуже.

 

[hammet]

один отчаянный обратился к девелоперам
http://bugs.mysql.com/bug.php?id=3166
занятно

-~{}~ 15.11.07 18:14:

продолжаю тему тут, может найдется решение....
http://forum.mysqlperformanceblog.com/s/m/2205/#msg_2205