Development

Вышел долгожданный и многообещающий релиз 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. А также советую посетить официальную страницу плагина и больше узнать про его возможности.

Как создавать Providers для Zend_Tool

Posted in ZendFramework on July 3rd, 2010 by Yaroslav Vorozhko – Be the first to comment

Matthew Weier O’Phinney ведущий разработчик Zend Framework опубликовал новую статью про то, как создавать Providers для Zend_Tool.
В общем провайдеры (providers) Zend Tool отвечают за команды выполняемые через командную строку, CLI – приложений. Например таких как крон скрипты, миграционные скрипты и т.п.
Советую прочитать статью Matthew о провайдерах, чтоб ближе узнать о том, что представлят собой командная строка Zend Tool.

Sphinx query log parser – анализ query performance

Posted in Sphinx Search, Tips And Tricks on June 2nd, 2010 by Yaroslav Vorozhko – Be the first to comment

Написал простой скриптик на awk для парсинга Sphinx query.log файла.

Парсинг всего файла:

CODE:
  1. awk '{ s += $6 } END { print "seconds: ", s, " average: ", s/NR, " queries: ", NR }' query.log

Парсинг за конкретный период, например за второе Июня:

CODE:
  1. awk '{ if($2=="Jun" && $3==2) {s += $6; r++} } END {print "total seconds: ", s, "average: ", s/r, " total queries: ", r}' query.log

В приведенных скриптах $N - это номер строки в лог файле.

NR - это общее количество записей в файле разделенных переводом строки.

Пример лог файла:

[Wed Jun  2 11:20:52.379 2010] 0.002 sec [ext2/0/rel 2024 (0,10)] [wordpress] spectrum
[Wed Jun  2 11:20:52.384 2010] 0.003 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] spectrum
[Wed Jun  2 11:20:52.709 2010] 0.002 sec [ext2/0/rel 963 (0,10)] [wordpress] tin
[Wed Jun  2 11:20:52.713 2010] 0.002 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] tin
[Wed Jun  2 11:20:52.997 2010] 0.003 sec [ext2/0/rel 1154 (0,10)] [wordpress] xi
[Wed Jun  2 11:20:53.004 2010] 0.004 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] xi
[Wed Jun  2 11:20:53.029 2010] 0.003 sec [ext2/0/rel 1945 (0,10)] [wordpress] nasa
[Wed Jun  2 11:20:53.035 2010] 0.003 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] nasa
[Wed Jun  2 11:21:09.359 2010] 0.005 sec [ext2/0/rel 22308 (0,10)] [wordpress] september

На выводе получится:

seconds:  566.738  average:  0.00948642  queries:  59742

Надеюсь это краткое описание языка awk поможет вам написать парсер для своих лог файлов.

Спасибо!

Как увеличить скорость процесса индексации Sphinx Search

Posted in Development, Sphinx Search on May 12th, 2010 by Yaroslav Vorozhko – 2 Comments

Индексирование - это одна из двух важных операций выполняемых Sphinx Search (далее Sphinx). Если учитывать, что индексирование миллиона документов может занять от 20-30 минут на среднем сервере, то можно сказать, что индексирование одна из самых важных операций, которую стоит продумать очень тщательно.

Почему надо оптимизировать скорость индексации документов?

  1. Индексация очень “тяжелый” процесс для системы, каждый раз когда выполняется индексация, система использует много CPU и IO ресурсов
  2. Переиндексирование и объединение (merge) индексов занимает вдвое больше места на диске, чем объем всего индекса
  3. Индексирование замедляет выполнение других задач, например поиска по документам или выполнение sql запросов
  4. Загруженная система “тормозит” работу веб сайта, а из-за этого сайт теряет часть своих пользователей.

В этой статье вы узнаете как избежать всех выше перечисленных проблем.

Источник данных

Sphinx поддерживает два SQL источника данных - это MySQL и PostgreSQL. Sphinx работает таким образом, что на основе слов из источника данных формирует индекс, который любит очень разрастаться в размере и занимать все дисковое пространство и память.

Не будем останавливаться на оптимизации баз данных, а скажу одно, проверьте, что sql запросы, которые будут выбирать данные для индекса - работаю быстро. Это можно сделать с помощью команды sql EXPLAIN. Если же вас все таки не устраивает производительность вашей баз данных, то за дополнительными советами вы можете обратиться на сайт www.mysqlperformanceblog.com.

Итак, первое правило такое: индексируйте только те поля таблиц, по которым собираетесь выполнять поиск. Например не стоит включать в индекс большие текстовые поля, если по ним не будет поиска. Особенно это важно, если вы используете Sphinx не как полнотекстовый поиск, а как key-value базу данных.

