Enterprise Platform
Verteiltes Caching
Verlagern Sie häufig genutzte Daten und leseintensive Workloads in eine verteilte In-Memory-Ebene, die Anwendungen mit einer Latenz von unter einer Millisekunde und hohem Durchsatz versorgt, ohne dass Änderungen am Anwendungscode für das Abfrage-Caching erforderlich sind.
Geschwindigkeit ohne Neugestaltung der Architektur
Die verteilte In-Memory-Cache-Ebene befindet sich zwischen Ihren Anwendungen und dem zentralen Transaktionsverarbeitungssystem. Sie verschiebt häufig genutzte Daten in eine „Shared-Nothing“-Speicherebene, die horizontal skalierbar ist, und ermöglicht Lesevorgänge im Sub-Millisekunden-Bereich mit ANSI-SQL- und ACID-Garantien.
Vorteile
Warum verteiltes Caching?
Extrem niedrige Latenz, beliebig skalierbar
Datenzugriff im Sub-Millisekundenbereich in einem verteilten Cluster, der linear auf Millionen von Transaktionen pro Sekunde und Petabyte an Daten skaliert.
Hohe Verfügbarkeit für einen Betrieb rund um die Uhr
Bleiben Sie auch bei Ausfall eines Standorts verfügbar. Die geografisch verteilte Replikation von Rechenzentren läuft im Aktiv-Aktiv- oder Aktiv-Passiv-Modus, mit Rack-Erkennung und konfigurierbaren Sicherungskopien.
Entlastung des Kerns
Fangen Sie leseintensiven und repetitiven Verkehr vor dem Mainframe oder der Kern-Datenbank ab – das senkt MIPS- und Lizenzkosten, ohne das System of Record zu ändern.
Native Integration in MariaDB
Bei der Bereitstellung als Abfrageergebnis-Cache vor Ihrer „ MariaDB “-Datenbank sind keinerlei Codeänderungen erforderlich. Funktioniert mit jedem System of Record: Oracle, SQL Server oder Mainframe.
Funktionen
Gebaut für Live-Daten im Cache<br>
Horizontale Skalierbarkeit
Lineare Skalierung durch Partitionierung der Daten über den Cluster hinweg – mit automatischer Neuverteilung, sobald neue Knoten hinzukommen.
Hohe Konsistenz
Read-Through, Write-Through und Write-Behind sorgen dafür, dass der Schlüssel-Wert-Cache mit Ihrem System of Record synchron bleibt.
Multimodell mit ANSI-SQL
Ein Cluster enthält Schlüssel-Wert-Daten, relationale Daten, JSON-Daten und Vektordaten. Die Abfrage von Schlüssel-Wert- und relationalen Daten erfolgt über ANSI-SQL, sodass vorhandene Tools und Kenntnisse weiterhin genutzt werden können.
Unternehmensgerechter Betrieb
Ihr Ops-Team verwaltet eine Konsole. Führen Sie die Bereitstellung auf Kubernetes durch, überwachen Sie Cache-Cluster über MariaDB Enterprise Manager und stellen Sie die Verfügbarkeit durch Active-Active-Replikation sicher.
Ebenfalls enthalten:
Native Festplattenpersistenz
Schlüssel-Wert- und SQL-APIs
Semantischer Cache
Agenten-Gedächtnis
Wiederherstellung zu einem bestimmten Zeitpunkt
Bereitstellung eines Kubernetes-Operators
OpenTelemetry Observierbarkeit
VVerschlüsselung während der Übertragung und im Ruhezustand
Rollenbasierte Zugriffskontrolle und Audit-Protokollierung
Rollierende Upgrades ohne Ausfallzeit<br>
Suchen Sie nach den Preisen für „ Enterprise Platform “?
Empfohlene Ressourcen
Los geht’s
Jetzt mit MariaDB loslegen
Eine Echtzeit-Datenbankplattform, auf die Sie sich verlassen können – für alles, was Sie heute betreiben, und für alles, was Sie in Zukunft entwickeln werden.
Häufig gestellte Fragen
Der verteilte Cache von MariaDB ist eine In-Memory-Cache- und Compute-Schicht auf Basis von MariaDB GridGain. Er sitzt zwischen Ihren Anwendungen und den Systemen of Record und bedient heiße Daten in Sub-Millisekunden.
Die In-Memory-Architektur verteilt Daten über den Arbeitsspeicher vieler Server – so laufen Lesevorgänge und Berechnungen parallel. Werden Knoten hinzugefügt, werden die Daten automatisch neu verteilt, und Durchsatz und Kapazität skalieren linear.
Beide speichern Daten im Arbeitsspeicher. Redis ist ein Single-Thread-Key-Value-Datenspeicher, während der verteilte Cache von „ MariaDB “ multithreaded ist und ANSI-SQL, ACID-Transaktionen sowie eine festplattenbasierte Persistenz bietet.
Nein. Bei Verwendung als Abfrage-Cache mit dem intelligenten Proxy MaxScale fungiert er als transparente Schicht vor der MariaDB-Datenbank.
Ja. MariaDB Enterprise Manager erkennt die Cache-Cluster automatisch – zusammen mit MariaDB Server und MaxScale. Single Sign-on in GridGain Control Center ermöglicht eine tiefergehende Verwaltung einzelner Cluster.