GeminiDB (for Cassandra) ist eine Cloud-native NoSQL-Datenbank, die mit Cassandra kompatibel ist. Sie unterstützt die Cassandra Query Language (CQL), die eine SQL-ähnliche Syntax bietet. GeminiDB (for Cassandra) ist sicher, zuverlässig, skalierbar und einfach zu verwalten. GeminiDB (for Cassandra) bietet eine herausragende Lese-/Schreibleistung und unterstützt die Cassandra 3.11 DB-Engine.
Ein mehrschichtiges Sicherheitssystem, einschließlich VPC, Subnetz, Sicherheitsgruppe, SSL und fein abgestufter Berechtigungskontrolle, gewährleistet die Sicherheit der Datenbank und die Privatsphäre der Benutzer. Sie können eine Instanz über drei Verfügbarkeitszonen (AZs) bereitstellen und Daten schnell sichern oder wiederherstellen, um die Datenzuverlässigkeit zu verbessern. Die verteilte Architektur bietet eine herausragende Ausfallsicherheit (N-1-Zuverlässigkeit).
GeminiDB (for Cassandra) bietet Ihnen eine Leistung, die dreimal so hoch ist wie die der Open-Source-Version. Daten können rund um die Uhr in diese hochverfügbare Datenbank geschrieben werden und mit automatischem Load Balancing und flexibler Skalierung verfügen Sie immer über die Leistung, die Sie benötigen.
Dank der Entkopplung von Rechen- und Speicherkapazität können Sie innerhalb von Minuten Rechenknoten hinzufügen und die Speicherkapazität innerhalb von Sekunden ohne Serviceunterbrechungen erhöhen. Die Rechencluster bestehen aus mehreren homogenen Knoten und die Daten werden in einem verteilten, gemeinsamen Speicherpool gespeichert. Rechen- und Speicherressourcen sind voneinander entkoppelt, sodass sie flexibel skaliert werden können, ohne Daten migrieren zu müssen.
GeminiDB (for Cassandra) ist eine verteilte Datenbank mit entkoppelter Speicher- und Rechenarchitektur. Ein Rechencluster kann aus mehreren homogenen Knoten bestehen, und die Daten werden in einem verteilten, gemeinsamen Speicherpool gespeichert. Sie können Rechen- und Speicherressourcen flexibel skalieren, ohne Daten migrieren zu müssen.
Backups werden in Object Storage Service (OBS)-Buckets gespeichert. Das ermöglicht zum einen die Bereitstellung von Disaster-Recovery-Funktionen und zum anderen das Einsparen von Speicherplatz. Bei der Erstellung einer DB-Instanz wird die automatische Backup-Richtlinie standardmäßig aktiviert. Nach Abschluss der Erstellung wird sofort eine automatisches Voll-Backup erstellt. Die Standard-Aufbewahrungsfrist für Backups beträgt 7 Tage. Sie können die Aufbewahrungsfrist für Backups anpassen und die Backup-Richtlinie ändern. Darüber hinaus können Sie jederzeit gemäß Ihren Serviceanforderungen ein Backup initiieren. Manuelle Backups werden gespeichert, bis Sie sie manuell löschen.
GeminiDB (for Cassandra) verwendet Virtual Private Clouds (VPCs) und Netzwerksicherheitsgruppen, um DB-Instanzen isoliert zu halten. VPCs ermöglichen es Ihnen, festzulegen, welche IP-Adressen auf eine bestimmte Datenbank zugreifen dürfen. Der Einsatz einer DB-Instanz in einer VPC erhöht die Sicherheit. Um die Sicherheit der Datenbank weiter zu verbessern, können Sie Subnetze und Sicherheitsgruppen konfigurieren, um den Zugriff auf DB-Instanzen zu steuern.
VPC-Sicherheitsgruppen können mit Regeln konfiguriert werden, um den Datenverkehr zu und von DB-Instanzen zu kontrollieren.
GeminiDB (for Cassandra) reduziert die Time-to-Market. Relationale Datenbanken können in wenigen Minuten eingerichtet und genutzt werden, ohne dass hierfür dedizierte DB-Instanzen oder -Server bereitgestellt werden müssen.
- VPCs isolieren Ressourcen und steuern den Zugriff
- SSL-Verbindungen gewährleisten Datensicherheit und -integrität
- Regeln für Sicherheitsgruppen steuern den Datenverkehr zu und von spezifischen IP-Adressen und Ports und schützen Verbindungen zwischen GeminiDB (for Cassandra) und anderen Diensten
GeminiDB (for Cassandra) überwacht die Leistung der Instanz und reduziert 60 % der Betriebs- und Wartungsaktivitäten. Es liefert Echtzeitüberwachungsinformationen über CPU-Auslastung, Festplattennutzung, IOPS und Anzahl aktiver Verbindungen, sodass Sie den Instanzstatus jederzeit überprüfen können.
Flavor | vCPUs | Speicher (GB) | Max. Speicherplatz (GB) |
geminidb.cassandra.xlarge.arm.8 | 4 | 32 | 24.000 |
geminidb.cassandra.2xlarge.arm.8 | 8 | 64 | 48.000 |
geminidb.cassandra.4xlarge.arm.8 | 16 | 128 | 96.000 |
geminidb.cassandra.8xlarge.arm.8 | 32 | 256 | 192.000 |
geminidb.cassandra.15xlarge.arm.8 | 60 | 480 | 360.000 |
Kompatible API | Instanztyp | Version |
Cassandra | Cluster | 3.11 |
Elastic Cloud Server (ECS) stellt GeminiDB (for Cassandra) elastische Rechenressourcen zur Verfügung. GeminiDB (for Cassandra) muss Ressourcen beim ECS anfordern, um eine Betriebsumgebung für DB-Instanzen aufzubauen.
Backups werden in Object Storage Service (OBS)-Buckets gespeichert, die über Wiederherstellungsfunktionen verfügen und Speicherplatz sparen.
GeminiDB (für Cassandra) verwendet Virtual Private Clouds (VPCs) und Netzwerksicherheitsgruppen, um DB-Instanzen isoliert zu halten. VPCs ermöglichen es Ihnen, festzulegen, welche IP-Adressen auf eine bestimmte Datenbank zugreifen dürfen. Durch das Ausführen einer DB-Instanz in einem VPC verbessert sich die Sicherheit.
Cloud Eye fungiert als offene Überwachungsplattform und überwacht GeminiDB (for Cassandra)-Ressourcen für Sie. Es meldet Alarme und gibt rechtzeitig Warnungen aus, um sicherzustellen, dass die Dienste ordnungsgemäß ausgeführt werden.
GeminiDB (for Cassandra) bietet eine hervorragende Lese- und Schreibleistung sowie Flexibilität und Ausfallsicherheit, sodass Websites die Produktkataloge, Empfehlungen, Personalisierungs-Engines und Transaktionsdatensätze bereitstellen, problemlos mit hoher Gleichzeitigkeit umgehen und eine geringe Latenz gewährleisten können.
Vorteile
- Groß angelegte Cluster: Jedes Cluster kann bis zu 200 Knoten umfassen und unterstützt schreibintensive Internetanwendungen bei der Verarbeitung großer Datenmengen.
- Hohe Verfügbarkeit und Skalierbarkeit: Das Ausfallen eines Knotens beeinträchtigt nicht die Verfügbarkeit des gesamten Clusters. Rechenressourcen und Speicherplatz können schnell und mit minimalen Serviceunterbrechungen skaliert werden.
- Schreibvorgänge mit hoher Gleichzeitigkeit: Die hohe Schreibleistung hilft Ihnen dabei, eine große Anzahl von gleichzeitigen E-Commerce-Transaktionen zu bewältigen.
GeminiDB (for Cassandra) ist vollständig kompatibel mit Cassandra und kann Ihnen daher helfen, Daten von verschiedenen Terminal-Arten zu erfassen, zu organisieren und zu speichern, sowie die Daten in Echtzeit zu verdichten und zu analysieren.
Vorteile
- Groß angelegte Cluster: Die groß angelegten Cluster eignen sich hervorragend für die Erfassung und Speicherung einer großen Anzahl von Produktionskennzahlen.
- Hohe Verfügbarkeit und Leistung: Daten können rund um die Uhr in diese Datenbank geschrieben werden.
- Schnelles Backup und Wiederherstellung: Snapshots ermöglichen ein schnelles Backup und eine ebenso schnelle Wiederherstellung.
- Skalierung in Minuten: Service- oder Projektspitzen können problemlos bewältigt werden.
Die Tabelle zeigt das Leistungsverhältnis von GeminiDB (for Cassandra) zu Open-Source-Cassandra (ECS mit Datenträgertyp: Ultra-high I/O)
Verwendete Hardware | Gleichzeitige Threads des Clients | Verwendete Daten | 95% Read und 5% Update | 50% Read und 50% Update | 65% Read, 25% Update und 10% Insert | 90% Insert und 10% Read |
8 vCPUs 32 GB | 64 | 100 GB | 8,62 | 8,60 | 4,19 | 5,67 |
16 vCPUs 64 GB | 128 | 200 GB | 8,31 | 3,47 | 3,05 | 4,28 |
32 vCPUs 128 GB | 1256 | 400 GB | 10,18 | 3,85 | 3,76 | 4,99 |
GeminiDB (for Cassandra) schneidet bei der Lese-Latenz zehnmal besser ab als das Open-Source-Cassandra-Cluster.
Das GeminiDB (for Cassandra)-Cluster bietet im Wesentlichen die gleiche Schreibleistung wie das Open-Source-Cluster.
Das Hinzufügen von Knoten beeinflusst sowohl das GeminiDB (for Cassandra)-Cluster als auch das Open-Source-Cluster geringfügig.
- Der Skalierungsprozess von GeminiDB (for Cassandra) ist schnell und beeinträchtigt den Service nur für kurze Zeit (10 Sekunden). Es sind keine Änderung von Parametern erforderlich, und der Skalierungsprozess dauert 10 Minuten.
- Für ein Open-Source-Cassandra-Cluster hängt die Dauer des Hinzufügens von Knoten von der Datenmenge und den Parametereinstellungen ab, und die Auswirkungen auf die Leistung variieren. In einem Testszenario dauerte die Skalierung mehr als 30 Minuten bei einer voreingestellten Datengröße von 50 GB.
- Wenn eine Instanz mehrere Knoten hat und jeder Knoten über 4 vCPUs verfügt, sollten auf jedem Knoten nicht mehr als 250 GB vorhanden sein. Die Transaktionen pro Sekunde (TPS) auf jedem Knoten dürfen 1000 nicht überschreiten.
- Wenn eine Instanz mehrere Knoten hat und jeder Knoten über 8 vCPUs verfügt, sollten auf jedem Knoten nicht mehr als 250 GB vorhanden sein. Die Transaktionen pro Sekunde (TPS) auf jedem Knoten dürfen 2500 nicht überschreiten.
- Wenn eine Instanz mehrere Knoten hat und jeder Knoten über 16 vCPUs verfügt, sollten auf jedem Knoten nicht mehr als 500 GB vorhanden sein. Die Transaktionen pro Sekunde (TPS) auf jedem Knoten dürfen 5000 nicht überschreiten.
- Wenn eine Instanz mehrere Knoten hat und jeder Knoten über 32 vCPUs verfügt, sollten auf jedem Knoten nicht mehr als 500 GB vorhanden sein. Die Transaktionen pro Sekunde (TPS) auf jedem Knoten dürfen 10000 nicht überschreiten.
Speichern Sie keine großen Daten wie Bilder und Dateien in diesen Datenbanken.
Die maximale Größe des Schlüssels und des Werts in einer einzelnen Zeile darf 64 KB nicht überschreiten, und die durchschnittliche Größe der Zeilen darf 10 KB nicht überschreiten.
Die Datenlöschungsrichtlinie muss bei der Gestaltung einer Tabelle berücksichtigt werden. Daten in einer Tabelle dürfen nicht unendlich anwachsen, ohne gelöscht zu werden.
Partitionsschlüssel können Workloads gleichmäßig verteilen, um Datenungleichgewichte zu vermeiden. Ein Partitionsschlüssel eines Primärschlüssels bestimmt eine logische Partition zum Speichern von Tabellendaten. Wenn Partitionsschlüssel nicht gleichmäßig verteilt sind, sind Daten und Last zwischen den Knoten unausgewogen, was zu einem Datenungleichgewicht führt.
Die Gestaltung der Partitionsschlüssel kann Zugriffsanfragen auf Daten gleichmäßig verteilen, um BigKey- oder HotKey-Probleme zu vermeiden.
- BigKey-Problem: Die Hauptursache für BigKey ist eine unsachgemäße Gestaltung des Primärschlüssels. Infolgedessen gibt es zu viele Datensätze oder zu viele Daten in einer einzelnen Partition. Sobald eine Partition extrem groß wird, erhöht sich der Zugriff darauf, belastet einen Server, auf dem sich die Partition befindet, und kann sogar zu einem Out-of-Memory (OOM)-Fehler führen.
- HotKey-Problem: Dieses Problem tritt auf, wenn ein Schlüssel in kurzer Zeit häufig verwendet wird. Zum Beispiel kann eine Breaking News zu einem Anstieg des Datenverkehrs und einer großen Anzahl von Anfragen führen. Infolgedessen steigen die CPU-Auslastung und die Last auf dem Knoten, auf dem sich der Schlüssel befindet, was sich auf andere Anfragen an den Knoten auswirkt und die Erfolgsquote der Dienste verringert. HotKey-Probleme treten auch bei der Bewerbung beliebter Produkte und bei Live-Streaming von Internetprominenten auf.
Die Anzahl der Zeilen eines einzelnen Partitionsschlüssels darf 100.000 nicht überschreiten, und der Festplattenspeicher einer einzelnen Partition darf 100 MB nicht überschreiten.
Die Größe der Datensätze unter einem einzelnen Partitionsschlüssel darf 100 MB nicht überschreiten.
Stellen Sie eine starke Konsistenz zwischen den in GeminiDB (for Cassandra) geschriebenen Datenkopien sicher, aber unterstützen Sie keine Transaktionen.
Konsistenzmodell | Konsistenz wird unterstützt | Beschreibung |
Konsistenz bei gleichzeitigem Schreiben | Ja | GeminiDB (for Cassandra) unterstützt keine Transaktionen und das Schreiben von Daten ist streng konsistent. |
Konsistenz zwischen Tabellen | Ja | GeminiDB (for Cassandra) unterstützt keine Transaktionen und das Schreiben von Daten ist streng konsistent. |
Konsistenz bei der Datenmigration | Konsistenz möglich | DRS bietet Funktionen zum Sammeln, Vergleichen und Überprüfen von Daten. Nach der Migration der Dienste wird automatisch eine Datenüberprüfung durchgeführt. |
Bei der Speicherung großer Datenmengen muss eine Datenbankaufteilung in Betracht gezogen werden. Stellen Sie sicher, dass die Anzahl der Knoten im GeminiDB (for Cassandra)-Cluster weniger als 100 beträgt. Wenn die Anzahl der Knoten 100 überschreitet, sollte der Cluster vertikal oder horizontal aufgeteilt werden.
Vertikale Aufteilung: Daten werden nach funktionalen Modulen aufgeteilt, z.B. Datenbank für Bestellungen, Datenbank für Produkte und Datenbank für Benutzer. In diesem Modus sind die Tabellenstrukturen mehrerer Datenbanken unterschiedlich.
Horizontale Aufteilung: Daten in derselben Tabelle werden in Blöcke aufgeteilt und in verschiedenen Datenbanken gespeichert. Die Tabellenstrukturen in diesen Datenbanken sind gleich.
Vermeiden Sie Tombstones, die durch großflächiges Löschen verursacht werden.
- Verwenden Sie nach Möglichkeit „Time to Live” (TTL) anstelle von „Delete“
- Löschen Sie keine großen Datenmengen. Löschen Sie Daten anhand des Primärschlüssel-Präfixes.
- Es können maximal 1.000 Zeilen gleichzeitig innerhalb eines Partitionsschlüssels gelöscht werden.
- Vermeiden Sie die Abfrage von gelöschten Daten während einer Bereichsabfrage.
- Löschen Sie nicht häufig Daten eines großen Bereichs in einer Partition.
Kontrollieren Sie den Umfang und die Menge der Datenbank. Es wird empfohlen, dass die Anzahl der Datensätze in einer einzelnen Tabelle nicht mehr als 100 Milliarden beträgt. Es wird zudem empfohlen, dass eine einzelne Datenbank nicht mehr als 100 Tabellen enthält. Die maximale Anzahl der Felder in einer einzelnen Tabelle sollte zwischen 20 und 50 liegen.
Schätzen Sie ab, wie viele Ressourcen GeminiDB (for Cassandra)-Server verarbeiten können. Wenn geschätzt wird, dass N Knoten verwendet werden müssen, wird empfohlen, zusätzliche N/2 Knoten hinzuzufügen, um eine Ausfallsicherheit und Leistungskonsistenz zu gewährleisten. In normalen Szenarien sollte die CPU-Auslastung jedes Knotens auf 50 % begrenzt werden, um Schwankungen während Spitzenzeiten zu vermeiden.
Führen Sie einen Testlauf basierend auf Service-Szenarien durch, um große Datenmengen zu speichern. Bei Service-Szenarien mit einer großen Anzahl von Anfragen und Datenvolumen ist es erforderlich, die Leistung im Voraus zu testen, da sich das Verhältnis von Lese- zu Schreibzugriffen, der Random Access Mode und die Instanzspezifikationen erheblich unterscheiden können.
Teilen Sie das Datenbankcluster angemessen in verschiedene Granularitätsstufen auf.
- In verteilten Szenarien können Microservices eines Dienstes ein GeminiDB (for Cassandra)-Cluster gemeinsam nutzen, um Ressourcen- und Wartungskosten zu reduzieren.
- Der Dienst kann je nach Datenrelevanz, Anzahl der Tabellen und Anzahl der Datensätze in einer einzelnen Tabelle in verschiedene Cluster aufgeteilt werden.
Vermeiden Sie das häufige Aktualisieren von Feldern in einem einzelnen Datensatz.
Wenn es zu viele verschachtelte Elemente wie Listen, Maps oder Sets gibt, wirkt sich dies negativ auf die Lese- und Schreibleistung aus. Konvertieren Sie in diesem Fall solche Elemente zur Speicherung in JSON-Dateien.
Neue Features
Mehr erfahren
