MarketplaceCommunityDEENDEENProdukteCore ServicesRoadmapRelease NotesLeistungsbeschreibungZertifikate und TestatePrivate CloudManaged ServicesVorteileSicherheit/DSGVONachhaltigkeitOpenStackMarktführerPreisePreismodelleComputing & ContainerSpeicherNetzwerkDatenbank & AnalyseSicherheitManagement & ApplikationPreisrechnerLösungenBranchenGesundheitswesenÖffentlicher SektorWissenschaft & ForschungAutomotiveMedienunternehmenEinzelhandelAnwendungsfälleKünstliche IntelligenzHigh Performance ComputingBig Data & AnalyticsInternet of ThingsDisaster RecoveryData StorageKomplettlösungenCloud-Lösungen TelekomCloud-Lösungen PartnerSwiss Open Telekom CloudReferenzkundenPartnerCIRCLE PartnerTECH PartnerPartner werdenAcademyTrainings & ZertifizierungenEssentials TrainingFundamentals TrainingPractitioner Online-TrainingArchitect TrainingZertifizierungenCommunityCommunity BlogsCommunity EventsBibliothekStudien und WhitepaperWebinareBusiness NavigatorMarketplaceSupportExperten-SupportKI-ChatbotShared ResponsibilityRichtlinien für Sicherheitstests (Penetrationstests)Open Telekom Cloud AppTools zur SelbsthilfeErste SchritteTutorialStatus DashboardFAQTechnische DokumentationNewsBlogMessen & EventsFachartikelPresseanfragenMarketplaceCommunity

0800 3304477 24 Stunden am Tag, 7 Tage die Woche

E-Mail schreiben

Jetzt starten und 250 € Startguthaben sichern
ProdukteCore ServicesPrivate CloudManaged ServicesVorteilePreisePreismodellePreisrechnerLösungenBranchenAnwendungsfälleKomplettlösungenSwiss Open Telekom CloudReferenzkundenPartnerCIRCLE PartnerTECH PartnerPartner werdenAcademyTrainings & ZertifizierungenCommunityBibliothekBusiness NavigatorMarketplaceSupportExperten-SupportTools zur SelbsthilfeTechnische DokumentationNewsBlogMessen & EventsFachartikelPresseanfragen
  • 0800 330447724 Stunden am Tag, 7 Tage die Woche
  • E-Mail schreiben
Jetzt starten und 250 € Startguthaben sichern

GeminiDB

GeminiDB 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 ist sicher, zuverlässig, skalierbar und einfach zu verwalten. GeminiDB bietet eine herausragende Lese-/Schreibleistung und unterstützt die Cassandra 3.11 DB-Engine.

Eine Frau und ein Mann vor einem Bildschirm, die Frau zeigt auf einen Monitor

Gründe für GeminiDB in der Open Telekom Cloud

Blaues Schild vor grauem Server-Icon.

Hohe Sicherheit und Zuverlässigkeit

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).

Icon mit Diagramm und Tacho

Herausragende Lese-/Schreibleistung

GeminiDB 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.

Icon mit Zahnrad und Pfeilen in jede Richtung

Flexible Skalierung

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.


Architektur

GeminiDB 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.

Grafik Architektur GaussDB NoSQL

Key Features von GeminiDB

Hände auf einer Tastatur die die Datensicherung symbolisieren.

Datensicherung

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.

 
Icon Netzwerk

Netzwerkisolierung

GeminiDB 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.

Icon Schloss

Zugriffskontrolle

VPC-Sicherheitsgruppen können mit Regeln konfiguriert werden, um den Datenverkehr zu und von DB-Instanzen zu kontrollieren.

Icon Schlüssel

Verschlüsselung

GeminiDB verwendet Secure Sockets Layer (SSL), um übertragene Daten zu verschlüsseln. Sie können das Root-CA-Zertifikat aus der Managementkonsole herunterladen und für die Authentifizierung beim Verbinden mit einer Datenbank hochladen.

Icon Zahnrad

Sicherheitssystem

GeminiDB 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 und anderen Diensten
Icon Diagramm

Leistungsüberwachung

GeminiDB ü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.

Icon mit Haken

Sofort einsatzbereit

Sie können eine DB-Instanz über die Managementkonsole erstellen und auf die Datenbank mit privaten Netzwerk-IP-Adressen zugreifen, um die Latenz zu reduzieren und die Kosten für die Nutzung eines öffentlichen Netzwerks zu vermeiden.

 

GeminiDB Instanz-Spezifikationen

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 APIs und Versionen

