Полнотекстовый поиск django: Mysql не настолько плохо? (по сравнению со сфинксом, xapian)
Я изучаю механизмы полнотекстового поиска для django. Должно быть просто установить, быстро индексация, быстро индексировать обновление, не блокируясь при индексации, быстро искать.
После чтения многих веб-страниц я вставил короткий список: Mysql MYISAM fulltext, djapian/python-xapian, и django-сфинкс, я не выбрал lucene, потому что это кажется сложным, ни стог сена, поскольку он имеет меньше функций, чем djapian/django-spĥinx (как полевое взвешивание).
Затем я сделал некоторые сравнительные тесты, чтобы сделать так, я собрал много бесплатных книг в сети для генерации таблицы базы данных с 1 485 000 записи (идентификатор, заголовок, тело), каждая запись приблизительно 600 байтов длиной. От базы данных я также генерировал список 100 000 существующих слов и переставил их для создания поискового списка. Для тестов я сделал 2, работает на моем ноутбуке (4Go RAM, Двухъядерные 2.0 ГГц): первый, сразу после перезагрузки сервера для очистки всех кэшей второе сделано juste после, чтобы протестировать, как хороший кэшируются результаты. Вот "самодельные" результаты сравнительного теста:
1485000 records with Title (150 bytes) and body (450 bytes)
Mysql 5.0.75/Ubuntu 9.04 Fulltext :
==========================================================================
Full indexing : 7m14.146s
1 thread, 1000 searchs with single word randomly taken from database :
First run : 0:01:11.553524
next run : 0:00:00.168508
Mysql 5.5.4 m3/Ubuntu 9.04 Fulltext :
==========================================================================
Full indexing : 6m08.154s
1 thread, 1000 searchs with single word randomly taken from database :
First run : 0:01:09.553524
next run : 0:00:20.316903
1 thread, 100000 searchs with single word randomly taken from database :
First run : 9m09s
next run : 5m38s
1 thread, 10000 random strings (random strings should not be found in database) :
just after the 100000 search test : 0:00:15.007353
1 thread, boolean search : 1000 x (+word1 +word2)
First run : 0:00:21.205404
next run : 0:00:00.145098
Djapian Fulltext :
==========================================================================
Full indexing : 84m7.601s
1 thread, 1000 searchs with single word randomly taken from database with prefetch :
First run : 0:02:28.085680
next run : 0:00:14.300236
python-xapian Fulltext :
==========================================================================
1 thread, 1000 searchs with single word randomly taken from database :
First run : 0:01:26.402084
next run : 0:00:00.695092
django-sphinx Fulltext :
==========================================================================
Full indexing : 1m25.957s
1 thread, 1000 searchs with single word randomly taken from database :
First run : 0:01:30.073001
next run : 0:00:05.203294
1 thread, 100000 searchs with single word randomly taken from database :
First run : 12m48s
next run : 9m45s
1 thread, 10000 random strings (random strings should not be found in database) :
just after the 100000 search test : 0:00:23.535319
1 thread, boolean search : 1000 x (word1 word2)
First run : 0:00:20.856486
next run : 0:00:03.005416
Как Вы видите, Mysql не так плох вообще для полнотекстового поиска. Кроме того, его кэш запроса очень эффективен.
Mysql кажется мне хорошим выбором, поскольку нет ничего для установки (я должен только записать маленький сценарий для синхронизации производственной таблицы Innodb с таблицей поиска MyISAM), и поскольку мне действительно не нужна функция расширенного поиска как стемминг и т.д...
Вот вопрос: Что Вы думаете о механизме полнотекстового поиска Mysql по сравнению со сфинксом и xapian?
3 ответа
Я не тестировал Xapian, но в прошлом году я сделал презентацию, сравнивающую полнотекстовые решения: {{1} } http://www.slideshare.net/billkarwin/practical-full-text-search-with-my-sql
Sphinx быстрее всех выполняет поиск. Но сложно индексировать данные, которые поступают постепенно, потому что добавление данных в индекс примерно так же дорого, как создание всего индекса с нуля.
Итак, некоторые люди поддерживают два индекса Sphinx: один большой индекс с заархивированными данными и один маленький индекс с последними данными. Периодически (например, еженедельно) они объединяют последний индекс с архивным индексом (объединение двух индексов обходится дешевле) и усекают небольшой индекс, чтобы подготовиться к новой неделе. Это отлично работает для чего-то вроде форума, но не так хорошо для вики.
Вы также можете попробовать Apache Solr . Это оболочка для Lucene, которая делает использование Lucene намного проще и еще более функциональным. Я не знал о Solr, когда создавал эту презентацию.
The Washington Times - это пример проекта, в котором Solr используется вместе с Django:
Вы также можете рассмотреть SphinxQL , который сочетает в себе простоту использования полнотекстовых возможностей MySQL с мощностью и гибкостью Sphinx.
Инструкции по установке здесь
Отлично, если вы можете обойтись полным текстом MyISAM. Безусловно, удобно, если он встроен в базу данных, чтобы вы могли легко и относительно эффективно выполнять поиск с соединениями с другими таблицами. И поиск в логическом режиме - это здорово.
Обратной стороной является довольно элементарное сопоставление слов. Очевидно, что без выделения корней, но также и без специальной обработки дефиса / апострофа, а минимальная длина слова по умолчанию и стоп-лист являются чрезмерно чрезмерными. (Когда программное обеспечение думает, что «как бы то ни было» - это обычное слово, волнуйтесь!)
Хуже всего: конечно, это эксклюзивно для неприятного старого MyISAM, поэтому оно не будет хорошо сидеть в ваших таблицах InnoDB. (Вы используете InnoDB, верно?)