PyLucene не смог

Вы не думайте, я тут потихоньку таки занимаюсь написанием форума, в частности — прикручиванием к нему поиска. Вчера и сегодня пытался сделать это с помощью библиотеки PyLucene. И как вы, возможно, уже догадались, ничего хорошего из этого не вышло... Точнее, я таки заставил это все работать, но по дороге идея обросла слишком большим количеством уговоров себя, что "ну ладно, смирюсь", и была в итоге похоронена.

Скажу сразу, что мне очень хочется реализовать поиск независимо от движка БД. Поэтому вещи типа встроенного поиска MySQL, Sphinx или TSearch2 отпали. Пока, по крайней мере... И я обратился к поиску отдельных библиотек, реализующих индексированный поиск по произвольным документам.

Слово "PyLucene" чаще всего встречается, когда ищешь что-то, посвященное индексированному поиску под Питон. Оно представляет собой обертку для Java-библиотеки Lucene. Библиотека быстрая (по заявлениям) и очень способная: развитый язык запросов, нечеткий поиск, морфология (включая русскую).

Первый минус — типичный (уж извините) для многих Java-софтин монструозный интерфейс. Даже самые простые вещи делаются с помощью создания трех-четырех промежуточных объектов, реализующих абстракции, которые будут нужны потомкам. Когда-нибудь... Вот для примера поиск строки в индексе:

store = PyLucene.FSDirectory.getDirectory(settings.SEARCH_INDEX_ROOT, False)
analyzer = PyLucene.RussianAnalyzer()
searcher = PyLucene.IndexSearcher(store)
try:
  query = PyLucene.QueryParser('text', analyzer).parse(text)
  hits = searcher.search(query)
  for i, doc in hits:
    print doc.get('topic_id')
finally:
  searcher.close()

Но ладно, я не буду сильно зубоскалить — проблема неудобного интерфейса оказалась самой невинной из всех. Убили же идею совсем другие вещи:

• PyLucene не дружит с питоновскими тредами. Спрашиваете, причем здесь треды? Вот, читайте.

  PyLucene портирован очень витиевато: Java-библиотека компилируется компилятором gcj в бинарник с Сишным интерфейсом, который уже потом может использовать Питон. Проблема в том, что этот бинарник везет за собой часть java-машины, у которой есть сборщик мусора, который следит за java-тредами. И вот как-то так выходит, что питоновская программа в этом случае должна обеспечить странное условие: импорт PyLucene должен происходить обязательно из java-треда. На практике это выливается в то, что Django'вский отладочный сервер, который импортирует для чисто внутренних нужд стандартный питоновский модуль threading, просто напросто мгновенно падает в segmentation fault при попытке загрузить PyLucene. По слухам, та же участь постигает любое приложение, работающее под mod_python.

  Да, а в рассылке PyLucene в этом, похоже, проблемы и не видят: "вам просто нужно обеспечить, чтобы все треды в вашей программе создавались через наш враппер PythonThread". Ага... Сейчас я пойду переписывать все библиотеки и фреймворки, чтобы PyLucene не падала.

• PyLucene — нераздельная, и при работе занимает 20 МБ в памяти. Жирновато, учитывая, что питоновский интерпретатор + Django + сайт с форумом занимает только 15. Это было бы нормально в Java-среде, где весь сервер жил бы в одном процессе, но в форкающемся питоновском FastCGI-сервере по 20 лишних МБ на процесс — это плохо.

• Я не смог заставить парсер запросов не выкидывать слово "быть". Попытки накормить RussianAnalyzer пустым списком стоп-слов все время приводили к некому странному Exception'у.

Другими словами, PyLucene не смог. Реальное его использование для джанговского приложения я вижу только в виде отдельного внешнего сервера, написанного на их PythonThread'ах. А это совсем не то, чего мне хочется. Теперь буду пробовать Xapian.