Kompatible API

Instanztyp

Version

Cassandra

Cluster

3.11

 
 

Vernetzte Dienste

Elastic Cloud Server (ECS)

Elastic Cloud Server (ECS) stellt GeminiDB elastische Rechenressourcen zur Verfügung. GeminiDB muss Ressourcen beim ECS anfordern, um eine Betriebsumgebung für DB-Instanzen aufzubauen.

Object Storage Service (OBS)

Backups werden in Object Storage Service (OBS)-Buckets gespeichert, die über Wiederherstellungsfunktionen verfügen und Speicherplatz sparen.

Virtual Private Cloud (VPC)

GeminiDB 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

Cloud Eye fungiert als offene Überwachungsplattform und überwacht GeminiDB-Ressourcen für Sie. Es meldet Alarme und gibt rechtzeitig Warnungen aus, um sicherzustellen, dass die Dienste ordnungsgemäß ausgeführt werden.

 
 

Anwendungsszenarien

Internet

GeminiDB 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.
Industrielle Datenerfassung

GeminiDB 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.
 

Performance

Die Tabelle zeigt das Leistungsverhältnis von GeminiDB 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

 

Testergebnisse

GeminiDB schneidet bei der Lese-Latenz zehnmal besser ab als das Open-Source-Cassandra-Cluster.

Das GeminiDB-Cluster bietet im Wesentlichen die gleiche Schreibleistung wie das Open-Source-Cluster.

Das Hinzufügen von Knoten beeinflusst sowohl das GeminiDB-Cluster als auch das Open-Source-Cluster geringfügig. 

  • Der Skalierungsprozess von GeminiDB 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.

Best Practices zur Auswahl der besten Konfiguration

  • 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.

 

Best Practice: Designregeln

Regeln

Regel 1

Speichern Sie keine großen Daten wie Bilder und Dateien in diesen Datenbanken.

Regel 2

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.

Regel 3

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.

Regel 4

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.

Regel 5

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.

Regel 6 

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.

Regel 7

Stellen Sie eine starke Konsistenz zwischen den in GeminiDB geschriebenen Datenkopien sicher, aber unterstützen Sie keine Transaktionen.

Konsistenzmodell

Konsistenz wird unterstützt

Beschreibung

Konsistenz bei gleichzeitigem Schreiben

Ja

GeminiDB unterstützt keine Transaktionen und das Schreiben von Daten ist streng konsistent.

Konsistenz zwischen Tabellen

Ja

GeminiDB 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.

Regel 8

Bei der Speicherung großer Datenmengen muss eine Datenbankaufteilung in Betracht gezogen werden. Stellen Sie sicher, dass die Anzahl der Knoten im GeminiDB-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.

Regel 9

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.
 

Best Practices: Design-Empfehlungen

Empfehlungen

Empfehlung 1

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.

Empfehlung 2

Schätzen Sie ab, wie viele Ressourcen GeminiDB-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.

Empfehlung 3

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.

Empfehlung 4

Teilen Sie das Datenbankcluster angemessen in verschiedene Granularitätsstufen auf. 

  • In verteilten Szenarien können Microservices eines Dienstes ein GeminiDB-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.

Empfehlung 5

Vermeiden Sie das häufige Aktualisieren von Feldern in einem einzelnen Datensatz.

Empfehlung 6

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

Der neue GaussDB (für Cassandra)-Service ist jetzt in der EU-DE-Region verfügbarView Details
Umbenennung des Datenbank-Dienstes GaussDBView Details
GeminiDB unterstützt Storage Auto-scalingView Details
Sie wollen keine Updates verpassen?Besuchen Sie unsere Portfolio Roadmap und entdecken Sie neue Services und Updates.
Mehr erfahren

Weitere Informationen zu diesem Produkt

Dokumentationen

 

Die Open Telekom Cloud Community

Hier treffen sich Nutzer, Entwickler und Product Owner um sich zu helfen, auszutauschen und zu diskutieren.

Jetzt entdecken  

Kostenfreie Experten-Hotline

Unsere zertifizierten Cloud-Experten stehen Ihnen mit persönlichem Service zur Seite.

 0800 3304477 (aus Deutschland)

 +800 33044770 (aus dem Ausland)

 24 Stunden am Tag, 7 Tage die Woche

E-Mail schreiben

Unser Kunden-Service steht Ihnen per E-Mail-Support kostenlos zur Verfügung.

E-Mail schreiben 

AIssistant Cloudia

Unsere KI-gestützte Suche hilft bei Ihrem Cloud-Anliegen.