Обоснование решений. Использование метрик при выборе технологий

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

Проблема

На одном из текущих проектов встала необходимость выбрать поисковой движок. Система разрабатывается на основе одного из PHP-фреймворков, приближающего удобство работы к Ruby on Rails. База данных — PostgreSQL. Пользователи чаще всего ищут документы среди здоровенной базы текстовых материалов, лежащих в файловой системе. Но могут и уточнить запрос через расширенный поиск — тут нужно использовать еще и атрибуты документа, которые хранятся в базе данных.

Весь контент на русском языке, так что простым сравнением запроса с текстом документа не обойтись — нужно учитывать морфологию. Да и объем хранилища немаленький, с перспективами многократного роста, так что нужны хорошие механизмы индексации. Такие движки есть у двух популярных поисковиков — Яндекса (Яндекс.Сервер) и Google (Google Search Appliance). Причем у первого есть бесплатная версия, пусть и с ограничениями. На первом этапе проекта клиент больше занят созданием и отладкой общей инфраструктуры компании, так что готов по максимуму использовать бесплатное ПО. Поэтому даже чужой логотип в результатах поиска вполне терпим, да и заказчик всеми руками за известный бренд.

Тут всплывает первая проблема. Яндекс.Сервер позволяет искать по полям БД только в платной версии. Значит нужно совмещать два результата поиска — полученный внешним движком и собственный, по полям базы данных. Либо искать компромиссное решение. Первый вариант имеет тонну технических подводных камней. Даже найдя после брейншторминга более-менее подходящую схему взаимодействия двух движков, нерешенными остаются и производительность, и релевантность итоговых результатов, и еще серия моментов. Нужно ведь чтобы сперва отработал один из поисковиков, затем передал результаты другому, чтобы искать уже только среди них. А кроме этого — задача обработать, склеить, отсортировать итоговый список.

С компромиссными вариантами также обнаружились проблемы. Альтернативные поисковые механизмы есть в достаточном количестве. Но окончательно убедить клиента в том, что они смогут получить хоть как-нибудь сравнимое с Яндексом качество поиска в русскоязычных текстах никак не получалось. Так что вопрос долго футболился между обсуждениями итогового решения и необходимостью дополнительных исследований.

Решение

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

  1. производительность:
    1. скорость работы;
    2. выдерживаемые нагрузки;
  2. качество:
    1. поиск по базе данныхo;
    2. поиск по файловой системе;
    3. релевантность;
    4. морфология;
  3. стоимость;
  4. совместимость с ПО;
  5. перспективность:
    1. бренд и перспективы развития;
    2. наличие крупных и известных проектов, использующих движок;
    3. опытность и размер команды разработчиков движка.

Все это нужно для выбора из следующего списка:

Список неоднороден — тут и отдельный поисковой сервер, и просто подключаемые библиотеки. Но наша задача — выдавать удовлетворяющий требованиям результат. А точный формат взаимодействия основной системы и поисковика в них не задан. Так что тут у нас полная свобода действий. 

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

Характеристика Движок Яндекс.Сервер (бесплатный) Яндекс.Сервер (платный) Sphinx Tsearch2 DataPark MnoGoSearch
Скорость работы отлично отлично отлично хорошо хорошо средне
Выдерживаемые нагрузки отлично отлично хорошо хорошо хорошо хорошо
Поиск по базе данных нет да, с ограничениями да да да да, с ограничениями
Поиск по файловой системе да да да нет да да
Релевантность да да да слабая да да
Морфология отлично отлично хорошо хорошо хорошо хорошо
Стоимость, тыс. $ 0 ~90 0 0 0 0
Бренд и перспективы развития отлично отлично отлично хорошо хорошо туманно
Наличие крупных и известных проектов, использующих движок список проектов (в том числе РИА Новости, Ведомости, Альфа-Банк) список проектов (в том числе РИА Новости, Ведомости, Альфа-Банк) список проектов (в том числе Joomla, phpBB) включен в PostgreSQLсписок проектов не найден (известно, что используют МойКруг, MediaWiki, www.linux.org.ru) список проектов (широко известных нет) список проектов (в том числе Много.ру, PHP.ru)включен в PHP
Опытность и размер команды разработчиков отлично отлично хорошо отлично хорошо хорошо

В итоге был выбран движок Sphinx. Он не так известен как Яндекс, но имеет очень хорошие показатели по всем важным нам параметрам. Да и по самой тревожившей клиента характеристике — морфологии — различие не настолько критичное. К тому же, проект делает российский разработчик.

Развитие решения

Простое сопоставление вариантов решений с характеристиками помогло сделать более быстрый выбор с минимальными усилиями. В более сложных случаях подход к выбору можно сделать еще более формализованным — трудно сравнивать “хорошо” и “$90 тыс”. Для этого проставим каждому из движков балл по каждой из характеристик. Можно взять банальное от 1 до 5 и расставить оценки на глазок. Можно для каждой метрики выбрать суб-характеристики и уже на их основе определить балл. Тут все зависит от того, насколько важно исследование. Для моего случая табличка будет такой:

