Txikizkako sare baten garapen teknologikoko saila gara. Egun batean, zuzendaritzak eskala handiko kalkuluak bizkortzeko zeregina ezarri zuen Apache Ignite MSSQLrekin batera erabiliz, eta Java kodearen ilustrazio eta adibide ederrekin web orri bat erakutsi zuen. Berehala gustatu zitzaidan gunea , zeinaren deskribapenak mirariak agintzen ditu: ez duzu zure Java edo Scala kodea eskuz zabaldu beharrik sareko nodo bakoitzean eta berriro zabaldu beharrik aldatzen den bakoitzean. Lanak aurrera egin ahala, Zero Deployment-ek erabilera zehatzak dituela ikusi zen, eta horien ezaugarriak partekatu nahi ditudan. Ebakiaren azpian pentsamenduak eta ezarpenaren xehetasunak daude.
1. Arazoaren adierazpena
Arazoaren funtsa honakoa da. SalesPoint salmenta puntuen direktorioa eta Sku (Stock Keeping Unit) produktuen direktorioa daude. Salmenta-puntuak "Denda mota" atributu bat du "txikia" eta "handia" balioekin. Salmenta-puntu bakoitzari sorta bat (salmenta-puntuko produktuen zerrenda) konektatzen da (DBMStik kargatuta) eta zehaztutako datatik zehaztutako produktua adierazten duen informazioa ematen da.
sortatik kanpo utzita edo sortara gehituta.
Salmenta puntuen cache partizionatua antolatu behar da eta bertan konektatutako produktuei buruzko informazioa gorde behar da hilabete lehenago. Borroka sistemarekin bateragarritasunak Ignite bezero-nodoak datuak kargatu behar ditu, inprimakiaren agregazio bat kalkulatu (Denda mota, Produktu-kodea, eguna, salmenta-puntu-kopurua) eta DBMSra kargatu berriro.
2. Literaturaren azterketa
Oraindik ez daukat esperientziarik, beraz, sukaldetik dantzan hasi naiz. Hau da, argitalpenen berrikuspenetik.
2016. artikulua Apache Ignite proiektuaren dokumentaziorako esteka bat dauka eta, aldi berean, dokumentazio honen lausotasunari errieta bat dago. Berriro irakurri dut pare bat aldiz, argitasuna ez dator. Tutorial ofizialera aipatzen dut Zein
baikor agintzen du: "Laster batean martxan egongo zara!" Ingurune-aldagaiaren ezarpenak asmatzen ari naiz, Apache Ignite Essentials-eko bi bideo ikusten, baina ez ziren oso erabilgarriak nire zeregin zehatzerako. Arrakastaz abiarazi dut Ignite komando-lerrotik "example-ignite.xml" fitxategi estandarrarekin, lehen aplikazioa eraikiz Maven erabiliz. Aplikazioak funtzionatzen du eta Zero Deployment erabiltzen du, zer edertasuna!
Gehiago irakurri dut, eta hor adibidea berehala erabiltzen du affinityKey (lehenago SQL kontsulta baten bidez sortua), eta BinaryObject misteriotsua ere erabiltzen du:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); irakurri dut : formatu bitarra - isla bezalako zerbait, objektu baten eremuetara izenaren arabera sartzea. Eremu baten balioa irakur dezake objektua guztiz deserializatu gabe (memoria aurreztuz). Baina zergatik erabiltzen da BinaryObject Person ordez, Zero Deployment dagoenez? Zergatik IgniteCache IgniteCache-ra transferitu da ? Oraindik ez dago argi.
Konputazio aplikazioa birsortzen ari naiz nire kasurako. MSSQL-n salmenta-puntuen direktorioaren gako nagusia [id] [int] EZ NULL gisa definitzen da, analogiaz sortzen dut cachea
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")xml konfigurazioan cachea partizionatuta dagoela adierazten dut
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Salmenta puntuaren arabera banatzeak suposatzen du beharrezko agregatua eraikiko dela kluster-nodo bakoitzean bertan dauden salesPointCache erregistroetarako, eta ondoren bezero-nodoak azken batuketa egingo du.
Tutoriala irakurtzen ari naiz , analogiaz egiten dut. Kluster nodo bakoitzean IgniteRunnable() exekutatzen dut, honelako zerbait:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Agregazio eta kargatzeko logika gehitzen dut eta probako datu multzo batean exekutatzen dut. Dena lokalean funtzionatzen du garapen zerbitzarian.
Bi CentOs proba-zerbitzari abiarazten ditut, IP helbideak default-config.xml-n zehazten ditut, bakoitzean exekutatzen ditut
./bin/ignite.sh config/default-config.xmlIgnite nodo biak martxan daude eta elkar ikus dezakete. Bezeroaren aplikazioaren xml konfigurazioan eskatzen diren helbideak zehazten ditut, hasten da, hirugarren nodo bat gehitzen dio topologiari eta berehala bi nodo daude berriro. Erregistroak "ClassNotFoundException: model.SalesPoint" erakusten du lerroan
SalesPoint sp=salesPointCache.get(spId);StackOverflow-ek dio errorearen arrazoia CentOs zerbitzarietan SalesPoint klase pertsonalizaturik ez dagoela dela. Iritsi gara. Zer gertatzen da "ez duzu zure Java kodea eskuz zabaldu behar nodo bakoitzean" eta abar? Edo "zure Java kodea" ez al da SalesPoint-i buruz?
Seguruenik zerbait galdu dut - berriro bilatzen hasten naiz, irakurtzen eta berriro bilatzen. Pixka bat igaro ondoren, gaiari buruzko guztia irakurri dudala sentsazioa daukat, jada ez dago ezer berririk. Bilatzen ari nintzela, iruzkin interesgarri batzuk aurkitu ditut.
, GridGain Systems-eko arkitekto nagusia, StackOverflow-en, 2016ko apirilean:
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.Beste iritzi autoritario bat: , produktuen kudeaketako zuzendaria, GridGain Systems.
HabrΓ©ri buruzko artikulua Denis Magdaren hiru artikulu aipatzen ditu: , , 2016-2017. Bigarren artikuluan, Denis-ek MaintenanceServiceNodeStartup.jar bidez kluster-nodo bat hastea proposatzen du. Abian ere erabil dezakezu xml konfigurazioarekin eta komando-lerroarekin, baina gero eskuz klase pertsonalizatuak jarri behar dituzu zabaldutako kluster nodo bakoitzean:
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.Izan ere, hori da. Hona hemen, zergatik, formatu bitar misteriotsu hau!
3.SingleJar
Denis-ek nire balorazio pertsonalean lehen postua hartu zuen, eskuragarri dauden guztien artean tutorial erabilgarriena. Berean Github-ek kluster-nodoak konfiguratzeko guztiz prest egindako adibide bat dauka, okupazio gehigarririk gabe konpilatzen duena.
Modu berean egiten dut eta komando lerroko argumentuaren arabera "datu-nodoa" edo "bezero-nodoa" abiarazten duen jar fitxategi bakarra lortzen dut. Muntaia hasi eta funtzionatzen du. Zero Deployment garaitu da.
Proba-datu megabytetik borroka-datu hamarnaka gigabyterako trantsizioak erakutsi zuen formatu bitarra arrazoi bategatik existitzen dela. Nodoetan memoria-kontsumoa optimizatzea beharrezkoa zen, eta hor BinaryObject oso erabilgarria izan zen.
4. Ondorioak
Apache Ignite proiektuaren dokumentazioaren lausotasunari buruz aurkitutako lehen errieta bidezkoa izan zen; ezer gutxi aldatu da 2016tik. Hasiberrientzat ez da erraza webgune eta/edo biltegi batean oinarritutako prototipo funtzionala muntatzea.
Egindako lanaren emaitzetan oinarrituta, Zero Deployment-ek funtzionatzen duela iruditu zitzaion, baina sistema mailan soilik. Honelako zerbait: BinaryObject urruneko kluster nodoei klase pertsonalizatuekin lan egiten irakasteko erabiltzen da; Zero hedapena - barne-mekanismoa
Apache Ignite bera eta sistema-objektuak kluster osoan banatzen ditu.
Nire esperientzia Apache Ignite erabiltzaile berrientzat erabilgarria izatea espero dut.
Iturria: www.habr.com