Menü

In-Memory Data Grid: Hazelcast 3.9 bietet optimiertes Caching

Mit erweiterten Konfigurations- und Caching-Optionen verspricht Hazelcast mehr Leistung, Skalierbarkeit und eine verbesserte Bedienung.

Lesezeit: 1 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen
Von

Um die Leistungsfähigkeit und die Geschwindigkeit des In-Memory Data Grid zu verbessern, bietet Hazelcast 3.9 eine erweiterte Near-Cache-Konfiguration. Während der lokale Zwischenspeicher bisher nur für Java Clients zur Verfügung stand, lässt sich Near Cache in der neuen Version auch für Clients mit Scala, .NET/C#, C++, Python sowie Node.js einbinden. Zu einer deutlich verringerten Latenz des Speichers soll außerdem die neue Möglichkeit beitragen, Near Cache Keys nicht mehr nur in seriellen BLOBs abzulegen, sondern bei Bedarf auch nicht serielle Objekte als Schlüssel zu verwenden. Near-Cache-Zugriffe sollen dadurch binnen Nanosekunden erfolgen. Geschwindigkeitsvorteile bei Abfragen sollen sich zudem dadurch ergeben, dass HD IMap in Hazelcast 3.9 Indizes grundsätzlich in High-Density Memory ablegt.

Mit der Option Datenstrukturen auch dynamisch konfigurieren zu können, greift Hazelcast einen lang gehegten Wunsch der Community auf. In früheren Versionen mussten sämtliche Konfigurationen im Vorfeld erfolgen. Nun lässt sich beispielsweise eine neue IMap-Konfiguration auch in einen laufenden Cluster einspielen. Die Verteilung auf alle Cluster-Mitglieder erfolgt anschließend automatisch.

Die dritte wichtige Neuerung in Hazelcast 3.9 betrifft Lite Cluster-Mitglieder. Diese lassen sich sowohl als Computational Nodes oder auch als Alternative zu Clients nutzen. Künftig können Lite Cluster-Mitglieder auch nachträglich noch in vollwertige Cluster-Mitglieder überführt werden – beispielsweise wenn eine Anwendung gestartet wird, Anwender die Datenmigration aber erst nach der vollständigen Initialisierung der Anwendung vollziehen möchten.

Ein Upgrade von 3.8-Clustern auf die neue Version Hazelcast 3.9 ist erstmals ohne Ausfallzeiten möglich, nachdem die dafür erforderliche Infrastruktur für Rolling Upgrades auf neue Minor Releases bereits in Version 3.8 umgesetzt wurde. (map)