Sme oddelenie vývoja technológií maloobchodnej siete. Jedného dňa si manažment stanovil za úlohu urýchliť rozsiahle výpočty pomocou Apache Ignite v spojení s MSSQL a ukázal webovú stránku s krásnymi ilustráciami a príkladmi kódu Java. Stránka sa mi hneď zapáčila , ktorého popis sľubuje zázraky: nemusíte manuálne nasadzovať svoj kód Java alebo Scala na každý uzol v mriežke a znova ho nasadzovať pri každej zmene. Ako práca postupovala, ukázalo sa, že Zero Deployment má špecifické využitie, o vlastnosti ktorých sa chcem podeliť. Pod rezom sú myšlienky a detaily implementácie.
1. Vyjadrenie problému
Podstata problému je nasledovná. Existuje adresár predajných miest SalesPoint a produktový adresár Sku (Stock Keeping Unit). Miesto predaja má atribút „Typ obchodu“ s hodnotami „malý“ a „veľký“. Ku každému predajnému miestu (načítanému z DBMS) je pripojený sortiment (zoznam produktov predajného miesta) a uvedená informácia, že od uvedeného dátumu je uvedený produkt
vyradené zo sortimentu alebo pridané do sortimentu.
Je potrebné usporiadať rozdelenú vyrovnávaciu pamäť predajných miest a ukladať do nej informácie o pripojených produktoch na mesiac vopred. Kompatibilita s bojovým systémom vyžaduje, aby klientsky uzol Ignite načítal údaje, vypočítal agregáciu formulára (typ obchodu, kód produktu, deň, počet_predajných_bodov) a nahral ho späť do DBMS.
2. Štúdium literatúry
Zatiaľ nemám žiadne skúsenosti, tak začínam tancovať od sporáka. Teda z recenzie publikácií.
Článok 2016 obsahuje odkaz na dokumentáciu projektu Apache Ignite a zároveň výčitku k vágnosti tejto dokumentácie. Prečítal som si to niekoľkokrát, jasnosť neprichádza. Odkazujem na oficiálny návod že
optimisticky sľubuje: „Za chvíľu budete v prevádzke!“ Zisťujem nastavenia premenných prostredia, pozerám dve videá Apache Ignite Essentials, ale pre moju konkrétnu úlohu neboli veľmi užitočné. Úspešne som spúšťal Ignite z príkazového riadku so štandardným súborom „example-ignite.xml“, čím som vytvoril prvú aplikáciu pomocou Maven. Aplikácia funguje a využíva Zero Deployment, aká krása!
Čítal som ďalej a príklad okamžite používa affinityKey (vytvorený skôr prostredníctvom dotazu SQL) a dokonca používa tajomný BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); čítal som to : binárny formát – niečo ako odraz, prístup k poliam objektu podľa názvu. Dokáže prečítať hodnotu poľa bez úplnej deserializácie objektu (úspora pamäte). Prečo sa však používa BinaryObject namiesto osoby, keďže existuje nulové nasadenie? Prečo IgniteCache prenesené do IgniteCache ? Zatiaľ to nie je jasné.
Prerábam aplikáciu Compute, aby vyhovovala môjmu prípadu. Primárny kľúč adresára predajných miest v MSSQL je definovaný ako [id] [int] NOT NULL, vyrovnávaciu pamäť vytváram analogicky
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")V konfigurácii xml uvádzam, že vyrovnávacia pamäť je rozdelená
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Rozdelenie podľa miesta predaja predpokladá, že na každom uzle klastra sa vytvorí požadovaný agregát pre záznamy salesPointCache, ktoré sú tam dostupné, a potom klientsky uzol vykoná konečný súčet.
Čítam návod , robím to analogicky. Na každom uzle klastra spustím IgniteRunnable (), niečo takéto:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Pridávam logiku agregácie a nahrávania a spúšťam ju na testovacej množine údajov. Všetko funguje lokálne na vývojovom serveri.
Spustím dva testovacie servery CentOs, špecifikujem IP adresy v default-config.xml, spustím na každom
./bin/ignite.sh config/default-config.xmlOba Ignite uzly sú spustené a vidia sa navzájom. V xml konfigurácii klientskej aplikácie zadávam požadované adresy, tá sa spustí, pridá do topológie tretí uzol a hneď sú zase dva uzly. Protokol zobrazuje v riadku „ClassNotFoundException: model.SalesPoint“.
SalesPoint sp=salesPointCache.get(spId);StackOverflow hovorí, že dôvodom chyby je, že na serveroch CentOs neexistuje žiadna vlastná trieda SalesPoint. Prišli sme. Čo tak „nemusíte manuálne nasadzovať svoj kód Java na každý uzol“ a tak ďalej? Alebo „váš kód Java“ nie je o SalesPointe?
Asi mi niečo uniklo – začínam znova hľadať, čítať a znova hľadať. Po chvíli mám pocit, že som k téme prečítala všetko, už nie je nič nové. Pri hľadaní som našiel zaujímavé komentáre.
, hlavný architekt v spoločnosti GridGain Systems, na StackOverflow, apríl 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.Ďalší autoritatívny názor: , riaditeľ produktového manažmentu, GridGain Systems.
Článok o Habrém odkazuje na tri články Denisa Magdu: , , 2016-2017. V druhom článku Denis navrhuje spustenie uzla klastra cez MaintenanceServiceNodeStartup.jar. Môžete tiež použiť spustenie s konfiguráciou xml a príkazovým riadkom, ale potom musíte manuálne umiestniť vlastné triedy na každý nasadený uzol klastra:
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.Naozaj, to je všetko. Tu sa ukazuje, prečo, tento záhadný binárny formát!
3.SingleJar
Denis obsadil prvé miesto v mojom osobnom hodnotení, IMHO najužitočnejší návod zo všetkých dostupných. V jeho Github obsahuje úplne hotový príklad nastavenia uzlov klastra, ktorý sa skompiluje bez akéhokoľvek dodatočného squattingu.
Robím to rovnakým spôsobom a získam jeden súbor jar, ktorý spustí „údajový uzol“ alebo „klientsky uzol“ v závislosti od argumentu príkazového riadka. Montáž sa spustí a funguje. Zero Deployment bolo porazené.
Prechod z megabajtov testovacích dát na desiatky gigabajtov bojových dát ukázal, že binárny formát existuje z nejakého dôvodu. Bolo potrebné optimalizovať spotrebu pamäte na uzloch a práve tu sa BinaryObject ukázal ako veľmi užitočný.
4. Závery
Prvá výčitka o vágnosti projektovej dokumentácie Apache Ignite sa ukázala ako spravodlivá, od roku 2016 sa toho zmenilo len málo. Pre začiatočníka nie je ľahké zostaviť funkčný prototyp na základe webovej stránky a/alebo úložiska.
Na základe výsledkov vykonanej práce vznikol dojem, že Zero Deployment funguje, ale len na systémovej úrovni. Niečo ako toto: BinaryObject sa používa na učenie vzdialených uzlov klastra pracovať s vlastnými triedami; Zero Deployment – vnútorný mechanizmus
Apache Ignite sám a distribuuje systémové objekty po celom klastri.
Dúfam, že moje skúsenosti budú užitočné pre nových používateľov Apache Ignite.
Zdroj: hab.com