Григорий, спасибо за статью, описанное сильно коррелирует с моим собственным опытом. В моем случае загрузка выполняется из нескольких источников, источник 1 заполняет поле 1, источник 2 заполняет поле 2 и так далее. Причем выполняется параллельно всеми серверными узлами кластера. Удалось значительно уменьшить время за счет использования BinaryObject + EntryProcessor. Поэтому плюсую все утверждения ниже
* если вы пишете данные с уникальными ключами — используйте .. всегда putAll, если не хотите заморачиваться * вы включите SQL только в том случае, если он вам нужен * Пишите через BinaryObject вместо POJO своего класса
Да, забыл упомянуть в тексте. Peer-class-loading в xml-конфиге я включал/выключал, но это ни на что не влияло.
Способ деплоя не поменялся, «data node» либо «client node» в зависимости от аргумента командной строки. Потому что работает — не трожь, да и другого варианта перед глазами нет.
Полная десериализация пользовательских классов на дата нодах сильно расходует память, пришлось разбираться с BinaryObject. Теперь дата ноды не используют классы модели, но запуск всех узлов единым jar-файлом — удобная штука, пока остается.
>> внешних экспертов «ФОРС»
это какой-то интегратор?
Григорий, спасибо за статью, описанное сильно коррелирует с моим собственным опытом. В моем случае загрузка выполняется из нескольких источников, источник 1 заполняет поле 1, источник 2 заполняет поле 2 и так далее. Причем выполняется параллельно всеми серверными узлами кластера. Удалось значительно уменьшить время за счет использования BinaryObject + EntryProcessor. Поэтому плюсую все утверждения ниже
Способ деплоя не поменялся, «data node» либо «client node» в зависимости от аргумента командной строки. Потому что работает — не трожь, да и другого варианта перед глазами нет.
Полная десериализация пользовательских классов на дата нодах сильно расходует память, пришлось разбираться с BinaryObject. Теперь дата ноды не используют классы модели, но запуск всех узлов единым jar-файлом — удобная штука, пока остается.