Im Mai wurde eine neue Version von
Apache Ignite veröffentlicht - 2.5. Es wurden viele Änderungen vorgenommen, von denen eine vollständige Liste in den Versionshinweisen enthalten ist. In diesem Artikel werden wir wichtige Innovationen betrachten, die es wert sind, beachtet zu werden.
Apache Ignite ist eine horizontal skalierbare Plattform für die Transaktionsspeicherung von Daten sowie für das verteilte Rechnen über diese Daten im Echtzeitmodus.
Ignite wird verwendet, wenn horizontale Skalierbarkeit und eine sehr hohe Datenverarbeitungsgeschwindigkeit erforderlich sind. Letzteres wird auch erreicht, indem die Plattform zum Speichern von Daten direkt im RAM als Primärspeicher und nicht als Cache (In-Memory Computing) optimiert wird. Das Produkt zeichnet sich durch eine vollwertige Abfrage-Engine ANSI SQL 1999, Festplattenspeicher, RAM-Erweiterung, eine große Anzahl integrierter Integrationstools und maschinelles Zero-ETL-Lernen aus.
Zu den Unternehmen, die Apache Ignite verwenden, gehören Unternehmen wie
Veon / Beeline ,
Sberbank, Huawei, Barclays, Citi, Microsoft und viele andere .
Neue Topologieoption: Der Stern um ZooKeeper
Eine der wichtigsten Änderungen in Version 2.5 ist eine neue Version der Topologie. Bisher hatte Ignite nur eine "Ring" -Topologie, die zum Austausch von Ereignissen innerhalb eines Clusters verwendet wurde und eine effiziente und schnelle Skalierbarkeit auf einer Skala von bis zu 300 Knoten bot.
Die neue Topologie ist für Installationen von vielen Hunderttausenden von Knoten ausgelegt.
Jetzt können Sie wählen: Verwenden Sie die alte Topologie, in der Ignite für Sie ausreicht, oder
ergänzen Sie - für große Cluster -
die große Ignite mit einem kleinen ZooKeeper, über den der Austausch von Ereignissen stattfindet.
Warum ist das so und wie hilft es?
Der große „Ring“ hat einen Nachteil: Unter Berücksichtigung des Netzwerkaustauschs und der Netzwerkverarbeitung kann die Benachrichtigung aller Knoten über ein neues Ereignis Sekunden erreichen. Dies ist an sich schon schlecht. Wenn Sie berücksichtigen, dass die Wahrscheinlichkeit eines Knotenausfalls aufgrund eines vorübergehenden Netzwerkausfalls, von Geräten oder anderen Problemen mit der Clustergröße zunimmt, wird die Topologie-Rekonstruktion zu einer ganz normalen Aufgabe, insbesondere bei Clustern, die auf billiger (Standard-) Hardware basieren. Im großen "Ring" führt dies zu zusätzlichem Chaos, unterbricht die Verarbeitung des Ereignisflusses und zwingt ihn, erneut zu beginnen, wobei gleichzeitig Informationen über die neue Topologie übertragen werden.
Der neue „Stern“, in dem sich der ZooKeeper-Cluster in der Mitte befindet, ermöglicht nicht nur die Aufrechterhaltung der Skalierbarkeit (ZooKeeper kann auch horizontal wachsen), sondern erhöht sogar die Skalierbarkeit erheblich - Effizienz bei großen Volumina. Wenn wir die Verantwortung für die Verarbeitung von Ereignissen teilen und mit Daten arbeiten, können wir einen viel kompakteren ZooKeeper-Cluster für die Ereignisverarbeitung zuweisen, wodurch die Abhängigkeit von Ereignissen von der Clustergröße verringert wird.
Dies wirkt sich nicht auf den Datenaustausch zwischen Ignite-Knoten aus, z. B. während des Neuausgleichs, sowie auf das Speichern oder Abrufen von Daten, da alle diese Vorgänge die Ereignistopologie über direkte Verbindungen zwischen Clusterknoten umgehen.
Das Hinzufügen einer neuen Topologie wirkt sich in keiner Weise auf die alte aus - es wird weiterhin empfohlen, da es viel einfacher zu warten und leichter ist und keine zusätzlichen Elemente erfordert.
Wenn Sie jedoch die Grenze für die Skalierung des Ignite-Rings erreicht haben, können Sie sich nicht auf Mikrooptimierung und Hacking einlassen, wenden Sie kein spezifisches Wissen und keine „Krücken“ an. In diesem Fall verfügen Sie über eine offiziell verfügbare und unterstützte Lösung, die die Implementierung und Unterstützung eines so großen Clusters erheblich erleichtert.
Detaillierte Informationen zur neuen Topologie finden
Sie in der Dokumentation .
Thin Clients: Thin Java Client, Thin Client-Authentifizierung
In Version 2.4 wurde Unterstützung für Thin Clients außerhalb von JDBC / ODBC bereitgestellt, die keine vollwertigen Teilnehmer an der Topologie sind, viel weniger Ressourcen benötigen, aber gleichzeitig eine reduzierte Funktionalität bieten. Der erste Thin Client war der Client für .NET.
Ab Version 2.5 ist auch ein Thin Client für Java verfügbar.
Auf diese Weise kann Ignite in ressourcensensitive Anwendungen eingebettet werden, z. B. in Anwendungen auf Endgeräten, ohne zusätzliche Ebenen. Zuvor war für diese Aufgabe eine Zwischenschicht erforderlich, die beispielsweise über REST Anforderungen empfing und dann den internen "Thick" -Client zum Datenaustausch mit dem Ignite-Cluster verwendete.
Der Thin Client kann verwendet werden, indem die Standard-JAR-Core-JAR-Datei "Zero-Dependency" beispielsweise aus dem Maven-Repository verbunden wird.
Ein Beispiel für die Verwendung eines Thin Clients:
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 (...) { ... }
Auch in Version 2.4 gab es keine Authentifizierung für Thin Clients. Ab Version 2.5 wird es zusammen mit der Unterstützung der Verschlüsselung beim Zugriff auf Thin Clients in Ignite eingeführt.
ClientConfiguration clientCfg = new ClientConfiguration() .setAddresses("127.0.0.1:10800");
Detaillierte Informationen finden
Sie in der Dokumentation .
SQL: Authentifizierung und Benutzerverwaltung, schnelles Massenladen
Die verteilte ANSI99-SQL-Engine war in der Vergangenheit eine der Stärken und wichtigen Unterscheidungsmerkmale von Apache Ignite. Es ermöglicht einem „einzelnen Fenster“ über den Java / .NET / C ++ - Client oder über den JDBC / ODBC-Treiber, SQL-Abfragen über dem gesamten Cluster sowohl im RAM als auch in Ignite Native Persistence auszuführen.
In den Versionen 2.0–2.4 konzentrierten sich die Entwickler nicht nur auf die Steigerung der Produktivität (was nie ausreicht), sondern auch auf die Beschleunigung des Ladens von Primär- und Massendaten und die umfassendere Unterstützung von DDL, z. B. Vorgänge wie CREATE TABLE, ALTER TABLE, CREATE INDEX usw. die auch durch ein "einzelnes Fenster" konsistent auf dem Cluster ausgeführt werden könnte.
In Version 2.5 wurde ein Schritt zur Weiterentwicklung von DDL unternommen: Die Authentifizierung für SQL und die entsprechenden Befehle
CREATE USER ,
ALTER USER ,
DROP USER wurden hinzugefügt.
Wenn Sie zuvor geplant hatten, Ignite SQL in einer sterilen DMZ mit Zugriffskontrolle auf der Ebene der darüber liegenden Dienste zu hosten, können Sie jetzt die Sicherheit mit der von SQL verwalteten Authentifizierung erhöhen.
In Bezug auf die Download-Geschwindigkeit großer Datenmengen erschienen 2,5 Innovationen in 2.
Der erste ist der
neue Befehl COPY SQL in JDBC, mit dem Sie den Inhalt einer CSV-Datei im Massenmodus schnell in eine Tabelle übertragen können.
COPY FROM "/path/to/local/file.csv" INTO city ( ID, Name, CountryCode, District, Population) FORMAT CSV
Der zweite ist der Streaming-Modus für JDBC, der über den
neuen SET-Befehl aktiviert wird. Es ermöglicht das Laden von Daten über Standard-INSERT-Vorgänge, um neue Datensätze transparent zu gruppieren und optimal in den Ignite-Cluster zu laden. Die Übertragung akkumulierter Vorgänge an den Cluster erfolgt beim Ausfüllen eines Stapels oder beim Schließen einer JDBC-Verbindung.
SET STREAMING ON
Maschinelles Lernen: Genetische Algorithmen, Partitionierung
Maschinelles Lernen ist einer der strategischen Entwicklungsbereiche von Ignite. ML implementiert das Zero-ETL-Paradigma, mit dem direkt auf die Daten trainiert werden kann, die im Transaktionsspeicher von Ignite liegen. Dadurch werden erhebliche Zeit- und Ressourceneinsparungen bei der Datenkonvertierung und der Netzwerkübertragung in ein Trainingssystem erzielt.
In Version 2.5 werden
genetische Algorithmen zu den verfügbaren Tools hinzugefügt.
Um den Lernprozess zu optimieren und den Netzwerkaustausch zu minimieren, wurden ML-Berechnungen unterstützt, die Informationen zu den Partitionen enthalten, auf denen sie ausgeführt werden, und zusätzliche Informationen an diese Partitionen binden können. Da Partitionen in Bezug auf die Verteilung atomar sind und eine Partition nicht zwischen mehreren Knoten aufgeteilt werden kann, können Sie den Lernprozess optimieren und dem Algorithmus mehr Garantien geben.
Detaillierte Informationen finden
Sie in der Dokumentation .
Und vieles mehr
Auch in Version 2.5 ist es implementiert: