Мы - аддзел развіцця тэхналогій рознічнай сеткі. Аднойчы кіраўніцтва паставіла задачу паскорыць аб'ёмныя вылічэнні за рахунак выкарыстання Apache Ignite у звязку з MSSQL, паказала сайт з выдатнымі ілюстрацыямі і прыкладамі Java-кода. На сайце адразу спадабаўся , апісанне якога абяцае цуды: Вы не можаце рабіць manually deploy your Java or Scala code on each node in the grid and re-deploy it each time it changes. Па ходзе працы аказалася, што Zero Deployment валодае спецыфікай выкарыстання, асаблівасцямі якой я і хачу падзяліцца. Пад катам разважанні і падрабязнасці рэалізацыі.
1. Пастаноўка задачы
Сутнасць задачы ў наступным. Ёсць даведнік кропак продажу SalesPoint і даведнік тавараў Sku (Stock Keeping Unit). Кропка продажаў мае атрыбут «тыпМагазіна» са значэннямі «малы» і «вялікі». Да кожнай кропкі продажаў падключаецца (загружаецца з СКБД) асартымент (спіс тавараў пункту продажу) і падаецца інфармацыя аб тым, што з указанай даты ўказаны тавар
выключаецца з асартыменту або дадаецца ў асартымент.
Патрабуецца арганізаваць партыцыянаваны кэш кропак продажу і захоўваць у ім інфармацыю аб падключаных таварах на месяц наперад. Сумяшчальнасць з баявой сістэмай патрабуе ад кліенцкага вузла Ignite загружаць дадзеныя, вылічаць агрэгат віду (тып крама, код тавару, дзень, лік_кропак_продажаў) і выгружаць яго назад у СКБД.
2. Вывучэнне літаратуры
Досведу пакуль што няма, так што пачынаю скакаць ад печкі. Гэта значыць, з агляду публікацый.
Артыкул 2016 года змяшчае спасылку на дакументацыю праекта Apache Ignite і заадно папрок у невыразнасці гэтай дакументацыі. Перачытаў пару разоў, яснасць не надыходзіць. Звяртаюся да афіцыйнага тутарыялу , Які
аптымістычна абяцае "You'll be up and running in a jiffy!". Разбіраюся з наладамі зменных асяроддзя, гляджу два відэа Apache Ignite Essentials, для маёй канкрэтнай задачы яны аказаліся не вельмі карысныя. Паспяхова запускаю Ignite з каманднага радка са стандартным файлам «example-ignite.xml», збіраю першы дадатак з дапамогай Maven. Прыкладанне працуе і выкарыстоўвае Zero Deployment, якая прыгажосць!
Чытаю далей, а тамака прыклад адразу выкарыстае affinityKey (створаны раней праз SQL-запыт), ды яшчэ і ўжываецца загадкавы BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Шанаваў : бінарны фармат - нешта накшталт рэфлексіі, доступ да палёў аб'екта па імені. Можа чытаць значэнне поля без поўнай дэсерыялізацыі аб'екта (эканомія памяці). Але навошта замест Person выкарыстоўваецца BinaryObject, бо есць Zero Deployment? Навошта IgniteCache перакладаецца ў IgniteCache ? Пакуль незразумела.
Перарабляю Compute Application пад свой выпадак. Першасны ключ даведніка кропак продажаў у MSSQL вызначаны як [id] [int] NOT NULL, ствараю кэш па аналогіі
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")У xml-канфігу ўказваю, што кэш партыцыянаваны
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Партыцыянаванне па кропках продажаў мяркуе, што патрабаваны агрэгат будзе пабудаваны на кожным вузле кластара для наяўных там запісаў salesPointCache, пасля чаго кліенцкі вузел выканае выніковае сумаванне.
Чытаю тутарыял , раблю па аналогіі. На кожным вузле кластара запускаю IgniteRunnable(), прыкладна вось так:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Дадаю логіку агрэгацыі і выгрузкі, запускаю на тэставым наборы дадзеных. Лакальна на сэрвэры распрацоўкі ўсё працуе.
Запускаю два тэставых сервера CentOs, паказваю ip-адрасы ў default-config.xml, выконваю на кожным
./bin/ignite.sh config/default-config.xmlАбодва вузла Ignite запускаюцца і бачаць адзін аднаго. Паказваю патрэбныя адрасы ў xml-канфігу кліенцкага прыкладання, яно запускаецца, дадае трэці вузел у тапалогію і адразу ж вузлоў становіцца зноў два. У логу значыцца "ClassNotFoundException: model.SalesPoint" у радку
SalesPoint sp=salesPointCache.get(spId);StackOverflow кажа, што прычына памылкі - на серверах CentOs няма карыстацкага класа SalesPoint. Прыехалі. Як жа "не трэба рабіць manually deploy your Java code on each node" і далей па тэксце? Ці «your Java code» - гэта не пра SalesPoint?
Верагодна, я нешта выпусціў — зноў пачынаю шукаць, чытаць і зноў шукаць. Праз час узнікае адчуванне, што я прачытаў па тэме ўсё, нічога новага ўжо няма. Пакуль шукаў, знайшоў некалькі цікавых зацемак.
, Lead Architect at GridGain Systems, на StackOverflow, красавік 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.Яшчэ адно аўтарытэтнае меркаванне: , Director of product management, GridGain Systems.
Артыкул на Хабры спасылаецца тры артыкулы Denis Magda: , , 2016-2017 гадоў. У другім артыкуле Denis прапануе стартаваць вузел кластара праз MaintenanceServiceNodeStartup.jar. Можна таксама выкарыстоўваць запуск з xml-канфігурацыяй і камандным радком, але тады трэба ўручную пакласці карыстацкія класы на кожны які разгортваецца вузел кластара:
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. SingleJar
Denis заняў у маім асабістым рэйтынгу першае месца, імхо самы карысны тутарыял з усіх даступных. У яго на гітхабе змяшчаецца цалкам гатовы прыклад налады вузлоў кластара, які кампілюецца без усялякіх дадатковых прысяданняў.
Раблю па выяве і падабенству, атрымліваю адзіны файл jar, які запускае "data node" або "client node" у залежнасці ад аргументу каманднага радка. Зборка запускаецца і працуе. Zero Deployment пераможаны.
Пераход ад мегабайтаў тэставых дадзеных да дзясяткаў гігабайтаў баявых паказаў, што бінарны фармат існуе нездарма. Запатрабавалася аптымізаваць выдатак памяці на нодах, і вось тут BinaryObject апынуўся вельмі карысны.
4. высновы
Першы сустрэты папрок у невыразнасці дакументацыі праекта Apache Ignite аказаўся справядлівы, з 2016 года памянялася няшмат. Навічку няпроста сабраць які функцыянуе прататып на аснове сайта і/або рэпазітара.
Па выніку праведзенай працы склалася ўражанне, што Zero Deployment працуе, але толькі на сістэмным узроўні. Прыкладна так: BinaryObject прымяняецца, каб навучыць выдаленыя вузлы кластара працаваць з карыстацкімі класамі; Zero Deployment – унутраны механізм
самога Apache Ignite і распаўсюджвае па кластары сістэмныя аб'екты.
Спадзяюся, мой досвед будзе карысны новым карыстачам Apache Ignite.
Крыніца: habr.com