Доброго времени суток. При добавление записей и индекс (bulk insert) или создании нового индекса и добавлением в него данных (Кластер в пределах одного физического сервера) сильно падает производительность при выполнении пользователями поисковых запросов. По сути, невозможно искать документы во время заливки данных - неприемлемое время выполнения запросов.
Имеет ли смысл развернуть изолированный(discovery.zen.ping.multicast.enabled: false, discovery.zen.ping.unicast.hosts: ["host1", "host2", "hostN"]) кластер на другом сервере, заливать в него данные, а потом перенести шарды (shard allocation) на первый кластер, будет ли это более безболезненно для первого кластера? Понятно что проиграю со временем загрузки.....
Или можно использовать какое нибудь другое решение? Задача сохранить скорость выполнения запросов....
Вы не пытались проанализировать, от чего скорость падает? CPU перегружено, скорости диска не хватает? Переносить шарды из одного кластера в другой муторно - надо будет настраивать репозиторий, копировать данные туда из одного кластера, восстанавливать данные в другой. Проще было бы добавить вторую ноду в существующий кластер, и тогда, действительно, можно двигать шарды туда-сюда с помощью Allocation Filtering.
И CPU и JVM, при постоянном пополнении кластера всё равно периодически приходиться делать rolling restart. Я понимаю что это муторно, но скорость релокации всегда же одинаковая(в отличии от bulk indexing), то есть можно например по шедулеру переносить шардоы ночью, или это бестолковая идея?
Rolling restart? Может у вас просто памяти не хватает или схема не оптимально настроена? Что приводит к необходимости перегружать весь кластер? Я, конечно, не знаком с вашей ситуацией, но мне кажется, надо начать с настройки кластера вместо того, чтобы решать ситуаций с помощью странных схем.
Возможно где то натупил с настройками, но почему то после двух недель работы с кластером все виртуалки загружены 100% CPU и 100% RAM, => Rolling Restart. Читал про flush, попробовал, наверно что-то недопонял, но эффекта 0.
Еще один вопрос, читал что количество шардов должно быть равно количеству ядер, в идеальных условиях. Сервер 16 ядер (32 логических) 32 шарда на 8 виртуалок, вместе с репликами объем индекса 2 ТБ это приемлимо?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.