Так во всех API совершенно одинаковые методы, специально так. Документация на них есть по второй ссылке выше (API reference).

Плюс конкретно для Питоновского есть пара тестовых программок, которые показывают ключевое: как поискать, как построить сниппет. Ну и, конечно, MySQLdb + SphinxQL тоже никто не отменял.

В общем, довольно удивительно читать про «нету описания клиентов», да.

Offtopic: примерно настолько, как удивительно читать (был недавно тред на форуме) «ничего не работает, мы потратили кучу сил, надоело и плюнули» — при этом, разумеется, полчаса времени на то, чтобы отправить нам внятный багрепорт с конкретным описанием, а что же именно и при каких конкретно условиях не работает, не нашлось ни до, ни после треда. ;) Чо, бывает…

Стесняюсь спросить, а это что? :)

sphinxsearch.com/docs/2.1.1/sphinxql-reference.html
sphinxsearch.com/docs/2.1.1/api-reference.html

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

Что там догадываться, в документации все английским по-белому написано. Произвольный объем данных в фиксированную RAM не засунешь, поэтому все основывается на дисковых индексах все равно, конечно. Как иначе.

спасибо за сравнение!

Нам уже давно самим любопытно, но руки не доходили категорически, а тут такой подарок :)

а там случаем не несколько сотен тысяч запросов с отдельными выборками тормозят?

типично запрос select * from data where id in (1,2,3,...,100000) это куда быстрее, чем 100000 запросов select *… where id=$id; в случае монги синтаксис, понятно, другой, но беда-то та же самая

> сравнивать-то надо, по справедливости, с RT-индексами Sphinx-а.

там в итоге после OPTIMIZE совершенно (!) такой же дисковый получается :)

только вставки чуть побыстрее!!!

Не поверишь: если бы кто-то делал поиск не хуже, я бы в своем время тупо не начал писать Sphinx. ;)

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

Экранирование это один очень простой (реализация в одну строчку) метод EscapeString() в том API.

Про клиент ничего сказать не могу. «Какой лучше» в случае mysql, такой и в нашем, видимо.

Скажем так, сделать стало куда проще :)

id = log -1 --format='commit %C(green)%h%C(white) by %C(yellow)%an%C(white), %ar (%ad)%n%n%B'

Ага, понятно, "… а потом уже и анекдотов насочиняли" ;)

> Ну использовать sql, как говорят разработчики, стоит только для разработки, а само приложение все-таки должно работать через нормальное апи,

???

> непонятно, как и зачем серьезно заниматься NLP (и синтаксисом в частности) простому смертному.

Личное ощущение (возможно, неверное), что это смотря какие задачи перед собой ставить. Некоторые можно решить, некоторые нет.

> потом еще и результаты обучения использовать свободно нельзя

Опа. Как нельзя?!

> вот решений, где пришедший запрос компилируется в машинный код и запускается на выполнение, я не видел, я не видел и посвященных этому выступлений на конференциях. Я даже постов об этом не видел.

Я в свое время делал примитивный прототип, когда приделывал поддержку вычислялки выражений в Сфинкс. С удивлением обнаружил, что доводить до продакшна смысла особого нет, тк. в среднем ускорение получается сильно маргинальное. Все остальные оверхеды слишком высокие. Пост про сравнение вариантов реализации вычислялок самих по себе впрочем можно написать. Стоит заняться на досуге, интересно?

Да нет, не пришлось бы. Типично достаточно пары-тройки отдельных.

Построить индексы (в базе, в Сфинксе, итп) по нескольким наиболее частым отдельным (!) полям таки значительно лучше для производительности, чем не использовать никакие индексы совсем, правда? Вот я ровно об этом.

Ну и перебор в спецрешении как раз не совершенно полный, а поколоночный. В чем как раз немалая часть выигрыша.

> и несколько удивились полученным результатам.

А чего удивляться-то? При поиске без ключевых слов по атрибутам там того, полный перебор:

The SPH_MATCH_FULLSCAN mode will be automatically activated in place of the specified matching mode when the following conditions are met: 1) The query string is empty (ie. its length is zero), 2) docinfo storage is set to extern.

То есть сравнение, извините, из разряда «мы жахнули SELECT * по таблице MySQL без индексов и несколько удивились результатам» :)

Нужно наиболее селективное условие (навскидку возраст) проиндексировать как ключевое слово и его искать, тогда скорость несколько улучшится. Sphinx все равно проиграет, конечно. Специализированные решения всегда рулят. Привет anight-у ;)

> P.S. Попробуйте мой примерчик, и расскажите, на сколько процентов увеличилось быстродействие теста на вашей платформе.

Ну, для этого полную готовую программу выложить было бы неплохо, наверное? Хотя бы исходник, про бинарник уж молчу.

Да вроде очевидно, какие. Если действительно интересно — добро пожаловать в приват, а спорить здесь ради совершенно пустого спора — я не буду.

Пообсуждать качество перевода, кстати, завсегда готов в привате; поднабить руку именно с переводами одна из целей (вторичная, понятно).

И кстати, еще кроме Алгола, Кобола итп «радостей» жизни!