Esame mažmeninės prekybos tinklo technologijų plėtros skyrius. Vieną dieną vadovybė užsibrėžė užduotį paspartinti didelio masto skaičiavimus naudojant Apache Ignite kartu su MSSQL ir parodė svetainę su gražiomis iliustracijomis ir Java kodo pavyzdžiais. Man iškart patiko svetainė , kurio aprašymas žada stebuklus: jums nereikia rankiniu būdu diegti Java arba Scala kodo kiekviename tinklelio mazge ir diegti jį iš naujo kiekvieną kartą, kai jis pasikeičia. Darbui įsibėgėjus paaiškėjo, kad Zero Deployment turi specifinį panaudojimą, kurio funkcijomis noriu pasidalinti. Po pjūviu pateikiamos mintys ir įgyvendinimo detalės.
1. Problemos pareiškimas
Problemos esmė tokia. Yra „SalesPoint“ pardavimo vietų katalogas ir „Sku“ (atsargų saugojimo padalinio) produktų katalogas. Prekybos vietoje yra atributas „Parduotuvės tipas“, kurio reikšmės yra „small“ ir „large“. Prie kiekvienos prekybos vietos (pakraunamas iš DBVS) prijungiamas asortimentas (prekybos vietos prekių sąrašas) ir pateikiama informacija, kad nuo nurodytos datos nurodyta prekė
pašalintas iš asortimento arba įtrauktas į asortimentą.
Būtina sutvarkyti atskirtą prekybos vietų talpyklą ir prieš mėnesį saugoti joje informaciją apie prijungtus produktus. Suderinamumas su kovos sistema reikalauja, kad „Ignite“ kliento mazgas įkeltų duomenis, apskaičiuotų formos suvestinę (parduotuvės tipas, prekės kodas, diena,_pardavimo_taškų_skaičius) ir įkeltų atgal į DBVS.
2. Literatūros studijos
Patirties dar neturiu, tad pradedu šokti nuo krosnies. Tai yra iš publikacijų apžvalgos.
2016 straipsnis yra nuoroda į Apache Ignite projekto dokumentaciją ir kartu priekaištas dėl šios dokumentacijos neapibrėžtumo. Perskaičiau kelis kartus, aiškumas neateina. Remiuosi oficialia pamoka Kuris
optimistiškai žada: „Tuoj akimirksniu pradėsite veikti! Išsiaiškinu aplinkos kintamojo nustatymus, žiūriu du „Apache Ignite Essentials“ vaizdo įrašus, bet jie nebuvo labai naudingi mano konkrečiai užduočiai. Sėkmingai paleidžiu „Ignite“ iš komandinės eilutės su standartiniu failu „example-ignite.xml“, sukurdamas pirmąją programą naudojant Maven. Programa veikia ir naudoja Zero Deployment, koks grožis!
Skaitau toliau, o pavyzdyje iš karto naudojamas affinityKey (sukurtas anksčiau naudojant SQL užklausą) ir netgi naudojamas paslaptingas BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); skaityti : dvejetainis formatas – kažkas panašaus į atspindį, prieiga prie objekto laukų pagal pavadinimą. Gali nuskaityti lauko reikšmę visiškai nesutvarkydamas objekto (taupo atmintį). Bet kodėl vietoj asmens naudojamas BinaryObject, nes yra nulinis diegimas? Kodėl „IgniteCache“. perkelta į „IgniteCache“. ? Dar neaišku.
Perkuriu skaičiavimo programą, kad ji atitiktų mano atvejį. Pardavimo vietų katalogo pirminis raktas MSSQL yra apibrėžiamas kaip [id] [int] NOT NULL, aš sukuriu talpyklą pagal analogiją
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Xml konfigūracijoje nurodysiu, kad talpykla yra padalinta
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Skirstant pagal pardavimo vietą daroma prielaida, kad kiekviename klasterio mazge bus sukurtas reikalingas ten pasiekiamų salesPointCache įrašų agregatas, o po to kliento mazgas atliks galutinį sumavimą.
Aš skaitau pamoką , darau pagal analogiją. Kiekviename klasterio mazge paleidžiu IgniteRunnable (), maždaug taip:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Pridedu agregavimo ir įkėlimo logiką ir paleidžiu ją bandomajame duomenų rinkinyje. Viskas veikia lokaliai kūrimo serveryje.
Paleidžiu du CentOs bandomuosius serverius, nurodau IP adresus default-config.xml, paleidžiu kiekviename
./bin/ignite.sh config/default-config.xmlAbu „Ignite“ mazgai veikia ir gali matyti vienas kitą. Kliento aplikacijos xml konfigūracijoje nurodau reikiamus adresus, ji paleidžiama, prideda trečią mazgą į topologiją ir iš karto vėl du mazgai. Žurnalo eilutėje rodoma „ClassNotFoundException: model.SalesPoint“.
SalesPoint sp=salesPointCache.get(spId);„StackOverflow“ teigia, kad klaidos priežastis yra ta, kad „CentOs“ serveriuose nėra tinkintos „SalesPoint“ klasės. Mes atvykome. O kaip „nereikia rankiniu būdu diegti Java kodo kiekviename mazge“ ir pan.? Ar „jūsų Java kodas“ nėra susijęs su „SalesPoint“?
Tikriausiai kažką praleidau – vėl pradedu ieškoti, skaityti ir dar kartą ieškoti. Po kiek laiko apima jausmas, kad perskaiciau viska temoje, nieko naujo jau nera. Beieškodama radau įdomių komentarų.
, „GridGain Systems“ vyriausiasis architektas, „StackOverflow“, 2016 m. balandžio mėn.:
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.Dar viena autoritetinga nuomonė: , „GridGain Systems“ produktų valdymo direktorius.
Straipsnis apie Habré nurodo tris Deniso Magdos straipsnius: , , 2016-2017 m. Antrame straipsnyje Denisas siūlo paleisti klasterio mazgą per MaintenanceServiceNodeStartup.jar. Taip pat galite naudoti paleidimą su xml konfigūracija ir komandų eilute, bet tada kiekviename įdiegtame klasterio mazge turite rankiniu būdu įdėti pasirinktines klases:
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.Tikrai taip. Čia paaiškėja, kodėl, šis paslaptingas dvejetainis formatas!
3.SingleJar
Denisas užėmė pirmąją vietą mano asmeniniame įvertinime, IMHO – naudingiausia pamoka iš visų turimų. Jo „Github“ yra visiškai paruoštas klasterio mazgų nustatymo pavyzdys, kuris kompiliuojamas be jokio papildomo pritūpimo.
Aš darau tai taip pat ir gaunu vieną jar failą, kuris paleidžia „duomenų mazgą“ arba „kliento mazgą“, priklausomai nuo komandinės eilutės argumento. Montavimas prasideda ir veikia. Nulinis diegimas buvo nugalėtas.
Perėjimas nuo megabaitų bandomųjų duomenų prie dešimčių gigabaitų kovinių duomenų parodė, kad dvejetainis formatas egzistuoja dėl priežasties. Reikėjo optimizuoti atminties suvartojimą mazguose, ir čia „BinaryObject“ pasirodė labai naudingas.
4. Išvados
Pirmasis priekaištas dėl Apache Ignite projekto dokumentacijos neapibrėžtumo pasirodė esąs teisingas, mažai kas pasikeitė nuo 2016 m. Pradedančiajam nėra lengva surinkti veikiantį prototipą, pagrįstą svetaine ir (arba) saugykla.
Remiantis atlikto darbo rezultatais, susidarė įspūdis, kad Zero Deployment veikia, bet tik sistemos lygmeniu. Kažkas panašaus: „BinaryObject“ naudojamas mokyti nuotolinius klasterio mazgus dirbti su pasirinktomis klasėmis; Zero Deployment – vidinis mechanizmas
Apache Ignite pati ir paskirsto sistemos objektus visame klasteryje.
Tikiuosi, kad mano patirtis bus naudinga naujiems „Apache Ignite“ vartotojams.
Šaltinis: www.habr.com