Апацхе Игните Зеро имплементација: стварно нула?

Апацхе Игните Зеро имплементација: стварно нула?

Ми смо одељење за развој технологије малопродајне мреже. Једног дана, менаџмент је поставио задатак да убрза прорачуне великих размера коришћењем Апацхе Игните-а у комбинацији са МССКЛ-ом и показао веб локацију са прелепим илустрацијама и примерима Јава кода. Одмах ми се допао сајт Зеро Деплоимент, чији опис обећава чуда: не морате ручно да примењујете свој Јава или Сцала код на сваком чвору у мрежи и поново га постављате сваки пут када се промени. Како је посао напредовао, показало се да Зеро Деплоимент има специфичне намене, чије карактеристике желим да поделим. Испод реза су мисли и детаљи имплементације.

1. Изјава о проблему

Суштина проблема је следећа. Постоји СалесПоинт директоријум продајних места и каталог производа Ску (Стоцк Кеепинг Унит). Продајно место има атрибут „Тип продавнице“ са вредностима „мало“ и „велико“. Асортиман (листа производа продајног места) повезан је са сваким продајним местом (учитава се из ДБМС) и даје се информација да је од наведеног датума наведени производ
искључени из асортимана или додати у асортиман.

Потребно је организовати партиционисану кеш меморију продајних места и чувати у њој информације о повезаним производима месец дана унапред. Компатибилност са борбеним системом захтева да клијентски чвор Игните учита податке, израчуна агрегат форме (тип продавнице, шифра производа, дан, број_продајних тачака) и отпреми га назад у ДБМС.

2. Студиј књижевности

Још немам искуства, па почињем да плешем са шпорета. Односно из прегледа публикација.

Члан 2016. године Представљамо Апацхе Игните: Први кораци садржи везу ка документацији пројекта Апацхе Игните и истовремено замерку због недоречености ове документације. Прочитао сам га неколико пута, јасноћа не долази. Позивам се на званични водич почетакКоји
оптимистично обећава „Почећете за трен!“ Схватам подешавања променљиве окружења, гледам два видео снимка Апацхе Игните Ессентиалс, али нису били од велике користи за мој специфични задатак. Успешно сам покренуо Игните из командне линије са стандардном датотеком „екампле-игните.кмл“, правећи прву апликацију Цомпуте Апплицатион користећи Мавен. Апликација ради и користи Зеро Деплоимент, каква лепота!

Читао сам даље, и тамо пример одмах користи аффинитиКеи (направљен раније путем СКЛ упита), па чак користи и мистериозни БинариОбјецт:

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

читати незнатно: бинарни формат - нешто попут рефлексије, приступање пољима објекта по имену. Може да прочита вредност поља без потпуне десеријализације објекта (уштеда меморије). Али зашто се БинариОбјецт користи уместо Персон, пошто постоји нулта примена? Зашто ИгнитеЦацхе пребачен у ИгнитеЦацхе ? Још није јасно.

Преправљам Цомпуте апликацију да одговара мом случају. Примарни кључ директоријума продајних места у МССКЛ је дефинисан као [ид] [инт] НОТ НУЛЛ, правим кеш по аналогији

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

У кмл конфигурацији означавам да је кеш партициониран

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

Партиционисање по продајном месту претпоставља да ће на сваком чвору кластера бити изграђен потребан агрегат за салесПоинтЦацхе записе који су тамо доступни, након чега ће клијентски чвор извршити коначно сумирање.

Читам туторијал Прва апликација Игните Цомпуте, ја то радим по аналогији. На сваком чвору кластера покрећем ИгнитеРуннабле(), нешто овако:

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

Додајем логику агрегације и отпремања и покрећем је на скупу тестних података. Све ради локално на развојном серверу.

Покрећем два ЦентОс тест сервера, наведем ИП адресе у дефаулт-цонфиг.кмл, извршим на сваком

./bin/ignite.sh config/default-config.xml

Оба Игните чвора раде и могу да се виде. Одређујем тражене адресе у кмл конфигурацији клијентске апликације, она се покреће, додаје трећи чвор у топологију и одмах опет постоје два чвора. Дневник приказује „ЦлассНотФоундЕкцептион: модел.СалесПоинт“ у реду

SalesPoint sp=salesPointCache.get(spId);

СтацкОверфлов каже да је разлог за грешку то што не постоји прилагођена класа СалесПоинт на ЦентОс серверима. Стигли смо. Шта кажете на „не морате ручно да примењујете свој Јава код на сваком чвору“ и тако даље? Или се „ваш Јава код“ не односи на СалесПоинт?

Вероватно сам нешто пропустио – поново почињем да тражим, читам и поново тражим. После неког времена имам осећај да сам прочитао све на тему, нема више ништа ново. Док сам тражио, нашао сам неке занимљиве коментаре.

Валентин Куличенко, водећи архитекта у ГридГаин Системс, одговор на СтацкОверфлов, април 2016:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

Још једно ауторитативно мишљење: Денис Магда, директор управљања производима, ГридГаин Системс.

Чланак на Хабреу о микросервисима референцира три чланка Дениса Магде: Микросервис Део И, Микросервис Део ИИ, Микросервис Део ИИИ 2016-2017. У другом чланку, Денис предлаже покретање чвора кластера преко МаинтенанцеСервицеНодеСтартуп.јар. Такође можете да користите покретање са кмл конфигурацијом и командном линијом, али тада морате ручно да ставите прилагођене класе на сваки распоређени чвор кластера:

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

Заиста, то је то. Овде се испоставља, зашто, овај мистериозни бинарни формат!

3.СинглеЈар

Денис је заузео прво место у мојој личној оцени, ИМХО најкориснији водич од свих доступних. У његовој МицроСервицесЕкампле Гитхуб садржи потпуно готов пример подешавања чворова кластера, који се компајлира без икаквог додатног сквота.

Радим то на исти начин и добијам једну јар датотеку која покреће „чвор података“ или „цлиент ноде“ у зависности од аргумента командне линије. Скупштина почиње и ради. Зеро Деплоимент је поражен.

Прелазак са мегабајта тестних података на десетине гигабајта борбених података показао је да бинарни формат постоји с разлогом. Било је неопходно оптимизовати потрошњу меморије на чворовима, и ту се показало да је БинариОбјецт био веома користан.

4. Закључци

Први приговор на нејасност пројектне документације Апацхе Игните показао се фер; мало се тога променило од 2016. Почетнику није лако да састави функционални прототип заснован на веб локацији и/или спремишту.

На основу резултата обављеног посла, стекао се утисак да Зеро Деплоимент функционише, али само на системском нивоу. Нешто овако: БинариОбјецт се користи за учење удаљених чворова кластера да раде са прилагођеним класама; Зеро Деплоимент - интерни механизам
Апацхе Игните сам и дистрибуира системске објекте по целом кластеру.

Надам се да ће моје искуство бити корисно новим корисницима Апацхе Игните-а.

Извор: ввв.хабр.цом

Додај коментар