Раньше на Авито можно было найти нужный товар, используя фильтрацию по ключевым словам или навигацию по дереву категорий. Этот способ, хоть и казался привычным, был не всегда удобен — чтобы найти товар или услугу, нужно было сделать большое количество кликов. Более года назад у нас появилась релевантность, благодаря которой поиск стал лучше, и найти товар или услугу теперь проще и удобнее даже на главной странице. С этим нововведением в выдачу перестали попадать неподходящие, откровенно «мусорные» товары. И это только один из шагов, чтобы сделать поиск лучше. Мы постепенно изменяем инфраструктуру, что позволяет нам работать над качеством поиска более интенсивно, быстрее улучшать его и выкатывать новые фичи, приносящие пользу продавцам и покупателям на Авито.

В статье я расскажу, как менялся поиск на Авито: с чего начинали и как мы сейчас движемся по пути к улучшению жизни наших пользователей, поделюсь нашими нововведениями как в продукте, так и в его начинке — технической части. Совсем хардкорного мяса здесь не будет, но, надеюсь, вам понравится.

Добрый день, хаброжители!

Представляю вашему вниманию расширение для PostgreSQL, позволяющее отправлять поисковые запросы на Sphinx из PostgreSQL и получать результаты этих запросов.

Подробности реализации и ссылка на репозиторий под катом.

Мои читатели попросили сравнить проекты Manticore и Sphinx с точки зрения качества кода. Я могу сделать это только одним освоенным мною способом — проверить проекты с помощью статического анализатора PVS-Studio и посчитать плотность ошибок в коде. Итак, я проверил C и C++ код в этих проектах и, на мой взгляд, качество кода Manticore выше, чем качество кода Sphinx. Естественно, это очень узкий взгляд, и я не претендую на достоверность своего исследования. Однако меня попросили, и я сделал сравнение так, как умею.

В ходе работы DLP-система ежедневно перехватывает огромные массивы информации – это и письма сотрудников, и информация о действиях пользователей на рабочих станциях, и сведения о хранящихся в сети организации файловых ресурсах, и оповещения о несанкционированном выводе данных за пределы организации. Но полезной эта информация будет только в случае, если в DLP реализован качественный механизм поиска по всему массиву перехваченных коммуникаций. С тех пор, как в 2000 году увидела свет первая версия нашего DLP-решения, мы несколько раз меняли механизм поиска по архиву. Сегодня мы хотим рассказать о том, какие технологии мы использовали, какие видели в них преимущества и недостатки, и почему мы от них в итоге отказывались. Возможно, кому-то наш опыт окажется полезен.

Когда мы полтора года назад внедряли у себя генератор документаций Sphinx, перед нами стояла задача генерировать PDF. Дело оказалось весьма непростое. Готовых инструкций “бери и делай” на ресурсах не было. Мы пошли методом проб и ошибок. Через 3 дня мучений мы умели генерить PDF с нужным нам оформлением.

Сделали и забыли — работает же. Пока не случилась проблема со шрифтами. Снова намучились и снова решили. Но что примечательно — с тех пор готовой инструкции по генерации в PDF на просторах интернета не появилось. Поэтому выкладываю нашу. Внутри алгоритм с комментариями и файлами шаблона, особенностями ReST для LaTeX, которые мы собрали опытным путём.



Статья для тех, кто уже использует Sphinx, но имеет проблемы с LaTeX или PDF. Если вы только рассматривает Sphinx как инструмент документирования, будет полезно представлять, как готовить и подавать документацию в этих форматах.

Linux ядро на сегодняшний день — самый динамичный, сложный, крупный проект с открытым кодом. Как же обстоят дела с его документацией? Существует прямая связь: чем качественнее и доступнее документация проекта, тем проще для посторонних изучить основы дела, освоиться и стать полноправным участником.

На семинаре Kernel Recipies мейнтейнер документации Linux ядра Jonathan Corbet рассказал о нынешнем положении дел с документацией и о том, как будет совершаться переход от анархии к порядку. Первые успехи в этом начинании уже есть. Некоторые документы были недавно конвертированы в ReStructuredText с помощью питоновского Сфинкса. О том как это было рассказано внутри.

Андрей Аксенов (shodan, Разработчик поискового движка Sphinx)

Поиск устроен вот так:



Индексация – по большому счету, ничего сложного. Понятное дело, что по малому счету, там в каждой из трех «деталей» спрятан не то, что демон, а целое где-то стадо, где-то легион, не совсем понятно. Но концепция всегда простая. Все начинается с маленького простенького патчика к Многосерчу, а потом 15 лет этой херней занимаешься.

Берешь документы, разваливаешь их на ключевые слова. И просто взять и развалить документ на ключевые слова «мама, мыла, раму» – это ты не далеко ушел от grep’а, потому что потом все равно эти ключевые слова перебирать. Надо строить некую спец. структуру – полнотекстовый индекс. Вариантов для его построения человечество придумало в свое время довольно много, но, слава Богу, от всех отказалось и в нормальных продакшн системах, по большому счету, победил на данный момент вариант ровно один. Про него и буду рассказывать. Все остальные имеют скорее историческое значение, что ли, и практического интереса не представляют.

С прошлого митапа про Sphinx прошло уже больше года, так что самое время собраться снова. 18 июня состоится второй SphinxSearch meetup, территориально снова в Avito, регистрируйтесь и присоединяйтесь! Что-то интересное обещают порассказывать Avito, Ozon.ru и Нетология, ну и я тоже буду присутствовать, участвовать и состоять. Опять же пицца, кофе, печеньки. Под катом чуть подробнее о докладчиках и программе. Ну — и куда в точности приходить тоже там!!!

Мы любим делать интервью с нашими докладчиками. На этот раз — интервью с Андреем shodan Аксеновым, создателем поискового движка SphinxSearch(не знаю как сейчас, но раньше хабр использовал именно этот движок для поиска по сайту) и, как оказалось, еще пары движков. На нашей конференции он будет рассуждать на извечную тему: Devs vs CTO vs CEO. Само интервью вышло довольно интересным. Андрей честно и откровенно ответил на вопросы, за что ему большой респект :)

Я тебя знаю как разработчика Sphinxsearch, но, как показывает твоя краткая биография, которую ты дал в описании доклада, похоже компьютерная графика — твоя главная страсть?

Все одновременно проще и сложнее, какой-то главной мегастрасти нету :) Есть сколько-то интересные области, есть безразличные. Делать всякий низкий уровень, типа поискового движка, 3D игры, обработки видеозахвата, крохотного недогипервизора (V8086), патчить MySQL или ядро операционки, писать спецмодули к Апачику, улучшать известный алгоритм сжатия или даже просто ковыряться с особо толстыми и тормозными SQL запросами — все это бывает довольно интересно (а бывает нет! но чаще интересно). А вот рисовать формочки для GUI, неважно, на моднейшем Node.js или дохлом Delphi, или там править унылые отчеты в 1C — таки не очень. Говорю по личному опыту, тк. в какой-то мере занимался всем вышеперечисленным и еще всяким.

Что обычно делает python-программист, когда его отправляют воевать с ошибкой?
Сначала он лезет в sentry. Здесь можно найти время, сервер, подробности сообщения об ошибке, traceback и, может быть, какой-нибудь полезный контекст. Затем, если этих данных недостаточно, программист идет c бутылкой к админам. Те залезают на сервер, ищут это сообщение в файловых логах, и, может быть, находят его и некоторые предшествующие ошибке записи, которые в редких случаях могут помочь в расследовании.
А что делать, если в логах только loglevel=ERROR, а ошибка настолько крута, что ее локализация требует сопоставления логики поведения нескольких различных демонов, которые запущены на десятке серверов?

Решение — централизованное хранилище логов. В самом простом случае — syslog (за 5 лет, что был развернут в rutube, не использовался ни разу), для более сложных целей — ELK. Скажу честно, "ластик" — крут, и позволяет быстро крутить разнообразную аналитику, но вы интерфейс Kibana видели? Этой штуке так же далеко до консольных less/grep, как винде до линукса. Поэтому мы решили сделать свой велосипед, без Java и Node.js, зато с sphinxsearch и Python.

Сегодня в этот погожий весенний денек хочется написать не только о поиске видео, но и о технической
реализации работы со Sphinxsearch в нагруженном Django-проекте.

Начать стоит, наверно, с постановки бизнес-задачи:

• Необходимо искать релевантные видео по названию, описанию и другим текстовым данным
• К каждому видео надо искать похожие видео
• Надо чтобы нужные ролики показывались в выдаче нужных запросов на нужных местах.