Второе правило: держите длину индекса как можно меньше. Скажем у вас есть каталог товаров размером в 10GB, и товары которые были добавлены год назад вы не хотите использовать в поиске. Поэтому сделайте ограничение на выбираемые данные, не включайте в и индекс всю базу данных, а ограничьтесь только последним годом, задав соответствующее условие в sql запросе. Таким образом вы добьетесь существенного уменьшения длины индекса и увеличения производительности поиска.

Третье правило: разбивайте большие индексы на более мелкие в соответствии какому либо критерию. Например, год можно разбить по кварталам и уменьшить индекс в 4 раза. Если вам известна, какая категория товаров в какое время была добавлена, то вы можете производить поиск, только в одном из четырех индексов, а для поиска по всем данным, можно использовать распределенный индекс, который будет включать все четыре квартальных индекса. Прежде чем решить какую схему использовать с одним монолитным индексом или четырьмя распределенными, проверьте запросы которые вы будете выполнять к sphinx. Если большинство запросов потребует использование индекса за весь год, то возможно вам и не стоит разбивать индекс по кварталам. Смотрите ниже как может повлиять использование распределенных индексов на общую производительность запросов.

Четвертое правило: используйте ranged (ограниченные) запросы по количеству выбираемых записей. Это уменьшит нагрузку на sphinx и на базу данных.

Аттрибуиты

Каждый атрибут по умолчанию занимает 32 или 64 бита, и учитывая, что обычно Sphinx используется для индексирования по меньшей мере миллионов документов, то в Sphinx была предусмотрена возможность задавать определенный размер для атрибута.

Пятое правило: ограничивайте длину атрибуту битовой маской, там где это возможно. Например количество стран не превышает размера в 16 бит, поэтому такой атрибут стоит ограничить 2 байтами. А это уменьшит размер атрибута в 2 раза на 32 битной платформе и в 4 раза на 64 битной, что в свою очередь существенно уменьшит общий размер индекса. Конечно, лучшим вариантом будет ограничить каждый атрибут с минимальным запасом длины. Но, в таком случае, незабывайте периодически проверять атрибуты, чтоб неожиданно не выйти за пределы размера атрибута.

Распределенные (distributed) индексы

Про распределенные индексы вы должны знать, что скорость работы такого индекса зависит от скорости самого медленного агента. В большой системе с тысячами индексов, десятками sphinx агентами и несколькими серверами тяжело обнаружить проблему “медленного агента”. Но, как показала практика, всегда найдется какой нибудь перезагруженный sphinx агент, который замедляет 20% всех запросов. Избежать этой проблемы можно с помощью регулярного поэтапно тестирования каждого агента и переноса нагрузки на других агентов. Много информации про скорость выполнения запросов вы можете получить исследуя логи shpinx.

Поэтому шестое правило следующее: регулярно тестируйте sphinx запросы и анализируйте логи.

Конфигурационные параметры индексера

При переиндексации, опция inplace_enable позволяет уменьшить вдвое требуемое дисковое пространство при переиндексации. Но, с другой стороны включение этой опции замедлит производительности индексации на 5-10%. Эта опция будет полезна на серверах с очень ограниченным количеством дискового пространства, правда при потере производительности индексации. По умолчанию опция отключена и следует заметить, что она влияет только на indexer не затрагивая никоим образом searchd.

С помощью mem_limit можно контролировать количество выделяемой оперативной памяти для индексации. Наиболее оптимальным вариантом будет установка от 256Mb до 1024Mb. Слишком низкие значения могут привести к ухудшению скорорсти индексации. Слишком высокие могут привести к timeout с MySQL базой. Так как буффер пул необходимо будет обработать большой, то возможна потеря соединения. По умолчанию данный параметр равен 32Mb. Максимальное значение 2047Mb.

Опция max_iops влияет на количество I/O(read, write) операций работы с диском в секунду. Если во время индексации, производительность поиска существенно уменьшается, то стоит подумать о настройке max_iops. По умолчанию данная опция имеет значение 0, т.е. неограничено (unlimited). Также стоит обратить внимание на опцию max_iosize, которая позволяет установить размер буфера чтения/записи при индексации. По умолчанию эта опция равна 0, т.е. размер буфера не ограничен. С помощью утилиты fio вы можете вычислить количество I/O операций в секунду, а также узнать размер I/O кеша. После того как вы определили характеристики вашего диска, попытайтесь потестировать indexer и searchd с разными настройками max_iops и max_iosize.

