Небольшой — потому-что в сравнении со Сфинксом скорость работы действительно не впечатляет, а для ленивых — потому-что все очень просто.
Чем привлек внимание, не смотря на скромные характеристики?
1. Возможностью real-time индексирования.
2. Наличие атрибутов документа и их использование в поиске и сортировке результата.
3. Простота работы и компактная четкая документация (хватило пары дней на изучение, собственно беглый взгляд по диагонали доков и явился толчком для более детального изучения продукта).
Мои впечатления о Hyper Estraier:
Данный поисковик принадлежит перу FalLabs, один продукт которой я уже тестил недавно. Короткий User's Guide (34 экрана на ноутбуке, из которых две трети — описание параметров и конфигов) с описанием некоторых интересных особенностей соблазнил на эксперимент.
Лично я примерно день потратил на изучение описания, несколько минут на установку плюс полчаса-час чтобы разобраться с простейшим вариантом работы, индексированием трех документов и игрой с результатами.
Еще день потратил, чтобы написать «на коленке» программу для индексирования уже рабочего объема данных для оценки его работоспособности и день для изучения и тестирования архитектуры клиент-сервер.
Стандартная установка с параметрами по умолчанию:
$ ./configure
$ make
$ make install
Требуется наличие:
— libiconv — входит в состав glibc;
— zlib — для сжатия данных
— QDBM — продукт той-же FalLabs, встраиваемая база данных. Установка по той-же, вышеприведенной схеме.
Индексирование.
Для индексирования документ должен быть представлен в формате «document draft» — собственный формат, идеологически близкий к формату http-протокола — заголовок/пустая строка/текст.
В заголовке перечисляются атрибуты в формате "@атрибут=значение". Одна строка — один атрибут.
Текст — простой plain-text. Файл в кодировке utf-8.
Работа.
1. Простейший вариант — командная строка.
Утилита estcmd создает поисковый индекс, управляет им и позволяет вести поиск. При задании опции -vh результат поиска вполне читаем, выдается со сниппетами в multipart-формате. Первая строка — разделитель блоков. Первый блок — заголовок-результат запроса — сколько всего документов, время поиска, кол-во документов по каждому из слов и т.п. Парсить такую выдачу легко и приятно.
Для данного варианта в пакете есть простой cgi-скрипт, можно искать более привычным способом, через браузер.
Если требуется что-то более красивое в своем дизайне — парсите выдачу любым удобным для вас инструментарием.
2. Более сложный вариант — клиент-сервер.
Он желателен для многопользовательской работы с базой поисковика. Плюс, если в первом варианте при каждом обращении некоторое время тратится на открытие базы, то в данном случае мы экономим на данной операции, ну и конечно, кэширование последних запросов заметно ускоряет выдачу при повторных обращениях.
Интерфейсы к поиску для данного варианта:
— API для C (документация с простейшими примерами);
— веб-интерфейс — простой поиск и управление базой;
— утилита командной строки estcall — фактически отправляет серверу те-же http-запросы, поисковая выдача аналогична описанной в предыдущем пункте.
Скорость работы.
Тестирование происходило на том-же сервере, что и прошлый раз — Opteron-2218, 2.6GHz, 8G ОП, HDD 73G+143G sas.
На этот раз вся работа велась на одном из 143-гигабайтных дисков.
Исходные данные — 3224992 поста с форумов одного проекта, общим объемом около 700 Mb.
Индексирование данных. Данные выгружались порциями по 5000 файлов, конвертировались в utf-8 и индексировались.
— первый вариант, командная строка — 6 часов, почти минута в минуту;
— второй вариант — файлы поштучно скармливались серверу — порядка 10.5 часов.
Медленно? Да. По сравнению со Сфинксом — черепаха. Но для первичного наполнения индекса время вполне приемлемое. Да и много-ли у нас проектов с такими объемами? А для текущего пополнения индекса новыми документами таких скоростей более чем достаточно. Я не нашел данных по ЖЖ, на главной странице Liveinternet.ru В данный момент (11:47, 03.01.2011) по дневникам сказано — «4518 сообщений за последний час» — это порядка 75 постов в секунду, примерно сопоставимо с полученной скорости индексирования по второму варианту (85 постов в секунду). Для ЛиРу данный поисковик не годится, но много ли сайтов с подобным трафиком?
Дисковый ресурсы:
— индекс, полученный по первому варианты занимает порядка 5.3 Gb на диске;
— индекс, полученный по второму варианту — около 6.3 Gb.
Почему так — не понял. Возможно это как-то зависит от возможности одновременной работы сервера с несколькими индексами, внутреннее название «нода» (node).
Скорость поиска.
К сожалению по данному вопросу более-менее развернутой статистики мне собрать пока не удалось. Массированных бомбардировок запросами я не устраивал. Могу поделиться субъективными ощущениями:
1. Первые запросы по свежепостроенному индексу обрабатываются довольно долго — порядка полутора секунд.
2. Повторно те-же запросы, как и перемещение между страницами заданного запроса — не более 1 сотой секунды.
3. Многословные запросы обрабатываются дольше. Например запрос из 5 слов (искал остатки последней спам-рассылки) даже на листание тратил порядка 0.17 секунды.
Все запросы я делал через веб-интерфейс сервера поисковика.
Выводы.
Я собираюсь обкатать его на группе форумов с трафиком в 10-20 тысяч постов/комментов в сутки.
PS. Я рассмотрел не все возможности Hyper Estraier. Если я правильно понял, возможен поиск сразу по нескольким индексам-нодам, а также многомашинный вариант работы. Так что не исключено, что реальная «мощность» движка может быть значительно выше, чем то, чего смог добиться я. Для любителей потестировать-помучать работа осталась :)
Чем привлек внимание, не смотря на скромные характеристики?
1. Возможностью real-time индексирования.
2. Наличие атрибутов документа и их использование в поиске и сортировке результата.
3. Простота работы и компактная четкая документация (хватило пары дней на изучение, собственно беглый взгляд по диагонали доков и явился толчком для более детального изучения продукта).
Мои впечатления о Hyper Estraier:
Данный поисковик принадлежит перу FalLabs, один продукт которой я уже тестил недавно. Короткий User's Guide (34 экрана на ноутбуке, из которых две трети — описание параметров и конфигов) с описанием некоторых интересных особенностей соблазнил на эксперимент.
Лично я примерно день потратил на изучение описания, несколько минут на установку плюс полчаса-час чтобы разобраться с простейшим вариантом работы, индексированием трех документов и игрой с результатами.
Еще день потратил, чтобы написать «на коленке» программу для индексирования уже рабочего объема данных для оценки его работоспособности и день для изучения и тестирования архитектуры клиент-сервер.
Стандартная установка с параметрами по умолчанию:
$ ./configure
$ make
$ make install
Требуется наличие:
— libiconv — входит в состав glibc;
— zlib — для сжатия данных
— QDBM — продукт той-же FalLabs, встраиваемая база данных. Установка по той-же, вышеприведенной схеме.
Индексирование.
Для индексирования документ должен быть представлен в формате «document draft» — собственный формат, идеологически близкий к формату http-протокола — заголовок/пустая строка/текст.
В заголовке перечисляются атрибуты в формате "@атрибут=значение". Одна строка — один атрибут.
Текст — простой plain-text. Файл в кодировке utf-8.
Работа.
1. Простейший вариант — командная строка.
Утилита estcmd создает поисковый индекс, управляет им и позволяет вести поиск. При задании опции -vh результат поиска вполне читаем, выдается со сниппетами в multipart-формате. Первая строка — разделитель блоков. Первый блок — заголовок-результат запроса — сколько всего документов, время поиска, кол-во документов по каждому из слов и т.п. Парсить такую выдачу легко и приятно.
Для данного варианта в пакете есть простой cgi-скрипт, можно искать более привычным способом, через браузер.
Если требуется что-то более красивое в своем дизайне — парсите выдачу любым удобным для вас инструментарием.
2. Более сложный вариант — клиент-сервер.
Он желателен для многопользовательской работы с базой поисковика. Плюс, если в первом варианте при каждом обращении некоторое время тратится на открытие базы, то в данном случае мы экономим на данной операции, ну и конечно, кэширование последних запросов заметно ускоряет выдачу при повторных обращениях.
Интерфейсы к поиску для данного варианта:
— API для C (документация с простейшими примерами);
— веб-интерфейс — простой поиск и управление базой;
— утилита командной строки estcall — фактически отправляет серверу те-же http-запросы, поисковая выдача аналогична описанной в предыдущем пункте.
Скорость работы.
Тестирование происходило на том-же сервере, что и прошлый раз — Opteron-2218, 2.6GHz, 8G ОП, HDD 73G+143G sas.
На этот раз вся работа велась на одном из 143-гигабайтных дисков.
Исходные данные — 3224992 поста с форумов одного проекта, общим объемом около 700 Mb.
Индексирование данных. Данные выгружались порциями по 5000 файлов, конвертировались в utf-8 и индексировались.
— первый вариант, командная строка — 6 часов, почти минута в минуту;
— второй вариант — файлы поштучно скармливались серверу — порядка 10.5 часов.
Медленно? Да. По сравнению со Сфинксом — черепаха. Но для первичного наполнения индекса время вполне приемлемое. Да и много-ли у нас проектов с такими объемами? А для текущего пополнения индекса новыми документами таких скоростей более чем достаточно. Я не нашел данных по ЖЖ, на главной странице Liveinternet.ru В данный момент (11:47, 03.01.2011) по дневникам сказано — «4518 сообщений за последний час» — это порядка 75 постов в секунду, примерно сопоставимо с полученной скорости индексирования по второму варианту (85 постов в секунду). Для ЛиРу данный поисковик не годится, но много ли сайтов с подобным трафиком?
Дисковый ресурсы:
— индекс, полученный по первому варианты занимает порядка 5.3 Gb на диске;
— индекс, полученный по второму варианту — около 6.3 Gb.
Почему так — не понял. Возможно это как-то зависит от возможности одновременной работы сервера с несколькими индексами, внутреннее название «нода» (node).
Скорость поиска.
К сожалению по данному вопросу более-менее развернутой статистики мне собрать пока не удалось. Массированных бомбардировок запросами я не устраивал. Могу поделиться субъективными ощущениями:
1. Первые запросы по свежепостроенному индексу обрабатываются довольно долго — порядка полутора секунд.
2. Повторно те-же запросы, как и перемещение между страницами заданного запроса — не более 1 сотой секунды.
3. Многословные запросы обрабатываются дольше. Например запрос из 5 слов (искал остатки последней спам-рассылки) даже на листание тратил порядка 0.17 секунды.
Все запросы я делал через веб-интерфейс сервера поисковика.
Выводы.
- Мощности данного поисковика вполне хватит для большинства сайтов, за исключением, пожалуй, крупных СМИ, блогов уровня ЖЖ и им подобных.
- Установка, настройка и работа с ним достаточно проста и не требует высокой квалификации и отдельного человека.
- Фактически с помощью Hyper Estraier можно индексировать любые документы, откуда можно вытянуть текст. Ссылки на некоторые программы-парсеры других форматов даны в документации. Также в наличии собственный краулер для индексирования веб-страниц.
Я собираюсь обкатать его на группе форумов с трафиком в 10-20 тысяч постов/комментов в сутки.
PS. Я рассмотрел не все возможности Hyper Estraier. Если я правильно понял, возможен поиск сразу по нескольким индексам-нодам, а также многомашинный вариант работы. Так что не исключено, что реальная «мощность» движка может быть значительно выше, чем то, чего смог добиться я. Для любителей потестировать-помучать работа осталась :)
