Полнотекстовый поиск по django: Mysql не так уж и плох? (против сфинкса, ксиапиана) - PullRequest
5 голосов
/ 06 мая 2010

Я изучаю полнотекстовые поисковые системы для django. Он должен быть прост в установке, быстрая индексация, быстрое обновление индекса, не блокировать во время индексации, быстрый поиск.

После прочтения многих веб-страниц я поместил в короткий список: Mysql MYISAM полный текст, djapian / python-xapian и django-sphinx Я не выбрал lucene, потому что он кажется сложным и не имеет стога сена, так как он имеет меньше возможностей, чем djapian / django-spĥinx (например, взвешивание полей).

Затем я сделал несколько тестов, для этого я собрал много бесплатных книг в сети, чтобы сгенерировать таблицу базы данных с 1 485 000 записей (id, title, body), каждая запись имеет длину около 600 байт. Из базы данных я также сгенерировал список из 100 000 существующих слов и перемешал их, чтобы создать список поиска. Для тестов я выполнил 2 прогона на своем ноутбуке (4Go RAM, Dual core 2.0Ghz): первый, сразу после перезагрузки сервера, чтобы очистить все кеши, второй выполняется после того, как проверяется, насколько хороши результаты кеширования , Вот «домашние» результаты теста:

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), и, поскольку мне действительно не нужна функция расширенного поиска, такая как stemming и т. Д. ...

Вот вопрос: что вы думаете о полнотекстовой поисковой системе Mysql против sphinx и xapian?

Ответы [ 3 ]

4 голосов
/ 06 мая 2010

Я не тестировал Xapian, но в прошлом году я проводил презентацию, сравнивая полнотекстовые решения: http://www.slideshare.net/billkarwin/practical-full-text-search-with-my-sql

Sphinx является самым быстрым при поиске.Но трудно индексировать данные, которые поступают постепенно, потому что добавление данных в индекс примерно так же дорого, как создание всего индекса с нуля.

Поэтому некоторые люди поддерживают два индекса Sphinx: один большой индекс с архивированными даннымии один маленький индекс с последними данными.Периодически (например, еженедельно) они объединяют последний индекс в архивированный индекс (объединение двух индексов обходится дешевле) и усекают небольшой индекс, чтобы подготовиться к новой неделе.Это прекрасно работает для чего-то вроде форума, но не так хорошо для вики.

Вы также можете проверить Apache Solr .Это оболочка для Lucene, и она делает использование Lucene намного проще и в то же время более функциональным.Я не знал о Solr, когда разрабатывал эту презентацию.

The Washington Times - пример проекта, в котором Solr используется вместе с Django:

2 голосов
/ 06 мая 2010

Если вы можете обойтись с полным текстом MyISAM, то отлично.Конечно, удобно встроить его в базу данных, чтобы вы могли легко и сравнительно эффективно выполнять поиск с объединением других таблиц.И поиск в логическом режиме великолепен.

Недостатком является то, что он довольно прост в подборе подходящих слов.Понятно, что никакого переноса нет, но также нет специальной обработки дефиса / апострофа, и минимальная длина слова по умолчанию и стоп-лист являются чрезмерно чрезмерными.(Когда программное обеспечение думает, что «howbeit» - это типичное слово, беспокойтесь!)

Хуже всего: конечно, это исключительно для старого и неприятного MyISAM, поэтому он не будет хорошо сидеть в ваших таблицах InnoDB.(Вы используете InnoDB, верно?)

1 голос
/ 06 мая 2010

Вы также можете рассмотреть SphinxQL , который объединяет простоту использования полнотекстовых возможностей MySQL с мощью и гибкостью Sphinx.

Инструкция по установке здесь

...