Требования к оборудованию для настройки Lucene (Solr / Zoie / Elasticsearch) - PullRequest
3 голосов
/ 03 мая 2011

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

Вот наши основные требования

  • Поиск в полуструктурированных данных
    • Документ содержит 15 полей, все из которых должны быть доступны для поиска
    • В основном числовые идентификаторы
    • Сроки
    • Имена
  • 10 + миллионов документов в индексе
  • 30-40 обновлений, пакетами каждую минуту
  • <100 мс Время отклика поиска с несколькими логическими операторами для 100 + запросов в минуту </li>

Вопросы

1) Возможно ли получить это исполнение на установке с одним сервером?

2) Если нет, то какая установка подходит для соответствия требованиям к производительности.

3) Мы рассматриваем несколько фреймворков поверх Lucene, среди них Solr и Zoie. Какая распределенная архитектура будет необходима для обработки описанной нагрузки и требований к производительности.

Ответы [ 2 ]

3 голосов
/ 03 мая 2011

1) Возможно ли получить это исполнение на установке с одним сервером?

Да, я так думаю. Но это своего рода «граница» (надеюсь, вы понимаете, о чем я) Что вам нужно, это достаточно оперативной памяти и мощности процессора. Finlay зависит от размера «больших» файлов, таких как fulltexte или около того, и размера вашей базы данных.

Для сравнения я использую lucene с 1,2 миллионами документов, 7 файлами, в основном с короткими полями (дата, числа и т. Д.), Но также с одним большим текстовым полем (500-5000 символов). Размер этой базы данных mysql (которая индексируется lucene) составляет 1-2 ГБ. Система работает на небольшом хосте VMware с одним ЦП и 4 ГБ ОЗУ. Результаты полнотекстового поиска возвращаются через 100-400 мс. Если у вас нет больших текстовых полей, ваши результаты будут возвращаться быстрее. (в зависимости от вида поиска -> например поиск по Facettet) Например: поиск фацетета по символу (255) Подано, возвращено в <70ms </p>

Возможно, для вашей конфигурации было бы полезно не визуализированное оборудование с большим объемом памяти (> 32 ГБ) и> 8 ядер.

30-40 обновлений, пакетами каждую минуту

означает ли это 30-40 новых документов в минуту? это не проблема! 30-40 обновлений в минуту с большим количеством новых документов были бы более сложными. Дополнительно вы должны периодически оптимизировать свой индекс (например, ночью)

3) Мы рассматриваем несколько фреймворков поверх Lucene, среди них Solr и Zoie.

Solr работает как приложение tomcat. Здесь вы должны определить, например, ОЗУ (см. Выше), которое назначено вашей поисковой системе. Существует несколько возможностей разбить ваш индекс (для большей производительности или более быстрого обновления), также возможна кластеризация.

0 голосов
/ 21 марта 2013

В случае «единственного сервера» для этих требований вы должны выглядеть примерно так: ElasticSearch . Потому что он оптимизирован для обновления почти в реальном времени очень хорошо. С Solr вы можете получить аналогичную производительность, но именно при смешивании запросов get / updates у Solr возникают проблемы в одном узле. Разделив его на 2 или более узлов - master / slave, вы получите производительность, аналогичную ElasticSearch, но на одном узле - нет.

Пожалуйста, посмотрите на это для более подробной информации - http://blog.socialcast.com/realtime-search-solr-vs-elasticsearch/

...