IgniteDataStreamer с allowOverwrite медленнее, чем putAll? - PullRequest
1 голос
/ 31 октября 2019

Я написал несколько тестов по загрузке данных. Я ожидаю, что IgniteDataStreamer будет быстрее (или равно), чем putAll(...), и это так, но за исключением этого случая:

  • число узлов сервера: 5
  • резервных копий кеша: 1
  • режим синхронизации записи: FULL_SYNC
  • стример данных разрешает перезапись: true
  • остальные настройки по умолчанию для стримера данных

Результаты:

putAll(...) скорость: 126630 в секунду

data streamer скорость: 30430 в секунду

В случае недопустимых перезаписей ИЛИ 0 резервных копий + PRIMARY_SYNC стример данных работает быстрее, чем положить все (примерно2 раза), как и ожидалось.

Так получается, подсказка производительности Ignite об использовании разрывов стримера данных? Каковы возможные причины и как избежать замедления потока данных?

Фрагмент кода теста:

for (int i = 0; i < size; i++) {
    pojoMap.put(String.valueOf(i), pojo);
}    
cache.putAll(pojoMap);

против

igniteDataStreamer.allowOverwrite(false);
for (int i = 0; i < size; i++) {
    igniteDataStreamer.addData(String.valueOf(i), pojo);
}
igniteDataStreamer.flush();

Gridgain CE 8.7.6

1 Ответ

1 голос
/ 02 ноября 2019

Это легко объяснить. Если allowOverwrite равно true, то стример данных будет отправлять данные с помощью отдельных методов cache.put . Этот подход намного медленнее, чем стандартный cache.putAll. Не уверен, почему стример данных не может использовать putAll в этом сценарии, по крайней мере, для атомарных кэшей (отдельный cache.puts имеет смысл для транзакционного кэша, чтобы избежать взаимоблокировок). Я проверю возможные оптимизации с сообществом.

Что касается allowOverwrite, равного false, стример обращается ко всем узлам , которые хранят первичные и резервные копии напрямую, и выполняет обновления вмест. Для вашего кластера это должно привести к 5 сетевым запросам (от приложения к каждому узлу), если все данные умещаются в 5 пакетов.

В целом, используйте allowOverwrite=false для начальной загрузки данных. Что касается allowOverwrite=true, сообщество увидит, есть ли место для внутренней оптимизации, по крайней мере, для атомарных кэшей.

...