Suntem departamentul de dezvoltare a tehnologiilor pentru rețeaua de retail. Odată, conducerea a dat sarcina de a accelera calculele masive prin utilizarea Apache Ignite împreună cu MSSQL, arătând un site cu ilustratii minunate și exemple de cod Java. Pe site mi-a plăcut imediat , descrierea căruia promite minuni: nu trebuie să-ți desfășori manual codul Java sau Scala pe fiecare nod din rețea și să-l repli pe fiecare dată când se schimbă. Pe parcursul lucrului, s-a dovedit că Zero Deployment are specificități de utilizare, a căror particularitate vreau să o împărtășesc. Mai jos, gânduri și detalii de implementare.
1. Formularea problemei
Sarcina este următoarea. Există un catalog al punctelor de vânzare SalesPoint și un catalog al produselor Sku (Stock Keeping Unit). Fiecare punct de vânzare are un atribut „tipMagazin” cu valorile „mic” și „mare”. Fiecare punct de vânzare se conectează (se încarcă din SGBD) cu sortimentul (lista produselor punctului de vânzare) și se furnizează informații că, dintr-o anumită dată, produsul specificat
este exclus din sortiment sau adăugat în sortiment.
Se necesită organizarea unui cache partitionat pentru punctele de vânzare și stocarea informațiilor despre produsele conectate pe o lună. Compatibilitatea cu sistemul de producție impune nodului client Ignite să încarce datele, să calculeze un agregat de tipul (tipMagazin, codProdus, zi, număr_puncte de vânzare) și să-l exporte înapoi în SGBD.
2. Studiul literaturii
Încă nu am experiență, așa că încep de la baza. Adică, cu o revizuire a publicațiilor.
Articolul din 2016 conține un link către documentația proiectului Apache Ignite și, de asemenea, o critică asupra neclarității acestei documentații. Am recitit de câteva ori, claritatea nu se instalează. Mă adresez tutorialului oficial , care
care promite optimist „Vei fi pregătit în curând!“. Îmi învăț setările variabilelor de mediu, vizionez două videoclipuri Apache Ignite Essentials, pentru sarcina mea specifică s-au dovedit a fi nu foarte utile. Lansesc cu succes Ignite din linia de comandă cu fișierul standard „example-ignite.xml”, construiesc prima aplicație folosind Maven. Aplicația funcționează și utilizează Zero Deployment, ce frumos!
Continui să citesc, iar acolo exemplul folosește imediat affinityKey (creat anterior printr-o interogare SQL), iar apoi apare și misteriosul BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Am citit : format binar — ceva de genul reflecției, acces la câmpurile obiectului după nume. Poate citi valoarea unui câmp fără a deserializa complet obiectul (economisind memorie). Dar de ce este folosit BinaryObject în loc de Person, având în vedere Zero Deployment? De ce IgniteCache<Key,Person> este tradus în IgniteCache<BinaryObject, BinaryObject>? Rămâne neclar.
Refac aplicația Compute pentru cazul meu. Cheia primară a dicționarului punctelor de vânzare în MSSQL este definită ca [id] [int] NOT NULL, creez un cache după analogie.
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")În configurația xml specific că cache-ul este Partitționat.
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Partiționarea pe punctele de vânzare presupune că agregatul necesar va fi construit pe fiecare nod al clusterului pentru înregistrările existente în salesPointCache, după care nodul client va efectua sumarea finală.
Citesc tutorialul. , fac după analogie. Pe fiecare nod al clusterului pornesc IgniteRunnable(), cam așa:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Adaug logica de agregare și export, rulez pe un set de date de test. Local pe serverul de dezvoltare totul funcționează.
Pornesc două servere de test CentOs, specific adresele IP în default-config.xml, execut pe fiecare
.\/bin\/ignite.sh config\/default-config.xmlAmbele noduri Ignite pornesc și se văd între ele. Specific adresele necesare în configurația xml a aplicației client, aceasta se pornește, adaugă un al treilea nod în topologie și imediat numărul de noduri devine din nou două. În log se menționează „ClassNotFoundException: model.SalesPoint” pe linia
SalesPoint sp=salesPointCache.get(spId);StackOverflow spune că cauza erorii este că pe serverele CentOs nu există clasa personalizată SalesPoint. Am ajuns. Ce facem cu „you don’t have to manually deploy your Java code on each node” și așa mai departe? Sau „your Java code” nu se referă la SalesPoint?
Probabil am omis ceva — încep din nou să caut, citesc și iar caut. După un timp, apare senzația că am citit tot ce este legat de subiect, nu mai este nimic nou. În timp ce căutam, am găsit câteva observații interesante.
, Lead Architect la GridGain Systems, pe StackOverflow, aprilie 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.O altă opinie autoritară: , Director de gestionare a produselor, GridGain Systems.
Articol pe Habr se referă la trei articole scrise de Denis Magda: , , Anul 2016-2017. În al doilea articol, Denis sugerează să pornești un nod de cluster prin MaintenanceServiceNodeStartup.jar. Poți folosi de asemenea lansarea cu configurație XML și linia de comandă, dar atunci trebuie să pui manual clasele personalizate pe fiecare nod din cluster la fiecare desfășurare:
Asta e tot. Pornește (..) nodul folosind fișierul MaintenanceServiceNodeStartup sau treci
maintenance-service-node-config.xml la scripturile ignite.sh/bat ale Apache Ignite.
Dacă preferi cea din urmă, asigură-te că construiești un fișier jar care va conține
toate clasele din directoarele java/app/common și java/services/maintenance.
Jar-ul trebuie adăugat în classpath-ul fiecărui nod unde serviciul
ar putea fi desfășurat.Adevărat, asta e tot. Iată-l, se pare, de aceea, acest format binar misterios!
3. SingleJar
Denis a ocupat locul întâi în clasamentul meu personal, în opinia mea cel mai util tutorial dintre toate disponibile. În el de pe GitHub conține un exemplu complet gata pentru configurarea nodurilor de cluster, care se compilează fără nicio altă complicație.
Fac după modelul lui și obțin un singur fișier jar, care pornește fie «data node», fie «client node», în funcție de argumentul din linia de comandă. Construirea se pornește și funcționează. Zero Deployment este învins.
Trecerea de la megabytes de date de test la zeci de gigabytes de date de producție a arătat că formatul binar există cu un scop. A fost necesar să optimizez utilizarea memoriei pe noduri, și aici BinaryObject s-a dovedit foarte util.
4. Concluzii
Prima obiecție întâlnită privind neclaritatea documentației proiectului Apache Ignite s-a dovedit a fi justă, din 2016 s-au schimbat puține lucruri. Este greu pentru un începător să construiască un prototip funcțional pe baza site-ului și/sau a depozitului.
Ca urmare a muncii efectuate, mi-a rămas impresia că Zero Deployment funcționează, dar doar la nivel de sistem. Aproximativ așa: BinaryObject este folosit pentru a învăța nodurile de cluster să lucreze cu clase personalizate; Zero Deployment - un mecanism intern
al Apache Ignite și distribuie obiecte sistematice în întreaga rețea de cluster.
Sper că experiența mea va fi utilă noilor utilizatori ai Apache Ignite.
Sursa: habr.com
