Mi smo odjel za tehnološki razvoj maloprodajne mreže. Jednog dana, uprava je postavila zadatak ubrzanja velikih izračuna korištenjem Apache Ignite-a u kombinaciji s MSSQL-om i pokazala web stranicu s prekrasnim ilustracijama i primjerima Java koda. Stranica mi se odmah svidjela , čiji opis obećava čuda: ne morate ručno implementirati svoj Java ili Scala kod na svakom čvoru u mreži i ponovno ga implementirati svaki put kada se promijeni. Kako je rad napredovao, pokazalo se da Zero Deployment ima specifične namjene, čije značajke želim podijeliti. Ispod presjeka nalaze se misli i detalji provedbe.
1. Izjava problema
Suština problema je sljedeća. Postoji imenik prodajnih mjesta SalesPoint i imenik proizvoda Sku (Stock Keeping Unit). Prodajno mjesto ima atribut "Vrsta trgovine" s vrijednostima "mali" i "veliki". Za svako prodajno mjesto povezan je asortiman (popis proizvoda prodajnog mjesta) (učitava se iz DBMS-a) i daje informacija da od navedenog datuma navedeni proizvod
isključeni iz asortimana ili dodani u asortiman.
Potrebno je organizirati particioniranu predmemoriju prodajnih mjesta i u nju pohraniti informacije o povezanim proizvodima za mjesec dana unaprijed. Kompatibilnost s borbenim sustavom zahtijeva da Ignite klijentski čvor učitava podatke, izračunava agregat obrasca (vrsta trgovine, šifra proizvoda, dan, broj_prodajnih_točaka) i učitava ga natrag u DBMS.
2. Studij književnosti
Nemam još iskustva pa počinjem plesati za šporetom. Odnosno iz pregleda publikacija.
Članak 2016 sadrži poveznicu na dokumentaciju projekta Apache Ignite i ujedno zamjerku nedorečenosti te dokumentacije. Pročitao sam ga nekoliko puta, jasnoća ne dolazi. Upućujem na službeni vodič Koji
optimistično obećava "Pokrenut ćete se za tren oka!" Smišljam postavke varijable okruženja, gledam dva videa Apache Ignite Essentials, ali nisu bili baš korisni za moj specifični zadatak. Uspješno pokrećem Ignite iz naredbenog retka sa standardnom datotekom “example-ignite.xml”, gradeći prvu aplikaciju koristeći Maven. Aplikacija radi i koristi Zero Deployment, kakva ljepota!
Čitao sam dalje, i tamo primjer odmah koristi affinityKey (stvoren ranije kroz SQL upit), pa čak koristi i misteriozni BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Pročitao sam ga : binarni format - nešto poput refleksije, pristup poljima objekta po imenu. Može pročitati vrijednost polja bez potpune deserijalizacije objekta (štedi memoriju). Ali zašto se koristi BinaryObject umjesto Person, budući da postoji Zero Deployment? Zašto IgniteCache prebačen u IgniteCache ? Još nije jasno.
Prepravljam aplikaciju Compute kako bi odgovarala mom slučaju. Primarni ključ direktorija prodajnih mjesta u MSSQL-u je definiran kao [id] [int] NOT NULL, stvaram predmemoriju po analogiji
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")U xml konfiguraciji ukazujem da je predmemorija particionirana
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Particioniranje prema prodajnom mjestu pretpostavlja da će se zahtijevani agregat izgraditi na svakom čvoru klastera za zapise salesPointCache koji su tamo dostupni, nakon čega će čvor klijenta izvršiti konačno zbrajanje.
Čitam tutorial , radim to po analogiji. Na svakom čvoru klastera pokrećem IgniteRunnable(), otprilike ovako:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Dodao sam agregaciju i logiku učitavanja i pokrenuo to na testnom skupu podataka. Sve radi lokalno na razvojnom poslužitelju.
Pokrećem dva CentOs testna poslužitelja, navodim IP adrese u default-config.xml, izvršavam na svakom
./bin/ignite.sh config/default-config.xmlOba Ignite čvora rade i mogu vidjeti jedan drugog. Specificiram tražene adrese u xml konfiguraciji klijentske aplikacije, ona se pokreće, dodaje treći čvor u topologiju i odmah se opet pojavljuju dva čvora. Dnevnik prikazuje "ClassNotFoundException: model.SalesPoint" u retku
SalesPoint sp=salesPointCache.get(spId);StackOverflow kaže da je razlog pogreške to što ne postoji prilagođena klasa SalesPoint na CentOs poslužiteljima. Stigli smo. Što kažete na "ne morate ručno implementirati svoj Java kod na svakom čvoru" i tako dalje? Ili se "vaš Java kod" ne odnosi na SalesPoint?
Vjerojatno sam nešto propustio - ponovno tražim, čitam i ponovno tražim. Nakon nekog vremena imam osjećaj da sam pročitao sve na temu, nema više ništa novo. Dok sam tražio, našao sam neke zanimljive komentare.
, vodeći arhitekt u GridGain Systems, na StackOverflowu, travanj 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.Još jedno mjerodavno mišljenje: , direktor upravljanja proizvodima, GridGain Systems.
Članak na Habréu upućuje na tri članka Denisa Magde: , , 2016-2017. U drugom članku Denis predlaže pokretanje čvora klastera preko MaintenanceServiceNodeStartup.jar. Također možete koristiti pokretanje s xml konfiguracijom i naredbenim retkom, ali tada trebate ručno staviti prilagođene klase na svaki raspoređeni čvor klastera:
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.Doista, to je to. Evo, ispada, zašto, ovaj tajanstveni binarni format!
3.SingleJar
Denis je zauzeo prvo mjesto u mojoj osobnoj ocjeni, IMHO najkorisniji tutorial od svih dostupnih. U njegovom Github sadrži potpuno gotov primjer postavljanja čvorova klastera koji se kompajlira bez ikakvog dodatnog čučanja.
Ja to radim na isti način i dobivam jednu jar datoteku koja pokreće "data node" ili "client node" ovisno o argumentu naredbenog retka. Montaža počinje i radi. Zero Deployment je poražen.
Prijelaz s megabajta testnih podataka na desetke gigabajta borbenih podataka pokazao je da binarni format postoji s razlogom. Bilo je potrebno optimizirati potrošnju memorije na čvorovima i tu se BinaryObject pokazao vrlo korisnim.
4. nalazi
Prvi prigovor na nedorečenost projektne dokumentacije Apache Ignite pokazao se opravdanim; malo se toga promijenilo od 2016. Početniku nije lako sastaviti funkcionalni prototip na temelju web stranice i/ili repozitorija.
Na temelju rezultata obavljenog rada stekao se dojam da Zero Deployment radi, ali samo na razini sustava. Nešto ovako: BinaryObject se koristi za učenje udaljenih čvorova klastera za rad s prilagođenim klasama; Zero Deployment - unutarnji mehanizam
Apache Ignite sam i distribuira sistemske objekte po klasteru.
Nadam se da će moje iskustvo biti korisno novim korisnicima Apache Ignitea.
Izvor: www.habr.com