Характеристика Движок Яндекс.Сервер (бесплатный) Яндекс.Сервер (платный) Sphinx Tsearch2 DataPark MnoGoSearch
Скорость работы 5 5 4 4 4 3
Выдерживаемые нагрузки 5 5 4 4 4 4
Поиск по базе данных 0 3 5 5 5 2
Поиск по файловой системе 5 5 5 0 5 5
Релевантность 5 5 4 3 4 4
Морфология 5 5 4 3 4 4
Стоимость 5 1 5 5 5 5
Бренд и перспективы развития 5 5 5 4 4 3
Наличие крупных и известных проектов, использующих движок 5 5 4 4 2 3
Опытность и размер команды разработчиков 5 5 4 5 4 3

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

Балл = P1*A1 + P2*A2 + … + Pn*An
где Pn — вес метрики, An — балл по метрике

Характеристик у нас 10, суммарный балл по ним — 33. Выходит, вес одного балла — 3,03% (т.е. 100% / 33). Получим такую табличку весов:

  Характеристика Важность, 1-5 Вес, %
A1 Скорость работы 2 6,06
A2 Выдерживаемые нагрузки 3 9,09
A3 Поиск по базе данных 5 15,15
A4 Поиск по файловой системе 5 15,15
A5 Релевантность 4 12,12
A6 Морфология 5 15,15
A7 Стоимость 5 15,15
A8 Бренд и перспективы развития 1 3,03
A9 Наличие крупных и известных проектов, использующих движок 2 6,06
A10 Опытность и размер команды разработчиков 1 3,03
  Итого 33 100

В итоговом расчете получаем вот что:

Характеристика Движок Яндекс.Сервер (бесплатный) Яндекс.Сервер (платный) Sphinx Tsearch2 DataPark MnoGoSearch
Средний балл 4,5 4,4 4,4 3,7 4,1 3,6
Средний взвешенный балл 4,24 4,09 4,48 3,45 4,33 3,82
Итоговое место 3 4 1 6 2 5

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

Аналогичные методики работают и в других случаях. Например, “расчет телодвижений” GOMS при сравнении эффективности интерфейсных решений. Или просто подсчет рейтингов для чартов на основе серии факторов. На такие количественные расчеты может уйти уйма времени — не всегда рационально их использовать. Но иногда сделать правильный выбор вслепую гораздо сложнее. Да и доказать его обоснованность на пальцах не проще.

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

13 Comments Обоснование решений. Использование метрик при выборе технологий

  1. Виталий

    Забыт Solr.

    В статье перечислены и сравниваются разные по сути вещи – отдельная библиотека реализующая специфический движок хранения для конкретной бд(Tsearch2), система претендующая на интерпрайз DataPark, но не имеющая своей подсистемы работы с индексом, и коммерческий Yandex.Server единственный из всех перечисленных своими средствами реализующий парсинг бинарных форматов. Сильно разные это штуки по функционалу.

    С таким подходом вы явно не найдете разницы между Lucene Solr и Nutch, но она есть.

    Reply
  2. Juras Vetrau

    Виталий,

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

    Solr поизучаем, спасибо за наводку 🙂

    Reply
  3. Hienadz Drahun

    Юра,

    Такая методика используется также в Task Analysis, для определения приоритетов use cases или функциональности.

    Reply
  4. Juras Vetrau

    Гена,

    Ну и в целом в системах принятия решений 🙂 Хотелось написать на наглядном примере, а про конкретику не всегда можно говорить до запуска системы. Так что выбрал пример с поиском, да и скриншоты приходится брать из старых проектов 🙂

    Reply
  5. Maxime

    Виталий, в DataparkSearch используется смешанное хранение, дляобратного индекса используется как раз таки собственнй индекс и при поиске SQL-сервер может не использоваться вообще.

    Reply
  6. Pingback: Сравнение поисковых движков « СоНоты

  7. Pingback: Founds » Blog Archive » DataparkSearch comparison

  8. werutzb

    Hi!

    I would like extend my SQL capabilities.
    I red so many SQL books and would like to
    get more about SQL for my position as db2 database manager.

    What can you recommend?

    Thanks,
    Werutz

    Reply
  9. Лекс

    По поводу tsearch2 очень спорный пункт релевантности. Спорный потому как человек который писал статью явно не вникал во все тонкости. Релевантность не только будет на ровне к примеру со сфинксом, но и ее можно увеличить добавив все необходимые минимизации отдельными полями, так как tsearch тесно интегрирован с индексами postgresql это безумно удобно и ему как минимум 4ка, и еще повысит оценку необходимо по пункту “Бренд и перспективы развития”.

    Reply
  10. Дмитрий

    @Лекс
    Имя огромный опыт с tsearch2 и Sphinx могу заметить, что при умелом обращении tsearch2 делает Sphinx по параметру релевантности.

    Reply
  11. Дмитрий

    @Лекс
    А ну и правильно ты заметил что перспективы развития у tsearch2 очень большие, так как поиск работает за счет индексов постгреса и каждое улучшение работы GIN индекса ускоряет работу поиска. По поводу скорости, не знаю с чем сравнивать, но базу данных с 10 000 000 записей у меня держит один сервер который генерирует около 6 000 000 запросов в день. Много это или мало уж не мне судить.

    Итого я бы дал:

    Производительность – 4 (но она поправится в скоре, воерьте)
    Перспективы – 5
    Релевантность – 5

    Reply
  12. Pingback: FTS Engine для Django/PostgreSQL

Leave a Reply

Your email address will not be published. Required fields are marked *