Vi er teknologiutviklingsavdelingen i et detaljhandelsnettverk. En dag satte ledelsen i oppgave å fremskynde beregninger i stor skala ved å bruke Apache Ignite i forbindelse med MSSQL, og viste en nettside med vakre illustrasjoner og eksempler på Java-kode. Jeg likte siden umiddelbart , beskrivelsen av hvilke lover mirakler: du trenger ikke å distribuere Java- eller Scala-koden manuelt på hver node i rutenettet og distribuere den på nytt hver gang den endres. Etter hvert som arbeidet skred frem, viste det seg at Zero Deployment har spesifikke bruksområder, funksjonene jeg ønsker å dele. Under kuttet er tanker og gjennomføringsdetaljer.
1. Redegjørelse av problemet
Essensen av problemet er som følger. Det er en SalesPoint salgspunktkatalog og en Sku (lagerholdsenhet) produktkatalog. Salgsstedet har attributtet "Store type" med verdiene "small" og "large". Et sortiment (liste over produkter fra salgsstedet) er knyttet til hvert salgssted (lastet fra DBMS) og det gis informasjon om at det spesifiserte produktet fra den angitte datoen
ekskludert fra sortimentet eller lagt til sortimentet.
Det er påkrevd å organisere en oppdelt cache med salgssteder og lagre informasjon om tilkoblede produkter i den i en måned i forveien. Kompatibilitet med kampsystemet krever at Ignite-klientnoden laster data, beregner et aggregat av skjemaet (butikktype, produktkode, dag, antall_salgspoeng) og laster det opp tilbake til DBMS.
2. Litteraturstudie
Jeg har ingen erfaring ennå, så jeg begynner å danse fra komfyren. Det vil si fra en gjennomgang av publikasjoner.
Artikkel 2016 inneholder en lenke til dokumentasjonen for Apache Ignite-prosjektet og samtidig en bebreidelse for vagheten i denne dokumentasjonen. Jeg leste den på nytt et par ganger, klarhet kommer ikke. Jeg viser til den offisielle opplæringen Som
lover optimistisk "Du kommer i gang i en håndvending!" Jeg finner ut av miljøvariabelinnstillingene, ser på to Apache Ignite Essentials-videoer, men de var ikke veldig nyttige for min spesifikke oppgave. Jeg starter Ignite fra kommandolinjen med standardfilen "example-ignite.xml", og bygger det første programmet bruker Maven. Applikasjonen fungerer og bruker Zero Deployment, for en skjønnhet!
Jeg leste videre, og der bruker eksemplet umiddelbart affinityKey (opprettet tidligere gjennom en SQL-spørring), og bruker til og med det mystiske BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); lese : binært format - noe som refleksjon, tilgang til feltene til et objekt ved navn. Kan lese verdien av et felt uten å fullstendig deserialisere objektet (sparer minne). Men hvorfor brukes BinaryObject i stedet for Person, siden det er Zero Deployment? Hvorfor IgniteCache overført til IgniteCache ? Det er ikke klart ennå.
Jeg lager Compute-applikasjonen på nytt for å passe til mitt tilfelle. Primærnøkkelen til katalogen over salgssteder i MSSQL er definert som [id] [int] IKKE NULL, jeg lager en cache analogt
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")I xml-konfigurasjonen indikerer jeg at cachen er partisjonert
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Partisjonering etter salgssted forutsetter at det nødvendige aggregatet vil bygges på hver klyngennode for salesPointCache-postene som er tilgjengelige der, hvoretter klientnoden vil utføre den endelige summeringen.
Jeg leser opplæringen , jeg gjør det analogt. På hver klyngennode kjører jeg IgniteRunnable(), noe som dette:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Jeg legger til aggregerings- og opplastingslogikk og kjører den på et testdatasett. Alt fungerer lokalt på utviklingsserveren.
Jeg starter to CentOs-testservere, spesifiser IP-adressene i default-config.xml, kjører på hver
./bin/ignite.sh config/default-config.xmlBegge Ignite-nodene kjører og kan se hverandre. Jeg spesifiserer de nødvendige adressene i xml-konfigurasjonen til klientapplikasjonen, den starter, legger til en tredje node til topologien og umiddelbart er det to noder igjen. Loggen viser "ClassNotFoundException: model.SalesPoint" i linjen
SalesPoint sp=salesPointCache.get(spId);StackOverflow sier at årsaken til feilen er at det ikke er noen tilpasset SalesPoint-klasse på CentOs-servere. Vi har kommet. Hva med "du trenger ikke å distribuere Java-koden manuelt på hver node" og så videre? Eller handler "din Java-kode" ikke om SalesPoint?
Jeg har nok gått glipp av noe – jeg begynner å søke igjen, lese og søke igjen. Etter en stund får jeg følelsen av at jeg har lest alt om temaet, det er ikke noe nytt lenger. Mens jeg søkte, fant jeg noen interessante kommentarer.
, hovedarkitekt hos GridGain Systems, på StackOverflow, april 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.En annen autoritativ mening: , Direktør for produktledelse, GridGain Systems.
Artikkel om Habré refererer til tre artikler av Denis Magda: , , 2016-2017. I den andre artikkelen foreslår Denis å starte en klyngennode via MaintenanceServiceNodeStartup.jar. Du kan også bruke lansering med xml-konfigurasjon og kommandolinje, men da må du manuelt legge inn egendefinerte klasser på hver distribuert klyngennode:
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.Det er det faktisk. Her viser det seg, hvorfor, dette mystiske binære formatet!
3.SingleJar
Denis tok førsteplassen i min personlige vurdering, IMHO den mest nyttige opplæringen av alle tilgjengelige. I hans Github inneholder et helt ferdig eksempel på å sette opp cluster noder, som kompilerer uten ekstra knebøy.
Jeg gjør det på samme måte og får en enkelt jar-fil som starter "data node" eller "client node" avhengig av kommandolinjeargumentet. Monteringen starter og fungerer. Zero Deployment har blitt beseiret.
Overgangen fra megabyte med testdata til titalls gigabyte med kampdata viste at det binære formatet eksisterer av en grunn. Det var nødvendig å optimalisere minneforbruket på noder, og det var her BinaryObject viste seg å være svært nyttig.
4. Konklusjoner
Den første bebreidelsen som ble møtt om vagheten i Apache Ignite-prosjektdokumentasjonen viste seg å være rettferdig; lite har endret seg siden 2016. Det er ikke lett for en nybegynner å sette sammen en fungerende prototype basert på et nettsted og/eller depot.
Basert på resultatene av arbeidet som ble gjort, var inntrykket at Zero Deployment fungerer, men kun på systemnivå. Noe sånt som dette: BinaryObject brukes til å lære eksterne klyngenoder å jobbe med egendefinerte klasser; Zero Deployment - intern mekanisme
Apache Ignite seg selv og distribuerer systemobjekter gjennom hele klyngen.
Jeg håper erfaringen min vil være nyttig for nye Apache Ignite-brukere.
Kilde: www.habr.com