Ni estas la fako pri teknologia disvolviĝo de podetala reto. Iun tagon, administrado fiksis la taskon akceli grandskalajn kalkulojn uzante Apache Ignite kune kun MSSQL, kaj montris retejon kun belaj ilustraĵoj kaj ekzemploj de Java-kodo. Mi tuj ŝatis la retejon , kies priskribo promesas miraklojn: vi ne devas mane deploji vian Java aŭ Scala kodon sur ĉiu nodo en la krado kaj re-deploji ĝin ĉiufoje kiam ĝi ŝanĝiĝas. Dum la laboro progresis, montriĝis, ke Zero Deployment havas specifajn uzojn, kies funkciojn mi volas dividi. Sub la tranĉo estas pensoj kaj realigaj detaloj.
1. Deklaro de la problemo
La esenco de la problemo estas kiel sekvas. Estas SalesPoint-vendpunkto-adresaro kaj Sku (Stock Keeping Unit) produkta dosierujo. La vendejo havas atributon "Tipo de vendejo" kun la valoroj "malgranda" kaj "granda". Sortimento (listo de produktoj de la vendejo) estas konektita al ĉiu vendejo (ŝarĝita de la DBMS) kaj informoj estas provizitaj, ke de la specifita dato la specifita produkto
ekskludita el la sortimento aŭ aldonita al la sortimento.
Necesas organizi dividitan kaŝmemoron de vendopunktoj kaj konservi en ĝi informojn pri konektitaj produktoj dum monato anticipe. Kongrueco kun la batalsistemo postulas la Ignite-klientnodon ŝarĝi datumojn, kalkuli entuton de la formo (Butiktipo, Produkta kodo, tago, nombro_de_vendaj_punktoj) kaj alŝuti ĝin reen al la DBMS.
2. Studo de literaturo
Mi ankoraŭ ne havas sperton, do mi komencas danci de la forno. Tio estas, el recenzo de eldonaĵoj.
Artikolo 2016 enhavas ligilon al la dokumentado de la projekto Apache Ignite kaj samtempe riproĉon pri la malprecizeco de tiu ĉi dokumentaro. Mi relegis ĝin kelkajn fojojn, klareco ne venas. Mi referencas al la oficiala lernilo , kiu
optimisme promesas "Vi ekfunkcios tuj!" Mi eltrovas la mediovariablajn agordojn, spektas du filmetojn de Apache Ignite Essentials, sed ili ne estis tre utilaj por mia specifa tasko. Mi sukcese lanĉas Ignite de la komandlinio kun la norma dosiero "example-ignite.xml", konstruante la unuan aplikaĵon uzante Maven. La aplikaĵo funkcias kaj uzas Zero Deployment, kia beleco!
Mi legas plu, kaj tie la ekzemplo tuj uzas affinityKey (kreitan pli frue per SQL-demando), kaj eĉ uzas la misteran BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Mi legis ĝin : binara formato - io kiel reflektado, alirante la kampojn de objekto laŭnome. Kapablas legi la valoron de kampo sen tute deserialigi la objekton (ŝparante memoron). Sed kial BinaryObject estas uzata anstataŭ Person, ĉar ekzistas Nula Deplojo? Kial IgniteCache transdonita al IgniteCache ? Ĝi ankoraŭ ne estas klara.
Mi refaras la Komputan Aplikon laŭ mia kazo. La ĉefa ŝlosilo de la dosierujo de vendopunktoj en MSSQL estas difinita kiel [id] [int] NE NULL, mi kreas kaŝmemoron per analogio
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")En la xml-agordo mi indikas, ke la kaŝmemoro estas dividita
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Dispartigo de vendloko supozas, ke la bezonata entuto estos konstruita sur ĉiu aretnodo por la salesPointCache-rekordoj haveblaj tie, post kio la klientnodo faros la finan sumon.
Mi legas la lernilon , mi faras ĝin per analogio. Sur ĉiu cluster nodo mi rulas IgniteRunnable(), ion kiel ĉi tio:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Mi aldonas agregan kaj alŝutan logikon kaj rulas ĝin sur prova datumaro. Ĉio funkcias loke sur la evoluservilo.
Mi lanĉas du CentOs-testservilojn, precizigas la IP-adresojn en default-config.xml, ekzekutas sur ĉiu
./bin/ignite.sh config/default-config.xmlAmbaŭ Ignite-nodoj funkcias kaj povas vidi unu la alian. Mi specifas la postulatajn adresojn en la xml-agordo de la klienta aplikaĵo, ĝi komenciĝas, aldonas trian nodon al la topologio kaj tuj estas du nodoj denove. La protokolo montras "ClassNotFoundException: modelo.SalesPoint" en la linio
SalesPoint sp=salesPointCache.get(spId);StackOverflow diras, ke la kialo de la eraro estas, ke ne ekzistas kutima SalesPoint-klaso sur CentOs-serviloj. Ni alvenis. Kiom pri "vi ne devas mane deploji vian Java-kodon sur ĉiu nodo" kaj tiel plu? Aŭ ĉu "via Java-kodo" ne estas pri SalesPoint?
Verŝajne mi maltrafis ion - mi denove komencas serĉi, legi kaj serĉi denove. Post iom da tempo, mi havas la senton, ke mi legis ĉion pri la temo, estas nenio nova plu. Dum mi serĉis, mi trovis kelkajn interesajn komentojn.
, Ĉefarkitekto ĉe GridGain Systems, pri StackOverflow, aprilo 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.Alia aŭtoritata opinio: , Direktoro de produktadministrado, GridGain Systems.
Artikolo pri Habré referencoj tri artikoloj de Denis Magda: , , 2016-2017. En la dua artikolo, Denis sugestas komenci grapolnodon per MaintenanceServiceNodeStartup.jar. Vi ankaŭ povas uzi lanĉon kun xml-agordo kaj komandlinio, sed tiam vi devas mane meti kutimajn klasojn sur ĉiu deplojita grapolnodo:
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.Ja tio estas. Ĉi tie rezultas, kial, ĉi tiu mistera binara formato!
3.SingleJar
Denis okupis la unuan lokon en mia persona takso, MIHO la plej utila lernilo el ĉiuj disponeblaj. En lia Github enhavas tute pretan ekzemplon pri starigo de grapolnodoj, kiu kompilas sen aldona kaŭrado.
Mi faras ĝin same kaj ricevas ununuran jardosieron, kiu lanĉas "datumnodon" aŭ "klientnodon" depende de la komandlinia argumento. La asembleo komenciĝas kaj funkcias. Nula Deplojo estis venkita.
La transiro de megabajtoj da testaj datumoj al dekoj da gigabajtoj da bataldatenoj montris, ke la binara formato ekzistas ial. Necesis optimumigi memorkonsumon sur nodoj, kaj ĉi tie BinaryObject montriĝis tre utila.
4. Konkludoj
La unua riproĉo renkontita pri la malprecizeco de la dokumentado de la projekto Apache Ignite montriĝis justa; malmulto ŝanĝiĝis ekde 2016. Ne estas facile por komencanto kunmeti funkciantan prototipon bazitan sur retejo kaj/aŭ deponejo.
Surbaze de la rezultoj de la laboro farita, la impreso estis, ke Zero Deployment funkcias, sed nur je la sistemnivelo. Io kiel ĉi tio: BinaryObject estas uzata por instrui forajn grapolnodojn labori kun kutimaj klasoj; Zero Deployment - interna mekanismo
Apache Ignite mem kaj distribuas sistemajn objektojn tra la areto.
Mi esperas, ke mia sperto estos utila al novaj uzantoj de Apache Ignite.
fonto: www.habr.com