Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
Спасибо за статью,
Однозначно в избранное!
Однозначно в избранное!
Сфинкс использую, но что насчет интерграции? Каким образом они объединены?
Аксенов на конференции говорил что недолюбливает этот способ использования (SphinxSE) ))
удобнее всего через sphinxql имхо
sphinxse запросы корявенькие
sphinxse запросы корявенькие
дык можно sql_attr_string успешно делать начиная с какой-то версии
наименее распространенный интерфейс (и через это наименее тестируемый соотв-но)
всякие новые интересные изменения строго в последнюю очередь
кривоватый синтаксис (причем afair спрямить концептуально нельзя)
но мы ж начали обсуждение с удобства, да? :)
вот имхо (имхо) удобнее всего в большинстве случае именно sphinxql
всем понятные запросы, через привычный mysql интерфейс, все привычно и наглядно
всякие новые интересные изменения строго в последнюю очередь
кривоватый синтаксис (причем afair спрямить концептуально нельзя)
но мы ж начали обсуждение с удобства, да? :)
вот имхо (имхо) удобнее всего в большинстве случае именно sphinxql
всем понятные запросы, через привычный mysql интерфейс, все привычно и наглядно
кстати, по поводу SphinxQL.
Насколько я понял, Sphinx реализует сервер MySQL 4?
Я просто из Erlang коннектился к сфинксу этим драйвером github.com/dizzyd/erlang-mysql-driver и получал кучу ошибок т.к. драйвер поддерживает только MySQL 5, пришлось долго разбираться.
Насколько я понял, Sphinx реализует сервер MySQL 4?
Я просто из Erlang коннектился к сфинксу этим драйвером github.com/dizzyd/erlang-mysql-driver и получал кучу ошибок т.к. драйвер поддерживает только MySQL 5, пришлось долго разбираться.
Все несколько затейливее. Мы поддерживаем протокол версии 10, который начиная от версии 4.1 и далее везде, включая 5.x. Ошибки бывают по двум причинам: 1) либо драйвер вместо флагов протокола разбирает еще и текстовый номер версии сервера, зачем-то пытается принимать всякие решения на ее основе, и сходит с ума (это чаще всего); 2) либо наша комбинация флагов оказывается для драйвера шибко неожиданной, и драйвер опять таки сходит с ума. Ну те. драйвера, скажем так, не всегда по одной только публичной спецификации работают и не во всех теоретически возможных случаях корректно ;)
если кстати segfault-ы репортить в трекер, у нас появляются шансы их починить
а если не репортить, не повляются
такой дуализм
а если не репортить, не повляются
такой дуализм
О, пользуясь случаем sphinxsearch.com/bugs/view.php?id=696 — зарепортил, но никто не заревьюил. Проблема все еще актуальна. Если искать по индексу триграмм слово короче 3-х символов, то зависает намертво. Проявляется только в 1.10, в предыдущей версии работало без сбоев.
Интересный костыль для добавления в innoDB функциональности, которая там не нужна.
Для себя я решил давно и прочно, что если нужен поиск по базе, то его нужно делать НЕ средствами базы.
Для мелких таблиц подход из статьи вполне применим, но если нужно искать по полутора гигабайтам, то увы.
Любой полнотекстовый индекс будет весить никак не меньше половины данных.
Как следствие — замедление поиска по мере накопления данных в таблице, блокировки, выход из буфферов и прочие нехорошие вещи.
Абстрагируясь от вышеназванного, хотел бы покритиковать пару моментов. При беглом прочтении видно, что поиск по LIKE не использует индексов (поскольку данные из нескольких колонок конкатенируются вживую). Разумеется, такой запрос будет ужасно медленным. Также в триггерах не нравятся циклы (FOR EACH ROW) — дешевле делать синхронизацию через INSERT INTO mirror_table SELECT * FROM original_table WHERE original_table.id NOT IN (SELECT id FROM mirror_table) и аналогично удаление (обновление останется в цикле, но это обычно достаточно редкая операция).
Для себя я решил давно и прочно, что если нужен поиск по базе, то его нужно делать НЕ средствами базы.
Для мелких таблиц подход из статьи вполне применим, но если нужно искать по полутора гигабайтам, то увы.
Любой полнотекстовый индекс будет весить никак не меньше половины данных.
Как следствие — замедление поиска по мере накопления данных в таблице, блокировки, выход из буфферов и прочие нехорошие вещи.
Абстрагируясь от вышеназванного, хотел бы покритиковать пару моментов. При беглом прочтении видно, что поиск по LIKE не использует индексов (поскольку данные из нескольких колонок конкатенируются вживую). Разумеется, такой запрос будет ужасно медленным. Также в триггерах не нравятся циклы (FOR EACH ROW) — дешевле делать синхронизацию через INSERT INTO mirror_table SELECT * FROM original_table WHERE original_table.id NOT IN (SELECT id FROM mirror_table) и аналогично удаление (обновление останется в цикле, но это обычно достаточно редкая операция).
> Любой полнотекстовый индекс будет весить никак не меньше половины данных.
чисто в порядке бесполезных любопытных фактов, можно довольно ощутимо меньше
у меня навскидку сфинксом при hitless_words=all, stopwords=top100.txt получилось 31% от текста
те. это индекс без позиций слов и с отрезанием top-100 стопов такой получился
сильно зажатый индекс без позиций слов, говорят, до всего-то 7% от текста люди упихивали
зачем он такой реально нужен, конечно, все равно не очень ясно :)
чисто в порядке бесполезных любопытных фактов, можно довольно ощутимо меньше
у меня навскидку сфинксом при hitless_words=all, stopwords=top100.txt получилось 31% от текста
те. это индекс без позиций слов и с отрезанием top-100 стопов такой получился
сильно зажатый индекс без позиций слов, говорят, до всего-то 7% от текста люди упихивали
зачем он такой реально нужен, конечно, все равно не очень ясно :)
Мне казалось что с появлением сфинкса проблема полнотекстового поиска ушла в небытие.
>В типе таблиц MyISAM есть полноценный полнотекстовый поиск данных
>полноценный
O RLY?
>полноценный
O RLY?
Спасибо, интересно.
По оформлению (извините, что придираюсь) — лучше вверху красивую картинку, а ниже цифры.
По оформлению (извините, что придираюсь) — лучше вверху красивую картинку, а ниже цифры.
>> Существует ряд сторонних решений для полнотекстового поиска. Наиболее популярные платформы это Sphinx и проекты на базе Apache Lucene. Их использование лишено смысла при небольших объемах данных (таких как в нашем примере), а иногда просто невозможно в связи с ограничениями (хостер, злой админ, кривые руки и т. д.).
Да, ладно. А предположим у вас в текст в базе лежит словосочетание «красные конфеты». А пользователь на форме в сайте вводит «красная конфета». Как вы средствами MySQL будете обрабатывать эту ситуацию?
Да, ладно. А предположим у вас в текст в базе лежит словосочетание «красные конфеты». А пользователь на форме в сайте вводит «красная конфета». Как вы средствами MySQL будете обрабатывать эту ситуацию?
Это как раз не сложно. Нужно подключить внешний морфологический движок и делать запрос в базу что-то типа — «красный красная красную… конфета конфеты конфету ...» Естественно необходимо правильно выставить весовые коефициенты
Не тривиальное решение.
Не буду говорить за Сфинкс, но в Solr (lucene), это проблема без проблем. Поэтому не лучше ли не изобретать велосипед и использовать нормальный поисковый движок.
Не буду говорить за Сфинкс, но в Solr (lucene), это проблема без проблем. Поэтому не лучше ли не изобретать велосипед и использовать нормальный поисковый движок.
эта проблема решается я хотел сказать
У каждого решения есть свои плюсы и минусы.
Сфинкс хорошо безусловно, но не позволяет организовать поиск в реальном времени.
Lucene — решает проблему реального времени.
MySql Fulltext search — хорош тем, что не нужно ставить ничего дополнительного.
Сфинкс хорошо безусловно, но не позволяет организовать поиск в реальном времени.
Lucene — решает проблему реального времени.
MySql Fulltext search — хорош тем, что не нужно ставить ничего дополнительного.
MySql Fulltext search не является полноценным поиском без морфологического словаря и это есть проблема. Ибо статей подобных этой много. Но вот про морфологический словарь все забывают.
Realtime индексы убогие… Не поддерживают даже поиск по подстроке, стеммеры, морфологию и пр. Т.е. как ввел поисковое слово так его и будет искать. Нужно ручками реализовывать всю обработку (либо при индексировании прогнать текст через морфологическую либу либо при поиске запрос прогнать)
> стеммеры, морфологию и пр.
я аж проснулся
видимо если ее не включать в конфиге, то не поддерживают
а если включать
Z:\work\sphinx\sphinx>mysql -P9306
Welcome to the MySQL monitor. Commands end with; or \g.
Your MySQL connection id is 1
Server version: 1.11-dev (r2691)
mysql> insert into rt values (123,'running','',1);
Query OK, 1 row affected (0.00 sec)
mysql> select * from rt where match('run');
+------+--------+------+
| id | weight | gid |
+------+--------+------+
| 123 | 1500 | 1 |
+------+--------+------+
1 row in set (0.00 sec)
я аж проснулся
видимо если ее не включать в конфиге, то не поддерживают
а если включать
Z:\work\sphinx\sphinx>mysql -P9306
Welcome to the MySQL monitor. Commands end with; or \g.
Your MySQL connection id is 1
Server version: 1.11-dev (r2691)
mysql> insert into rt values (123,'running','',1);
Query OK, 1 row affected (0.00 sec)
mysql> select * from rt where match('run');
+------+--------+------+
| id | weight | gid |
+------+--------+------+
| 123 | 1500 | 1 |
+------+--------+------+
1 row in set (0.00 sec)
Только sphinx. Все эти «встроенные поиски» даже рядом не стоят.
Про триггера и вставку в MyISAM
Cтоит понимать, что транзакция на вставку в таблицу завершится тогда когда отработает триггер.
Триггер, разумеется, сумеет вставить в таблицу данные, и таблица будет залочена.
А вот паралельный запрос уже не сумеет вставить данные. Триггер будет ждать освобождения лока, а транзакция будет ждать триггер.
В общем при таком подходе теряется вся соль возможности паралельной вставки в InnoDB таблицу.
Cтоит понимать, что транзакция на вставку в таблицу завершится тогда когда отработает триггер.
Триггер, разумеется, сумеет вставить в таблицу данные, и таблица будет залочена.
А вот паралельный запрос уже не сумеет вставить данные. Триггер будет ждать освобождения лока, а транзакция будет ждать триггер.
В общем при таком подходе теряется вся соль возможности паралельной вставки в InnoDB таблицу.
А в Postgre кто нибудь работал с полнотекстовым индексом? (Мне не нужно, но просто интересно)
Синхронизация будет обеспечиваться за счет триггеров.
Лучше за счет репликации.
А в чем конкретно настолько продвинутее использовать основную таблицу в innodb, чтобы ради этого городить такой огород с зеркалами в myisam? Ну кроме транзакций, которые в небольших проектах и не особо нужны, атомарных операций myisam вполне достаточно. Ведь речь идет о небольшой проекте если правильно понял?
А кто что может сказать про качественные инфиксные индексаторы под запросы вида LIKE '%text%'?
Что насчет Zend Lucence?
Поскольку на пхп — жалкое и убогое поделие. Достаточно проиндексировать 10-20К документов, чтобы поиск начал занимать 2-3 секунды.
Отличная штука, она меня очень спасла. Использовал правда не Java версию, а зендовский модуль.
У меня была проблема в том, что надо было искать по 8 таблицам, что очень не удобно. Надо писать свой костыль. А Zend Lucene быстро подключил.
У меня была проблема в том, что надо было искать по 8 таблицам, что очень не удобно. Надо писать свой костыль. А Zend Lucene быстро подключил.
Спасибо, отличная статья!
Кармы не хватает, так бы однозначно плюсанул.
Коллеги, я бы хотел осветить одну очень интересную «плюшку» MySQL, а именно использования xPath/XML-деревьев, которая доступна с версии 5.1. Испытал и внедрил в СMS на Zend Framework, название пока говорить не буду, планируется opensource. Получается эдакий аналог MongoDB и сравнительно шустрая скорость выборки. Есть пример работы с этим чудом на PHP. Но вот друзья, кармы не хватает. Я, конечно, не клянчу в открытую, если поможете — опубликую в ближайшую неделю, т.к я очень досконально изучил этот вопрос. Если нет, то опубликую в блоге и в посте по теме запощу линк в комментарии.
Кармы не хватает, так бы однозначно плюсанул.
Коллеги, я бы хотел осветить одну очень интересную «плюшку» MySQL, а именно использования xPath/XML-деревьев, которая доступна с версии 5.1. Испытал и внедрил в СMS на Zend Framework, название пока говорить не буду, планируется opensource. Получается эдакий аналог MongoDB и сравнительно шустрая скорость выборки. Есть пример работы с этим чудом на PHP. Но вот друзья, кармы не хватает. Я, конечно, не клянчу в открытую, если поможете — опубликую в ближайшую неделю, т.к я очень досконально изучил этот вопрос. Если нет, то опубликую в блоге и в посте по теме запощу линк в комментарии.
спасибо за статью. Отличная работа, осталось изложить все в ООП расширить ActiveRecord доп функциональностью и все будет пучком.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полнотекстовый поиск в InnoDB