Поиск в Cicero: Sphinx

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

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

В итоге, Cicero теперь имеет поиск, использующий Sphinx. Дальше — традиционый рассказ о реализации.

Индексация

Sphinx умеет читать данные из MySQL и PostgreSQL, но также и из пользовательской программы, которая выдает на stdout некий псевдо-XML. Я воспользовался именно этим способом, потому что 1) мне, как я уже упоминал, не хочется привязываться к конкретной СУБД и 2) потому что я хочу индексировать статьи, а искать топики. Поясню второй пункт.

Когда Sphinx индексирует документы в БД, он просит указать в конфигурации SQL-запрос, который будет выдавать строки, которые такими документами и считаются. В них должен быть ID и текст. Все бы хорошо, но у меня в форуме единица информации — целиком топик, а не отдельная статья. Получается, мне нужен запрос, который бы выдавал ID топика и весь его текст, то есть текст всех его статей. Я слишком плохо знаю SQL, чтобы составить такой запрос, поэтому я и написал для этого несложный код, который выдает топики с текстом всех их статей, соединеных вместе:

# Составляет текст топика из текста его статей
def text(topic):
  return ' '.join([a.text for a in topic.article_set.all()])

# Превращает dict с данными топика в sphinx'овый псевдо-XML
def format_document(document):
  return  '\n'.join(
    ['<document>'] +
    ['<%s>%s</%s>' % (k, document[k], k) for k in ['id', 'group', 'timestamp', 'title', 'body']] +
    ['</document>', '']
  )

# Выбирает и форматирует данные топика в dict
def topic_dict(topic):
  return {
    'id': topic.id,
    'group': topic.forum_id,
    'timestamp': int(mktime(topic.created.timetuple())),
    'title': escape(topic.subject.encode('utf-8')),
    'body': escape(text(topic).encode('utf-8')),
  }

for topic in Topic.objects.all():
  print format_document(topic_dict(topic))

API

Из Джанго к серверу Sphinx'а можно обращаться двумя способами: через django-sphinx или через включенный в поставку самого Sphinx'а общий питоновский API. Я попробовал оба, причем переключался с одного на другой и обратно раза два. Остановился на сфинксовом API. Почему не подошел django-sphinx определенно сказать не берусь :-). Видимо, на мой вкус он оказался недостаточно вылизанным. По идее он старается быть похожим на джанговский queryset, но в паре мест некрасиво лажается:

• цепочные вызовы не генерят новые instance'ы поискового запроса, а модифицируют изначальный, что странно: уж либо функциональная парадигма, либо объектная
• слайсинг (указание [offset:limit]) возвращает уже таки результат, а не модифицированный запрос, что заставляет делать его обязательно последним

В итоге остановился на sphinxapi.py из поставки. Код вьюхи, которая его использует, очень прямолинейный и скучный, но чтобы не отходить от традиций приведу его здесь:

def search(request, slug):
  forum = get_object_or_404(Forum, slug=slug)
  try:
    from sphinxapi import SphinxClient, SPH_MATCH_EXTENDED, SPH_SORT_RELEVANCE
  except ImportError:
    return render_to_response(request, 'cicero/search_unavailable.html', {})
  try:
    page = int(request.GET.get('page', '1'))
    if page < 1:
      raise Http404
  except ValueError:
    raise Http404
  term = request.GET.get('term', '').encode('utf-8')
  if term:
    sphinx = SphinxClient()
    sphinx.SetServer(settings.SPHINX_SERVER, settings.SPHINX_PORT)
    sphinx.SetMatchMode(SPH_MATCH_EXTENDED)
    sphinx.SetSortMode(SPH_SORT_RELEVANCE)
    sphinx.SetFilter('gid', [forum.id])
    sphinx.SetLimits((page - 1) * settings.PAGINATE_BY, settings.PAGINATE_BY)
    results = sphinx.Query(term)
    pages = _page_count(results['total_found'])
    if pages > 0 and page > pages:
      raise Http404
    ids = [m['id'] for m in results['matches']]
    topics = ids and Topic.objects.filter(id__in=ids)
  else:
    topics, pages = None, None
  return render_to_response(request, 'cicero/search.html', {
    'page_id': 'search',
    'forum': forum,
    'topics': topics,
    'term': term,
    'has_next': page < pages,
    'has_previous': page > 1,
    'page': page,
    'pages': pages,
    'query_dict': request.GET,
  })

