Wij zijn de afdeling technologieontwikkeling voor de detailhandel. Op een gegeven moment gaf het management de opdracht om volumetrische berekeningen te versnellen door gebruik te maken van Apache Ignite in combinatie met MSSQL, en toonde een website met prachtige illustraties en voorbeelden van Java-code. De website viel meteen in de smaak. , waarvan de beschrijving wonderen belooft: you don’t have to manually deploy your Java or Scala code on each node in the grid and re-deploy it each time it changes. Tijdens het werk bleek dat Zero Deployment specifieke gebruikseisen heeft, waarvan ik graag de details wil delen. Hieronder mijn gedachten en de implementatiedetails.
1. Probleemstelling
De kern van het probleem is als volgt. Er is een referentie van verkooplocaties SalesPoint en een referentie van goederen SKU (Stock Keeping Unit). Een verkooplocatie heeft een attribuut ‘typeWinkel’ met de waarden ‘klein’ en ‘groot’. Aan elke verkooplocatie wordt een assortiment (lijst van goederen die beschikbaar zijn in de verkooplocatie) gekoppeld (geladen vanuit de DBMS), en er wordt informatie verstrekt dat een bepaald product vanaf de aangegeven datum
wordt uitgesloten of toegevoegd aan het assortiment.
Er moet een gepartitioneerde cache voor verkooplocaties worden georganiseerd en deze moet informatie bevatten over de gekoppelde producten voor een maand vooruit. De compatibiliteit met het productie systeem vereist dat de client-knooppunt Ignite gegevens laadt, een aggregaat van het type (typeWinkel, productcode, dag, aantal_verkooplocaties) berekent en deze terug in de DBMS exporteert.
2. Literatuurstudie
Ik heb nog geen ervaring, dus ik begin bij het begin. Dat wil zeggen met een overzicht van publicaties.
Een artikel uit 2016 bevat een verwijzing naar de documentatie van het project Apache Ignite en een aanmerking over de onduidelijkheid van deze documentatie. Ik heb het een paar keer opnieuw gelezen, maar duidelijkheid blijft uit. Ik richt me op de officiële tutorial , die
die optimistisch belooft: “You’ll be up and running in a jiffy!”. Ik probeer de omgevingsvariabelen in te stellen, bekijk twee video's over Apache Ignite Essentials, maar voor mijn specifieke taak bleken ze niet bijzonder nuttig. Ik start Ignite succesvol vanuit de opdrachtregel met het standaardbestand “example-ignite.xml” en bouw mijn eerste applicatie met Maven. De applicatie werkt en maakt gebruik van Zero Deployment, wat fantastisch is!
Ik lees verder, en daar is een voorbeeld dat meteen affinityKey gebruikt (eerder aangemaakt via SQL-query), en daarbij wordt ook de mysterieuze BinaryObject toegepast:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Ik heb een beetje gelezen. : binaire formaat - iets als reflectie, toegang tot objectvelden op naam. Het kan de waarde van een veld lezen zonder volledige deserialisatie van het object (geheugenbesparing). Maar waarom wordt BinaryObject in plaats van Person gebruikt, aangezien er Zero Deployment is? Waarom wordt IgniteCache vertaald naar IgniteCache? Tot nu toe is het onduidelijk.
Ik pas de Compute Application aan voor mijn situatie. De primaire sleutel van de verkooplocatiedatabase in MSSQL is gedefinieerd als [id] [int] NOT NULL, ik maak een cache aan op basis van een vergelijkbaar principe.
IgniteCache salesPointCache=ignite.cache("spCache")In de xml-configuratie geef ik aan dat de cache gepartitioneerd is.
Partitionering op verkooplocaties houdt in dat de vereiste aggregaat op elke knoop van het cluster wordt opgebouwd voor de bestaande records in salesPointCache, waarna de klantknoop de eindtotaalberekening uitvoert.
Ik lees de tutorial. , ik doe het op een vergelijkbare manier. Op elke knoop van het cluster start ik IgniteRunnable(), ongeveer zo:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Ik voeg de logica voor aggregatie en export toe, en voer deze uit op een testdataset. Lokaal op de ontwikkelingsserver werkt alles.
Ik start twee testservers CentOs, geef de ip-adressen op in default-config.xml en voer dit uit op elke server.
./bin/ignite.sh config/default-config.xmlBeide Ignite-nodes worden gestart en zien elkaar. Ik geef de benodigde adressen op in de xml-configuratie van de clientapplicatie, deze wordt gestart, voegt een derde node toe aan de topologie en meteen zijn er weer twee nodes. In de log staat "ClassNotFoundException: model.SalesPoint" in regel
SalesPoint sp=salesPointCache.get(spId);StackOverflow zegt dat de oorzaak van de fout is dat de SalesPoint gebruikersklasse niet op de CentOs-servers staat. Oeps. Hoe zit het met "je hoeft je Java-code niet handmatig op elke node te implementeren" en verder in de tekst? Of is "je Java-code" niet van toepassing op SalesPoint?
Waarschijnlijk heb ik iets gemist - ik begin opnieuw te zoeken, 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 zocht, vond ik een aantal interessante opmerkingen.
, Lead Architect bij GridGain Systems, op StackOverflow, april 2016:
Modelklassen worden niet peer gedeployed, maar je kunt de withKeepBinary() vlag op de cache gebruiken en BinaryObjects opvragen. Op deze manier vermijd je deserialisatie aan de serverzijde en krijg je geen ClassNotFoundException.Nog een gezaghebbende mening: , Director of Product Management, GridGain Systems.
Artikel op 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. Het is ook mogelijk om te starten met een xml-configuratie en de opdrachtregel, maar dan moet je handmatig de gebruikersklassen op elk te implementeren clusterknooppunt plaatsen:
Dat is het. Start (..) het knooppunt met behulp van het MaintenanceServiceNodeStartup-bestand of geef
maintenance-service-node-config.xml door aan de ignite.sh/bat-scripts van Apache Ignite.
Als je de laatste optie verkiest, zorg er dan voor dat je een jar-bestand bouwt dat alle klassen uit de mappen java/app/common en java/services/maintenance bevat.
De jar moet worden toegevoegd aan het classpath van elk knooppunt waar de service
kan worden ingezet.Inderdaad, dat is het. Kijk aan, daar is het voor, dit mysterieuze binaire formaat!
3. SingleJar
Denis staat op de eerste plaats in mijn persoonlijke ranglijst, imo het nuttigste tutorial van alle beschikbare. In zijn op GitHub staat een volledig werkend voorbeeld van het configureren van clusterknooppunten, dat compileert zonder enige extra moeite.
Ik doe het naar voorbeeld en vergelijk, en ontvang een enkel jar-bestand dat de «data node» of «client node» opstart, afhankelijk van het argument van de opdrachtregel. De build start en werkt. Zero Deployment is overwonnen.
De overgang van megabytes aan testdata naar tientallen gigabytes aan productiegegevens toonde aan dat het binaire formaat niet voor niets bestaat. Het werd nodig om het geheugengebruik op de knooppunten te optimaliseren, en hier bleek BinaryObject heel nuttig.
4. Conclusies
De eerste kritiek op de vaagheid van de documentatie van het Apache Ignite-project bleek terecht, er is sinds 2016 weinig veranderd. Voor een beginner is het moeilijk om een werkend prototype te bouwen op basis van de website en/of de repository.
Uiteindelijk had ik de indruk dat Zero Deployment werkt, maar alleen op systeemniveau. Ongeveer zo: BinaryObject wordt gebruikt om externe knooppunten van het cluster te leren omgaan met gebruikersklassen; Zero Deployment is een intern mechanisme
van Apache Ignite zelf en verspreidt systeemobjecten door het cluster.
Ik hoop dat mijn ervaring nuttig zal zijn voor nieuwe gebruikers van Apache Ignite.
Bron: habr.com
