суббота, 8 октября 2016 г.

Elastic Search - опыт эксплуатации

      Сейчас у нас находятся в эксплуатации несколько поисковых Elastic Search кластеров, в сумме больше 150 машин. Хочу поделится своим опытом настройки/эксплуатации этого хозяйства. 
        Выделенные master ноды - это очень важно для стабильности Elastic Search. Если в кластере нет выделенных master нод - то при перегрузке кластер рассыпается. Текущий мастер выпадает, кластер начинает выбирать новую мастер ноду, после этого начинается rebalance шард а так как ноды перегружены - они то и дело снова вылетают из кластера. Причем вылетают из кластера не всегда по своей вине. Так как master нода также обслуживает запросы - она может быть ими перегружена и просто вовремя не послать/не принять heartbeat запросы от всех остальных нод. Даже если кластер соберется вновь - он может сам собой рассыпаться из-за нагрузки генерируемой процессом перебалансировки.  В таком коматозном состоянии кластер может находится очень долго. Вплоть до нескольких часов. Лечится это только уберанием нагрузки и перезапуском всех нод. Если в кластере есть выделенные master ноды -  он в аналогичной ситуации ведет себя гораздо стабильнее. Как только search queue на рабочих нодах заполняется - они начинают игнорировать все остальные запросы. То есть те запросы для обработки которых у них не хватает ресурсов - быстро возвращаются с ошибкой. То есть даже в условиях перегрузки кластер остается полностью работоспособным и управляемым.
          Хранить какие-то данные в поисковом кластере - это плохая идея. Elastic Search это не база данных. Даже не потому что мгновенный апдейт индекса эластика - это иллюзия. Это просто абстракция которая была реализована поверх immutable solr индексов.  Даже если ваши данные не часто изменяются, и вы не собираетесь сделать Elastic Search  основным хранилищем этих данных - все равно не храните их в  Elastic Search. Поставьте рядом in-memory key-value хранилище и храните их там. Уберите из Elastic Search все данные которые не используются при выполнении поисковых запросов. При увеличении размера ElasticSearch документа в два раза производительность кластера уменьшится примерно в два раза. Поэтому уменьшение размера ElasticSearch документа - это эффективный способ оптимизации кластера. Почему так происходит ? Чтобы понять это достаточно представить как Elastic Search выполняет запросы - https://www.elastic.co/guide/en/elasticsearch/guide/current/distributed-search.html  
           Ограничьте глубину постраничной навигации. Если у вас больше миллиона документов - никакому разумному пользователю не нужно листать больше 100 страниц. Это решение во многом связано с бизнес логикой, поэтому это не всегда возможно наложить подобное ограничение. Стоимость выполнение поисковых запросов с большими номерами  страниц - на порядки выше стоимости выполнения аналогичных поисковых запросов для маленьких номеров страниц. Просто потому что для генерации результата поиска  N, вам нужно передать между нодами и отсортировать список документов размером N * [documents_per_page] * [number_of_shards].
            

среда, 5 октября 2016 г.

Рекомендательная система Flickr

    http://code.flickr.net/2016/09/30/personalized-group-recommendations-on-flickr/ - ребята рассказали довольно много интересных подробностей. Хотя о том как они оптимизировали вычисления они так и не рассказали