Wy binne de ôfdieling technologyûntwikkeling fan in retailnetwurk. Op in dei sette management de taak om grutskalige berekkeningen te fersnellen troch Apache Ignite te brûken yn kombinaasje mei MSSQL, en liet in webside sjen mei prachtige yllustraasjes en foarbylden fan Java-koade. Ik fûn de side fuortendaliks leuk , wêrfan de beskriuwing wûnders belooft: jo hoege jo Java- of Scala-koade net manuell yn te setten op elke knooppunt yn it raster en elke kear as it feroaret opnij ynsette. As it wurk fuortgong, die bliken dat Zero Deployment spesifike gebrûk hat, wêrfan de funksjes ik diele wol. Under de besuniging binne tinzen en útfieringsdetails.
1. Ferklearring fan it probleem
De essinsje fan 'e taak is as folget. D'r is in map fan SalesPoint-ferkeappunten en in produktmap fan Sku (Stock Keeping Unit). It ferkeappunt hat in "Store type" attribút mei de wearden "lyts" en "grut". In assortiment (list mei produkten fan it ferkeappunt) is ferbûn oan elk ferkeappunt (laden fan 'e DBMS) en ynformaasje wurdt levere dat fan' e oantsjutte datum it opjûne produkt
útsletten fan it assortiment of taheakke oan it assortiment.
It is ferplichte om in partitioneare cache fan ferkeappunten te organisearjen en ynformaasje oer ferbûne produkten dêryn te bewarjen foar in moanne fan tefoaren. Kompatibiliteit mei it fjochtsysteem fereasket de Ignite-kliïntknooppunt om gegevens te laden, in aggregaat fan 'e foarm te berekkenjen (winkeltype, produktkoade, dei, oantal_ferkeappunten) en it werom te uploaden nei de DBMS.
2. Literatuerstúdzje
Ik ha noch gjin ûnderfining, dus ik begjin fan de kachel te dûnsjen. Dat is, út in resinsje fan publikaasjes.
Artikel 2016 befettet in keppeling nei de dokumintaasje fan it Apache Ignite-projekt en tagelyk in ferwyt foar de vagueness fan dizze dokumintaasje. Ik lês it in pear kear op 'e nij, dúdlikens komt net. Ik ferwize nei de offisjele tutorial , dy't
optimistysk belooft "Jo sille yn in japtrap op en rinne!" Ik fyn de ynstellings foar omjouwingsfariabele út, sjoch twa Apache Ignite Essentials-fideo's, mar se wiene net heul nuttich foar myn spesifike taak. Ik lansearje mei súkses Ignite fanút de kommandorigel mei it standertbestân "example-ignite.xml", it bouwen fan de earste applikaasje mei help fan Maven. De applikaasje wurket en brûkt Zero Deployment, wat in skientme!
Ik lês fierder, en dêr brûkt it foarbyld fuortendaliks affinityKey (earder makke troch in SQL-query), en brûkt sels it mysterieuze BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); ik ha it lêzen : binêre opmaak - soksawat as refleksje, tagong ta de fjilden fan in objekt mei namme. Kin lêze de wearde fan in fjild sûnder folslein deserializing it objekt (besparje ûnthâld). Mar wêrom wurdt BinaryObject brûkt ynstee fan Persoan, om't d'r Zero Deployment is? Wêrom IgniteCache oerdroegen oan IgniteCache ? It is noch net dúdlik.
Ik meitsje de Compute-applikaasje opnij om by myn saak te passen. De primêre kaai fan 'e map fan ferkeappunten yn MSSQL is definiearre as [id] [int] NET NULL, ik meitsje in cache troch analogy
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Yn 'e xml-konfiguraasje jou ik oan dat de cache partitioneare is
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Partitioning by punt fan ferkeap giet derfan út dat de fereaske aggregaat sil wurde boud op elke kluster knooppunt foar de salesPointCache records beskikber dêr, wêrnei't de klant knooppunt sil útfiere de definitive gearfetting.
Ik lês de tutorial , Ik doch it troch analogy. Op elke klusterknoop rin ik IgniteRunnable (), soksawat as dit:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Ik foegje aggregaasje- en uploadlogika ta en rinne it op in testgegevensset. Alles wurket lokaal op 'e ûntwikkelingstsjinner.
Ik lansearje twa CentOs-testservers, spesifisearje de IP-adressen yn default-config.xml, útfiere op elk
./bin/ignite.sh config/default-config.xmlBeide Ignite-knooppunten rinne en kinne elkoar sjen. Ik spesifisearje de fereaske adressen yn 'e xml-konfiguraasje fan' e kliïntapplikaasje, it begjint, foeget in tredde knooppunt ta oan 'e topology en fuortendaliks binne d'r twa knooppunten wer. It log toant "ClassNotFoundException: model.SalesPoint" yn 'e rigel
SalesPoint sp=salesPointCache.get(spId);StackOverflow seit dat de reden foar de flater is dat d'r gjin oanpaste SalesPoint-klasse is op CentOs-tsjinners. Wy binne oankommen. Hoe sit it mei "jo moatte jo Java-koade net manuell ynsette op elke knooppunt" ensafuorthinne? Of giet "jo Java-koade" net oer SalesPoint?
Ik haw wierskynlik wat mist - ik begjin wer te sykjen, te lêzen en wer te sykjen. Nei in skoftke krij ik it gefoel dat ik alles oer it ûnderwerp lêzen haw, der is neat nijs mear. Wylst ik socht, fûn ik wat nijsgjirrige opmerkings.
, Lead Architect 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.In oare autoritative miening: , Direkteur fan produktbehear, GridGain Systems.
Artikel oer Habré ferwiist trije artikels fan Denis Magda: , , 2016-2017. Yn it twadde artikel stelt Denis foar om in klusterknooppunt te begjinnen fia MaintenanceServiceNodeStartup.jar. Jo kinne ek lansearring brûke mei xml-konfiguraasje en kommandorigel, mar dan moatte jo oanpaste klassen manuell pleatse op elke ynset klusterknooppunt:
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.Yndied, dat is it. Hjir docht bliken, wêrom, dit mysterieuze binêre formaat!
3. SingleJar
Denis naam it earste plak yn myn persoanlike wurdearring, IMHO de meast brûkbere tutorial fan alle beskikber. Yn syn Github befettet in folslein klear foarbyld fan it ynstellen fan klusterknooppunten, dy't kompilearret sûnder ekstra squatting.
Ik doch it op deselde manier en krij in inkele jar-bestân dat "dataknooppunt" of "kliïntknooppunt" lanseart ôfhinklik fan it kommandorigelargumint. De gearstalling begjint en wurket. Zero Deployment is ferslein.
De oergong fan megabytes oan testgegevens nei tsientallen gigabytes oan gefjochtsgegevens liet sjen dat it binêre formaat foar in reden bestiet. It wie nedich om it ûnthâldferbrûk op knopen te optimalisearjen, en dit is wêr't BinaryObject heul nuttich die bliken te wêzen.
4. Konklúzjes
De earste ferwyt tsjinkaam oer de vagueness fan 'e Apache Ignite-projektdokumintaasje die bliken earlik te wêzen; bytsje is feroare sûnt 2016. It is net maklik foar in begjinner om in funksjonearjend prototype te sammeljen basearre op in webside en / of repository.
Op grûn fan de resultaten fan it dien wurk wie de yndruk dat Zero Deployment wurket, mar allinich op systeemnivo. Sa'n ding as dit: BinaryObject wurdt brûkt om klusterknooppunten op ôfstân te learen om te wurkjen mei oanpaste klassen; Zero Deployment - ynterne meganisme
Apache Ignite sels en distribúsje systeemobjekten troch it kluster.
Ik hoopje dat myn ûnderfining nuttich sil wêze foar nije Apache Ignite-brûkers.
Boarne: www.habr.com