Многофункциональный Python-клиент эластичный поиск, отправляющий объем данных JSON в один кластер ES

Question

Я планирую установить на каждом из моих серверов ec2 (около 50-60 серверов ec2) python-клиент эластичный поиск (около 50-60 серверов ec2) для отправки данных в мой единственный кластер ES.Итого - объемный индекс 50/60 каждую секунду
Каждый объемный json может иметь до ~ 500 документов / ~ 3-4 МБ объемного json.Предполагая, что я использую 20 узлов кластера m4.large или, может быть, больше.

Мой вопрос здесь

1. Как кластер нагрузки ES будет распределять запросы, поступающие с разных серверов?
2. Запросы, поступающие с разных серверов так часто, как это повлияетмоя система?
3. asticsearch vs Curl до конечной точки, что лучше?

Answer 1

Из моего опыта Вы должны проверить это с вашей конкретной настройкой.

Это зависит от:

• Насколько велик ваш кластер ES
• Насколько велик размер вашей базы данных
• Сколько у вас реплик
• Сколько у вас узлов индексирования
• Идентификаторы, поддерживающие любой узел / осколок
• Насколько велики ваши документы
• Насколько сложна ваша пользовательская токенизация / индексация
• Есть ли у вас какие-либо всплески при отправке документов
• Сколько других запросов выполняется в кластере
• Насколько велик интервал обновления

1. Посмотрите данные с ваших серверов во время тестовых прогонов

curl localhost: 9200 / _cat / thread_pool? V = true

node_name name                active queue rejected
prodnode  bulk                     0     0        0
prodnode  fetch_shard_started      0     0        0
prodnode  fetch_shard_store        0     0        0
prodnode  flush                    0     0        0
prodnode  force_merge              0     0        0
prodnode  generic                  0     0        0
prodnode  get                      0     0        0
prodnode  index                    0     0        0
prodnode  listener                 0     0        0
prodnode  management               1     0        0
prodnode  refresh                  0     0        0
prodnode  search                   0     0        0
prodnode  snapshot                 0     0        0
prodnode  warmer                   0     0        0

2. Исходя из моего опыта, цифры, которые вы упомянули, должны управляться кластером Первая проблема, с которой вы можете столкнуться: массовое отклонение ( действительно хорошая статья об этом ). Можете ли вы код терпеть и пересылать ошибочные документы? По своей структуре массовые запросы лучше объединять в одну очередь, и один агент отправляет их в кластер. Кластер заблокирует это или дроссель, если это не может не отставать. Лучше поэкспериментировать.

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