En mayo,
se lanzó una nueva versión de
Apache Ignite : 2.5. Se han realizado muchos cambios, una lista completa de las cuales se puede encontrar en las Notas de la versión. Y en este artículo consideraremos innovaciones clave a las que vale la pena prestarles atención.
Apache Ignite es una plataforma escalable horizontalmente para el almacenamiento transaccional de datos, así como la computación distribuida sobre estos datos en modo casi en tiempo real.
Ignite se usa cuando se necesita escalabilidad horizontal y una velocidad de procesamiento de datos muy alta. Esto último también se logra mediante la optimización de la plataforma para almacenar datos directamente en la RAM como almacenamiento primario, en lugar de un caché (Computación en memoria). Las características distintivas del producto son un motor de consulta ANSI SQL 1999 completo, almacenamiento en disco, RAM en expansión, una gran cantidad de herramientas de integración integradas y aprendizaje automático Zero-ETL.
Entre las compañías que usan Apache Ignite se encuentran compañías como
Veon / Beeline ,
Sberbank, Huawei, Barclays, Citi, Microsoft y muchas otras .
Nueva opción de topología: The Star Around ZooKeeper
Uno de los principales cambios en la versión 2.5 es una nueva versión de la topología. Anteriormente, Ignite solo tenía una topología de "anillo", que se usaba para intercambiar eventos dentro de un clúster y proporcionaba una escalabilidad eficiente y rápida, en una escala de hasta 300 nodos.
La nueva topología está diseñada para instalaciones de muchos cientos y miles de nodos.
Ahora puede elegir: usar la topología anterior, donde Ignite es suficiente para usted o, para grupos grandes,
complementar el Ignite grande con un pequeño ZooKeeper a través del cual se realizará el intercambio de eventos.
¿Por qué es esto y cómo ayuda?
El gran "anillo" tiene un inconveniente: teniendo en cuenta el intercambio y el procesamiento de la red, la notificación de todos los nodos sobre un nuevo evento puede llegar a segundos. Esto en sí mismo es malo, y si tiene en cuenta que la probabilidad de una falla de nodo debido a una falla temporal de la red, el equipo u otros problemas aumenta con el tamaño del clúster, la reconstrucción de la topología se convierte en una tarea bastante normal, especialmente en clústeres construidos en hardware barato (de consumo). En el gran "anillo", esto introduce un caos adicional, interrumpe el procesamiento del flujo de eventos y lo obliga a comenzar de nuevo, transmitiendo simultáneamente información sobre la nueva topología.
La nueva "estrella", donde el clúster ZooKeeper se encuentra en el centro, permite no solo mantener la escalabilidad (ZooKeeper también puede crecer horizontalmente), sino que incluso aumenta significativamente su escalabilidad: eficiencia en grandes volúmenes. Después de todo, compartiendo la responsabilidad de procesar eventos y trabajando con datos, podemos asignar un clúster ZooKeeper mucho más compacto para el procesamiento de eventos, reduciendo así la dependencia de los eventos en el tamaño del clúster.
Esto no afecta el intercambio de datos entre nodos Ignite, por ejemplo, durante el reequilibrio, así como el almacenamiento o la recuperación de datos, porque todas estas operaciones fueron y van alrededor de la topología del evento a través de conexiones directas entre nodos del clúster.
Además, agregar una nueva topología no afecta de ninguna manera a la anterior; sigue siendo recomendable, ya que es mucho más fácil de mantener y más ligero, no requiere elementos adicionales.
Pero si ha alcanzado el límite de escalar el "anillo" de Ignite, no puede participar en la microoptimización y la piratería, no aplique conocimientos y "muletas" específicos. En este caso, tiene una solución oficialmente disponible y compatible que facilitará significativamente la implementación y el soporte de un clúster tan grande.
Se puede
encontrar información detallada sobre la nueva topología
en la documentación .
Thin Clients: Thin Java Client, Thin Client Authentication
En la versión 2.4, se proporcionó soporte para clientes ligeros fuera de JDBC / ODBC, que no son participantes de pleno derecho en la topología, requieren mucho menos recursos, pero al mismo tiempo ofrecen una funcionalidad reducida. El primer cliente ligero fue el cliente para .NET.
A partir de la versión 2.5, también está disponible un cliente ligero para Java.
Esto permite que Ignite se incruste en aplicaciones sensibles a los recursos, por ejemplo, en aplicaciones en dispositivos terminales, sin capas adicionales. Anteriormente, esta tarea requería una capa intermedia, que, por ejemplo, a través de REST, recibía solicitudes y luego usaba el cliente interno "grueso" para intercambiar datos con el clúster Ignite.
El Thin Client se puede utilizar conectando el archivo JAR estándar de ignite-core "de dependencia cero", por ejemplo, desde el repositorio maven.
Un ejemplo de uso de un cliente ligero:
ClientConfiguration cfg = new ClientConfiguration().setAddresses("127.0.0.1:10800"); try (IgniteClient igniteClient = Ignition.startClient(cfg)) { System.out.println(">>> ."); final String CACHE_NAME = "put-get-example"; ClientCache<Integer, Address> cache = igniteClient.getOrCreateCache(CACHE_NAME); System.out.format(">>> [%s].\n", CACHE_NAME); Integer key = 1; Address val = new Address(", 20", 101000); cache.put(key, val); System.out.format(">>> [%s] .\n", val); Address cachedVal = cache.get(key); System.out.format(">>> [%s] .\n", cachedVal); } catch (...) { ... }
También en la versión 2.4 no había autenticación para clientes ligeros. A partir de la versión 2.5, se lanzará en Ignite, junto con la compatibilidad con el cifrado al acceder a clientes ligeros.
ClientConfiguration clientCfg = new ClientConfiguration() .setAddresses("127.0.0.1:10800");
Se puede
encontrar información detallada
en la documentación .
SQL: autenticación y gestión de usuarios, carga masiva rápida
El motor distribuido ANSI99 SQL ha sido históricamente una de las fortalezas e importantes características distintivas de Apache Ignite. Permite una "ventana única", a través del cliente Java / .NET / C ++ o mediante el controlador JDBC / ODBC, para ejecutar consultas SQL en la parte superior de todo el clúster, tanto en RAM como en Ignite Native Persistence.
En las versiones 2.0–2.4, los desarrolladores se centraron además de aumentar la productividad (que nunca es suficiente), también en acelerar la carga de datos primarios y masivos y un soporte más completo para DDL, operaciones como CREATE TABLE, ALTER TABLE, CREATE INDEX, etc. que también a través de una "ventana única" podría ejecutarse consistentemente en el clúster.
En la versión 2.5, se dio un paso hacia el desarrollo posterior de DDL:
se agregaron la autenticación para SQL y los comandos correspondientes
CREAR USUARIO ,
ALTERAR USUARIO ,
DROP USER .
Si anteriormente planeaba alojar Ignite SQL en una DMZ estéril con control de acceso a nivel de servicios suprayacentes, ahora puede aumentar la seguridad con la autenticación administrada por SQL.
En términos de velocidad de descarga de grandes volúmenes de datos, 2.5 innovaciones aparecieron en 2.
El primero es el
nuevo comando COPY SQL en JDBC, que le permite transferir rápidamente, en modo masivo, el contenido de un archivo CSV a una tabla.
COPY FROM "/path/to/local/file.csv" INTO city ( ID, Name, CountryCode, District, Population) FORMAT CSV
El segundo es el modo de transmisión para JDBC, habilitado a través del
nuevo comando SET . Permite cargar datos a través de operaciones INSERT estándar para agrupar de forma transparente y cargar de manera óptima nuevos registros en el clúster Ignite. La transferencia de operaciones acumuladas al clúster se produce al completar un lote o al cerrar una conexión JDBC.
SET STREAMING ON
Aprendizaje automático: algoritmos genéticos, particionamiento
El aprendizaje automático es una de las áreas estratégicas de desarrollo de Ignite. ML implementa el paradigma Zero-ETL, que permite la capacitación directamente sobre los datos que se encuentran en el almacenamiento transaccional Ignite. De este modo, se logran ahorros significativos de tiempo y recursos en la conversión de datos y la transferencia de red a un sistema de capacitación.
En la versión 2.5,
los algoritmos genéticos se agregan al conjunto de herramientas accesibles.
Además, para optimizar el proceso de aprendizaje y minimizar el intercambio de redes, ha aparecido soporte para cálculos ML, que tienen información sobre las particiones en las que se ejecutan y pueden vincular información adicional a estas particiones. Dado que las particiones son atómicas en términos de distribución, y una partición no se puede cortar entre varios nodos, esto le permite optimizar el proceso de aprendizaje, proporcionando más garantías para el algoritmo.
Se puede
encontrar información detallada
en la documentación .
Y mucho mas
También en la versión 2.5 se implementa: