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 года происходит первый запуск пока еще бесплатного сервиса с предоставлением информации по госзакупкам Саратовской, Самарской и Пензенской областей. Идет отладка основного функционала системы.

Статья нацелена на тех кто уже знает что такое Sphinx и SphinxQL
Цель: Обеспечить непрерывность работы поиска по сайту с помощью Sphinx в момент проведения технических работ над одной из нод Sphinx кластера.

Sphinx отличный инструмент для организации поиска по сайту. В проекте в котором я участвую поиск объявлений происходит с помощью Sphinx. Объявления хранятся в бд в EAV модели а поиск по ним выполняет Sphinx затем объявления извлекаются по найденным сфинксом идентификаторам. Таким образом если Sphinx перестанет работать то это скажется на всём сайте.

Для работы используются rt индексы sphinx для моментального внесения изменений в поисковую выдачу если какое либо объявление будет отредактировано или забанено. Пока это работало на одной ноде всё было хорошо до тех пор пока не возникало необходимости внести изменения в саму структуру индексов. Для изменения списка атрибутов в поисковом индексе необходимо было править конфигурацию, перезапускать сфинкс и выполнять переиндексацию объявлений. Для того чтобы это производить без остановки работы сайта решено было построить кластер с одной главной нодой фактически выполняющей роль балансировщика и двумя дочерними нодами содержащими индекс и являющимися зеркальными между собой.

Немного облегчил установку sphinxapi.py через pip.
Просто

pip install https://github.com/Romamo/sphinxapi/zipball/master

Используем

import sphinxapi

Поисковый сервер Sphinx (sphinxsearch) позиционируется как система, весьма неплохо масштабируемая под высокие нагрузки и большие объёмы индексов. В целом это неплохо — но иногда под рукой нет машины с 16-ядерным процессором и 256Гб оперативки. А что делать, если ядро всего одно? А если и с объёмом памяти не очень? А если это не сервер и даже не средний PC, а вообще роутер на SoC, с далеко не самым быстрым «камнем», и где всего 32Мб оперативки, да и ту нужно делить с другими процессами и системой? Взлетит ли в таком случае поисковик? Будет ли работать? Оправдано ли?
Да, взлетит. Да, будет работать. Да, вполне оправдано.

Есть у нас хобби — развивать интернет-магазин по продаже напитков и продуктов оптом.
Товары у нас появляются путем привлечения поставщиков и размещения их товаров в магазине.
Клиенты — владельцы ресторанов и кафе, которые заказывают товары оптом с доставкой на следующий день.
Когда количество позиций по товарам перевалило за 20 тыс., поиск через like в MS SQL стал слишком уж неверный, тем более когда поставщики загружали товар с ошибками или названия товаров были латиницей/кириллицей. После месяца различных ухищрений в процедуре поиска с конвертацией latin-cyrilic-latin, исправления грамматических ошибок, мы в конце концов осознали, что это тупиковый путь развития поиска.

Привет, Хабр!

Представляем вашему вниманию Searchanise — поисковый сервис, созданный специально для интернет-магазинов. Бесплатный, совсем-совсем.

Проект уже далеко не в тестинге, а вполне в продакшне: прямо сейчас полторы тысячи онлайн-магазинов используют Searchanise. И это только начало (по крайней мере, мы на это надеемся).