Вывод

  • Формируйте свой основной sql запрос (sql_query) грамотно.
  • Не включайте все поля сразу, а выбирайте только те, которые будете использовать.
  • Используйте условия (where) в sql выборке, чтоб не перегружать индекс ненужными данными.
  • Разбивайте большие монолитные индексы, на более мелкие в соответствии какому либо критерию, например по кварталу или году.
  • Используйте возможность пошаговой выборки (ranged queries), это уменьшит вероятность блокировки базы данных на время выборки.
  • Ограничивайте короткие атрибуты битовой маской.
  • Тестируйте sphinx запросы и анализируйте логи.

Создание простого доступа к ресурсам из ZF контроллера

Posted in PHP, Tips And Tricks, ZendFramework on March 22nd, 2010 by Yaroslav Vorozhko – 2 Comments

Было бы очень хорошо иметь возможность доступа к загружаемым в bootstrap ресурсам из контроллеров приложения. Например, я хотел бы получить доступ к "DB" ресурсу из контроллера следующим образом $this->db;
Для этого напишем Action Helper, который будет загружать определенные ресурсы в контроллер приложения:

CODE:
  1. class My_ResourceInjector extends Zend_Controller_Action_Helper_Abstract
  2. {
  3.     protected $_resources;
  4.  
  5.     public function __construct(array $resources = array())
  6.     {
  7.         $this->_resources = $resources;
  8.     }
  9.  
  10.     public function preDispatch()
  11.     {
  12.         $bootstrap  = $this->getBootstrap();
  13.         $controller = $this->getActionController();
  14.         foreach ($this->_resources as $name) {
  15.             if ($bootstrap->hasResource($name)) {
  16.                 $controller->$name = $bootstrap->getResource($name);
  17.             }
  18.         }
  19.     }
  20.  
  21.     public function getBootstrap()
  22.     {
  23.         return $this->getFrontController()->getParam('bootstrap');
  24.     }
  25. }

и инициализируем его в bootstrap:

CODE:
  1. class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
  2. {
  3.     protected function _initResourceInjector()
  4.     {
  5.         Zend_Controller_Action_HelperBroker::addHelper(
  6.             new My_ResourceInjector(array(
  7.                 'db',
  8.                 'layout',
  9.                 'navigation',
  10.             ));
  11.         );
  12.     }
  13. }

Код выше, создаст ссылки на ресурсы: db, layout и navigation. Это значит, что теперь вы можете получить к ним прямой доступ из контроллеров.

CODE:
  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public function barAction()
  4.     {
  5.         $this->layout->disableLayout();
  6.         $model = $this->getModel();
  7.         $model->setDbAdapter($this->db);
  8.         $this->view->assign(
  9.             'model'      => $this->model,
  10.             'navigation' => $this->navigation,
  11.         );
  12.     }
  13.  
  14.     // ...
  15. }

Этото решение ведет к некоторому упрощению - теперь нет необходимости вытягивать bootstrap из объекта инициализации, а потом вытягивать ресурс.
Но, у этого решения есть несколько проблем: Откуда мы знаем, какие ресурсы были связаны с контроллером? Как мы можем это контролировать?
Отсюда, вытекает решение создать пул необходимых ресурсов для контроллера.
read more »

Настраиваем PHPUnit тесты в Zend Framework 1.10

Posted in Development, PHP, Testing, ZendFramework on February 9th, 2010 by Yaroslav Vorozhko – 4 Comments

В документации к Zend Framework есть описание как создавать PHPUnit тесты для контроллеров и для баз данных. Но, к сожалению они не объясняют как настроить приложения для выполнения Unit тестов.
В данной статье приведены шаги по настройке Unit тестов:
1. Установка phpunit
2. Установка xdebug
3. Настройка phpunit.xml
4. Создание TestHelper.php для инициализации приложения
5. Написание и выполнение простого теста

В первую очередь для выполнения тестов нам понадобится phpunit, который можео установить из PEAR пакета PHPUnit.

CODE:
  1. $ pear channel-discover pear.phpunit.de
  2. $ pear config-set preferred_state alpha
  3. $ pear install phpunit/PHPUnit
  4. or you may wish to install all the optional supporting packages:
  5. $ nano /usr/local/php5/etc/php.ini  // memory_limit = 32M; change this to at least 32M
  6. // if you get a permission denied error on the ZF community server, send an email to fw-servers mail list
  7. $ pear install --alldeps  phpunit/PHPUnit

Следующим шагом установим xdebug. Xdebug мы будем использовать для проверки покрытие кода тестами.

CODE:
  1. $ pecl install xdebug-beta

Теперь откройте ваш php.ini файл и пропишите загрузку xdebug.

CODE:
  1. zend_extension=/usr/lib/..../..../php5/20060613/xdebug.so

read more »