Oleme jaemüügivõrgu tehnoloogiaarenduse osakond. Ühel päeval seadis juhtkond ülesandeks kiirendada suuremahulisi arvutusi, kasutades Apache Ignite'i koos MSSQL-iga, ning näitas veebisaiti kaunite illustratsioonide ja Java-koodi näidetega. Sait meeldis mulle kohe , mille kirjeldus tõotab imet: te ei pea oma Java- või Scala-koodi käsitsi juurutama igas võrgustiku sõlmes ja iga kord, kui see muutub, uuesti juurutama. Töö edenedes selgus, et Zero Deploymentil on spetsiifilised kasutusvõimalused, mille funktsioone tahan jagada. Lõike all on mõtted ja teostuse üksikasjad.
1. Probleemi avaldus
Probleemi olemus on järgmine. Seal on SalesPointi müügipunktide kataloog ja Sku (laopidamise üksus) tootekataloog. Müügikohal on atribuut "Poe tüüp" väärtustega "small" ja "large". Iga müügikohaga (laetud DBMS-ist) on ühendatud sortiment (müügikoha toodete nimekiri) ja edastatakse teave, et alates määratud kuupäevast on määratud toode
sortimendist välja jäetud või sortimenti lisatud.
Müügipunktide vahemälu on vaja korraldada ja selles kuu aega ette salvestada teavet ühendatud toodete kohta. Ühilduvus võitlussüsteemiga nõuab, et Ignite'i kliendisõlm laadiks andmed, arvutaks vormi koondnäitaja (poe tüüp, tootekood, päev,_müügipunktide_arv) ja laadiks need tagasi DBMS-i.
2. Kirjanduse õppimine
Mul pole veel kogemusi, nii et hakkan pliidilt tantsima. Ehk siis väljaannete ülevaatest.
Artikkel 2016 sisaldab linki Apache Ignite’i projekti dokumentatsioonile ja samas etteheiteid selle dokumentatsiooni ebamäärasuse pärast. Lugesin paar korda uuesti läbi, selgust ei tule. Viitan ametlikule õpetusele Mis
lubab optimistlikult: "Sa hakkad kiirelt tööle!" Nuputan keskkonnamuutuja seadeid, vaatan kahte Apache Ignite Essentialsi videot, kuid minu konkreetse ülesande täitmisel neist polnud suurt kasu. Käivitan edukalt Ignite'i käsurealt standardfailiga "example-ignite.xml", luues esimese rakenduse kasutades Mavenit. Rakendus töötab ja kasutab Zero Deploymenti, milline ilu!
Lugesin edasi ja seal kasutab näide kohe affinityKey-d (loodud varem SQL-päringu kaudu) ja kasutab isegi salapärast BinaryObjecti:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); ma lugesin seda : binaarvorming – midagi peegelduse sarnast, ligipääs objekti väljadele nime järgi. Oskab lugeda välja väärtust ilma objekti täielikult deserialiseerimata (mälu säästmine). Kuid miks kasutatakse isiku asemel BinaryObjecti, kuna seal on null juurutus? Miks IgniteCache üle kantud IgniteCache'i ? See pole veel selge.
Teen arvutusrakenduse ümber, et see sobiks minu juhtumiga. MSSQL-i müügikohtade kataloogi primaarvõti on määratletud kui [id] [int] NOT NULL, loon vahemälu analoogia põhjal
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Xml-konfiguratsioonis näitan, et vahemälu on jaotatud
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Müügikoha järgi jaotamine eeldab, et seal saadaolevate salesPointCache'i kirjete jaoks ehitatakse igale klastri sõlmele vajalik kogum, mille järel teostab kliendisõlm lõpliku summeerimise.
Ma loen õpetust , teen seda analoogia põhjal. Igas klastri sõlmes käitan IgniteRunnable() midagi sellist:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Lisan koondamise ja üleslaadimise loogika ning käivitan selle testandmete komplektis. Kõik töötab arendusserveris kohapeal.
Käivitan kaks CentOs testserverit, määran IP-aadressid failis default-config.xml, käivitan mõlemas
./bin/ignite.sh config/default-config.xmlMõlemad Ignite'i sõlmed töötavad ja näevad üksteist. Määran kliendirakenduse xml konfiguratsioonis vajalikud aadressid, käivitub, lisab topoloogiasse kolmanda sõlme ja kohe on jälle kaks sõlme. Logis on real “ClassNotFoundException: model.SalesPoint”.
SalesPoint sp=salesPointCache.get(spId);StackOverflow ütleb, et vea põhjuseks on see, et CentOsi serverites pole kohandatud SalesPointi klassi. Jõudsime kohale. Kuidas oleks sellega, et "te ei pea oma Java-koodi igas sõlmes käsitsi juurutama" ja nii edasi? Või pole „teie Java-kood” seotud SalesPointiga?
Ilmselt jäi midagi kahe silma vahele – hakkan uuesti otsima, lugema ja uuesti otsima. Mõne aja pärast tekib tunne, et olen kõik teemast läbi lugenud, pole enam midagi uut. Otsides leidsin huvitavaid kommentaare.
, GridGain Systemsi juhtivarhitekt, StackOverflow's, aprill 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.Teine autoriteetne arvamus: , GridGain Systemsi tootehalduse direktor.
Artikkel Habré kohta viitab kolmele Denis Magda artiklile: , , 2016-2017. Teises artiklis soovitab Denis käivitada klastrisõlme saidi MaintenanceServiceNodeStartup.jar kaudu. Käivitamist saate kasutada ka xml-i konfiguratsiooni ja käsureaga, kuid seejärel peate igale juurutatud klastri sõlmele käsitsi lisama kohandatud klassid:
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.Tõepoolest, see on kõik. Siin selgub, miks, see salapärane kahendvorming!
3.SingleJar
Denis saavutas minu isiklikus hinnangus esikoha, IMHO kõige kasulikum õpetus kõigist saadaolevatest. Tema omas Github sisaldab täiesti valmis näidet klastri sõlmede seadistamisest, mis kompileerib ilma täiendava squattimiseta.
Teen seda samamoodi ja saan ühe jar-faili, mis käivitab olenevalt käsurea argumendist "andmesõlme" või "kliendisõlme". Kokkupanek algab ja töötab. Zero Deployment on lüüa saanud.
Üleminek megabaitidelt testandmetelt kümnetele gigabaitidele lahinguandmetele näitas, et binaarvorming eksisteerib põhjusega. Vaja oli optimeerida sõlmede mälutarbimist ja siin osutus BinaryObject väga kasulikuks.
4. Järeldused
Esimene etteheide Apache Ignite'i projekti dokumentatsiooni ebamäärasuse kohta osutus õiglaseks; 2016. aastast on vähe muutunud. Algajal ei ole lihtne veebisaidi ja/või hoidla põhjal toimiva prototüübi koostamine.
Tehtud töö tulemuste põhjal jäi mulje, et Zero Deployment töötab, kuid ainult süsteemi tasemel. Midagi sellist: BinaryObjecti kasutatakse kaugklastri sõlmede õpetamiseks kohandatud klassidega töötama; Zero Deployment – sisemine mehhanism
Apache Ignite ise ja levitab süsteemiobjekte kogu klastris.
Loodan, et minu kogemus on kasulik uutele Apache Ignite'i kasutajatele.
Allikas: www.habr.com