En mai, une nouvelle version d'
Apache Ignite est sortie - 2.5. De nombreuses modifications y ont été apportées, dont la liste complète se trouve dans les notes de version. Et dans cet article, nous examinerons les innovations clés qui méritent une attention particulière.
Apache Ignite est une plate-forme évolutive horizontale pour le stockage transactionnel de données, ainsi que l'informatique distribuée au-dessus de ces données en mode quasi-temps réel.
Ignite est utilisé lorsqu'une évolutivité horizontale et une vitesse de traitement des données très élevée sont nécessaires. Ce dernier est également atteint en optimisant la plate-forme de stockage des données directement dans la RAM en tant que stockage principal, plutôt qu'en cache (In-Memory Computing). Les caractéristiques distinctives du produit sont un moteur de requête à part entière ANSI SQL 1999, un stockage sur disque, une RAM en expansion, un grand nombre d'outils d'intégration intégrés et un apprentissage automatique Zero-ETL.
Parmi les sociétés qui utilisent Apache Ignite figurent des sociétés telles que
Veon / Beeline ,
Sberbank, Huawei, Barclays, Citi, Microsoft et bien d'autres .
Nouvelle option de topologie: l'étoile autour de ZooKeeper
L'un des changements majeurs de la version 2.5 est une nouvelle version de la topologie. Auparavant, Ignite ne disposait que d'une topologie en «anneau», qui était utilisée pour échanger des événements au sein d'un cluster et offrait une évolutivité efficace et rapide, sur une échelle allant jusqu'à 300 nœuds.
La nouvelle topologie est conçue pour des installations de plusieurs centaines et milliers de nœuds.
Vous pouvez maintenant choisir: utilisez l'ancienne topologie, où Ignite vous suffit, ou - pour les grands clusters -
complétez le grand Ignite avec un petit ZooKeeper à travers lequel l'échange d'événements aura lieu.
Pourquoi cela et comment cela aide-t-il?
Le gros «anneau» a un inconvénient: compte tenu de l'échange et du traitement du réseau, la notification de tous les nœuds d'un nouvel événement peut atteindre quelques secondes. C'est mauvais en soi, et si vous tenez compte du fait que la probabilité d'une défaillance de nœud en raison d'une défaillance temporaire du réseau, de l'équipement ou d'autres problèmes augmente avec la taille du cluster, alors la reconstruction de la topologie devient une tâche tout à fait ordinaire, en particulier sur les clusters construits sur du matériel bon marché (marchandise). Dans le grand «anneau», cela introduit un chaos supplémentaire, interrompt le traitement du flux d'événements et l'oblige à recommencer, transmettant simultanément des informations sur la nouvelle topologie.
La nouvelle «étoile», où le cluster ZooKeeper est situé au centre, permet non seulement de maintenir l'évolutivité (ZooKeeper peut également croître horizontalement), mais même d'augmenter considérablement son évolutivité - l'efficacité sur de gros volumes. Après tout, en partageant la responsabilité du traitement des événements et de l'utilisation des données, nous pouvons allouer un cluster ZooKeeper beaucoup plus compact pour le traitement des événements, réduisant ainsi la dépendance des événements à la taille du cluster.
Cela n'affecte pas l'échange de données entre les nœuds Ignite, par exemple lors du rééquilibrage, ainsi que le stockage ou la récupération des données, car toutes ces opérations ont fait le tour de la topologie de l'événement via des connexions directes entre les nœuds du cluster.
De plus, l'ajout d'une nouvelle topologie n'affecte en rien l'ancienne - elle reste néanmoins recommandée, car elle est beaucoup plus facile à entretenir et plus légère, ne nécessite pas d'éléments supplémentaires.
Mais si vous avez atteint la limite de mise à l'échelle de «l'anneau» Ignite, vous ne pouvez pas vous lancer dans la microoptimisation et le piratage, n'appliquez pas de connaissances spécifiques et de «béquilles». Dans ce cas, vous disposez d'une solution officiellement disponible et prise en charge qui facilitera considérablement la mise en œuvre et la prise en charge d'un cluster aussi important.
Des informations détaillées sur la nouvelle topologie sont
disponibles dans la documentation .
Clients légers: client Java léger, authentification client léger
Dans la version 2.4, la prise en charge des clients légers en dehors de JDBC / ODBC, qui ne sont pas des participants à part entière de la topologie, est beaucoup moins gourmande en ressources, mais offre en même temps des fonctionnalités réduites. Le premier client léger était le client pour .NET.
À partir de la version 2.5, un client léger pour Java est également disponible.
Cela permet à Ignite d'être intégré dans des applications sensibles aux ressources, par exemple, dans des applications sur des terminaux, sans couches supplémentaires. Auparavant, cette tâche nécessitait une couche intermédiaire, qui, par exemple, via REST, recevait des demandes, puis utilisait le client interne «épais» pour échanger des données avec le cluster Ignite.
Le client léger peut être utilisé en connectant le fichier JAR ignite-core «à dépendance zéro» standard, par exemple, à partir du référentiel maven.
Un exemple d'utilisation d'un client léger:
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 (...) { ... }
Toujours dans la version 2.4, il n'y avait pas d'authentification pour les clients légers. À partir de la version 2.5, il, avec la prise en charge du chiffrement lors de l'accès aux clients légers, fera ses débuts dans Ignite.
ClientConfiguration clientCfg = new ClientConfiguration() .setAddresses("127.0.0.1:10800");
Des informations détaillées peuvent être
trouvées dans la documentation .
SQL: authentification et gestion des utilisateurs, chargement rapide en masse
Historiquement, le moteur SQL ANSI99 distribué a été l'une des forces et des caractéristiques distinctives importantes d'Apache Ignite. Il permet à une «fenêtre unique», via le client Java / .NET / C ++ ou via le pilote JDBC / ODBC, d'exécuter des requêtes SQL au-dessus de l'ensemble du cluster, à la fois en RAM et en Ignite Native Persistence.
Dans les versions 2.0 à 2.4, les développeurs se sont concentrés non seulement sur l'augmentation de la productivité (ce qui n'est jamais suffisant), mais aussi sur l'accélération du chargement des données primaires et en masse et une prise en charge plus complète de DDL, telles que les opérations CREATE TABLE, ALTER TABLE, CREATE INDEX, etc., qui également via une «fenêtre unique» pourrait être exécutée de manière cohérente sur le cluster.
Dans la version 2.5, une étape a été franchie vers le développement ultérieur de DDL: l'authentification pour SQL et les commandes correspondantes
CREATE USER ,
ALTER USER ,
DROP USER ont été ajoutées.
Si vous aviez précédemment prévu d'héberger Ignite SQL dans une zone démilitarisée stérile avec contrôle d'accès au niveau des services sus-jacents, vous pouvez désormais augmenter la sécurité avec l'authentification gérée par SQL.
En termes de vitesse de téléchargement de gros volumes de données, 2,5 innovations sont apparues en 2.
La première est la
nouvelle commande COPY SQL dans JDBC, qui vous permet de transférer rapidement, en mode groupé, le contenu d'un fichier CSV vers une table.
COPY FROM "/path/to/local/file.csv" INTO city ( ID, Name, CountryCode, District, Population) FORMAT CSV
Le second est le mode de streaming pour JDBC, activé via la
nouvelle commande SET . Il permet de charger des données via des opérations INSERT standard pour regrouper et charger de manière transparente de nouveaux enregistrements dans le cluster Ignite. Le transfert des opérations accumulées vers le cluster se produit lors du remplissage d'un lot ou lors de la fermeture d'une connexion JDBC.
SET STREAMING ON
Apprentissage automatique: algorithmes génétiques, partitionnement
L'apprentissage automatique est l'un des domaines stratégiques de développement d'Ignite. ML implémente le paradigme Zero-ETL, qui permet de s'entraîner directement sur les données qui se trouvent dans le stockage transactionnel Ignite. Ainsi, des économies de temps et de ressources importantes sont réalisées sur la conversion des données et le transfert du réseau vers un système de formation.
Dans la version 2.5,
des algorithmes génétiques sont ajoutés à l'ensemble d'outils accessibles.
De plus, pour optimiser le processus d'apprentissage et minimiser les échanges réseau, un support est apparu pour les calculs ML, qui contiennent des informations sur les partitions sur lesquelles ils sont exécutés et sont capables de lier des informations supplémentaires à ces partitions. Étant donné que les partitions sont atomiques en termes de distribution, et qu'une partition ne peut pas être coupée entre plusieurs nœuds, cela vous permet d'optimiser le processus d'apprentissage, offrant plus de garanties à l'algorithme.
Des informations détaillées peuvent être
trouvées dans la documentation .
Et bien plus
Toujours dans la version 2.5, il est implémenté: