Development

Скрипт миграции обычных индексов на real time индексы Sphinx Search

Posted in Sphinx Search on September 22nd, 2010 by Yaroslav Vorozhko – Be the first to comment
Скрипт предназначен для заполнения и обнволения real time индексов. Скрипт выполняет похожую работу, которую делал sphinx indexer для обычных индексов.
Поэтому конфигурационный файл sources.ini практически повторяет конфигурацию блока source из sphinx.conf.

Скрипт предназначен для заполнения и обнволения real time индексов. Скрипт выполняет похожую работу, которую делал sphinx indexer для обычных индексов.

Поэтому конфигурационный файл sources.ini практически повторяет конфигурацию блока source из sphinx.conf.

Возможности

  • Заполнять индекс данными
  • Дописывать в индекс новые данные
  • Обновлять в индексе существующие данные
  • Выполнять pre и post sql запросы
  • Поддерживает ranged запросы

Установка

Скачайте архив из launchpad.net

Распакуйте его в любую директорию вашего веб сервера.

Откройте sources.ini, в этом файле уже определен один раздел, используйте его как пример.

Определять можно столько разделов, сколько потребуется.

Каждый раздел описывает один источник данных для одного real time индекса.

Для поддержки добавления новых данных в индекс без перезаписи старых, необходимо использовать счетчик id для источника данных.

Вы должны будете выполнить следующие шаги:

  • Создать таблицу для счетчиков
  • Добавить счетчики в таблицу
  • Изменить sql_query для поддержки $start и $end
  • Изменить sql_query_range для выборки минимального и максимального id используя таблицу счетчик
  • Изменить sql_query_post_index для обновления таблицы счетчика

Подробнее про счетчик вы можете прочитать в документации к Sphinx Search

Теперь когда мы закончили с конфигурацией, можно начать заполнение индекса.

Для этого просто запустить indexer.php

CODE:
  1. php indexer.php

Спасибо!

Желаю удачи!

Тестирование производительности Обычных, Real Time и Смешанных индексов Sphinx Search

Posted in Sphinx Search on September 21st, 2010 by Yaroslav Vorozhko – Be the first to comment

Немного определенй

Обычный индекс - это индекс, который имеет блок source в конфигурационном файле Sphinx и заполняется путем вызова утилиты indexer.
Real time (RT) - не имеет блока source, а содержит только определение полей и атрибутов. Заполнение RT индекса уже не является обязанностью утилит Sphinx, а ложиться на плечи разработчика приложения.
Смешанный индекс - это индекс, который образуется путем создания распределенного индекса из обычного индекса и RT индекса.

Пример смешанного индекса:

CODE:
  1. index distributed
  2. {
  3. type = distributed
  4. local = plain_main_index
  5. local = real_time_increment_index
  6. }

В данном примере мы через один распределенный индекс можем обращаться одновременно к RT и обычным индексам.

Измерение производительности

Я провел несколько сравнительных тестов над всеми типами индексов, а именно:

  1. Сравнил использования HDD каждым из типов
  2. Сравнил скорость поиска по одиночному запросу
  3. Сравнил скорость поиска по мулти запросам

Все тесты проходили на четырех различных наборах данных. Данные были взяты из wikipedia и распределены на четыри части по:
10 тыс., 100 тыс., 1 млн. и 2 млн. записей.

Сравнение HDD

Я сравнил использование hdd, только для обычных и RT индексов.

hdd usage by RT and plain index

Красное поле RT индексы.
Синее поле обычные индексы.

Как видно из диаграммы, RT индексы для 1 млн. и 2 млн. данных используют примерно на 20% больше места.
Но, Я считаю, что RT индексы все таки по этому показателю лучше, так как для обычных индексов при переиндексации требуется в 2 раза больше места чем сам индекс. Соответственно используя RT мы сможем экономнее использовать hdd на сервере.

Сравнение скорости поиска по одинчоному запросу

Для запросов я создал словарь из 1000 самых популярных слов из каждого индекса. И по этим словам выполнил запросы.

single query performance tests

Красное поле RT индексы.
Синее поле обычные индексы.
Желтое поле смешанные индексы.

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

Сравнение скорости поиска по мулти запросам

Словарь я использовал тот же, что и для предыдущего теста, только поиск исполнял сразу по пять запросов паралельно.

multi query performance tests

Красное поле RT индексы.
Синее поле обычные индексы.
Желтое поле смешанные индексы.

Тут мы видим практически туже самую картину. На больших объемах RT индексы сильно проигрывают обычным индексам.
Но, стоит отметить, что производительность мультизапросов примерно в 5 раз лучше чем у одинчоных запросов.

Из этого можно сделать несколько выводов:

  • RT индексы работают быстро только на малых масивах данных
  • Для поддержки высокой производительности приложение стоит проектировать с поддержкой мульти запросов
  • RT индексы могуть стать хорошей заменой инкрементному индексу

Благодарю за внимание.
Желаю удачи!

Переходить ли на Sphinx Search real time индексы

Posted in Sphinx Search on September 20th, 2010 by Yaroslav Vorozhko – 2 Comments

Проблема обычных индексов

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

Для больших массивов данных, используется метод main + delta индексы.
Где main содержит основную часть данных, а delta - только последние изменения.

Таким образом, чтоб поддерживать индекс "свежим" необходимо перестраивать delta индекс, каждые 3-5 минут.
Но, чем больше становится delta индекс, тем дольше идет перестроение, поэтому delta индекс рекомендуется сбрасывать в
main индекс раз в сутки или неделю в зависимости от частоты обновления данных.

Отсюда возникает две проблемы:

  1. Из-за частой переиндексации система всегда нагружена.
  2. Данные попадают в индекс только спустя 3-5-10 минут.

Real time индексы

В версии 1.10 Sphinx включил поддержку нового типа индексов - real time индексы.
Основное преимущество и отличие от обычных индексов - это возможность обновить запись в индексе на "лету".
Также - это поддержка mysql протокола, что позволяет использовать существующие инструменты(mysql client, mysqldump) для работы с real time индексами.
Для обычных индексов доступ по mysql протоколу также поддерживается, но только в режиме чтения.
И - это SphinxQL, язык запросов основанный на SQL, поддерживающие такие операции как SELECT, DELETE, INSERT, REPLACE.

Но, в данный момент сущесвтует проблема с производительность в RT индексах на больших объемах данных.
Хотя, на малых объемах, скажем до 500.000 документов содержащих статьи из wikipedia, скорость работы не уступает обычным индексам.

Из этого можно сделать вывод, что простота работы и высокая скорость поиска на небольших объемах данных выгодно отличет real time
индексы от обычных индексов для delta (инкрементного) индекса.

Вывод
Real time индексы можно использовать как инкрементный delta индекс в Sphinx.
Это снизит нагрузку на сервер, и упростит обновление данных в инкрементном индексе.
А поддержка смешанных индексов позволит очень просто подключить RT индексы к работающему приложению.

Пример смешанного индекса.

CODE:
  1. index distributed
  2. {
  3. type = distributed
  4. local = plain_main_index
  5. local = real_time_increment_index
  6. }

В данном примере мы через один распределенный индекс обращаемся одновременно к RT и обычным индексам.

Как мы видим миграция на RT индексы может быть сделана очень просто, начать можно с малого не трогая при этом основу работающей системы.

Всем желаю удачи в этом непростом, но интересном деле!

Первая Sphinx конференция в Москве 2010

Posted in Events, Sphinx Search on September 10th, 2010 by Yaroslav Vorozhko – 1 Comment

Sphinx открывает двери в свою первую конференцию в Москве, которая пройдет 24 Октября - участие в конференции бесплатное.

Программа

  • Андрей Аксенов, автор Sphinx, сделает доклад про текущие достижения Sphinx и планы развития проекта.
  • Петр Зайцев, CEO компании Percona и автор широко известного в узких кругах MySQL Performance Blog, расскажет о том, как Percona применяет Sphinx вместе с MySQL и вместо MySQL.
  • Ivinco, компания, которая оказывает услуги разработки и консалтинга с использованием LAMP(S) стека, сделает доклады про развертывание и поддержку многотерабайтного поискового кластера для Boardreader, сервиса поиска по форумам, индексирующего более 3 миллиардов документов и более 3 TB данных.
  • SuperJob.ru, ведущий рекрутинговый портал и Gorbushka.ru, популярный поисковик товаров, поделятся своими практическими знаниями про тонкости и специфику поиска в рекрутинге и поиска по товарам.
  • Разработчики Sphinx сделают несколько блиц-докладов про новые возможности, разработанные в последнее время.

