Wij zijn de technologieontwikkelingsafdeling van een retailnetwerk. Op een dag stelde het management de taak om grootschalige berekeningen te versnellen door Apache Ignite in combinatie met MSSQL te gebruiken, en toonde een website met prachtige illustraties en voorbeelden van Java-code. Ik vond de site meteen leuk , waarvan de beschrijving wonderen belooft: u hoeft uw Java- of Scala-code niet handmatig op elk knooppunt in het raster te implementeren en deze telkens opnieuw te implementeren wanneer deze verandert. Naarmate het werk vorderde, bleek dat Zero Deployment specifieke toepassingen heeft, waarvan ik de kenmerken wil delen. Onder de snit staan gedachten en implementatiedetails.
1. Verklaring van het probleem
De essentie van het probleem is als volgt. Er is een SalesPoint-lijst met verkooppunten en een Sku-productlijst (Stock Keeping Unit). Het verkooppunt heeft een attribuut ‘Winkeltype’ met de waarden ‘klein’ en ‘groot’. Aan elk verkooppunt wordt een assortiment (lijst met producten van het verkooppunt) gekoppeld (geladen vanuit het DBMS) en wordt informatie verstrekt dat vanaf de opgegeven datum het opgegeven product
uitgesloten van het assortiment of toegevoegd aan het assortiment.
Het is vereist om een gepartitioneerde cache van verkooppunten te organiseren en daarin een maand van tevoren informatie over aangesloten producten op te slaan. Compatibiliteit met het vechtsysteem vereist dat het Ignite-clientknooppunt gegevens laadt, een aggregaat van het formulier berekent (winkeltype, productcode, dag, aantal_verkooppunten) en dit terug uploadt naar het DBMS.
2. Literatuurstudie
Ik heb nog geen ervaring, dus ik begin te dansen vanaf de kachel. Dat wil zeggen, uit een overzicht van publicaties.
Artikel 2016 bevat een link naar de documentatie van het Apache Ignite-project en tegelijkertijd een verwijt voor de vaagheid van deze documentatie. Ik heb het een paar keer opnieuw gelezen, maar de duidelijkheid komt niet. Ik verwijs naar de officiële tutorial Die
belooft optimistisch: “Je kunt binnen een mum van tijd aan de slag!” Ik ben bezig met het uitzoeken van de instellingen van de omgevingsvariabelen en bekijk twee Apache Ignite Essentials-video's, maar die waren niet erg nuttig voor mijn specifieke taak. Ik start Ignite met succes vanaf de opdrachtregel met het standaardbestand “example-ignite.xml”, waarmee ik de eerste applicatie bouw met behulp van Maven. De applicatie werkt en maakt gebruik van Zero Deployment, wat een schoonheid!
Ik lees verder, en daar gebruikt het voorbeeld onmiddellijk affinityKey (eerder gemaakt via een SQL-query), en gebruikt het zelfs het mysterieuze BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); lezen : binair formaat - zoiets als reflectie, toegang tot de velden van een object op naam. Kan de waarde van een veld lezen zonder het object volledig te deserialiseren (geheugen besparen). Maar waarom wordt BinaryObject gebruikt in plaats van Person, aangezien er Zero Deployment is? Waarom IgniteCache overgebracht naar IgniteCache ? Het is nog niet duidelijk.
Ik ben de Compute-applicatie aan het aanpassen aan mijn situatie. De primaire sleutel van de directory met verkooppunten in MSSQL is gedefinieerd als [id] [int] NOT NULL, ik maak naar analogie een cache
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")In de xml-configuratie geef ik aan dat de cache gepartitioneerd is
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Bij het partitioneren op verkooppunt wordt ervan uitgegaan dat het vereiste aggregaat op elk clusterknooppunt wordt gebouwd voor de daar beschikbare salesPointCache-records, waarna het clientknooppunt de laatste optelling zal uitvoeren.
Ik ben de tutorial aan het lezen , Ik doe het naar analogie. Op elk clusterknooppunt voer ik IgniteRunnable() uit, zoiets als dit:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Ik voeg aggregatie en uploadlogica toe en voer deze uit op een testdataset. Alles werkt lokaal op de ontwikkelingsserver.
Ik start twee CentOs-testservers, specificeer de IP-adressen in default-config.xml en voer ze op elk uit
./bin/ignite.sh config/default-config.xmlBeide Ignite-nodes zijn actief en kunnen elkaar zien. Ik specificeer de vereiste adressen in de xml-configuratie van de clienttoepassing, deze start, voegt een derde knooppunt toe aan de topologie en onmiddellijk zijn er weer twee knooppunten. In het logboek wordt 'ClassNotFoundException: model.SalesPoint' in de regel weergegeven
SalesPoint sp=salesPointCache.get(spId);StackOverflow zegt dat de reden voor de fout is dat er geen aangepaste SalesPoint-klasse op CentOs-servers is. We zijn aangekomen. Hoe zit het met “u hoeft uw Java-code niet handmatig op elk knooppunt te implementeren” enzovoort? Of gaat “uw Java-code” niet over SalesPoint?
Ik heb waarschijnlijk iets gemist - ik begin opnieuw te zoeken, te lezen en opnieuw te zoeken. Na een tijdje krijg ik het gevoel dat ik alles over het onderwerp heb gelezen, er is niets nieuws meer. Terwijl ik aan het zoeken was, kwam ik een aantal interessante opmerkingen tegen.
, hoofdarchitect bij GridGain Systems, op 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.Nog een gezaghebbende mening: , Directeur productmanagement, GridGain Systems.
Artikel over Habré verwijst naar drie artikelen van Denis Magda: , , 2016-2017. In het tweede artikel stelt Denis voor om een clusterknooppunt te starten via MaintenanceServiceNodeStartup.jar. U kunt ook starten met xml-configuratie en opdrachtregel gebruiken, maar dan moet u handmatig aangepaste klassen op elk geïmplementeerd clusterknooppunt plaatsen:
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.Dat is het inderdaad. Hier blijkt, waarom, dit mysterieuze binaire formaat!
3. Enkele pot
Denis behaalde de eerste plaats in mijn persoonlijke beoordeling, IMHO de nuttigste tutorial van allemaal beschikbaar. In zijn Github bevat een volledig kant-en-klaar voorbeeld van het opzetten van clusternodes, dat compileert zonder extra kraken.
Ik doe het op dezelfde manier en krijg een enkel jar-bestand dat “data node” of “client node” start, afhankelijk van het opdrachtregelargument. De montage begint en werkt. Zero Deployment is verslagen.
De overgang van megabytes aan testgegevens naar tientallen gigabytes aan gevechtsgegevens liet zien dat het binaire formaat niet voor niets bestaat. Het was nodig om het geheugengebruik op knooppunten te optimaliseren, en dit is waar BinaryObject erg nuttig bleek te zijn.
4. Conclusies
Het eerste verwijt dat men tegenkwam over de vaagheid van de documentatie van het Apache Ignite-project bleek terecht; er is sinds 2016 weinig veranderd. Het is voor een beginner niet eenvoudig om een functionerend prototype in elkaar te zetten op basis van een website en/of repository.
Op basis van de resultaten van het uitgevoerde werk was de indruk dat Zero Deployment werkt, maar alleen op systeemniveau. Zoiets als dit: BinaryObject wordt gebruikt om externe clusterknooppunten te leren werken met aangepaste klassen; Zero Deployment - intern mechanisme
Apache ontsteekt zichzelf en distribueert systeemobjecten door het cluster.
Ik hoop dat mijn ervaring nuttig zal zijn voor nieuwe Apache Ignite-gebruikers.
Bron: www.habr.com