Ons is 'n afdeling vir kleinhandelnetwerktegnologie-ontwikkeling. Sodra die bestuur die taak gestel het om volumetriese berekeninge te bespoedig deur Apache Ignite in samewerking met MSSQL te gebruik, het 'n webwerf gewys met pragtige illustrasies en Java-kode-voorbeelde. Het daarvan gehou op die webwerf , wie se beskrywing wonderwerke beloof: jy hoef nie jou Java- of Scala-kode handmatig op elke nodus in die rooster te ontplooi en dit weer te ontplooi elke keer as dit verander nie. In die loop van die werk het dit geblyk dat Zero Deployment die besonderhede van gebruik het, waarvan ek die kenmerke wil deel. Onder die snit is refleksies en implementeringsbesonderhede.
1. Verklaring van die probleem
Die kern van die probleem is soos volg. Daar is 'n SalesPoint-verkooppuntgids en 'n Sku-produkgids (Voorraadhou-eenheid). Die verkoopspunt het 'n kenmerk "Winkeltipe" met die waardes "klein" en "groot". 'n Assortiment ('n lys produkte van die verkoopspunt) word aan elke verkoopspunt gekoppel (gelaai vanaf die DBBS) en inligting word verskaf dat vanaf die gespesifiseerde datum die gespesifiseerde produk
uit die reeks verwyder of by die reeks gevoeg word.
Dit is nodig om 'n afgeskorte kas van verkoopspunte te organiseer en inligting oor gekoppelde produkte vir 'n maand vooruit daarin te stoor. Verenigbaarheid met die gevegstelsel vereis dat die Ignite-kliëntnodus data laai, 'n totaal van die vorm (Winkeltipe, ItemID, dag, aantal_verkope_punte) bereken en dit terug oplaai na die DBBS.
2. Literatuurstudie
Daar is nog geen ondervinding nie, so ek begin van die stoof af dans. Dit wil sê uit 'n resensie van publikasies.
Artikel 2016 bevat 'n skakel na die dokumentasie van die Apache Ignite-projek en terselfdertyd verwyt oor die vaagheid van hierdie dokumentasie. Herlees 'n paar keer, duidelikheid kom nie. Verwys na die amptelike tutoriaal Watter
belowe optimisties "Jy sal in 'n japtrap aan die gang wees!". Ek hanteer die instellings van omgewingsveranderlikes, ek kyk na twee Apache Ignite Essentials-video's, vir my spesifieke taak was hulle nie baie nuttig nie. Begin Ignite suksesvol vanaf die opdragreël met die verstek "example-ignite.xml"-lêer, bou die eerste toepassing met behulp van maven. Die toepassing werk en gebruik Zero Deployment, wat 'n skoonheid!
Ek lees verder, en daar gebruik die voorbeeld onmiddellik affinityKey (vroeër geskep deur 'n SQL-navraag), en selfs die geheimsinnige BinaryObject word gebruik:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); lees : binêre formaat - iets soos refleksie, toegang tot objekvelde op naam. Kan die waarde van 'n veld lees sonder om die voorwerp heeltemal te deserialiseer (geheuebesparing). Maar hoekom word BinaryObject in plaas van Persoon gebruik, want daar is Zero Deployment? Hoekom IgniteCache vertaal in IgniteCache ? Dit is nog nie duidelik nie.
Ek herontwerp die Compute-toepassing vir my saak. Die primêre sleutel van die verkoopspuntgids in MSSQL word gedefinieer as [id] [int] NIE NULL nie, ek skep 'n kas volgens analogie
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")In die xml-config spesifiseer ek dat die kas gepartisioneer is
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Partisionering volgens verkoopspunte veronderstel dat die vereiste totaal op elke nodus van die cluster gebou sal word vir die salesPointCache-rekords wat daar beskikbaar is, waarna die kliëntnodus die finale opsomming sal uitvoer.
Lees die tutoriaal , Ek doen na analogie. Op elke knoop van die cluster hardloop ek IgniteRunnable (), iets soos hierdie:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Ek voeg die logika van samevoeging en ontlaai by, ek voer dit op 'n toetsdatastel uit. Alles werk plaaslik op die ontwikkelingsbediener.
Ek loop twee CentOs-toetsbedieners, spesifiseer ip-adresse in default-config.xml, voer op elke
./bin/ignite.sh config/default-config.xmlBeide Ignite nodusse begin en sien mekaar. Ek spesifiseer die nodige adresse in die xml-config van die kliënttoepassing, dit begin, voeg 'n derde nodus by die topologie, en dadelik is daar weer twee nodusse. Die log sê "ClassNotFoundException: model.SalesPoint" in die reël
SalesPoint sp=salesPointCache.get(spId);StackOverflow sê dat die oorsaak van die fout is dat daar geen pasgemaakte SalesPoint-klas op CentOs-bedieners is nie. Ons het aangekom. Hoe gaan dit met "jy hoef nie jou Java-kode handmatig op elke nodus te ontplooi nie" ensovoorts? Of gaan “jou Java-kode” nie oor SalesPoint nie?
Ek het seker iets gemis – ek begin weer soek, lees en weer soek. Na 'n rukkie is daar 'n gevoel dat ek alles oor die onderwerp gelees het, daar is niks meer nuut nie. Terwyl ek gesoek het, het ek 'n paar interessante opmerkings gekry.
, Hoofargitek by GridGain Systems, op 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.Nog 'n gesaghebbende mening: , Direkteur van produkbestuur, GridGain Systems.
Artikel oor Habré haal drie artikels deur Denis Magda aan: , , 2016-2017. In die tweede artikel stel Denis voor om 'n groepknoop via MaintenanceServiceNodeStartup.jar te begin. U kan ook launch met xml-konfigurasie en opdragreël gebruik, maar dan moet u persoonlike klasse handmatig op elke ontplooide groepknoop plaas:
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.Inderdaad, dit is dit. Hier is dit, blyk dit, wel, hierdie geheimsinnige binêre formaat!
3.SingleJar
Denis het die eerste plek behaal in my persoonlike gradering, IMHO die nuttigste tutoriaal beskikbaar. In sy die github bevat 'n heeltemal klaargemaakte voorbeeld van die opstel van cluster nodusse, wat saamstel sonder enige bykomende squats.
Ek doen dit in die beeld en gelykenis, ek kry 'n enkele jar-lêer wat die "data node" of "kliënt node" begin, afhangende van die command line argument. Die bouwerk is aan die gang. Zero Deployment is verslaan.
Die oorgang van megagrepe se toetsdata na tientalle gigagrepe gevegsdata het getoon dat die binêre formaat met ’n rede bestaan. Dit was nodig om die geheueverbruik op die nodusse te optimaliseer, en hier blyk BinaryObject baie nuttig te wees.
4. Gevolgtrekkings
Die eerste verwyte met die onduidelikheid van die dokumentasie van die Apache Ignite-projek blyk regverdig te wees, min het sedert 2016 verander. Dit is nie maklik vir 'n beginner om 'n funksionele prototipe te bou gebaseer op 'n webwerf en/of 'n bewaarplek nie.
As gevolg van die werk wat gedoen is, was die indruk dat Zero Deployment werk, maar slegs op stelselvlak. Iets soos hierdie: BinaryObject word gebruik om afgeleë cluster nodusse te leer om met persoonlike klasse te werk; Zero Deployment - interne meganisme
Apache Ignite self en versprei stelselvoorwerpe regdeur die groep.
Ek hoop dat my ervaring nuttig sal wees vir nuwe gebruikers van Apache Ignite.
Bron: will.com