А еще нефункциональные требования:

• Django-проект с дофига просмотрами и постоянными обновлениями описаний видео
• Инкапсуляция работы с поисковым движком в библиотеке и совместимость с остальными библиотеками на сайте (в первую очередь, Django REST Framework)

Про то, как в Rutube используется sphinxsearch и будет данный рассказ.

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

Одна из неприятных особенностей Sphinx'а — очень скудная информация на русском языке. Удивишись тем, что тема распределения нагрузки не была затронута, решил поделиться данным решением на Хабре.

Цель: повысить производительность Sphinx путём разделения нагрузки на несколько потоков.

Всем привет! Не так давно мы реализовали полнотекстовый поиск для системы сбора отзывов Cackle Reviews. Получилось здорово, теперь любой модератор за несколько миллисекунд может найти интересующие его отзывы по слову или предложению с поддержкой стемминга (нечёткого поиска по части слова или его словоформам). Всё это работает на Sphinx — системе полнотекстового поиска.

В интернете есть много статей о Sphinx, но, к сожалению, часть из них устарела, некоторые другие не претендуют на полный и точный how to. Так что в данном посте мы постарались изложить все шаги — установки, настройки, индексации и поддержке дельта индекса.

Вот вы там все сидите и ничего не знаете, а мы, тем временем, пилим помаленьку мега-релиз поискового движка Sphinx за номером 3.0. Грядет ряд больших переделок. Часть из них, как полагается, ещё даже как следует не начата. Однако большая часть уже скорее готова, чем нет. А отдельно взятые изменения даже протекли в публичную ветку 2.3. Так что, пожалуй, настало время вкратце начинать рассказывать, чего ожидать в светлом будущем: надеюсь, не столь отдалённом. Кому интересно почитать, все под кат; кому послушать, приходите на meetup в эту субботу. Если совсем вкратце, то: прощай, концепция дополняющего основную базу движка; привет, хранилище документов, тотальный RT, репликация, REST и ряд других известных ключевых слов.

Обработка текста в поисковом движке выглядит достаточно простой снаружи, однако на самом деле это сложный процесс. При индексации текст документов должен быть обработан стриппером HTML, токенайзером, фильтром стоп-слов, фильтром словоформ и морфологическим процессором. А ещё при этом нужно помнить про исключения (exceptions), слитные (blended) символы, N-граммы и границы предложений. При поиске всё становится ещё сложнее, поскольку помимо всего вышеупомянутого нужно вдобавок обрабатывать синтаксис запроса, который добавляет всевозможные спец. символы (операторы и маски). Сейчас мы расскажем, как всё это работает в Sphinx.

Картина в целом

Упрощённо конвейер обработки текста (в движке версий 2.х) выглядит примерно так:



Выглядит достаточно просто, однако дьявол кроется в деталях. Есть несколько очень разных фильтров (которые применяются в особом порядке); токенайзер занимается ещё чем-то помимо разбиения текста на слова; и наконец под «и т.д.» в блоке морфологии на самом деле находится ещё по меньшей мере три разных варианта.

Поэтому более точной будет следующая картина:

Одна из самых важных задач стоящих при разработке сайта, это реализация полнотекстового поиска. Один из популярных и простых вариантов реализации, это использование Sphinx. На хабре уже есть посвящённые ему статьи, но не заслуженно не упомянута библиотека Query Builder. Это я и постараюсь исправить.

Здравствуй, читатель!

Некоторое время назад мне была поставлена задача внедрения MediaWiki в корпоративной сети.
И главной проблемой этого внедрения стал поиск информации, содержащейся в вики.
В этой статье я хотел бы рассказать о том, как подружить поиск Sphinx с MediaWiki.
Причина по которой я хотел бы это написать — отсутствие русскоязычной документации и более-менее приличного руководства или описания, которое помогало бы моим коллегам быстро и просто начать использовать этот прекрасный поисковый механизм.
Возможно, я просто не умею пользоваться гуглом…

Задача

