Som el departament de desenvolupament tecnològic d'una xarxa comercial. Un dia, la direcció es va encarregar d'accelerar els càlculs a gran escala mitjançant l'ús d'Apache Ignite juntament amb MSSQL i va mostrar un lloc web amb il·lustracions precioses i exemples de codi Java. De seguida em va agradar el lloc , la descripció de la qual promet miracles: no cal desplegar manualment el codi Java o Scala a cada node de la graella i tornar-lo a desplegar cada vegada que canviï. A mesura que avançava el treball, va resultar que Zero Deployment té usos específics, les característiques de les quals vull compartir. A sota del tall hi ha pensaments i detalls d'implementació.
1. Enunciat del problema
L'essència del problema és la següent. Hi ha un directori de punts de venda de SalesPoint i un directori de productes Sku (Unitat de manteniment d'estocs). El punt de venda té un atribut "Tipus de botiga" amb els valors "petit" i "gran". Es connecta un assortiment (llista de productes del punt de venda) a cada punt de venda (carregat des del DBMS) i es proporciona informació que a partir de la data especificada el producte especificat
exclosos de l'assortiment o afegits a l'assortiment.
Cal organitzar una memòria cau particionada de punts de venda i emmagatzemar-hi informació sobre productes connectats amb un mes d'antelació. La compatibilitat amb el sistema de combat requereix que el node client Ignite carregui dades, calculi un agregat del formulari (tipus de botiga, codi de producte, dia, nombre_de_punts_vendes) i el torni a carregar al DBMS.
2. Estudi de la literatura
Encara no tinc experiència, així que començo a ballar des dels fogons. És a dir, a partir d'una revisió de publicacions.
Article 2016 conté un enllaç a la documentació del projecte Apache Ignite i alhora un retreu per la vaguetat d'aquesta documentació. Ho torno a llegir un parell de vegades, la claredat no arriba. Em refereixo al tutorial oficial Que
promet amb optimisme "Estaràs en funcionament en un tres i no res!" Estic esbrinant la configuració de la variable d'entorn, veient dos vídeos d'Apache Ignite Essentials, però no van ser molt útils per a la meva tasca específica. He llançat correctament Ignite des de la línia d'ordres amb el fitxer estàndard "example-ignite.xml", creant la primera aplicació utilitzant Maven. L'aplicació funciona i utilitza Zero Deployment, quina bellesa!
Vaig llegir més enllà, i allà l'exemple utilitza immediatament affinityKey (creat anteriorment mitjançant una consulta SQL) i fins i tot utilitza el misteriós BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); ho he llegit : format binari: una cosa com la reflexió, l'accés als camps d'un objecte pel nom. Pot llegir el valor d'un camp sense deserialitzar completament l'objecte (estalvi de memòria). Però, per què s'utilitza BinaryObject en lloc de Person, ja que hi ha Zero Deployment? Per què IgniteCache transferit a IgniteCache ? Encara no està clar.
Estic tornant a crear l'aplicació Compute per adaptar-la al meu cas. La clau primària del directori de punts de venda a MSSQL es defineix com a [id] [int] NOT NULL, creo una memòria cau per analogia
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")A la configuració xml indiqui que la memòria cau està particionada
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>La partició per punt de venda suposa que l'agregat necessari es crearà a cada node del clúster per als registres salesPointCache disponibles allà, després del qual el node client realitzarà la suma final.
Estic llegint el tutorial , ho faig per analogia. A cada node del clúster executo IgniteRunnable(), una cosa així:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Afegeixo la lògica d'agregació i càrrega i l'executo en un conjunt de dades de prova. Tot funciona localment al servidor de desenvolupament.
Llenço dos servidors de prova CentOs, especifiqueu les adreces IP a default-config.xml, executo a cadascun
./bin/ignite.sh config/default-config.xmlEls dos nodes d'Ignite s'estan executant i es poden veure. Especifico les adreces requerides a la configuració xml de l'aplicació client, s'inicia, afegeix un tercer node a la topologia i immediatament hi ha dos nodes de nou. El registre mostra "ClassNotFoundException: model.SalesPoint" a la línia
SalesPoint sp=salesPointCache.get(spId);StackOverflow diu que el motiu de l'error és que no hi ha cap classe de SalesPoint personalitzada als servidors CentOs. Hem arribat. Què tal "no heu de desplegar manualment el vostre codi Java a cada node" i així successivament? O "el vostre codi Java" no és sobre SalesPoint?
Probablement m'he perdut alguna cosa: començo a buscar de nou, a llegir i a buscar de nou. Al cap d'una estona, tinc la sensació que he llegit tot sobre el tema, ja no hi ha res de nou. Mentre buscava, he trobat alguns comentaris interessants.
, Arquitecte principal de GridGain Systems, a StackOverflow, abril de 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.Una altra opinió autoritzada: , Director de gestió de productes de GridGain Systems.
Article sobre Habré fa referència a tres articles de Denis Magda: , , 2016-2017. Al segon article, Denis suggereix iniciar un node de clúster mitjançant MaintenanceServiceNodeStartup.jar. També podeu utilitzar el llançament amb la configuració xml i la línia d'ordres, però llavors heu de posar manualment classes personalitzades a cada node de clúster desplegat:
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.De fet, això és tot. Aquí resulta, per què, aquest misteriós format binari!
3.SingleJar
Denis va ocupar el primer lloc a la meva qualificació personal, en el meu cas el tutorial més útil de tots els disponibles. En el seu Github conté un exemple completament preparat de la configuració de nodes de clúster, que es compila sense cap ocupació addicional.
Ho faig de la mateixa manera i obteniu un únic fitxer jar que llança "node de dades" o "node client" segons l'argument de la línia d'ordres. Comença el muntatge i funciona. Zero Deployment ha estat derrotat.
La transició de megabytes de dades de prova a desenes de gigabytes de dades de combat va demostrar que el format binari existeix per una raó. Calia optimitzar el consum de memòria als nodes, i aquí és on BinaryObject va resultar ser molt útil.
4. Conclusions
El primer retret que es va trobar sobre la vaguetat de la documentació del projecte Apache Ignite va resultar just; poc ha canviat des del 2016. No és fàcil per a un principiant muntar un prototip funcional basat en un lloc web i/o repositori.
A partir dels resultats del treball realitzat, la impressió va ser que Zero Deployment funciona, però només a nivell de sistema. Una cosa així: BinaryObject s'utilitza per ensenyar als nodes de clúster remots a treballar amb classes personalitzades; Zero Deployment: mecanisme intern
Apache Ignite i distribueix objectes del sistema per tot el clúster.
Espero que la meva experiència sigui útil als nous usuaris d'Apache Ignite.
Font: www.habr.com