Мы хотим переиндексировать документы в наш новый кластер 7.2 Elasticsearch из нашего старого кластера 1.7 Elasticsearch (около 2 ТБ данных), и мы хотим максимизировать пропускную способность индексирования
Для целей индексации мы будем использовать BulkProcessor API. Мы имели в виду три подхода:
- Имеют
N (настраиваемые) потоки, считывающие данные с не перекрывающихся временных периодов из кластера 1,7, и имеем один BulkProcessor Экземпляр с установленным setConcurrentRequests до N - Иметь
N поток, потребляющий от непересекающихся таймфреймов от 1.7 и N BulkProcessors с setConcurrentRequests как 1 для каждого - Имеют
1 нить, потребляющую от 1,7, и имеют 1 BulkProcessor с setConcurrentRequests as N
Я планирую оставить для остальных параметров BulkProcessor только их значения по умолчанию.
Мой вопрос , для 1, видите ли вы потенциальную возможность конфликта блокировки в BulkProcessor, когда мы add BulkRequests к нему? Исходя из исходного кода, я вижу, что он получает блокировку при вызове add (который в итоге вызывает internalAdd)
Чтобы уменьшить возможную конкуренцию за блокировку, мы запланировали 2 & 3
С 2, поскольку между потоком производителя и BulkProcessor будет отображаться 1:1, я не вижу конфликта блокировки там
С 3, поскольку существует один производитель, я больше не вижу разногласий
Я бы определенно экспериментировал с различными стратегиями, но у меня вроде бы не хватает времени, так что просто получаю подсказку о преимуществах / предостережениях из подхода 3 помог бы мне начать
Кроме того, не беспокойтесь о емкости здесь. Мы настроим параметр N аналогично