Sphinx Search

Первая 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.

До встречи!

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

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 запросы и анализируйте логи.

Sphinx Search плагин поиска для Wordpress – поиск с Sphinx Search для начинающих

Posted in PHP, Sphinx Search, WPSphinx plugin on December 23rd, 2009 by Yaroslav Vorozhko – 6 Comments

Два года назад Петр Зайцев из Percona попросил меня написать ему плагин поиска для WordPress используя Spinx Search. Сейчас этот модуль работает на mysqlperformanceblog.com.

Данная статья будет полезна тем кто только начинает знакомится с Sphinx Search. Ее можно использовать  как начальное руководство для написания простого поисковика на Sphinx Search.

Возможности плагина:

  • Быстрый поиск, ну это и понятно, мы ведь используем Sphinx Search
  • Возможность использовать расширенный синтаксис поиска (http://www.sphinxsearch.com/doc.html#extended-syntax)
  • Сортировка результатов поиска по дате или по релевантности
  • Поиск по постам, комментариям или страницам. Это отличает этот плагин от стандартного поиска на WP, который не производит поиск по комментариям и страницам. А также многие другие поисковые плагины не имеют такой возможности.
  • Есть возможность исключить из результатов поска комментарии, страницы или посты
  • И многие другие вкусности, про которые вы можете узнать на странице плагина

Все это позволяет нам делать Sphinx Search, и сейчас мы разеберем как это реализовано.

Конфигурационный файл

В первую очередь нам надо знать как устроен индекс. (sphinx.conf можно найти в каталоге rep/sphinx.conf)

Мы использовали самое простое решение это один монолитный индекс для всех данных: постов, страниц и комментариев. Формируется такой индекс единым SQL запросом, который приводить я тут не буду, он очень длинный и нас сейчас он не интересует (это все таки статья про Spihnx Search, а не про MySQL :) ), но посмотреть его можно в том же sphinx.conf.

Единственное, что нам стоит знать это какие атрибуты у нас есть:

  • comment_ID
  • post_ID
  • isPost
  • isComment
  • isPage
  • post_type
  • date_added

Атрибуты isPost, isComment и isPage отвечают за тип источника. date_added содержит дату добавления данных.

Поиск

Теперь рассмотрим как делать поиск, фильтрацию и сортировку используя атрибуты.
Пример:

CODE:
  1. if ( empty($this->params['search_comments']) ){
  2.     $this->config->sphinx->SetFilter('isComment', array(0));
  3. }
  4.                
  5. if ( empty($this->params['search_pages']) ){
  6.     $this->config->sphinx->SetFilter('isPage', array(0));
  7. }
  8.            
  9. if ( empty($this->params['search_posts']) ){
  10.     $this->config->sphinx->SetFilter('isPost', array(0));
  11. }
  12.        
  13.        
  14. if ( $this->params['search_sortby'] == 'date' ){ {
  15.     $this->config->sphinx->SetSortMode(SPH_SORT_ATTR_DESC, 'date_added');}
  16. } else {
  17.     $this->config->sphinx->SetSortMode(SPH_SORT_RELEVANCE);
  18. }
  19.  
  20. $res = $this->config->sphinx->Query ( $this->search_string, $this->config->admin_options['sphinx_index'] ););

Первое, если один из аттрибутов не установлен, то с помощью SetFilter('isPost', array(0)) мы исключаем его из поиска.
Второе, если пользователь захотел отсортировать результаты по дате добавления, то мы испольязем режим сортировки по атрибуту SetSortMode(SPH_SORT_ATTR_DESC, 'date_added'). По умолчанию данные сортируются по релевантности.
И последнее мы выполняем собственно запрос с помощью метода Query(), первый параметр это запрос введенный пользователем, второй это индекс по которому выполнять поиск.

Результат поиска

Результат поиска мы должны обработать следующим образом:

  • Получить найденный идентификационные номера и по ним получить данные
  • Используя атрибуты isPost, isPage и isComment мы узнаем из какой таблицы получать данные
  • Потом объединяем полученный результат
  • И последнее мы выделяем ключевые слова в результата, путем добавления html тэга STRONG вокруг слова.

Выделение ключевых слов делает метод BuildExcerpts

