Somos el departamento de desarrollo tecnológico de una red minorista. Un día, la gerencia se propuso la tarea de acelerar los cálculos a gran escala utilizando Apache Ignite junto con MSSQL y mostró un sitio web con hermosas ilustraciones y ejemplos de código Java. Inmediatamente me gustó el sitio. , cuya descripción promete milagros: no es necesario implementar manualmente su código Java o Scala en cada nodo de la cuadrícula y volver a implementarlo cada vez que cambie. A medida que avanzaba el trabajo, resultó que Zero Deployment tiene usos específicos, cuyas características quiero compartir. Debajo del corte hay ideas y detalles de implementación.
1 Planteamiento del problema
La esencia del problema es la siguiente. Se cuenta con un directorio de puntos de venta SalesPoint y un directorio de productos SKU (Stock Keeping Unit). El punto de venta tiene un atributo “Tipo de tienda” con los valores “pequeña” y “grande”. Se conecta un surtido (lista de productos del punto de venta) a cada punto de venta (cargado desde el DBMS) y se proporciona información de que a partir de la fecha especificada el producto especificado
excluidos del surtido o añadidos al surtido.
Es necesario organizar un caché dividido de puntos de venta y almacenar en él información sobre los productos conectados con un mes de anticipación. La compatibilidad con el sistema de combate requiere que el nodo cliente de Ignite cargue datos, calcule un agregado del formulario (tipo de tienda, código de producto, día, número_de_puntos_de_ventas) y lo cargue nuevamente en el DBMS.
2. Estudio de la literatura.
Todavía no tengo experiencia, así que empiezo a bailar desde la estufa. Es decir, a partir de una revisión de publicaciones.
Artículo de 2016 contiene un enlace a la documentación del proyecto Apache Ignite y al mismo tiempo un reproche por la vaguedad de esta documentación. Lo releo un par de veces, no llega la claridad. Me refiero al tutorial oficial. Que
promete con optimismo "¡Estarás listo y funcionando en un santiamén!" Estoy averiguando la configuración de las variables de entorno y viendo dos videos de Apache Ignite Essentials, pero no fueron muy útiles para mi tarea específica. Ejecuto Ignite con éxito desde la línea de comando con el archivo estándar "example-ignite.xml", creando la primera aplicación. usando Maven. La aplicación funciona y utiliza Zero Deployment, ¡qué belleza!
Leí más, y allí el ejemplo usa inmediatamente affinityKey (creado anteriormente a través de una consulta SQL), e incluso usa el misterioso BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Leer : formato binario: algo así como una reflexión, acceder a los campos de un objeto por su nombre. Puede leer el valor de un campo sin deserializar completamente el objeto (ahorrando memoria). Pero, ¿por qué se usa BinaryObject en lugar de Person, ya que hay Zero Deployment? Por qué IgniteCache transferido a IgniteCache ? No está claro todavía.
Estoy rehaciendo la aplicación informática para adaptarla a mi caso. La clave primaria del directorio de puntos de venta en MSSQL se define como [id] [int] NOT NULL, creo un caché por analogía
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")En la configuración xml indico que el caché está particionado
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>La partición por punto de venta supone que el agregado requerido se creará en cada nodo del clúster para los registros salesPointCache disponibles allí, después de lo cual el nodo cliente realizará la suma final.
estoy leyendo el tutorial , lo hago por analogía. En cada nodo del clúster ejecuto IgniteRunnable(), algo como esto:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Agrego lógica de agregación y carga y la ejecuto en un conjunto de datos de prueba. Todo funciona localmente en el servidor de desarrollo.
Ejecuto dos servidores de prueba CentOs, especifico las direcciones IP en default-config.xml, ejecuto en cada uno
./bin/ignite.sh config/default-config.xmlAmbos nodos de Ignite se están ejecutando y pueden verse entre sí. Especifico las direcciones requeridas en la configuración xml de la aplicación cliente, se inicia, agrega un tercer nodo a la topología e inmediatamente hay dos nodos nuevamente. El registro muestra "ClassNotFoundException: model.SalesPoint" en la línea
SalesPoint sp=salesPointCache.get(spId);StackOverflow dice que el motivo del error es que no hay una clase SalesPoint personalizada en los servidores CentOs. Hemos llegado. ¿Qué tal "no es necesario implementar manualmente el código Java en cada nodo", etc.? ¿O “su código Java” no se trata de SalesPoint?
Probablemente me perdí algo: empiezo a buscar de nuevo, a leer y a buscar de nuevo. Después de un tiempo tengo la sensación de que he leído todo sobre el tema, ya no hay nada nuevo. Mientras buscaba encontré algunos comentarios interesantes.
, arquitecto principal de GridGain Systems, en 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.Otra opinión autorizada: , Director de gestión de productos, GridGain Systems.
Artículo sobre Habré hace referencia a tres artículos de Denis Magda: , , 2016-2017. En el segundo artículo, Denis sugiere iniciar un nodo del clúster a través de MaintenanceServiceNodeStartup.jar. También puede usar el inicio con la configuración xml y la línea de comando, pero luego debe colocar manualmente clases personalizadas en cada nodo del clúster implementado:
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 hecho, eso es todo. ¡Aquí resulta, por qué, este misterioso formato binario!
3.Un solo frasco
Denis ocupó el primer lugar en mi calificación personal, en mi humilde opinión, el tutorial más útil de todos los disponibles. En su Github contiene un ejemplo completamente listo para configurar nodos de clúster, que se compila sin ninguna ocupación adicional.
Lo hago de la misma manera y obtengo un único archivo jar que inicia el "nodo de datos" o el "nodo cliente" según el argumento de la línea de comando. El montaje comienza y funciona. El Despliegue Cero ha sido derrotado.
La transición de megabytes de datos de prueba a decenas de gigabytes de datos de combate demostró que el formato binario existe por una razón. Era necesario optimizar el consumo de memoria en los nodos, y aquí es donde BinaryObject resultó muy útil.
4. Conclusiones
El primer reproche recibido sobre la vaguedad de la documentación del proyecto Apache Ignite resultó ser justo: poco ha cambiado desde 2016. No es fácil para un principiante ensamblar un prototipo funcional basado en un sitio web y/o repositorio.
Según los resultados del trabajo realizado, la impresión fue que Zero Deployment funciona, pero sólo a nivel del sistema. Algo como esto: BinaryObject se utiliza para enseñar a los nodos del clúster remoto a trabajar con clases personalizadas; Despliegue cero: mecanismo interno
Apache Ignite distribuye objetos del sistema por todo el clúster.
Espero que mi experiencia sea útil para los nuevos usuarios de Apache Ignite.
Fuente: habr.com