Mi smo odjel za tehnološki razvoj maloprodajne mreže. Jednog dana, menadžment je postavio zadatak da ubrza velike proračune koristeći Apache Ignite u kombinaciji sa MSSQL-om i pokazao web stranicu sa prekrasnim ilustracijama i primjerima Java koda. Odmah mi se svidjela stranica , čiji opis obećava čuda: ne morate ručno postavljati svoj Java ili Scala kod na svaki čvor u mreži i ponovo ga postavljati svaki put kada se promijeni. Kako je posao napredovao, pokazalo se da Zero Deployment ima specifične namjene, čije karakteristike želim podijeliti. Ispod reza su misli i detalji implementacije.
1. Izjava o problemu
Suština problema je sljedeća. Postoji SalesPoint imenik prodajnih mjesta i Sku (Stock Keeping Unit) katalog proizvoda. Prodajno mjesto ima atribut „Vrsta trgovine“ s vrijednostima „malo“ i „veliko“. Asortiman (lista proizvoda prodajnog mjesta) je povezan sa svakim prodajnim mjestom (učitava se iz DBMS-a) i daje se informacija da je od navedenog datuma navedeni proizvod
isključeni iz asortimana ili dodani u asortiman.
Potrebno je organizirati particioniranu keš memoriju prodajnih mjesta i pohraniti u nju informacije o povezanim proizvodima za mjesec dana unaprijed. Kompatibilnost sa borbenim sistemom zahtijeva da klijentski čvor Ignite učita podatke, izračuna agregat forme (vrsta trgovine, šifra proizvoda, dan, broj_prodajnih bodova) i prenese ga nazad u DBMS.
2. Studij književnosti
Još nemam iskustva, pa počinjem da plešem sa šporeta. Odnosno, iz pregleda publikacija.
Član 2016 sadrži vezu na dokumentaciju projekta Apache Ignite i istovremeno zamjerka nedorečenosti ove dokumentacije. Pročitao sam ga nekoliko puta, ne dolazi do jasnoće. Pozivam se na službeni tutorijal , što je
optimistično obećava „Pokrenut ćeš se za tren!“ Pronalazim postavke varijabli okruženja, gledam dva Apache Ignite Essentials videa, ali nisu bili od velike koristi za moj specifični zadatak. Uspješno sam pokrenuo Ignite iz komandne linije sa standardnom datotekom “example-ignite.xml”, praveći prvu aplikaciju koristeći Maven. Aplikacija radi i koristi Zero Deployment, kakva ljepota!
Čitao sam dalje, i tamo primjer odmah koristi affinityKey (kreiran ranije kroz SQL upit), pa čak koristi i misteriozni BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Pročitao sam : binarni format - nešto poput refleksije, pristupanje poljima objekta po imenu. Može čitati vrijednost polja bez potpune deserijalizacije objekta (štedenje memorije). Ali zašto se BinaryObject koristi umjesto Person, budući da postoji Zero Deployment? Zašto IgniteCache prebačen u IgniteCache ? Još nije jasno.
Prepravljam Compute aplikaciju da odgovara mom slučaju. Primarni ključ imenika prodajnih mjesta u MSSQL je definiran kao [id] [int] NOT NULL, ja kreiram keš po analogiji
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")U xml konfiguraciji označavam da je keš particioniran
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Particioniranje po prodajnom mjestu pretpostavlja da će se na svakom čvoru klastera izgraditi potrebni agregat za tamo dostupne salesPointCache zapise, nakon čega će klijentski čvor izvršiti konačno zbrajanje.
Čitam tutorijal , ja to radim po analogiji. Na svakom čvoru klastera pokrećem IgniteRunnable(), otprilike ovako:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Dodajem logiku agregiranja i učitavanja i pokrećem je na skupu testnih podataka. Sve radi lokalno na razvojnom serveru.
Pokrećem dva CentOs test servera, specificiram IP adrese u default-config.xml, izvršavam na svakom
./bin/ignite.sh config/default-config.xmlOba Ignite čvora rade i mogu se vidjeti. Određujem tražene adrese u xml konfiguraciji klijentske aplikacije, ona se pokreće, dodaje treći čvor u topologiju i odmah opet postoje dva čvora. Dnevnik prikazuje “ClassNotFoundException: model.SalesPoint” u redu
SalesPoint sp=salesPointCache.get(spId);StackOverflow kaže da je razlog greške to što ne postoji prilagođena klasa SalesPoint na CentOs serverima. Stigli smo. Šta kažete na „ne morate ručno postavljati svoj Java kod na svaki čvor“ i tako dalje? Ili se „vaš Java kod“ ne odnosi na SalesPoint?
Verovatno sam nešto propustio - ponovo počinjem da tražim, čitam i ponovo 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 arhitekta u 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.Još jedno mjerodavno mišljenje: , direktor upravljanja proizvodima, GridGain Systems.
Članak na Habréu referencira tri članka Denisa Magde: , , 2016-2017. U drugom članku, Denis predlaže pokretanje čvora klastera putem MaintenanceServiceNodeStartup.jar. Također možete koristiti pokretanje s xml konfiguracijom i komandnom linijom, ali tada morate 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.Zaista, to je to. Evo, ispostavilo se, zašto, ovaj misteriozni binarni format!
3.SingleJar
Denis je zauzeo prvo mjesto u mojoj ličnoj ocjeni, IMHO najkorisniji vodič od svih dostupnih. U njegovom Github sadrži potpuno gotov primjer postavljanja čvorova klastera, koji se kompajlira bez dodatnog skvota.
Ja to radim na isti način i dobijam jednu jar datoteku koja pokreće “data node” ili “client node” u zavisnosti od argumenta komandne linije. Montaža počinje i radi. Zero Deployment je poražen.
Prelazak sa megabajta testnih podataka na desetine 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. Zaključci
Prvi prigovor na nejasnost projektne dokumentacije Apache Ignite pokazao se poštenim; malo se toga promijenilo od 2016. Početniku nije lako sastaviti funkcionalni prototip zasnovan na web stranici i/ili spremištu.
Na osnovu rezultata obavljenog posla, stekao se utisak da Zero Deployment funkcioniše, ali samo na nivou sistema. Nešto ovako: BinaryObject se koristi za podučavanje udaljenih čvorova klastera da rade sa prilagođenim klasama; Zero Deployment - interni mehanizam
Apache Ignite sam i distribuira sistemske objekte po cijelom klasteru.
Nadam se da će moje iskustvo biti korisno novim korisnicima Apache Ignite-a.
izvor: www.habr.com