Vi er teknologiudviklingsafdelingen i et detailnetværk. En dag stillede ledelsen til opgave at fremskynde storskalaberegninger ved at bruge Apache Ignite i forbindelse med MSSQL og viste en hjemmeside med flotte illustrationer og eksempler på Java-kode. Jeg kunne straks lide siden , hvis beskrivelse lover mirakler: du behøver ikke manuelt at implementere din Java- eller Scala-kode på hver node i gitteret og geninstallere den hver gang den ændres. Efterhånden som arbejdet skred frem, viste det sig, at Zero Deployment har specifikke anvendelser, hvis funktioner jeg vil dele. Under snittet er tanker og implementeringsdetaljer.
1. Beskrivelse af problemet
Essensen af problemet er som følger. Der er en SalesPoint salgsstedoversigt og en Sku (Stock Keeping Unit) produktkatalog. Salgsstedet har en "Butikstype"-attribut med værdierne "small" og "large". Et sortiment (liste over produkter fra salgsstedet) er forbundet til hvert salgssted (indlæst fra DBMS), og der gives oplysninger om, at det angivne produkt fra den angivne dato
udelukket fra sortimentet eller tilføjet sortimentet.
Det er påkrævet at organisere en opdelt cache af salgssteder og gemme oplysninger om tilsluttede produkter i den i en måned i forvejen. Kompatibilitet med kampsystemet kræver, at Ignite-klientknuden indlæser data, beregner et aggregat af formularen (butikstype, produktkode, dag, antal_salgspoint) og uploader det tilbage til DBMS.
2. Litteraturstudie
Jeg har ingen erfaring endnu, så jeg begynder at danse fra komfuret. Altså fra en gennemgang af publikationer.
Artikel 2016 indeholder et link til dokumentationen for Apache Ignite-projektet og samtidig en bebrejdelse for vagheden i denne dokumentation. Jeg genlæser den et par gange, klarheden kommer ikke. Jeg henviser til den officielle tutorial Hvilket
lover optimistisk "Du er i gang i et snuptag!" Jeg er ved at finde ud af indstillingerne for miljøvariabler, og ser to Apache Ignite Essentials-videoer, men de var ikke særlig nyttige til min specifikke opgave. Jeg starter med succes Ignite fra kommandolinjen med standardfilen "example-ignite.xml", og bygger den første applikation ved hjælp af Maven. Applikationen virker og bruger Zero Deployment, hvilken skønhed!
Jeg læste videre, og der bruger eksemplet straks affinityKey (oprettet tidligere gennem en SQL-forespørgsel), og bruger endda det mystiske BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); jeg læste det : binært format - noget som refleksion, adgang til felterne i et objekt ved navn. Kan aflæse værdien af et felt uden fuldstændig at deserialisere objektet (gemmer hukommelse). Men hvorfor bruges BinaryObject i stedet for Person, da der er Zero Deployment? Hvorfor IgniteCache overført til IgniteCache ? Det er ikke klart endnu.
Jeg laver Compute-applikationen om, så den passer til min sag. Den primære nøgle i kataloget over salgssteder i MSSQL er defineret som [id] [int] IKKE NULL, jeg opretter en cache analogt
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")I xml-konfigurationen angiver jeg, at cachen er partitioneret
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Opdeling efter salgssted forudsætter, at det nødvendige aggregat vil blive bygget på hver klynge node for de tilgængelige salesPointCache-poster, hvorefter klientknuden vil udføre den endelige summering.
Jeg læser selvstudiet , jeg gør det analogt. På hver klynge node kører jeg IgniteRunnable(), noget som dette:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Jeg tilføjer aggregerings- og uploadlogik og kører det på et testdatasæt. Alt fungerer lokalt på udviklingsserveren.
Jeg starter to CentOs-testservere, angiv IP-adresserne i default-config.xml, udfører på hver
./bin/ignite.sh config/default-config.xmlBegge Ignite noder kører og kan se hinanden. Jeg angiver de nødvendige adresser i xml-konfigurationen af klientapplikationen, den starter, tilføjer en tredje node til topologien og straks er der to noder igen. Loggen viser "ClassNotFoundException: model.SalesPoint" i linjen
SalesPoint sp=salesPointCache.get(spId);StackOverflow siger, at årsagen til fejlen er, at der ikke er nogen tilpasset SalesPoint-klasse på CentOs-servere. Vi er ankommet. Hvad med "du behøver ikke manuelt at implementere din Java-kode på hver node" og så videre? Eller handler "din Java-kode" ikke om SalesPoint?
Jeg er nok gået glip af noget – jeg begynder at søge igen, læse og søge igen. Efter et stykke tid får jeg en fornemmelse af, at jeg har læst alt om emnet, der er ikke noget nyt længere. Mens jeg søgte, fandt jeg nogle interessante kommentarer.
, Lead Architect 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 anden autoritativ udtalelse: , Direktør for produktledelse, GridGain Systems.
Artikel om Habré refererer til tre artikler af Denis Magda: , , 2016-2017. I den anden artikel foreslår Denis at starte en klynge node via MaintenanceServiceNodeStartup.jar. Du kan også bruge start med xml-konfiguration og kommandolinje, men så skal du manuelt placere brugerdefinerede klasser på hver installeret klynge node:
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.Ja, det er det. Her viser det sig, hvorfor, dette mystiske binære format!
3.SingleJar
Denis tog førstepladsen i min personlige vurdering, IMHO den mest nyttige tutorial af alle tilgængelige. I hans Github indeholder et helt færdigt eksempel på opsætning af cluster noder, som kompilerer uden yderligere squatting.
Jeg gør det på samme måde og får en enkelt jar-fil, der starter "data node" eller "client node" afhængigt af kommandolinjeargumentet. Monteringen starter og virker. Zero Deployment er blevet besejret.
Overgangen fra megabyte testdata til titusvis af gigabyte kampdata viste, at det binære format eksisterer af en grund. Det var nødvendigt at optimere hukommelsesforbruget på noder, og det var her, BinaryObject viste sig at være meget nyttig.
4 konklusioner
Den første bebrejdelse, man stødte på om Apache Ignite-projektets vaghed, viste sig at være retfærdig; lidt har ændret sig siden 2016. Det er ikke let for en nybegynder at sammensætte en fungerende prototype baseret på et websted og/eller et lager.
Baseret på resultaterne af det udførte arbejde var indtrykket, at Zero Deployment virker, men kun på systemniveau. Noget som dette: BinaryObject bruges til at lære fjernklynge noder at arbejde med brugerdefinerede klasser; Zero Deployment - intern mekanisme
Apache Ignite sig selv og distribuerer systemobjekter i hele klyngen.
Jeg håber, at min erfaring vil være nyttig for nye Apache Ignite-brugere.
Kilde: www.habr.com