К примеру, у вас есть уже настроенный и распространённый по всей компании сервис мониторинга Zabbix а ещё вы пользуетесь поисковым движком Sphinx. Он ищет быстро, но встроенных средств для живого мониторинга его производительности в разрезе индекса не имеет. К примеру, поисковых серверов у вас много и вы хотите соотносить потребление ресурсов системы каждым конкретным индексом дабы понимать — как распределять их по серверам — а так же видеть — какая из коллекций начинает отвечать дольше, чем хотелось бы — и понимать, коррелируется ли это с возрастанием пользовательской нагрузки или ещё чем-то.

Доброго времени суток, дорогие читатели!

Хочу рассказать вам об интересной задаче, которая стала передо мной в рамках проекта и, естественно, о ее решении.

Исходные данные:
Стандартный набор LAMP (далее СС),
Yii framework (версия здесь не важна),
удаленный сервер (далее УС), на котором установлен демон Sphinx, searchd.
На УС создан пользователь с правами рута (но не сам рут).
На СС установлен модуль ssh2_mod для PHP.

Сразу оговорюсь, в этой статье я не буду расписывать особенности Sphinx, кому интересно, могут почитать официальный мануал sphinxsearch.com/docs/current.html.
Ограничусь только общей информацией.

Итак, Sphinx — поисковый демон, в моем случае работает с MySQL. Основная особенность — он индексирует базу по определенным запросам (описанным в конфиге сфинкса), и результат выборки сохраняет в свои файлы. Чтобы информация была актуальной (в MySQL возможно и добавление и редактирование записей), нужно запускать индексацию сфинкса. Тогда, он сделает повторную выборку и сохранит ее себе.

Задача:
Запускать индексацию сфинкса на УС.
Причина именно удаленного запуска состоит в том, что необходимо запускать команды по крону с конкретными параметрами, определяемыми в коде. Кроны запускаются с СС.
Т.е. на сервере запускается крон, метод которого выполняет индексацию на УС.

Если это корпоративный блог, то, кажется, будет вполне целесообразным рассказать о нашей Компании, сотрудники которой будут публиковать здесь свои посты.
Итак, ООО “Инновационные поисковые технологии”

2008 г.

Компания плотно работает по двум направлениям: IT-разработки (преимущественно, направление 1С, SAP, отраслевые решения для Microsoft Dynamics NAV) и создание административных регламентов в лесохозяйственной и социальной сферах законодательства РФ. Разработка и внедрение программных продуктов осуществляется в основном на территории Саратовской области (заказчики – заводы, крупные и мелкие промышленные и торговые предприятия, ИП), работы по созданию НПА ведутся, в основном, на территории регионов государственных заказчиков: Смоленская область, Псковская область, Тверская область, Калужская область, Москва. В 2008г. перед нами впервые остро обозначаются две проблемы в работе с госзакупками: невозможность качественного консолидированного поиска (все тендеры публикуются на своих госпорталах, единый сайт госзакупок появится только через три года), полное отсутствие инструментов аналитики госзакупок (эта проблема на официальном ресурсе госзакупок России не решена и по сей день. Компании, анализирующие рынок, пользуются или услугами консалтинговых компаний или держат для этих целей целые отделы). Год завершается подписанием годового контракта с ИА Трейд.Су, большими обещаниями со стороны сотрудников этой организации, и ожиданиями успешного бизнеса в госзакупках.

2009 – 2010 г.

На смену позитивным ожиданиям достаточно быстро приходит разочарование: нужные закупки ищутся не в полном объеме, интерфейс приобретенного ресурса «съедает» время и нервы, потребность в аналитике нашего участия в госзакупках растет, а разумное решение этого вопроса отсутствует как факт. Наличие сильного IT-отдела и активная позиция компании становится хорошей основой для принятия нестандартного решения: мы создадим лучшие в России инструменты для поиска и анализа госзакупок.
В середине 2009 года проводится подробный анализ всех существующих российских тендерных систем, пишется техническое задание. Главные особенности, которые создавали ту самую разницу, заключались как в нашей концепции интерфейса (мы коснемся этого более подробно в блоге), так и адаптированным под проект поисковым движком Sphinx, (позже программисты обещали поделиться своими наработками, а сейчас в наших индексах около 15 млн. документов, и проект на таком массиве показывает хорошее быстродействие). На начало проекта в эксплуатации – два арендованных сервера. В июле 2010 года происходит первый запуск пока еще бесплатного сервиса с предоставлением информации по госзакупкам Саратовской, Самарской и Пензенской областей. Идет отладка основного функционала системы.