Использование Sphinx Search с ORM

Question

Я ищу реализацию поиска Sphinx на нашем сайте.

Вместо того, чтобы делать странные вещи с включением новых библиотек и т. Д., Мне больше смысла интегрировать его с помощью SphinxQL, так как это довольно близко к собственному SQL . Однако я обеспокоен тем, что нам может понадобиться изобретать колесо, чтобы мы могли использовать Sphinx с нашей системой.

Чтобы предотвратить это, я хочу перетащить Sphinx в нашу систему ORM.

Неужели кто-нибудь пробовал это раньше или может возникнуть проблема, с которой мы можем столкнуться?

В настоящее время мы используем сочетание Zend Framework с Propel

Answer 1

Долгое время Propel пользователя здесь, который недавно добавил Сфинкса в наше приложение с использованием Zend Framework.

Обратите внимание на Propel и MVC

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

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

Вы должны использовать тот же подход для реализации поиска Sphinx. Попробуйте абстрагировать его, используя расширенные классы ORM.

Заметки о Сфинкса

1. Создание представления для упрощения индексации: Sphinx не очень хорошо играть с передовыми подзапросов и легко запутается функциями MySQL. Попробуйте абстрагировать данные, которые вы хотите индексировать, чтобы общий SQL был таким простым, как SELECT id, field1, field2, field3 FROM MyView. Это особенно полезно, когда вы можете связать каждый документ Sphinx с учетной записью пользователя или с каким-либо другим внешним ключом, который является нетривиальным.

2. Sphinx может только индекс UINT: Возможно, никакой опасности в большинстве случаев, но вы не можете использовать UUID, или отрицательные числа, чтобы работать вокруг различных нечетных структур баз данных.

3. Избегайте дублирования документа ID: В каждом индексе Sphinx каждый идентификатор документа должен быть уникальным. Предположим, вы хотите сделать объекты типа A доступными для поиска, но вы хотите найти объект A путем поиска по тегам, комментариям и географическим положениям. Правильный способ сделать это с помощью Sphinx состоит в том, чтобы сделать индекс A со всеми метаданными об объекте и отдельными индексами для комментариев, тегов и географических позиций и убедитесь, что вы поместите атрибут sql_attr_uint для отображения обратно на объект A, затем выясните, что получить в вашем коде.

4. Используйте последнюю версию Сфинкса: Сфинкс в условиях быстрого развития и распределение, как Debian, как правило, имеет довольно устаревшую версию в репозитории. Если возможно, и у вас есть время для обеспечения стабильности, скомпилируйте его из источника (Sphinx имеет несколько зависимостей, поэтому в большинстве случаев это не будет проблемой). Кроме того, у кода библиотеки PHP есть отказоустойчивость, которая препятствует тому, чтобы клиентский код разговаривал с слишком недавней версией демона поиска Sphinx.

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

   $ а = AQuery :: Create() -> findByPk (ID_FROM_SPHINX)

   в цикле Еогеасп. Но в некоторых случаях это может быть слишком неэффективно, чтобы полагаться на ORM, чтобы получить список, особенно если вы просто хотите перечислить несколько столбцов, например. результаты поиска. Затем вместо этого вы можете использовать настраиваемый оптимизированный SQL-выбор, чтобы получить информацию (можно сделать в классах Propel).