Ne jemi departamenti i zhvillimit të teknologjisë së një rrjeti me pakicë. Një ditë, menaxhmenti vendosi detyrën për të shpejtuar llogaritjet në shkallë të gjerë duke përdorur Apache Ignite në lidhje me MSSQL dhe tregoi një faqe interneti me ilustrime të bukura dhe shembuj të kodit Java. Më pëlqeu menjëherë faqja , përshkrimi i të cilit premton mrekulli: ju nuk keni nevojë të vendosni manualisht kodin tuaj Java ose Scala në secilën nyje në rrjet dhe ta vendosni përsëri sa herë që ndryshon. Ndërsa puna përparoi, doli që Zero Deployment ka përdorime specifike, veçoritë e të cilave dua të ndaj. Më poshtë prerjes janë mendimet dhe detajet e zbatimit.
1. Deklarata e problemit
Thelbi i problemit është si më poshtë. Ekziston një drejtori SalesPoint e pikave të shitjes dhe një direktori produktesh Sku (Njësia e mbajtjes së aksioneve). Pika e shitjes ka një atribut "Lloji i dyqanit" me vlerat "i vogël" dhe "i madh". Një asortiment (lista e produkteve të pikës së shitjes) lidhet me secilën pikë shitje (të ngarkuar nga DBMS) dhe jepet informacion që nga data e specifikuar produkti i specifikuar
përjashtohen nga asortimenti ose i shtohen asortimentit.
Kërkohet të organizohet një memorie e ndarë e pikave të shitjes dhe të ruhet në të informacioni për produktet e lidhura për një muaj përpara. Përputhshmëria me sistemin luftarak kërkon që nyja e klientit Ignite të ngarkojë të dhënat, të llogarisë një total të formularit (lloji i dyqanit, kodi i produktit, dita, numri_i_pikave_shitjes) dhe ta ngarkojë përsëri në DBMS.
2. Studimi i letërsisë
Nuk kam ende ndonjë përvojë, kështu që po filloj të kërcej nga sobë. Kjo është, nga një rishikim i botimeve.
Neni 2016 përmban një lidhje me dokumentacionin e projektit Apache Ignite dhe në të njëjtën kohë një qortim për paqartësinë e këtij dokumentacioni. E rilexova disa herë, qartësia nuk vjen. I referohem tutorialit zyrtar Cila
premton në mënyrë optimiste "Do të jesh në këmbë dhe do të vraposh në një moment!" Po gjej cilësimet e ndryshores së mjedisit, duke parë dy video të Apache Ignite Essentials, por ato nuk ishin shumë të dobishme për detyrën time specifike. Unë e nis me sukses Ignite nga linja e komandës me skedarin standard "example-ignite.xml", duke ndërtuar aplikacionin e parë duke përdorur Maven. Aplikacioni funksionon dhe përdor Zero Deployment, çfarë bukurie!
Kam lexuar më tej, dhe atje shembulli përdor menjëherë affinityKey (i krijuar më herët përmes një pyetjeje SQL), dhe madje përdor BinaryObject misterioz:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); e lexova : format binar - diçka si reflektim, qasja në fushat e një objekti me emër. Mund të lexojë vlerën e një fushe pa e deserializuar plotësisht objektin (duke kursyer kujtesën). Por pse përdoret BinaryObject në vend të Person, pasi ekziston Zero Deployment? Pse IgniteCache transferuar në IgniteCache ? Nuk është ende e qartë.
Unë jam duke ribërë Aplikacionin Llogarit për t'iu përshtatur rastit tim. Çelësi kryesor i drejtorisë së pikave të shitjes në MSSQL është përcaktuar si [id] [int] NOT NULL, unë krijoj një cache me analogji
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Në konfigurimin xml tregoj se cache është e ndarë
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Ndarja sipas pikës së shitjes supozon se agregati i kërkuar do të ndërtohet në secilën nyje të grupimit për të dhënat salesPointCache të disponueshme atje, pas së cilës nyja e klientit do të kryejë mbledhjen përfundimtare.
Po lexoj tutorialin , e bëj me analogji. Në secilën nyje të grupit ekzekutoj IgniteRunnable(), diçka si kjo:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Unë shtoj logjikën e grumbullimit dhe ngarkimit dhe e ekzekutoj atë në një grup të dhënash testimi. Gjithçka funksionon në nivel lokal në serverin e zhvillimit.
Unë nis dy serverë testimi CentOs, specifikoj adresat IP në default-config.xml, ekzekutoj në secilin
./bin/ignite.sh config/default-config.xmlTë dy nyjet Ignite po funksionojnë dhe mund të shohin njëri-tjetrin. Unë specifikoj adresat e kërkuara në konfigurimin xml të aplikacionit të klientit, ai fillon, shton një nyje të tretë në topologji dhe menjëherë ka përsëri dy nyje. Regjistri tregon "ClassNotFoundException: model.SalesPoint" në rresht
SalesPoint sp=salesPointCache.get(spId);StackOverflow thotë se arsyeja e gabimit është se nuk ka klasë SalesPoint të personalizuar në serverët CentOs. Kemi mbërritur. Po në lidhje me "nuk keni nevojë të vendosni manualisht kodin tuaj Java në secilën nyje" dhe kështu me radhë? Apo "kodi juaj Java" nuk ka të bëjë me SalesPoint?
Ndoshta më ka humbur diçka - filloj përsëri të kërkoj, të lexoj dhe të kërkoj përsëri. Pas pak më vjen ndjenja se kam lexuar gjithçka për temën, nuk ka më asgjë të re. Ndërsa po kërkoja, gjeta disa komente interesante.
, arkitekt kryesor në GridGain Systems, në StackOverflow, prill 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.Një tjetër mendim autoritar: , Drejtor i menaxhimit të produktit, GridGain Systems.
Artikull në Habré referon tre artikuj nga Denis Magda: , , 2016-2017. Në artikullin e dytë, Denis sugjeron fillimin e një nyje grupi përmes MaintenanceServiceNodeStartup.jar. Ju gjithashtu mund të përdorni nisjen me konfigurimin xml dhe linjën e komandës, por më pas duhet të vendosni manualisht klasa të personalizuara në secilën nyje të grupimit të vendosur:
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.Në të vërtetë, kjo është ajo. Këtu rezulton, pse, ky format binar misterioz!
3.SingleJar
Denis zuri vendin e parë në vlerësimin tim personal, IMHO mësimi më i dobishëm nga të gjithë. Në të tijën Github përmban një shembull plotësisht të gatshëm të konfigurimit të nyjeve të grupimit, i cili përpilohet pa ndonjë mbledhje shtesë.
Unë e bëj në të njëjtën mënyrë dhe marr një skedar të vetëm jar që lëshon "nyjen e të dhënave" ose "nyjen e klientit" në varësi të argumentit të linjës së komandës. Asambleja fillon dhe funksionon. Zero Deployment është mposhtur.
Kalimi nga megabajt të të dhënave të testimit në dhjetëra gigabajt të dhëna luftarake tregoi se formati binar ekziston për një arsye. Ishte e nevojshme të optimizohej konsumi i kujtesës në nyje, dhe kjo është ajo ku BinaryObject doli të ishte shumë i dobishëm.
4. Konkluzione
Qortimi i parë i hasur në lidhje me paqartësinë e dokumentacionit të projektit Apache Ignite doli të ishte i drejtë; pak ka ndryshuar që nga viti 2016. Nuk është e lehtë për një fillestar të mbledhë një prototip funksional bazuar në një faqe interneti dhe/ose depo.
Bazuar në rezultatet e punës së bërë, u krijua përshtypja se Zero Deployment funksionon, por vetëm në nivel sistemi. Diçka si kjo: BinaryObject përdoret për të mësuar nyjet e grupeve të largëta për të punuar me klasa të personalizuara; Zero Deployment - mekanizëm i brendshëm
Apache Ignite vetë dhe shpërndan objektet e sistemit në të gjithë grupin.
Shpresoj se përvoja ime do të jetë e dobishme për përdoruesit e rinj të Apache Ignite.
Burimi: www.habr.com