Эластичный поиск 403 Запрос отклонен из-за слишком большого количества запросов / _bulk

Я пытаюсь синхронизировать 1 миллион записей с ES, и я делаю это, используя массовый API в пакете 2k. Но после вставки около 25–32 тыс. Эластичный поиск дает следующее исключение.

Unable to parse response body: org.elasticsearch.ElasticsearchStatusException
ElasticsearchStatusException[Unable to parse response body]; nested: ResponseException[method [POST], host [**********], URI [/_bulk?timeout=1m], status line [HTTP/1.1 403 Request throttled due to too many requests]
403 Request throttled due to too many requests /_bulk]; nested: ResponseException[method [POST], host [************], URI [/_bulk?timeout=1m], status line [HTTP/1.1 403 Request throttled due to too many requests]
403 Request throttled due to too many requests /_bulk];

Я использую эластичный поиск aws. Я думаю, мне нужно реализовать стратегию ожидания, чтобы справиться с этим, что-то вроде проверки статуса es и вызова массовой вставки, если статус все в порядке. Но не знаете, как это реализовать? Предлагает ли ES что-нибудь для этого заранее? Или Есть ли способ лучше с этим справиться?

Заранее спасибо.

Обновление: я использую эластичный поиск AWS версии 6.8.


person Manish    schedule 22.02.2021    source источник
comment
Ознакомьтесь с elastic.co/guide/ en / elasticsearch / reference / master / и stackoverflow.com/a/64896210/6200672 один раз.   -  person dravit    schedule 22.02.2021
comment
@dravit Я проверил эти два ответа, но они не ответили на то, что я ищу. В основном я ищу подход к экспоненциальному откату.   -  person Manish    schedule 22.02.2021
comment
Есть ли конкретная причина для экспоненциального подхода к отсрочке?   -  person dravit    schedule 22.02.2021
comment
@dravit, поэтому я использую эластичный поиск AWS, и они поддерживают ES до версии 7.9 только на данный момент. И моя команда использует 6,8 в текущей ситуации. Кроме того, я уже звоню с использованием массового API с размером пакета в 2000 документов. В настоящее время я работаю над подходом, чтобы проверить ответ ES после вызова массового API и подождать некоторое время и отправить следующий массовый запрос. Если у вас есть предложения получше, поделитесь.   -  person Manish    schedule 23.02.2021
comment
ES начал выдавать ошибку из-за высокого использования памяти. Даже на моем локальном компьютере я никогда не сталкивался с этой проблемой. Это может быть ограничение / ошибка AWS в зависимости от цены и вашего текущего плана. Можете ли вы попробовать с большим размером пакета, скажем 6 КБ, и явным ожиданием 5 секунд? Кроме того, каково значение refresh_interval (вы найдете его в настройках индекса)?   -  person dravit    schedule 24.02.2021
comment
@dravit Теперь я могу вставить 100 КБ, сделав что-то вроде этого: bulkRequest.timeout (TimeValue.timeValueMinutes (2)); bulkRequest.setRefreshPolicy (RefreshPolicy.WAIT_UNTIL); BulkResponse bulkResponse = esWrapper.bulkRequest (bulkRequest); // засыпаем на 1 секунду sleepAfterBatchWrite ();   -  person Manish    schedule 24.02.2021
comment
Я не думаю, что здесь можно использовать тайм-аут. Я бы посоветовал, возможно, использовать пакеты меньшего размера и написать свой код таким образом, чтобы следующий пакет отправлялся только после того, как предыдущий был выполнен и вызов вернулся.   -  person Val    schedule 25.02.2021
comment
@Val, да, сейчас я делаю только это, жду 1 секунду перед отправкой следующей партии. Но при таком подходе вставка всех данных займет много времени.   -  person Manish    schedule 25.02.2021


Ответы (2)


Спасибо @dravit за включение моего предыдущего ответа SO в комментарий, после комментариев OP кажется, что OP хочет улучшить производительность массовое индексирование и требуется экспоненциальная отсрочка, которую я не думаю, что Elasticsearch предоставляет из коробки.

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

  1. Следуйте моими советами по повышению скорости переиндексации в Elasticsearch и узнайте, что именно перечисленные здесь применимы, и выполнение их увеличивает скорость во сколько раз.
  2. Найдите стратегию пакетной обработки, которая лучше всего подходит для вашей среды, я не уверен, но эта статья от @spinscale, который является разработчиком Java-клиента высокого уровня для отдыха, может помочь, или вы можете задать вопрос на https://discuss.elastic.co/, я вспомнил, что он поделился очень хорошей стратегией пакетной обработки на одном из своих вебинаров, но не смог найти ссылку на нее.
  3. Обратите внимание на различные метрики ES, кроме массового пула потоков и размера очереди, и посмотрите, есть ли у вашего ES еще емкость. Можно ли увеличить размер очереди и увеличить скорость, с которой вы можете отправлять запросы на ES.
person user156327    schedule 26.02.2021
comment
Я нашел что-то вроде, в основном буду пробовать это на следующей неделе. У ES есть внутренняя задержка builder.setBackoffPolicy (BackoffPolicy .constantBackoff (TimeValue.timeValueSeconds (1L), 3)); ссылка: elastic.co/guide/en/elasticsearch/client/java-rest/master/. - person Manish; 26.02.2021

Ознакомьтесь с руководством по обработке ошибок здесь

Если вы получаете постоянный запрос 403, который дросселируется из-за слишком большого количества запросов или ошибок 429 Too Many Requests, рассмотрите возможность вертикального масштабирования. Amazon Elasticsearch Service регулирует запросы, если полезная нагрузка может привести к превышению использования памяти максимального размера кучи Java.

Масштабируйте приложение по вертикали или увеличивайте задержку между запросами.

person Mehdi Fathi    schedule 22.02.2021
comment
вероятно, не лучший способ, потому что это можно контролировать и другими способами. - person dravit; 22.02.2021
comment
@mehdi fahti, я прочитал это в документе, пожалуйста, прочтите внимательно вопрос. Я пытаюсь найти лучший способ увеличить задержку между запросами. Пожалуйста, прочтите вопрос. - person Manish; 23.02.2021