CODE:
  1. $opts = array(
  2.     'limit'  => $this->config->admin_options['excerpt_limit'],
  3.     'around' => $this->config->admin_options['excerpt_around'],
  4.     'chunk_separator' => $this->config->admin_options['excerpt_chunk_separator'],
  5.     'after_match' => $this->config->admin_options['excerpt_after_match'.$isTitle],
  6.     'before_match' => $this->config->admin_options['excerpt_before_match'.$isTitle]
  7. );
  8.                    
  9. $excerpts = $this->config->sphinx->BuildExcerpts(
  10.     $post_content,
  11.         'main_'.$this->config->admin_options['sphinx_index'],
  12.     $this->search_string,
  13.     $opts
  14. );

В параметрах этого метода надо указать строку результата в которой надо выделить слова, индекс, запрос и параметы выделения.  В результате мы получем строку с подсвеченными ключевыми словами, которые пристуствовали в запросе.

В итоге как мы видим, написать свой поиск используя Sphinx Search достаточно просто. Если у вас большой блог и вы также хотите получить быстрый и много-функциональный поиск, тогда скачивайте WPSphinx плагин - это бесплатно. :)

Как вы используете Sphinx Search API?

Posted in Development, LinkAider, Projects, Sphinx Search, ZendFramework on December 21st, 2009 by Yaroslav Vorozhko – Be the first to comment

Sphinx Search API для PHP пердставляет собой единый класс, который позволяет использовать все возможности Sphinx Search через его интерфейс. Но, такой класс является удобным только для небольших скриптов и задач.
Для более сложных задач и больших веб приложений необходимо другое решение. И это решения является проектированием и реализацией собственной обертки для Sphinx Search API.

В нашем проекте LinkAider.com мы используем следующие понятия и классы при работе с Sphinx Search:

  1. Сфинкс клиент, отвечающий за подключение, выполнение запросов и обработку ошибок. Для разработчика сфинкс клиент невидим, мы только сообщаем ему параметры подключения к searchd.
  2. Сфинкс индекс - это один из основных классов, с которым работает разработчик, этот класс отвечает за формирование запросов и выполнение запросов через Сфинкс клиент, а также за обработку результатов запроса.
  3. Сфинкс запрос - это еще один класс к которому обращается разработчик для составления запросов. Каждый запрос отвечает за свои индекс к которому обращается, а также содержит свои фильтры, группировки, сортировки и собственно сам запрос.
  4. Сфинкс результат - это класс, который разбирает ответ сфинкса и предоставляет удобный интерфейс к информации по каждому запросу, также он содержит информацию об ошибках, которую испльзуетя Сфинкс клиент для логирования. Сфинкс результат используется разработчиками для создания запросов к базе данных и получения искомых данных.

Пример работы выглядит следующим образом:

  1. Мы создаем объект Сфинкс индекс, который инициализирует Сфинкс клиент, устанавливая для него параметры подключения.
  2. Потом мы создаем объекты запросы для каждого указываем фильтры, группировки и т.п., и указываем к какому индексу делать запрос. Запросов может быть один или несколько, несколько запросов обрабатываються паралельно, что улучшает общую производительность системы.
  3. Каждый созданный запрос мы добавляем в Сфинкс индекс, при добавлении мы можем также указатьк какому индексу делать запрос.
  4. Специальный метод Run класса Сфинкс индекс запускает все запросы и как результат возвращает нам объект Сфинкс результат.
  5. Данные из Сфинкс результата мы используем чтоб создать запросы к базе данных и получить искомые данные.

Преимущеста, которые мы получем от работы с такой библотекой - это простота. Разработчик используя объект Сфинкс запрос может выполнять любые запросы.
Сфинкс результат предоставляет удобную обертку над массивом результата.
Нет необходимости помнить множество констант SphinxClient и парсить массив результата. В общем это выглдит так, как будто вы работаете с обычной таблицой, но не до конца. :)

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

Решение я вижу, в привязке каждого запроса к определенной таблице или группе таблиц.

По описнной выше логике я разрабатываю модуль Sphinx Search для Zend Framework, который я планирую выложить в откртый доступ очень скоро, возможно к новому году.

Поэтому хотелось бы узнать как вы используете Sphinx Search и какие преимущества и недостатки вывидите у вашего подхода.

Буду рад любым советам и рекомендациям.