Smo tehnološki razvojni oddelek maloprodajne mreže. Nekega dne je vodstvo postavilo nalogo pospešiti obsežne izračune z uporabo Apache Ignite v povezavi z MSSQL in pokazalo spletno stran s čudovitimi ilustracijami in primeri kode Java. Stran mi je bila takoj všeč , katerega opis obljublja čudeže: ni vam treba ročno namestiti kode Java ali Scala na vsako vozlišče v mreži in jo znova namestiti vsakič, ko se spremeni. Ko je delo napredovalo, se je izkazalo, da ima Zero Deployment posebne namene, katerih lastnosti želim deliti z vami. Pod rezom so misli in podrobnosti izvedbe.
1. Izjava problema
Bistvo problema je naslednje. Obstaja imenik prodajnih mest SalesPoint in imenik izdelkov Sku (Stock Keeping Unit). Prodajno mesto ima atribut »Vrsta trgovine« z vrednostma »majhno« in »veliko«. Z vsakim prodajnim mestom je povezan asortiment (seznam izdelkov prodajnega mesta) (naložen iz DBMS) in podana informacija, da od navedenega datuma navedeni izdelek
izločeno iz sortimenta ali dodano v sortiment.
Potrebno je organizirati razdeljen predpomnilnik prodajnih mest in vanj shraniti podatke o povezanih izdelkih za en mesec vnaprej. Združljivost z bojnim sistemom zahteva, da odjemalsko vozlišče Ignite naloži podatke, izračuna agregat obrazca (vrsta trgovine, koda izdelka, dan, število_prodajnih_točk) in ga naloži nazaj v DBMS.
2. Študij literature
Nimam še nobenih izkušenj, zato začenjam plesati za štedilnikom. Se pravi iz pregleda publikacij.
člen 2016 vsebuje povezavo do dokumentacije projekta Apache Ignite in hkrati očitek o nedorečenosti te dokumentacije. Nekajkrat sem ga ponovno prebral, jasnost ni prišla. Sklicujem se na uradno vadnico Kateri
optimistično obljublja "V hipu boš pripravljen!" Ugotavljam nastavitve spremenljivke okolja, gledam dva videoposnetka Apache Ignite Essentials, vendar nista bila zelo uporabna za mojo specifično nalogo. Uspešno zaženem Ignite iz ukazne vrstice s standardno datoteko »example-ignite.xml«, s čimer zgradim prvo aplikacijo z uporabo Maven. Aplikacija deluje in uporablja Zero Deployment, kakšna lepota!
Berem naprej in tam primer takoj uporabi affinityKey (ustvarjen prej prek poizvedbe SQL) in celo uporabi skrivnostni BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Prebral sem : binarna oblika - nekaj podobnega refleksiji, dostop do polj predmeta po imenu. Lahko prebere vrednost polja brez popolne deserializacije predmeta (prihrani pomnilnik). Toda zakaj se namesto osebe uporablja BinaryObject, saj obstaja Zero Deployment? Zakaj IgniteCache prenese v IgniteCache ? Ni še jasno.
Prenavljam aplikacijo Compute, da bo ustrezala mojemu primeru. Primarni ključ imenika prodajnih mest v MSSQL je definiran kot [id] [int] NOT NULL, po analogiji ustvarim predpomnilnik
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")V konfiguraciji xml navedem, da je predpomnilnik particioniran
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Particioniranje po prodajnem mestu predpostavlja, da bo zahtevani agregat zgrajen na vsakem vozlišču gruče za tam razpoložljive zapise salesPointCache, nato pa bo odjemalsko vozlišče izvedlo končno seštevanje.
Berem vadnico , delam po analogiji. Na vsakem vozlišču gruče zaženem IgniteRunnable(), nekaj takega:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Dodam logiko združevanja in nalaganja ter jo zaženem na testnem nizu podatkov. Vse deluje lokalno na razvojnem strežniku.
Zaženem dva testna strežnika CentOs, določim naslova IP v default-config.xml, izvedem na vsakem
./bin/ignite.sh config/default-config.xmlObe vozlišči Ignite delujeta in se lahko vidita. V konfiguraciji xml odjemalske aplikacije določim zahtevane naslove, ta se zažene, v topologijo doda tretje vozlišče in takoj sta spet dve vozlišči. Dnevnik v vrstici prikazuje »ClassNotFoundException: model.SalesPoint«.
SalesPoint sp=salesPointCache.get(spId);StackOverflow pravi, da je razlog za napako ta, da na strežnikih CentOs ni razreda SalesPoint po meri. Prispeli smo. Kaj pa "ni vam treba ročno namestiti kode Java na vsako vozlišče" in tako naprej? Ali pa se »vaša koda Java« ne nanaša na SalesPoint?
Verjetno sem kaj spregledal – spet začnem iskati, brati in spet iskati. Čez nekaj časa dobim občutek, da sem prebral vse na temo, nič novega ni več. Med iskanjem sem našel nekaj zanimivih komentarjev.
, vodilni arhitekt pri GridGain Systems, na StackOverflow, april 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.Še eno avtoritativno mnenje: , direktor produktnega upravljanja, GridGain Systems.
Članek na Habréju navaja tri članke Denisa Magde: , , 2016-2017. V drugem članku Denis predlaga zagon vozlišča gruče preko MaintenanceServiceNodeStartup.jar. Uporabite lahko tudi zagon s konfiguracijo xml in ukazno vrstico, vendar morate potem ročno postaviti razrede po meri v vsako nameščeno vozlišče gruče:
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.Res, to je to. Tukaj se izkaže, zakaj, ta skrivnostni binarni format!
3.SingleJar
Denis je zasedel prvo mesto v moji osebni oceni, IMHO najbolj uporabna vadnica od vseh razpoložljivih. V njegovem Github vsebuje popolnoma pripravljen primer nastavitve vozlišč gruče, ki se prevede brez dodatnega skvotanja.
To naredim na enak način in dobim eno samo datoteko jar, ki zažene »podatkovno vozlišče« ali »odjemalsko vozlišče«, odvisno od argumenta ukazne vrstice. Montaža se začne in deluje. Zero Deployment je bil premagan.
Prehod z megabajtov testnih podatkov na desetine gigabajtov bojnih podatkov je pokazal, da binarni format obstaja z razlogom. Treba je bilo optimizirati porabo pomnilnika na vozliščih in tukaj se je BinaryObject izkazal za zelo uporabnega.
4. Sklepi
Prvi očitek o nedorečenosti projektne dokumentacije Apache Ignite se je izkazal za poštenega, od leta 2016 se ni spremenilo malo. Začetniku ni enostavno sestaviti delujočega prototipa na podlagi spletnega mesta in/ali skladišča.
Glede na rezultate opravljenega dela je bil vtis, da Zero Deployment deluje, a le na sistemski ravni. Nekaj takega: BinaryObject se uporablja za učenje oddaljenih vozlišč gruče za delo z razredi po meri; Zero Deployment – notranji mehanizem
Apache Ignite sam in razdeli sistemske objekte po gruči.
Upam, da bo moja izkušnja koristna novim uporabnikom Apache Ignite.
Vir: www.habr.com