Впрочем с sphinxapi.py тоже не все было гладко. Я нашел там баг. Выражался он в том, что после поиска по некому слову сначала в одном форуме, потом в другом, а потом опять в первом, поиск начинал возвращать нулевые результаты. Причем после перезагрузки моего приложения баг пропадал, а затем возвращался снова. Я предположил, что где-то там сохраняется состояние предыдущих выборок, которое не должно сохраняться, и так оно, судя по всему, и есть. Вот начало кода класса SphinxClient:

class SphinxClient:
  _host = 'localhost'
  _port = 3312
  _offset = 0
  _limit = 20
  _mode = SPH_MATCH_ALL
  # и еще 12 параметров

  def __init__ (self):
    pass

То есть все то, что должно быть, кажется, полями экземпляров объектов, лежит не в экземплярах, а в классе и, следовательно, является общим для всех. Видимо, туда куда-то и попадают результаты предыдущих поисков. Решилась проблема использованием метода __init__ по назначению: я переписал назначение всех параметров туда:

class SphinxClient:
  def __init__ (self):
    self._host = 'localhost'
    self._port = 3312
    self._offset = 0
    self._limit = 20
    self._mode = SPH_MATCH_ALL
    # и еще 12 параметров

Андрею Аксенову. Я извиняюсь, что не оформил это патчем: очень лень было в багтракере регистрироваться :-). Может, поправите при случае?

Живой индекс

Sphinx'овый индекс — монолитный, в него нельзя добавить новый документ, а надо перестраивать с самого начала (что ни в коем случае не плохо, потому что из-за этого он очень быстрый, насколько я понимаю). Если индекс пересчитывать редко, то полезность поиска уменьшается, а пересчитывать часто — дорого. Для решения этой проблемы в документации рекомендуется завести два индекса: основной, который пресчитывается редко, и маленький дополнительный ("дельта"), в который попадают только новые статьи. Sphinx умеет прозрачно искать сразу по двум индексам.

Я так и сделал, причем для отделения новых топиков от старых получилось элегантно использовать уже существующую систему определения прочитанности. То есть я просто завел одного системного пользователя "cicero_search", который "прочитывает" все статьи при полной переиндексации, а его непрочитанные топики попадают в дельта-индекс. В коде это выглядит так:

cicero_search = Profile.objects.get(user__username='cicero_search')
if sys.argv[1] == 'unread':
  for topic in cicero_search.unread_topics():
    print format_document(topic_dict(topic))
elif sys.argv[1] == 'all':
  for topic in Topic.objects.all():
    print format_document(topic_dict(topic))
  cicero_search.add_read_articles(Article.objects.all())
  cicero_search.save()

Сейчас дельта-индекс пересчитывается раз в 10 минут, основной — раз в сутки.

Интерфейс

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

Надо будет еще ссылочку в сайдбары второстепенных страниц распихать, пока я это просто позабыл.

Впечатления и пожелания

В целом, все хорошо! Работает, ищет, все очень быстро (хотя при нынешних объемах это не показательно), русская морфология есть, релевантность вроде тоже вменяемая получается.

Но если помечтать, то у меня есть несколько пожеланий, в духе "каким я вижу идеальный поисковый сервер".

• Было бы страшно удобно, если бы у сервера был не свой собственный (бинарный!) протокол обмена данными, а чтобы для этого использовался бы HTTP с XML'ом или JSON'ом в качестве формата выдачи. Тогда необходимости в языковых библиотеках просто бы не возникло.

• XML-интерфейс индексатора все таки должен быть полнофункциональным (сейчас в Sphinx он может не все, что можно сделать SQL'ом) и, на самом деле, основным. Просто потому что этот подход гибче, да и свет клином не сошелся на двух СУБД. Собственно и доступ в СУБД можно реализовать над XML-интерфейсом, написав готовые индексаторы, которые будут делать запросы и выдавать XML. (Да, и это все таки должен быть XML, потому что на дворе 2007-й год, и смысла делать псевдо-XML со своим парсингом я, честно, не вижу :-) ).

• Как типичному представителю "девелоперов с Убунтой из коробки", мне очень хочется, чтобы можно было скачать готовый deb-пакет, а не собирать сервер из исходников.