Александр Кошелев

Тут неожиданно для меня вскрылось, что в одном из последних релизов Djapian существенно просела производительность индексирования.

Для проверки я решил найти или на худой конец намайнить какой-то большой массив данных и его проиндексировать. Подумав, решил что что-то типа википедии будет в самый раз. Быстро нашел xml дамп русской википедии и попробовал его залить в базу, а потом проиндекcировать. Для оперативности ограничился числом в 150К статей.

При тестировании действительно выяснилось, что с включенными транзакциями индекс обновляется очень медленно - примерно 0.5 док/сек. Причем виноваты не сами транзакции, а то что при каждом комите происходил flush базы. Отключив flush, производительность индексирования выросла в разы - до 15-20 док/сек, что уже очень не плохой показатель.

В итоге в хотфикс релизе я добавил возможность управлять транзакциями (по умолчанию они выключены) и сбросом кеша в базу через опции команды index - --transaction и --flush:

• --transaction - включает использование транзакций
• --flush - включает сброс файлового кеша при обновлении каждого документа

Ещё изменил политику работы с большим числом объектов в очереди индексирования. Теперь они обрабатываются постранично и не сжирают кучу виртуальной памяти из-за нерадивых client-side курсоров БД. Это тоже могло приводить к активному свопингу и ухудшению производительности.

Djapian стал ещё производительнее и лучше:-)

Очередной релиз Djapian подоспел.

Коротко расскажу о нововведениях:

• Добавлена работа с транзакциями Xapian при обновлении индекса. Теперь, если в процессе индексирования какого-то объекта, произойдет ошибка, то он не оставить никаких следов в индексе. Чуть-чуть просела производительность индексирования.

• Добавлена возможность использовать X объекты для фильтрации результатов. X объект - это аналог django.db.models.Q объектов, которые позволяют писать комплексные фильтры. Поддерживаются операторы И (&), ИЛИ (|) и отрицания(~). Пример:

  from djapian import X
  
  result_set = Article.indexer.search('foobar')\
           .filter(X(type='news') | (X(type='article') & X(tag='featured')))
  

• У каждого результата поиска появился атрибут tags с полями данного документа, которые хранятся непосредственно в индексе. В некоторых случаях позволяет не вытягивать из базы данных сам объект, используя в отрисовке выдачи элементы из tags.

• Исправлен баг с индексированием значений чисел с плавающей точкой.

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

На выходных в очередной раз засел за Djapian и новый релиз сделал. Качайте. Там в основном улучшения и добавление полезных фич, но есть и важный багфикс.

Я перескажу Release Notes:

• Язык стемминга можно задавать для каждого поискового запроса. Удобно, если документы в индексе могут быть на разных языках и по ним надо языко-зависимо искать. В прошлом релизе я это оторвал, но сейчас починил.
• Добавлена возможность добавлять в индекс модели без специального определения индексера. В таком случае он сгенерируется автоматически, Примерно также ведет себя админка, когда в неё регистрируешь модель без явного указания ModelAdmin класса.
• Добавлена возможность вытягивать объекты с select_related в prefetch режиме. Для этого надо его вызывать вот так: prefetch(select_related=True). Полезно в плане повышения производительности.
• Добавлены методы filter и exclude для фильтрации результатов поискового запроса по тегам. Поддерживаются привычные для джанги предикаты сравнения: __exact, __gt, __gte, __lt, __lte, __in. Теперь удобно стало отбирать результаты поиска по каким-то атрибутам.
• Добавлен композитный индексер, который позволяет делать запросы в несколько индексов (т.е. для нескольких моделей) одновременно. Поможет сделать "глобальный поиск по сайту" с однородным ранжированием.

Такие дела. В очередной раз призываю использовать Djapian, если вам нужен полнотекстовый поиск в ваших джанго-проектах. Я так же планирую написать цикл tutorial-постов, так ...

Обновление от 24 февраля 2009 года: проект я прекратил развивать, т.к. получил полный доступ к проекту Djapian. Все нижеперчисленные идеи уже туда портированы, успели проэволюционировать и дополниться другими. Так что смело пользуйтись самим Djapian.

Проблема выбора реализации для индексирования/поиска на сайте, поднятая мною недавно, пришла к своему разрешению. Как я уже говорил, остановился я на djapian. Но в том виде, в котором было данное приложение, его использовать было практически невозможно.

Решил немножко подкрутить там гайки и обтесать под свои нужды. Но поскольку изменений накопилось много, то я завел отдельный проект для моей ветки. Назвал я его просто и без затей django-xapian. И конечно же выкладываю в открытый доступ свои наработки. Вот домашняя страничка проекта http://webnewage.org/projects/p/django-xapian/

Основные изменения по сравнению с оригиналом:

• Код подтянут до транка джанги
• Исправлен NameError, который ставил крест на использовании оригинала:)
• Объекты обрабатываются только при срабатывании пользовательского триггера, а не просто по событию
• Перенесен сервис индексировани из отдельно скрипта в команду manage.py
• Оптимизирован процесс индексирования - убраны лишние действия, которые выполнял исходный скрипт, не отфильтровывая неактуальные уже изменения в объектах.
• Убрана махинация с неймспейсами
• Добавлена возможность индексирования не только непосредственно полей данных модели и но результатов выполнения методов, либо связанных ...

Очень часто встает задача организации поиска информации, которая хранится на сайта. Причем не простой поиск, а с богатыми возможностями и хорошими результатами, чтобы мы получили то что искали, а не что-то другое. На помощь приходит полнотекстовое индексирование.

В некоторые СУБД встроены механизмы полнотекстового индексировании, в другие нет. Но хочется иметь механизм универсальный и не зависящий от бекэнда хранения данных, ведь в конце концов информации может и не в базе вовсе храниться.

Первая проблема выбора - движок индексирования. Есть несколько примерно равных варианта, так что любой сможет выбрать тот, который более ему понравится по вторичным признакам, поскольку основную задачу, как мне кажется, они решают почти одинаково хорошо.

Вторая проблема выбрать реализацию для питона/джанги. Для джанги есть несколько сторонних приложений, которые позволяют использовать индексирование. Перечислю те, которые мне попались во время тематического поиска:

• django-sphinx
• djapian
• pyndexter

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

Бранч TextIndexingAbstractionLayer, который в последствии, я надеюсь, будет самый лучший ...