Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 67
1. уберите автооформление и сделайте
2. ...ответственность...
3. Преимущества.
зы плюс в карму
2. ...ответственность...
3. Преимущества.
зы плюс в карму
спасибо. полезная вещ. +1 в карму.
Ждем аналогичного теста, но с 50 000, 50 0000 и 5 000 000 строк. Тогда будет что обсуждать и будут основания для выводов.
Спасибо! У меня один вопрос, можеть быть и не в тему. Но.. Если в базе имеется вот такие данные.
Как будет выглядеть запрос, что бы не искать html теги? Тут у меня в примере только , но можеть быть и другие html теги. Не подскажете как избежать проблему? А то когда искать слово font, запрос вернет мне все поля где есть html тег font.
<font color="#fff"> Blablabla</font>Как будет выглядеть запрос, что бы не искать html теги? Тут у меня в примере только , но можеть быть и другие html теги. Не подскажете как избежать проблему? А то когда искать слово font, запрос вернет мне все поля где есть html тег font.
Тут у меня в примере только
<font>
Нужно завести отдельное поле, в котором будут объединены все поля, по которым нужно осуществлять поиск. В этом поле должен храниться текст, очищенный от html.
Как тут можно теги отдельно сохранить не пойму. Кажеться вы меня не так поняли. Вот например есть cms, пишу новость, html теги разрешены. Добавляем новость:
А тепер в поиске напишем слово spacer.А тепер? Вот что я имел ввиду.
<ul>
<li><a href="#">Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</a></li>
<li><a href="#">Fusce bibendum ultricies lorem.</a></li>
<li><a href="#">Nulla facilisis odio vitae neque.</a></li>
<li><a href="#">Etiam sit amet purus a eros viverra adipiscing.</a></li>
<li><a href="#">Nunc dignissim eleifend turpis</a></li>
</ul>
<br class="spacer" />
</div>
А тепер в поиске напишем слово spacer.А тепер? Вот что я имел ввиду.
Если наименование различных тегов ограниченно, то советую использовать Stopwords list
(http://dev.mysql.com/doc/refman/5.0/en/f…)
(http://dev.mysql.com/doc/refman/5.0/en/f…)
Есть в php функция htmlspetialchars.
в fulltext есть сортировка по релевантности
На сколько я помню, fulltext имел проблемы с русской морфологией. Давно уже не использовал его, надо будет как-то проверить, изменилась ли ситуация.
Стоп-слова можно и в like использовать. (`parent` like 'мама' and `parent` not like 'папа')
Есть ещё и regexp, с которым возможны такие конструкции: `parent` regexp 'мам(а|у|е|ы|ой)'. Его было бы интереснее сравнить с `parent` like '%мама%' and `parent` like '%маму%' and `parent` like '%маме%' and `parent` like '%мамы%' and `parent` like '%мамой%'.
Стоп-слова можно и в like использовать. (`parent` like 'мама' and `parent` not like 'папа')
Есть ещё и regexp, с которым возможны такие конструкции: `parent` regexp 'мам(а|у|е|ы|ой)'. Его было бы интереснее сравнить с `parent` like '%мама%' and `parent` like '%маму%' and `parent` like '%маме%' and `parent` like '%мамы%' and `parent` like '%мамой%'.
LIKE '%чтототам' вообще зло. Оно индекс не использует.
Года 2 назад писал подобный поиск, со словарем. Работает нереально долго, но иногда просто незаменим.
Пожалуй насчет "нереально долго" я соврал, все-же за приемлемое время. Например запрос по 3-м словам, в нескольких таблицах(допустим 5000 записей), в нескольких полях(2-3) занимал не более 5 секунд, на хорошем хостинге. Надо будет поковырять на досуге.
Использовался словарь - примерно 800 000 словоформ, с 2-мя полями "слово/словоформа" для выборки словоформ. Эксперименты по его оптимизации не проводил, хотя там можно все сделать программно из гораздо меньшей базы. Просто по сравнению с самим запросом, выборка из словаря занимает исчезающе малое время.
Использовался словарь - примерно 800 000 словоформ, с 2-мя полями "слово/словоформа" для выборки словоформ. Эксперименты по его оптимизации не проводил, хотя там можно все сделать программно из гораздо меньшей базы. Просто по сравнению с самим запросом, выборка из словаря занимает исчезающе малое время.
"поиск по словам не короче 4-х символов"
Ну это же настраивается. Можно и два символа, только индекс будет больше и тормозить будет сильнее.
Ну это же настраивается. Можно и два символа, только индекс будет больше и тормозить будет сильнее.
Автор, вы осознаете, что LIKE '%...%' - это всегда full scan всей таблицы, а FULLTEXT - нет?
В таблице из миллиона строк о варианте с LIKE речи идти не может, ну а тестировать производительность на таблице в 5000 строк бессмысленно.
PS. Я сам никогда не имел дела с FULLTEXT, если что :)
PPS. "Apache (без дополнительных модулей)" - боюсь даже предположить, почему это релевантно топику.
В таблице из миллиона строк о варианте с LIKE речи идти не может, ну а тестировать производительность на таблице в 5000 строк бессмысленно.
PS. Я сам никогда не имел дела с FULLTEXT, если что :)
PPS. "Apache (без дополнительных модулей)" - боюсь даже предположить, почему это релевантно топику.
В свое время пришлось реализовать поиск по таблице в которой более 7000000 строк. LIKE отрабатывал по ней около 20 минут, в то время как FULLTEXT (IN BOOLEAN MODE) - менее секунды.
Согласен. Fulltext хорош на больших текстах, не на полях в 250 символов.
И в больших текстах он рвет Like как тузик грелку.
Хотя до полноценного поиска на больших размерах не дотягивает.
Советую тем, кому нужен FullTextSearch смотреть в сторону последнего PostgresQL,
в нем модуль ранее известный как tsearch2 теперь часть ядра, всторенный стемминг русского, английского, можно прикрутить словари и т.п.
Специальные индексы GIN и GiST для FullTextSeach, возможность задавать слова с разным весом для заголовков и других частей текста...
На порядок мощнее.
И в больших текстах он рвет Like как тузик грелку.
Хотя до полноценного поиска на больших размерах не дотягивает.
Советую тем, кому нужен FullTextSearch смотреть в сторону последнего PostgresQL,
в нем модуль ранее известный как tsearch2 теперь часть ядра, всторенный стемминг русского, английского, можно прикрутить словари и т.п.
Специальные индексы GIN и GiST для FullTextSeach, возможность задавать слова с разным весом для заголовков и других частей текста...
На порядок мощнее.
У меня таблица с 9.000.000 строк. Колонки id(int), title(varchar)
Запрос (на VDS) типа:
SELECT * FROM `titles` WHERE
title title like '%string1%'
AND title like '%string2%'
AND title like '%string3%'
AND title like '%string4%'
LIMIT 50
4.5800 сек.
В данном случае мне FULLTEXT не подходит так как морфология не важна, а нужна 100% гарантия вхождения искомых слов и 100% результат даже при очень большом результате поиска.
Запрос (на VDS) типа:
SELECT * FROM `titles` WHERE
title title like '%string1%'
AND title like '%string2%'
AND title like '%string3%'
AND title like '%string4%'
LIMIT 50
4.5800 сек.
В данном случае мне FULLTEXT не подходит так как морфология не важна, а нужна 100% гарантия вхождения искомых слов и 100% результат даже при очень большом результате поиска.
Ваш самый быстрый запрос был выполнен за 0,019 сек, сымый долгий за 0,159. По сути - никакой разницы абсолютно. Но сам пост интересен, пишите еще, уважаемый автор!
А можно конкретней про условия испытания? Как запускали, какая операционная система?
Windows Vista, Отдельные скрипты PHP (6 штук) для каждого варианта, высчитывал среднее значение тоже естественно скриптом, причем значения до тысячных не менялись при создании новой БД. Повторюсь, что эксперимент не претендует на чистоту, т.к. не сервер, тем более не виртуальный. Условия так сказать домашние :)
Решал проблему FULLTEXT-ом, когда зашёл в тупик изобретая велосипед умного поиска :)
Больше всего в нем порадовало это приоритеты.
По скорости хочется верить, что таки обгоняет LIKE '%...%', но сам не экспериментировал не знаю.
Больше всего в нем порадовало это приоритеты.
По скорости хочется верить, что таки обгоняет LIKE '%...%', но сам не экспериментировал не знаю.
Сканировал таблицу, вырезал html, приводил все слова в именительный падеж, удалял "обычный язык" - операторы "обычной речи"
Потом результат в другую таблицу( так как на главную MyISAM вешать не охота) и .. просто радоваться :)
Лучше фултекста только создание кишкообразных таблиц вида docuID,wordID ...
Которые по сути дублируют внутрений функционал фултекста, но поддаются какому угодно контролю...
Потом результат в другую таблицу( так как на главную MyISAM вешать не охота) и .. просто радоваться :)
Лучше фултекста только создание кишкообразных таблиц вида docuID,wordID ...
Которые по сути дублируют внутрений функционал фултекста, но поддаются какому угодно контролю...
а как слова приводили в именительный падеж?
1.str_wordcount
2.создаем таблицу слов( 600к слов)
3.выбираем слово, пробуем отрезать и добавлять окончания и ищем это в базе
таким вот методом тыка понимать что это(глагол, прилагательное, существительное)
После чего наличие некоторых окончаний определяет форму слова( забыл как по научному называется, вроде как склонение)
расставляет флаги у слов - какое,что,в каком падеже..
можно использовать.
База такая генериться день :)
Делал для "гиперконтекста"
Бонус - система самособираемая. Даже "падонкофский" язык может просклонять если найдет записи с правильными окончаниями( аффтар, аффтара, аффтару... )
2.создаем таблицу слов( 600к слов)
3.выбираем слово, пробуем отрезать и добавлять окончания и ищем это в базе
таким вот методом тыка понимать что это(глагол, прилагательное, существительное)
После чего наличие некоторых окончаний определяет форму слова( забыл как по научному называется, вроде как склонение)
расставляет флаги у слов - какое,что,в каком падеже..
можно использовать.
База такая генериться день :)
Делал для "гиперконтекста"
Бонус - система самособираемая. Даже "падонкофский" язык может просклонять если найдет записи с правильными окончаниями( аффтар, аффтара, аффтару... )
В образовательных целях:
Для повышения грамотности: «и естественно решающим», «четырьмя», «заваисимости», «рпактически по любым типам полей», «поиске Гугла» и т.д. и т.п.
Для повышения грамотности: «и естественно решающим», «четырьмя», «заваисимости», «рпактически по любым типам полей», «поиске Гугла» и т.д. и т.п.
Бенчить MySQL надо с использованием select benchmark(...), а не php-скриптами, и уж точно не из браузера под апачем, если что.
И full-text index, и like неприменимы на больших объемах данных и важных задачах. Правильный метод - использование внешних поисковых движков типа сфинкса, ну и like для мелких фенечек, которые возникают три раза в год :)
И full-text index, и like неприменимы на больших объемах данных и важных задачах. Правильный метод - использование внешних поисковых движков типа сфинкса, ну и like для мелких фенечек, которые возникают три раза в год :)
Стоило бы подчеркнуть, что это всё только в контексте MySQL. У других СУБД с full-text index всё значительно лучше и нет необходимости во внешних движках, с которыми сложность системы возрастает и теряется возможность проведения комплексных SELECT-ов (полнотекстовый фильтр + доп. ограничения по интервалам и т.п.)
1. нет запросов
2. эти запросы никогда не будут эквивалентны по выдаче, как их можно сравнивать?
2. эти запросы никогда не будут эквивалентны по выдаче, как их можно сравнивать?
мне представляется сравнение двух настолько разных инструментов, как like и match() через fulltext, мягко говоря, странным
функционально fulltext намного богаче, и часто вы сможете like'ми заменить его только написав гору кода.
даже без подключенной русской морфологии прекрасно работает убирание окончаний стеммером Портера в реализации Котерова (найдите яндексом) и замена окончаний на *
fulltext за счет языка запросов, сортировщика по релевантности должен использоваться для решения других задач и на другом уровне.
кроме того, не забудьте о том, что fulltext indexes тормозят вставки. на больших таблицах это немаловажно
если уж вы пишете такой тест, то не стоит сравнивать тупо запуск двух серий запроса, лучше попробовать грамотно сравнить реализацию, скажем, по форуму или хабру поиска через эти дву пути (и то не представляю, как вы like'ом полученную выдачу будете по релевантности сортировать)
на реальных задачах, которые я решал при написании программного макета к диссертации fulltext давал очень хорошее быстродействие на базах в сотни тысяч больших статей, а вот lile %s% на словаре в 100 тысяч слов задумывался очень крепко.
сравнение познавательное, но, простите, слабенькое.
плюсанул вас два раза, пишите еще.
функционально fulltext намного богаче, и часто вы сможете like'ми заменить его только написав гору кода.
даже без подключенной русской морфологии прекрасно работает убирание окончаний стеммером Портера в реализации Котерова (найдите яндексом) и замена окончаний на *
fulltext за счет языка запросов, сортировщика по релевантности должен использоваться для решения других задач и на другом уровне.
кроме того, не забудьте о том, что fulltext indexes тормозят вставки. на больших таблицах это немаловажно
если уж вы пишете такой тест, то не стоит сравнивать тупо запуск двух серий запроса, лучше попробовать грамотно сравнить реализацию, скажем, по форуму или хабру поиска через эти дву пути (и то не представляю, как вы like'ом полученную выдачу будете по релевантности сортировать)
на реальных задачах, которые я решал при написании программного макета к диссертации fulltext давал очень хорошее быстродействие на базах в сотни тысяч больших статей, а вот lile %s% на словаре в 100 тысяч слов задумывался очень крепко.
сравнение познавательное, но, простите, слабенькое.
плюсанул вас два раза, пишите еще.
Мускуле фултекст убогий, используйте сфинкс.
Исследование интересное, спасибо и плюс вам в карму.
Но, имхо, всё-таки не совсем корректно подобным образом сравнивать LIKE и полнотекстовый поиск, т.к. сферы применения всё-таки несколько разные.
Но, имхо, всё-таки не совсем корректно подобным образом сравнивать LIKE и полнотекстовый поиск, т.к. сферы применения всё-таки несколько разные.
Было бы интересно видеть аналогичный сравнительный тест для Postgres.
Мне понравилось. Учитывая, что я фултекст не юзал никогда - автору плюс за просвещение =)
Присоединюсь к большинству, 5 000 записей — и правда маловато.
И запросов нет (
По поводу замеры с помощью PHP тоже двояко, с одной стороны результаты получаются не столь «чистые» как при использовании MySQL Console, но с другой пользователи действительно будут получать результаты через сайт, а не через консоль.
Для чистоты я бы предложил записей сделать побольше на 2-а порядка и результаты, и при помощи консоли, и при помощи PHP.
P.S. 100 запросов раз в секунду — слабая нагрузка, вопросы связанные с «прелестями» поиска появляются имхо на более высоконагруженных, так что я бы выполнял 1 000 (или даже 10 000) с плотностью — 100 / сек.
И запросов нет (
По поводу замеры с помощью PHP тоже двояко, с одной стороны результаты получаются не столь «чистые» как при использовании MySQL Console, но с другой пользователи действительно будут получать результаты через сайт, а не через консоль.
Для чистоты я бы предложил записей сделать побольше на 2-а порядка и результаты, и при помощи консоли, и при помощи PHP.
P.S. 100 запросов раз в секунду — слабая нагрузка, вопросы связанные с «прелестями» поиска появляются имхо на более высоконагруженных, так что я бы выполнял 1 000 (или даже 10 000) с плотностью — 100 / сек.
Добрый день, уточняющий вопрос
Какие именно индексы вы использовали?
По задумке теста ожидается использование:
Но в статье на нашел описание выбранных индексов и могу предположить, что использовались индексы отдельно второй и третей колонок, а не совместный индекс. Если это так — то это может являться причиной, по которой третий тест дал плохой результат.
Добавьте, пожалуйста, список индексов, спасибо!
два из которых использовались для поиска и были проиндексированы FULLTEXT'ом
Какие именно индексы вы использовали?
По задумке теста ожидается использование:
- индекс по первой колонке
- индекс по (первой + второй) колонкам
Но в статье на нашел описание выбранных индексов и могу предположить, что использовались индексы отдельно второй и третей колонок, а не совместный индекс. Если это так — то это может являться причиной, по которой третий тест дал плохой результат.
Добавьте, пожалуйста, список индексов, спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поиск: FULLTEXT или LIKE?