Стоит ли мне поучаствовать?

Если вам интересно что-то из нижеперечисленного - то обязательно!

  • Текущие достижения Sphinx, новые возможности, и планы развития.
  • Практические применения Sphinx, тонкости и советы, и бесценный боевой опыт.
  • Возможность поделиться своими идеями с сообществом и повлиять на планы разработки.
  • Встреча с пользователями и командой разработчиков Sphinx.

Подробнее о конференции на сайте Sphinx Search.

До встречи!

Как я установливал MongoDB на Ubuntu 64bit

Posted in Development, Tips And Tricks on September 8th, 2010 by Yaroslav Vorozhko – Be the first to comment

MongoDB для Ubuntu устанавливается следующей командой

CODE:
  1. sudo apt-get install mongodb

После, по туториалу создал каталог для данных

CODE:
  1. mkdir -p /data/db/
  2.  
  3. chown `id -n` /data/db

Запускаю mongodb командой mongodb и получаю следующую ошибку:

CODE:
  1. mongo: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory

Лучиться путем определения пути к libmozjs.so во время запуска mongodb или mongo клиента:

CODE:
  1. LD_LIBRARY_PATH=/usr/lib/xulrunner-`xulrunner --gre-version` mongodb

Теперь все работает.

Ждем пока мэинтейнеры пофиксят MongoDB зависимости.

Вышел долгожданный и многообещающий релиз Sphinx 1.10-beta

Posted in Sphinx Search on July 20th, 2010 by Yaroslav Vorozhko – 5 Comments

Чего же нам так нехватало в старых версиях, и что появилось в новой версии Sphinx?

Real time индексы

  • RT индексы позволяют моментально внести изменения в индекс
  • С ними стало также легко работать как с базой MySQL
  • Main+Delta схема обновления индекса ушла в прошлое
  • Больше нет необходимости в переиндексации

Режим работы prefork и threads

  • Позволяют легко организовывать многопоточность
  • Это лучше скажется на производительности запросов
  • Это позволит лучше утилизаровать мощности многоядерных CPU

Поддержка строковых атрибутов

Полная поддержка всех функций searchd в SphinxQL

Полный список изменений смотрите в оффициальной документации.

Если у вас есть вопросы или нужна консультация - пишите, я обязательно отвечу на все впоросы.

Детали разработки плагина поиска для Dokuwiki

Posted in Development, Dokuwiki, Sphinx Search on July 16th, 2010 by Yaroslav Vorozhko – Be the first to comment

custom-windows-mobile-development1В этой статье я расскажу некоторые подробности реализации нашего плагина поиска для Dokuwiki. Я постарался сделать описание как можно более понятным и развернутым. Главное вы узнаете как применяя простые техники можно создать отличную поисковую систему для dokuwiki.
Вы можете скачайте исходники с launchpad - они помогут вам лучше разобраться в плагине.

Данные

Страницы dokuwiki хранятся в простых текстовых файлах. Каждый файл имеет свое уникальное название, называемое ID страницы. Обычно каждая страница содержит один или несколько разделов.
Проблема обычных плагинов поиска для DW, что они не учитываю разделы. А это, заставляет пользователя просматривать всю страницу целиком или делать внутренний поиск по странице, чтоб найти нужные данные. Я встречал страницы которые при печати на принтере занимали 15 страниц размера A4, попробуйте в таком документе найти что то.
Учитывая такое положение вещей нами была разработана система анализа страниц, которая выявляла секции документа. В дальнейшем каждая секция попадала в индекс как отдельный документ, что при поиске обеспечивало более точный результат и пользователь получал точную ссылку на секцию в документе.

Я бы с удовольствием привел бы код анализа wiki документов, но его описание и длина займет пару страниц. Просто скачайте исходники из launchpad и посмотрите функцию getSectionByTitleLevel в файле functions.php

Индексация

Для создания индекса Sphinx Search была применена технология xmlpipe2.
Специальный скрипт создает XML файл, который в свою очередь загружается в Sphinx индекс.
В процессе написания скрипта индексации мы столкнулись с одной проблемой: wiki страницы не имеют уникального цифрового идентификатора, без которого невозможно связать результаты поиска с конкретной страницой.
Для решение этой задачи в роли внешнего хранилища данных мы использовали SQLite.

Для каждой записи в индексе мы:

  1. создавали уникальный ID основанный на значении CRC32, взятого от имени страницы(внутреннего строкового ID)
  2. записывали связь индеска и страницы в SQLite базу

Структура XML файла имеет следующий вид:
<?xml version="1.0" encoding="utf-8"?>
<sphinx:docset>

<sphinx:schema>
<sphinx:field name="title"/>
<sphinx:field name="body"/>
<sphinx:field name="namespace"/>
<sphinx:field name="pagename"/>
<sphinx:field name="level"/>
<sphinx:field name="modified"/>
<sphinx:attr name="level" type="int" bits="8" default="1"/>
</sphinx:schema>

Как видите она очень простая. Первые четыре поля самые важные - они отвечают за весь поиск.
По полям namespace и pagename производится подстрочный поиск. По полям body и title производиться поиск на точное совпадение.
Больше информации о поиске можно получить из файла sphinx.conf, который также находится в пакете плагина.

Поиск

Оригинальный поиск DW примитивен и содержит много недостатков, который я описал в предыдущей статье.
В нашем плагине мы сделали много улучшений по сравнению с обычным поиском.
Я расскажу про 3 основных:

  1. Группы результатов
  2. Прорисовка разметки результатов
  3. Фильтры по пространству имен (namespaces)

Группы результатов

При тестировании мы обнаружили, что иногда большие документы у которых много разделов, при поиске, могут занять первые 5, а то и 10 позиций. Чтоб избежать такого спама страницы результатов, мы объединили результаты, которые были извлечены из одного документа в группу. Скажу честно эта идея была взята у Google, когда результаты с одного домена группируются вместе.

Прорисовка разметки результатов

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

Для прорисовки секции использовали следующую конструкцию:

p_render('xhtml',p_get_instructions(getSectionByTitleLevel($data['page'], $data['title'], true)),$info);
getSectionByTitleLevel($data['page'], $data['title'], true) - согласно названии функции возвращает разметку конкретной секции внутри документа.
Прорисовка страницы целиком производиться проще:

p_wiki_xhtml($data['page'])
$data[‘page’] - это ID имя страницы

Фильтры по пространству имен (namespaces)
Одна из новых возможностей, которой нет ни в одном поисковом плагине для DW - это фильтр результатов поиска по пространству имен. Sphinx Search предоставляет большие возможности по обработке данных поиска. Используя расширенный синтаксис поиска мы создали следующие запросы:
1. Простой запрос по ключевому слову
(@(namespace,pagename) $starKeyword) | (@(body,title) {$keywords})
2. Запрос с фильтром по namespace
(@(namespace,pagename) {$categories}) & ((@(body,title) {$keywords}) | (@(namespace,pagename) {$starKeyword}))
3. Запрос по Matching Pagenames без фильтра по namespace
(@(namespace,pagename) $starKeyword)
4. Запрос по Matching Pagenames с фильтром по namespace
(@(namespace,pagename) $categories $starKeyword)

$keywords - это заданные ключевые слова
$starKeyword - это ключевые слова слева и справа которых добавлены звездочки для поиска в подстроках. Например: *hotel*.
$categories - это заданное пространство имен по которому необходимо ограничить поиск

Пару слов о внешнем виде

Также мы хорошо поработали над юзабилити. Мы изменили стандартные dokuwiki стили результатов поиска на Googl-like стили.
Смотрите как ужасно выглядит страница результатов в оригинальном поиске:

Original ugly dokuwiki search

А теперь сравните с стилями применяемыми в нашем плагине. Все просто и понятно, а также они очень хороши для чтения.

Nice Sphinx Search Dokuwiki search


Уже только ради внешнего вида стоит попробовать наш плагин поиска.

На данный момент, мы уже выпустили третью версию плагина, который вы можете бесплатно скачать на launchpad. А также советую посетить официальную страницу плагина и больше узнать про его возможности.