Pull to refresh

Comments 23

В связке с logstash частенько возникают проблемы.
* Даже с replica=2 при выходе из строя одной из 4 нод индекс приходит в негодность и поиск становится невозможным.
* Существенные проблемы с GC: приблизительно через две недели использования GC начинает выполняться по 20 секунд, при этом тормозит весь кластер.
При потере сети на одной из нод происходит split-brain с ожидаемыми последствиями.
Split-brain на четном количестве нод решается выставлением минимальной доступности 2 мастеров и установкой master-only ноды, которая есть почти не просит.
Что-то залез сейчас на сайт эластика, а там версия 1.0 + ништяки типа Kibana
P.S> а хотел написать про master-only ноду, но вовремя увидел ответ выше
logstash не хочет работать с 1.x версией. Пока крутится на 0.90.3 (если юзать embedded ES) хотя у нас заводится на 0.90.11
Кибана идет в комплекте уже с логстеш.
Просто щупал ES последний раз на 90.1. Многое поменялось похоже
logstash будет работать с любым es через http транспорт, с java api нет.

кибана идёт сама по себе.
Кибана идет и как embdeded в логстеш.
> Кибана идет в комплекте уже с логстеш.

Тут с разных сторон можно прочитать, что с чем идёт :)
logstash будет работать с любым es через http транспорт

Как раз решил потестить и столкнулся с этим, через http и вправду работает
Решается отключением мультикастом и переходом на юникаст с указанием списка мастеров.
GC не просто так начинает выполняться по 20 секунд, стоит ограничить fielddata cache и filter cache, если не влезаете в heap. Ну и bloom filter на исторических данных лучше выключать, потому как много ест, а толку ноль.
Спасибо, попробую.
У нас, наверное, не такие большие нагрузки. Серьезные проблемы были когда ES жил на медленном СХД.
Были постоянные проблемы с падением поиска из-за нехватки памяти — все в своп уходило.

Сейчас поставили на железные сервера с нормальными дисками — все проблемы ушли :)
4 ноды весьма не много. В остальном настройка алокации позволяет свести к нулю возможность выхода из строя индекса.
Так же сталкивался с проблемой GC, кластер в это время тормозит из-за только, что эта сборка (Concurrent Mark and Sweep) проходит в режиме Stop The World, то есть во время работы этой сборки приложение находится в «паузе». В нашем случае проблема сборки решилась выгрузки из памяти «холодных» данных. В нашем проекте кластер состоит из 20 нод, объем данных, постоянно присутствующих в кластере около 2.5 млрд документов. В настоящий момент CMS сборки не случаются вообще, т.к. уровень заполнения кучи меньше порогового, после которого включается CMS-механизм.
Насколько я помню, в основном 2Гис используется Sphinx как основной поисковый движок. Не планируете полностью переехать на ES?
ES используют внутренние системы сбора и актуализации информации. Внешние продукты используют нашу собственную разработку — UniSearch. Если кратко — то это кроссплатформенный, офлайновый, встраеваемый движок, заточенный на структуру данных 2ГИС. Sphinx ранее использовался для онлайн-версии 2ГИС. Сейчас там тоже работает UniSearch, вокруг которого для этих целей был построен бэкенд. Попробовать наиболее свежую версию поиска можно здесь.
А что используете для поиска в мобильном приложении? Или там ничего «интересного»?
Везде во внешних продуктах используется собственный движок UniSearch. Выше в комменте ответили подробнее :)
Основная сила ES лежит конечно же в Lucene. Очень продвинутая библиотека для работы с инвертированным индексом. Мы его эксплуатируем уже лет 5. В данный момент в эксплуатации кластер из ~20 машин. За это время пришли к архитектуре во многом похожей на ES, но в некоторых аспектах существенно отличающейся. В частности, мы храним документы отдельно, а не в индексе. А также, координацией поиска внутри кластера и индексацией занимаются отдельные машины. Это позволяет более «экономно» масштабировать систему.
 У нас похожая ситуация, ориентировочно то же количество нод. Хотим переехать на ElasticSearch — есть сила lucene, и не нужно поддерживать собственное решение, которое выходит достаточно затратно по ресурсам. Предварительные бенчмарки показывают схожую или превосходящую производительность системы. И да, наше решение на C#, что сразу вовлекает большие деньги на Enterprise Windows с возможностью использования достаточного объема памяти, в то время как Elastic Search создан для *nix.
Подскажите, пакетами какого размера вы заливали данные при тестировании в Solr и с какими параметрами коммитили?
Мы сейчас выбираем между Solr и Elastic. В защиту Солара хочу сказать, что тест на скорость поиска в статье совершенно нерепрезентативен, т.к. там коммитили после вставки каждого документа, а по-молчанию Solr после коммита перезапускает searchers и делает подогрев кеша, что само собой не быстрая операция сама по себе и плюс к этому пока не перезапустится searcher, поиск будет в ожидании чуда. Отсюда и тормоза.
В нашем дерби пока выигрывает Солр. В основном за своё умение делать сплит шардов и модифицировать update workflow с помощью плагинов.
Only those users with full accounts are able to leave comments. Log in, please.