Nous sommes le département de développement technologique d'un réseau de vente au détail. Un jour, la direction s'est donné pour tâche d'accélérer les calculs à grande échelle en utilisant Apache Ignite en conjonction avec MSSQL et a montré un site Web avec de belles illustrations et des exemples de code Java. J'ai tout de suite aimé le site , dont la description promet des miracles : vous n'êtes pas obligé de déployer manuellement votre code Java ou Scala sur chaque nœud de la grille et de le redéployer à chaque fois qu'il change. Au fur et à mesure de l’avancée des travaux, il s’est avéré que Zero Deployment avait des usages spécifiques, dont je souhaite partager les fonctionnalités. Sous la coupe se trouvent les réflexions et les détails de mise en œuvre.
1. Énoncé du problème
L'essence de la tâche est la suivante. Il existe un annuaire SalesPoint des points de vente et un annuaire produits Sku (Stock Keeping Unit). Le point de vente possède un attribut « Type de magasin » avec les valeurs « petit » et « grand ». Un assortiment (liste des produits du point de vente) est connecté à chaque point de vente (chargé depuis le SGBD) et des informations sont fournies qu'à partir de la date spécifiée le produit spécifié
exclus de l'assortiment ou ajoutés à l'assortiment.
Il est nécessaire d'organiser un cache cloisonné des points de vente et d'y stocker les informations sur les produits connectés un mois à l'avance. La compatibilité avec le système de combat nécessite que le nœud client Ignite charge les données, calcule un agrégat du formulaire (type de magasin, code produit, jour, nombre_de_points_de_vente) et le télécharge à nouveau dans le SGBD.
2. Etude de la littérature
Je n’ai pas encore d’expérience, alors je commence à danser aux fourneaux. Autrement dit, à partir d’un examen des publications.
Article de 2016 contient un lien vers la documentation du projet Apache Ignite et en même temps un reproche sur le flou de cette documentation. Je l'ai relu plusieurs fois, la clarté ne vient pas. Je me réfère au tutoriel officiel Qui
promet avec optimisme « Vous serez opérationnel en un tournemain ! » Je suis en train de déterminer les paramètres des variables d'environnement, de regarder deux vidéos Apache Ignite Essentials, elles n'étaient pas très utiles pour ma tâche spécifique. Je lance avec succès Ignite depuis la ligne de commande avec le fichier standard « example-ignite.xml », en créant la première application en utilisant Maven. L'application fonctionne et utilise Zero Deployment, quelle beauté !
J'ai lu plus loin, et là, l'exemple utilise immédiatement affinityKey (créé plus tôt via une requête SQL), et utilise même le mystérieux BinaryObject :
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Lis : format binaire - quelque chose comme la réflexion, accédant aux champs d'un objet par son nom. Peut lire la valeur d'un champ sans désérialiser complètement l'objet (économie de mémoire). Mais pourquoi BinaryObject est-il utilisé à la place de Person, puisqu'il n'y a aucun déploiement ? Pourquoi IgniteCache transféré vers IgniteCache ? Ce n'est pas encore clair.
Je suis en train de refaire l'application Compute en fonction de mon cas. La clé primaire de l'annuaire des points de vente en MSSQL est définie comme [id] [int] NOT NULL, je crée un cache par analogie
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Dans la config xml j'indique que le cache est partitionné
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Le partitionnement par point de vente suppose que l'agrégat requis sera construit sur chaque nœud de cluster pour les enregistrements salesPointCache qui y sont disponibles, après quoi le nœud client effectuera la sommation finale.
je suis en train de lire le tutoriel , je le fais par analogie. Sur chaque nœud de cluster, j'exécute IgniteRunnable(), quelque chose comme ceci :
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}J'ajoute une logique d'agrégation et de téléchargement et je l'exécute sur un ensemble de données de test. Tout fonctionne localement sur le serveur de développement.
Je lance deux serveurs de test CentOs, précise les adresses IP dans default-config.xml, exécute sur chacun
./bin/ignite.sh config/default-config.xmlLes deux nœuds Ignite sont en cours d’exécution et peuvent se voir. Je précise les adresses requises dans la configuration XML de l'application client, elle démarre, ajoute un troisième nœud à la topologie et immédiatement il y a à nouveau deux nœuds. Le journal affiche « ClassNotFoundException : model.SalesPoint » dans la ligne
SalesPoint sp=salesPointCache.get(spId);StackOverflow indique que la raison de l'erreur est qu'il n'existe pas de classe SalesPoint personnalisée sur les serveurs CentOs. Nous sommes arrivés. Que diriez-vous de « vous n'avez pas besoin de déployer manuellement votre code Java sur chaque nœud » et ainsi de suite ? Ou est-ce que « votre code Java » ne concerne pas SalesPoint ?
J'ai probablement raté quelque chose - je recommence à chercher, à lire et à chercher encore. Au bout d'un moment, j'ai l'impression d'avoir tout lu sur le sujet, il n'y a plus rien de nouveau. En cherchant, j'ai trouvé des commentaires intéressants.
, architecte principal chez GridGain Systems, sur StackOverflow, avril 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.Autre avis faisant autorité : , directeur de la gestion des produits, GridGain Systems.
Article sur Habré fait référence à trois articles de Denis Magda : , , 2016-2017. Dans le deuxième article, Denis suggère de démarrer un nœud de cluster via MaintenanceServiceNodeStartup.jar. Vous pouvez également utiliser le lancement avec la configuration XML et la ligne de commande, mais vous devez ensuite placer manuellement des classes personnalisées sur chaque nœud de cluster déployé :
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.En effet, c'est tout. Ici, il s'avère, eh bien, ce mystérieux format binaire !
3.Jar unique
Denis a pris la première place dans mon évaluation personnelle, à mon humble avis, le didacticiel le plus utile de tous disponibles. Dans son Github contient un exemple entièrement prêt à l'emploi de configuration de nœuds de cluster, qui se compile sans aucun squattage supplémentaire.
Je le fais de la même manière et j'obtiens un seul fichier jar qui lance le « nœud de données » ou le « nœud client » en fonction de l'argument de la ligne de commande. L'assemblage démarre et fonctionne. Le déploiement zéro a été vaincu.
Le passage de mégaoctets de données de test à des dizaines de gigaoctets de données de combat a montré que le format binaire existe pour une raison. Il fallait optimiser la consommation mémoire sur les nœuds, et c'est là que BinaryObject s'est avéré très utile.
4. Conclusions
Le premier reproche rencontré sur le flou de la documentation du projet Apache Ignite s'est avéré juste ; peu de choses ont changé depuis 2016. Il n’est pas facile pour un débutant d’assembler un prototype fonctionnel basé sur un site Web et/ou un référentiel.
Sur la base des résultats du travail effectué, l'impression était que Zero Deployment fonctionne, mais uniquement au niveau du système. Quelque chose comme ceci : BinaryObject est utilisé pour apprendre aux nœuds de cluster distants à travailler avec des classes personnalisées ; Zéro déploiement - mécanisme interne
Apache Ignite lui-même et distribue les objets système dans tout le cluster.
J'espère que mon expérience sera utile aux nouveaux utilisateurs d'Apache Ignite.
Source: habr.com