Service planen
Nehmen Sie sich etwas Zeit, um Ihren Oracle NoSQL Database Cloud Service-Service zu erstellen. Gehen Sie die hier aufgeführten Fragen durch, und entscheiden Sie vorab, was Sie erreichen möchten.
Dieser Artikel enthält die folgenden Themen:
Entwicklerüberblick
Verschaffen Sie sich einen allgemeinen Überblick über die Servicearchitektur, und wählen Sie ein SDK/Treiber aus, das Ihre Anwendungsentwicklungsanforderungen erfüllt.
NDCS-Entwickleraufgaben
Oracle NoSQL Database Cloud Service (NDCS) ist ein vollständig HA-Service. Sie wurde für anspruchsvolle Anwendungen entwickelt, die Antwortzeiten mit geringer Latenz, ein flexibles Datenmodell und elastische Skalierung für dynamische Workloads erfordern. Als vollständig verwalteter Service übernimmt Oracle alle administrativen Aufgaben wie Softwareupgrades, Sicherheitspatches, Hardwarefehler und Patching.
NoSQL Datenbank-SDKs/Treiber - Diese SDKs sind unter der Universal Permissive License (UPL) lizenziert und können entweder im NoSQL Cloud Service oder in der On-Premise-Datenbank verwendet werden. Dies sind voll funktionsfähige SDKs und bieten zahlreiche Funktionen. Diese Treiber können auch in Anwendungen verwendet werden, die mit Oracle NoSQL-Clustern ausgeführt werden, die in der Cloud anderer Anbieter ausgeführt werden.
- SDK (GitHub) - Enthält Details zur Installation, Verbindung und den ersten Schritten mit dem SDK
- API Guide - Stellt die im SDK verfügbaren Packages, Klassen, Methoden und Schnittstellen bereit
- Beispiele - Enthält Codebeispiele, die Sie ausprobieren können
OCI-Konsole - Bietet die Möglichkeit, Tabellen schnell zu erstellen, Tabellen zu ändern, Tabellen zu löschen, Daten zu laden, Indizes schnell zu erstellen, Indizes zu löschen, grundlegende Abfragen durchzuführen, Tabellenkapazitäten zu ändern und Metriken anzuzeigen.
Unterschied zwischen NoSQL-Datenbank-SDKs/Treibern und OCI-SDKs/Treibern:
- NoSQL Datenbank-SDKs können in Anwendungen verwendet werden, die eine Verbindung zum Cloud-Service, zu On-Premise-Datenspeichern und zum Cloud-Simulator NoSQL herstellen.
- NoSQL Datenbank-SDKs bieten eine viel umfangreichere Entwicklungserfahrung. Sie unterstützen weitere SQL-Features, die nicht über REST unterstützt werden.
- Sie können Implementierungen von Drittanbietern wie Jakarta NoSQL oder Eclipse TopLink mit NoSQL Database SDKs verwenden.
Oracle NoSQL Database Cloud Service-limits
Für Oracle NoSQL Database Cloud Service gelten verschiedene Standardlimits. Wenn Sie eine Oracle NoSQL Database Cloud Service-Tabelle erstellen, stellt das System sicher, dass die Anforderungen innerhalb der Begrenzungen des angegebenen Limits liegen. Einige Grenzwerte werden auf Tabellenebene festgelegt, andere auf Regionsebene.
Weitere Informationen zu Servicelimits, deren Umfang und wie Sie Ihre Servicelimits durch Weiterleitung einer Anforderung erhöhen können, finden Sie unter Service Limits. Im Folgenden sind die aktuellen Limits aufgeführt, die für Oracle NoSQL Database Cloud Service gelten.
Grenzwert | Geltungsbereich | Beschreibung | Wert in einer nicht gehosteten Umgebung | Wert in einer gehosteten Umgebung |
---|---|---|---|---|
Maximale Tabellenspeichergröße |
Tabelle |
Maximale Gesamtspeichergröße pro Mandant. Der gesamte Speicherplatz für mindestens eine Tabelle darf diesen Wert nicht überschreiten. |
5 TB |
17.5TB |
Tabellennamen |
Tabelle |
Maximale Anzahl der Zeichen, zulässige Zeichen und Anfangszeichen für Tabellennamen. |
Tischnamen dürfen maximal 256 Zeichen umfassen. Alle Namen müssen mit einem Buchstaben (a-z, A-Z) beginnen. Nachfolgende Zeichen können Buchstaben (a-z, A-Z), Ziffern (0-9) oder ein Unterstrich sein. |
Entspricht einer nicht gehosteten Umgebung |
Bereitgestellte Kapazität - maximaler Lese- und Schreibdurchsatz |
Tabelle |
Maximaler Lese- und Schreibdurchsatz beim Provisioning einer Tabelle. |
40.000 Leseeinheiten und 20.000 Schreibeinheiten pro Tabelle. |
Bis zu 420.000 Leseeinheiten und insgesamt 280.000 Schreibeinheiten für alle Tabellen in der gehosteten Umgebung |
On-Demand-Kapazität - maximaler Lese- und Schreibdurchsatz |
Tabelle |
Maximaler Lese- und Schreibdurchsatz bei Verwendung der On Demand-Kapazität für das Provisioning von Tabellen. |
10.000 Leseeinheiten und 5.000 Schreibeinheiten pro Tabelle. |
In einer gehosteten Umgebung nicht zulässig/erforderlich |
Bedarfsgesteuerte Kapazität - Anzahl Tabellen |
Bereich |
Anzahl der Tabellen mit On Demand-Kapazität. |
3 |
In einer gehosteten Umgebung nicht zulässig/erforderlich |
Provisioning-Modus ändern |
Tabelle |
Ändern Sie den Provisioning-Modus für die Tabelle von "Bereitgestellt" in "On Demand" oder umgekehrt. |
Kann nur einmal pro Tag geändert werden. |
- |
Maximale Anzahl Tabellen |
Bereich |
Die maximale Anzahl von Tabellen. |
30 |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Anzahl Spalten. |
Tabelle |
Die maximale Anzahl von Spalten. |
50 |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Anzahl Tabellenschemaupdates |
Tabelle |
Die maximale Anzahl von Tabellenschemaupdates. |
100 |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Anzahl von Indexen |
Tabelle |
Die maximale Anzahl von Indizes. |
5 |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Anzahl der Änderungen von Durchsatz- und Speicherlimits |
Tabelle |
Die maximale Anzahl der Änderungen von Durchsatz- und Speicherlimits. |
Oracle lässt Folgendes zu:
|
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Indexnamen |
Index |
Die maximale Anzahl von Zeichen, zulässige Zeichen und Anfangszeichen. |
Indexnamen dürfen maximal 64 Zeichen umfassen. Alle Namen müssen mit einem Buchstaben (a-z, A-Z) beginnen. Nachfolgende Zeichen können Buchstaben (a-z, A-Z), Ziffern (0-9) oder ein Unterstrich sein. |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Anzahl der einzelnen Vorgänge pro |
Anforderungs- |
Die maximale Anzahl der einzelnen Vorgänge pro |
50 |
Entspricht einer nicht gehosteten Umgebung. Dies kann auch mit der Aktualisierung von Servicelimits anfordern erhöht werden |
Maximale Datengröße pro |
Anforderungs- |
Die maximale Datengröße pro |
25 MB |
Entspricht einer nicht gehosteten Umgebung. Dies kann auch mit der Aktualisierung von Servicelimits anfordern erhöht werden |
Spaltennamen |
Spalte |
Die maximale Anzahl von Zeichen, zulässige Zeichen und Anfangszeichen. |
Feldnamen dürfen maximal 64 Zeichen umfassen. Alle Namen müssen mit einem Buchstaben (a-z, A-Z) beginnen. Nachfolgende Zeichen können Buchstaben (a-z, A-Z), Ziffern (0-9) oder ein Unterstrich sein. |
Entspricht einer nicht gehosteten Umgebung. |
Maximale Größe des sekundären Indexschlüssels |
Index |
Maximale Größe des Indexschlüssels. |
64 Byte |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Größe des Primärindexschlüssels |
Index |
Maximale Größe des Primärschlüssels. |
64 Byte |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Zeilengröße |
Zeile |
Maximale Zeilengröße. |
512 KB |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale Länge von Abfragezeichenfolgen. |
Abfrage |
Maximale Länge von Abfragezeichenfolgen. |
10 KB |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Maximale unterstützte Rate von DDL-Vorgängen. |
Bereich |
Maximale unterstützte Rate von DDL-Vorgängen. |
4 Pro Minute |
Dies kann mit der Aktualisierung von Servicelimits anfordern angepasst werden |
Höchstwerte für Durchsatz und Data Storage-Ressourcen. |
Bereich |
Höchstwerte für Durchsatz und Data Storage-Ressourcen. |
Pro Region lässt Oracle Folgendes zu:
Oracle lässt eine maximale Speichergröße von 5 TB pro Mandant zu. Die Region kann über eine einzelne Tabelle mit einer Speichergröße von 5 TB verfügen. In diesem Fall kann die Region keine weitere Tabelle erstellen. Sie können auch über mehrere Tabellen verfügen und sicherstellen, dass die Daten in allen Tabellen die maximale Speichergröße von 5 TB nicht überschreiten. |
420.000 Schreibeinheiten, 280.000 Leseeinheiten, 17,5 TB Speicher |
Verwandte Themen
Kapazität schätzen
Erfahren Sie, wie Sie Durchsatz- und Speicherkapazität für Oracle NoSQL Database Cloud Service schätzen.
Grundlagen für die Berechnung
Bevor Sie erfahren, wie Sie den Durchsatz und den Speicher für den Service schätzen, machen Sie sich mit den Definitionen für Durchsatz und Speichereinheit vertraut.
-
Schreibeinheit: Eine Schreibeinheit wird als Datendurchsatz von bis zu 1 KB pro Sekunde definiert. Ein Schreibvorgang ist ein beliebiger Oracle NoSQL Database Cloud Service-API-Aufruf, der zum Einfügen, Aktualisieren oder Löschen eines Datensatzes führt. Für eine NoSQL-Tabelle gilt ein Schreibgrenzwert, der die Anzahl der Schreibeinheiten angibt, die pro Sekunde verwendet werden können. Indexaktualisierungen verwenden auch Schreibeinheiten.
Beispiel: Für eine Datensatzgröße von weniger als 1 KB ist eine Schreibeinheit für einen Schreibvorgang erforderlich. Für eine Datensatzgröße von 1,5 KB werden zwei Schreibeinheiten für den Schreibvorgang erforderlich.
-
Read Unit (RU): Eine Leseeinheit wird als Datendurchsatz von bis zu 1 KB pro Sekunde für einen Lesevorgang mit Eventual Consistency definiert. Ihre NoSQL-Tabelle enthält einen Lesegrenzwert, der die Anzahl der Leseeinheiten angibt, die pro Sekunde verwendet werden können.
Beispiel: Bei einer Datensatzgröße von weniger als 1 KB ist eine Leseeinheit für einen Lesevorgang mit Eventuität erforderlich. Eine Datensatzgröße von 1,5 KB erfordert zwei Leseeinheiten für einen Lesevorgang mit Eventual Consistency und vier Leseeinheiten für einen Lesevorgang mit Absolute Consistency.
-
Storage Capacity: Eine Storage-Einheit ist ein einzelnes Gigabyte (GB) des Data Storage.
-
Vollständige Konsistenz: Es wird erwartet, dass die Daten zurückgegeben werden, die zuletzt in die Datenbank geschrieben wurden.
-
Endgültige Konsistenz: Die zurückgegebenen Daten sind möglicherweise nicht die Daten, die zuletzt in die Datenbank geschrieben wurden. Wenn keine neuen Aktualisierungen an den Daten vorgenommen werden, geben alle Zugriffe auf diese Daten letztendlich den zuletzt aktualisierten Wert zurück.
Hinweis:
Oracle NoSQL Database Cloud Service verwaltet automatisch die Lese- und Schreibkapazitäten, um die Anforderungen dynamischer Workloads bei der Verwendung von On-Demand-Kapazität zu erfüllen. Es wird empfohlen zu validieren, dass der Kapazitätsbedarf die On Demand-Kapazitätslimits nicht überschreitet. Weitere Informationen finden Sie unter Oracle NoSQL Database Cloud Service-limits.Faktoren mit Auswirkung auf die Kapazitätseinheit
Bevor Sie die Kapazitätseinheiten bereitstellen, müssen die folgenden Faktoren berücksichtigt werden, die sich auf Lesen, Schreiben und Speicherkapazität auswirken.
-
Datensatzgröße: Mit zunehmender Datensatzgröße erhöht sich auch die Anzahl der Kapazitätseinheiten, die beim Schreiben oder Lesen von Daten konsumiert werden.
-
Datenkonsistenz: Die Kosten der Lesezugriffe mit Absolutkonsistenz sind doppelt so hoch wie die der Lesevorgänge mit Eventual Consistency.
-
Sekundäre Indizes: Wenn ein vorhandener Datensatz in einer Tabelle geändert (hinzugefügt, aktualisiert oder gelöscht) wird, konsumiert die Aktualisierung sekundärer Indizes Schreibeinheiten. Die Gesamtkosten des bereitgestellten Durchsatzes für einen Schreibvorgang entsprechen der Summe der Schreibeinheiten, die durch Schreibvorgänge in die Tabelle und Aktualisierungen der lokalen Sekundärindizes belegt werden.
-
Auswahl der Datenmodellierung: Bei schemalosem JSON enthält jedes Dokument eine Eigenbeschreibung, wodurch der Gesamtgröße des Datensatzes Metadaten-Overhead hinzugefügt wird. Bei festen Schema-Tabellen beträgt der Overhead für jeden Datensatz genau 1 Byte.
-
Muster abfragen: Die Kosten eines Abfragevorgangs sind von der Anzahl der abgerufenen Zeilen, der Anzahl der Prädikate, der Größe der Quelldaten, den Projektionen und dem Vorhandensein von Indizes abhängig. Die Abfragen mit dem geringsten Aufwand geben einen Shard-Schlüssel oder einen Indexschlüssel (mit einem zugehörigen Index) an, um dem System die Verwendung von primären und sekundären Indizes zu ermöglichen. Eine Anwendung kann anhand verschiedener Abfragen den konsumierten Durchsatz untersuchen, um die Vorgänge zu optimieren.
Beispiel aus der Praxis: So schätzen Sie Ihre Application Workload
Im Beispiel einer E-Commerce-Anwendung erfahren Sie, wie Lese- und Schreibvorgänge pro Sekunde geschätzt werden. In diesem Beispiel wird Oracle NoSQL Database Cloud Service zum Speichern der Produktkataloginformationen der Anwendung verwendet.
-
Identifizieren Sie das Datenmodell (JSON oder feste Tabelle), die Datensatzgröße und die Schlüsselgröße für die Anwendung.
Angenommen, die E-Commerce-Anwendung folgt dem JSON-Datenmodell, und der Entwickler hat eine einfache Tabelle mit zwei Spalten erstellt. Eine Datensatz-ID (primärer Schlüssel) und ein JSON-Dokument für die Produktfeatures und -attribute. Das JSON-Dokument mit einer Größe unter 1 KB (0,8 KB) sieht wie folgt aus:
{ "additionalFeatures": "Front Facing 1.3MP Camera", "os": "Macintosh OS X 10.7", "battery": { "type": "Lithium Ion (Li-Ion) (7000 mAH)", "standbytime" : "24 hours" }, "camera": { "features": ["Flash","Video"], "primary": "5.0 megapixels" }, "connectivity": { "bluetooth": "Bluetooth 2.1", "cell": "T-mobile HSPA+ @ 2100/1900/AWS/850 MHz", "gps": true, "infrared": false, "wifi": "802.11 b/g" }, "description": "Apple iBook is the best in class computer for your professional and personal work.", "display": { "screenResolution": "WVGA (1280 x 968)", "screenSize": "13.0 inches" }, "hardware": { "accelerometer": true, "audioJack": "3.5mm", "cpu": "Intel i7 2.5 GHz", "fmRadio": false, "physicalKeyboard": false, "usb": "USB 3.0" }, "id": "appleproduct_1", "images": ["img/apple-laptop.jpg"], "name": "Myshop.com : Apple iBook", "sizeAndWeight": { "dimensions": [ "300 mm (w)", "300 mm (h)", "12.4 mm (d)" ], "weight": "1250.0 grams" }, "storage": { "hdd": "750GB", "ram": "8GB" } }
Es wird davon ausgegangen, dass die Anwendung über 100.000 derartiger Datensätze verfügt und dass der Primärschlüssel etwa 20 Byte groß ist. Nehmen wir außerdem an, dass Abfragen vorhanden sind, die Datensätze mit dem sekundären Index lesen würden. Beispiel: Sie finden alle Datensätze mit einer Bildschirmgröße von 13 Zoll. Daher wird ein Index im Feld
screenSize
erstellt.Die Informationen werden folgendermaßen zusammengefasst:
Tabellen Zeilen pro Tabelle Spalten pro Tabelle Schlüsselgröße (in Byte) Wertgröße in Byte (Summe aller Spalten) Indizes Indexschlüsselgröße in Byte 1
100000
2
20
1 KB
1
20
-
Identifizieren Sie die Liste der Vorgänge (in der Regel CRUD-Vorgänge und Indexlesungen) in der Tabelle sowie deren zu erwartende Rate (pro Sekunde).
Vorgang Anzahl von Vorgängen (pro Sekunde) Beispiel Erstellen Sie Datensätze.
3
Erstellen eines Produkts
Datensätze mit dem Primärschlüssel lesen
200
Lesen von Produktdetails anhand der Produkt-ID
Datensätze mit dem sekundären Index lesen
1
Abrufen aller Produkte mit einer Bildschirmgröße von 13 Zoll
Datensatz aktualisieren oder hinzufügen
5
Aktualisierung der Produktbeschreibung einer Kamera
oder
Hinzufügen von Informationen zum Gewicht einer Kamera
Datensatz löschen.
5
So löschen Sie ein vorhandenes Produkt:
-
Identifizieren Sie den Verbrauch von Lese- und Schreibvorgängen in KB.
Vorgang Annahmen (falls vorhanden) Formel Verbrauch beim Lesen (KB) Verbrauch beim Schreiben (KB) Hinweise/Erläuterungen Erstellen Sie Datensätze. Gehen Sie davon aus, dass die Datensätze ohne Ausführung von Bedingungsprüfungen (wenn sie vorhanden sind) erstellt werden. Record size (rounded to next KB) + 1 KB(index) * (number of indexes)
0 1 KB + 1 KB (1 ) = 2 KB Die Datensatzgröße beträgt 1 KB (0,8 KB für JSON-Spalten und 20 Byte für Schlüsselspalten) und es gibt einen Index der Größe 1 KB.
Bei einem Erstellungsvorgang fallen Kosten für Leseeinheiten an, wenn Sie die put-Befehle mit einigen Optionen ausführen. Da Sie sicherstellen müssen, dass Sie die aktuelle Version der Zeile lesen, werden absolut konsistente Lesevorgänge verwendet. In solchen Fällen verwenden Sie den Multiplikator 2 in der Leseeinheitenformel. Hier sind die verschiedenen Optionen zur Bestimmung der Leseeinheitskosten:- Wenn Option.IfAbsent oder Option.IfPresent verwendet wird, ist "Leseverbrauch" = 2
- Wenn setReturnRow verwendet wird, ist "Leseverbrauch" = 2 * Datensatzgröße
- Wenn Option.IfAbsent und setReturnRow verwendet werden, ist "Leseverbrauch" = 2 * Datensatzgröße
Datensätze mit dem Primärschlüssel lesen Record size round up to KB
Datensatzgröße = 1 KB 0 Datensatzgröße ist 1 KB Datensätze mit dem sekundären Index lesen Angenommen, 100 Datensätze werden zurückgegeben. record_size * number_of_records_matched
11KB *100 = 100KB
100 KB + 10 KB = 110 KB
0 Für den sekundären Index fallen keine Gebühren an. Die Datensatzgröße beträgt 1 KB. Für 100 Datensätze sind es 100 KB.
Die zusätzlichen 10 KB stehen für variablen Overhead, der je nach Anzahl der zurückgegebenen Batches und dem für die Abfrage festgelegten Größengrenzwert anfallen kann.
Die Gemeinkosten sind die Kosten für das Lesen des letzten Schlüssels in einem Batch. Diese Variable hängt von maxReadKB und Datensatzgröße ab. Der Overhead beträgt bis zu (numBatches - 1) * Schlüssellesekosten (1 KB).
Vorhandene Datensätze aktualisieren Angenommen, die Größe des aktualisierten Datensatzes ist identisch mit der alten Datensatzgröße (1 KB). Read consumption = record_size * 2
Write consumption = original_record_size + new_record_size + 1 KB (index) * (number of writes)
1 KG * 2 1 KB + 1 KB + 1 KB (1) * (2) = 4 KB Wenn Zeilen mit einer Abfrage (SQL-Anweisung) aktualisiert werden, werden sowohl Lese- als auch Schreibeinheiten verwendet. Je nach Update muss möglicherweise der Primärschlüssel, der Sekundärschlüssel oder sogar der Datensatz selbst gelesen werden. Absolute konsistente Lesevorgänge sind erforderlich, um sicherzustellen, dass wir den neuesten Datensatz lesen. Die Kosten für Lesezugriffe mit Absolute Consistency sind doppelt so hoch. Dies ist der Grund für die Multiplikation mit 2 in der Formel.
Leseverbrauch: Keine Gebühr für Index- und Datensatzgröße beträgt 1 KB. Wenn die Ausführung mit der Option setReturnRow ausgeführt wird, ist "Leseverbrauch" = 2 * Datensatzgröße
Schreibverbrauch: Die ursprüngliche und neue Datensatzgröße beträgt 1 KB und 1 KB für einen Index.
Datensatz löschen Read consumption = 1 KB (index) * 2
Write consumption = record_size + 1KB (index) * (number_of_indexes)
1 KB (1) *2 = 2 KB 1 KB + 1 KB(1) * (1) = 2 KB Bei einem Löschvorgang fallen sowohl Lese- als auch Schreibstückkosten an. Da Sie sicherstellen müssen, dass Sie die aktuellste Version der Zeile betrachten, werden absolut konsistente Lesevorgänge verwendet. Dies ist der Grund, warum Sie den 2-Multiplikator in der Leseeinheitsformel verwenden.
Wenn die Ausführung mit der Option setReturnRow ausgeführt wird, ist "Leseverbrauch" = 2 * Datensatzgröße. Ansonsten gilt: Leseverbrauch = 1 KB für einen Index
Schreibverbrauch: Die Datensatzgröße für den Index beträgt 1 KB und 1 KB. Die Anzahl der Indizes ist 1.
Ermitteln Sie mit den Schritten 2 und 3 die Lese- und Schreibeinheiten für die Anwendungs-Workload.
Betriebsabläufe Rate der Vorgänge Lesen pro Sekunde Schreiben pro Sekunde Datensätze erstellen
3
0
6
Datensätze mit dem Primärschlüssel lesen
300
300
0
Datensätze mit dem sekundären Index lesen
10
1.100
0
vorhandenen Datensatz aktualisieren
5
10
20
Datensatz löschen
1
2
2
Leseeinheiten gesamt: 1412
Schreibeinheiten insgesamt: 28
Daher wird geschätzt, dass die E-Commerce-Anwendung eine Workload von 1412 Lesevorgängen pro Sekunde und 28 Schreibvorgängen pro Sekunde aufweist. Laden Sie das Kapazitätsrechner-Tool herunter, um diese Werte eingeben und Durchsatz und Speicher Ihrer Anwendung schätzen.
Hinweis:
Bei den obigen Berechnungen werden Anforderungen von eventuell konsistenten Lesevorgängen angenommen. Bei einer Leseanforderung mit Absolute Consistency konsumiert der Vorgang das Doppelte an Kapazitätseinheiten. Daher wären die Lesekapazitätseinheiten 4844 Leseeinheiten.Monatskosten schätzen
Erfahren Sie, wie Sie die monatlichen Kosten Ihres Oracle Cloud-Abonnements schätzen.
Zur Vorbereitung auf Ihre Oracle Cloud-Servicebestellung stellt Ihnen Oracle einen Kostenrechner zur Verfügung, mit dem Sie Ihre monatliche Nutzung und die zugehörigen Kosten ermitteln können, bevor Sie sich auf ein Abonnementmodell oder einen Betrag festlegen.
Der Kostenrechner berechnet automatisch Ihre monatlichen Kosten basierend auf den von Ihnen eingegebenen Werten für Leseeinheiten, Schreibeinheiten und Speicher. Führen Sie die folgenden Schritte aus, um ein Verständnis für die Berechnung der Lese- und Schreibeinheiten für Ihre Anwendung zu erhalten:
-
Schritt 1: Navigieren Sie zu dem Thema Kapazität schätzen. Schätzen Sie Ihre Anwendungslast anhand des Beispiels und der unter diesem Thema beschriebenen Formeln.
Schritt 2: Laden Sie den Kapazitätsrechner von Oracle Technology Network herunter, und verwenden Sie ihn, um Schreibeinheiten, Leseeinheiten und die Speicherkapazität für Ihre Anwendung entsprechend den Kriterien der Anwendungs-Workload und der Datenbankvorgänge zu schätzen.
-
Schritt 2: Rufen Sie den Kostenrechner auf der Oracle Cloud-Website auf. Aktivieren Sie das Kontrollkästchen Datenmanagement. Scrollen Sie zu Oracle NoSQL Database Cloud, und klicken Sie auf Hinzufügen, um einen Eintrag für Oracle NoSQL Database Cloud in den Konfigurationsoptionen hinzuzufügen. Erweitern Sie NoSQL-Datenbank, um die verschiedenen Nutzungs- und Konfigurationsoptionen anzuzeigen. Eingabewerte für die Auslastungs- und Konfigurationsparameter, um die Kosten für die Nutzung von Oracle NoSQL Database Cloud Service aus Ihren Oracle Cloud Pay-As-You-Go- und Monthly Flex-Abonnements zu schätzen.
-
Schritt 3: Öffnen Sie den Kostenrechner auf der Oracle Cloud-Website. Wählen Sie in der Dropdown-Liste {\b Data Management}. Unter "Datenmanagement" werden verschiedene Optionen angezeigt. Navigieren Sie zu Oracle NoSQL Database Cloud. Klicken Sie auf "Add", um einen Eintrag für Oracle NoSQL Database Cloud in den Konfigurationsoptionen hinzuzufügen.
-
Schritt 4: Blenden Sie "Datenbank" ein - NoSQL, um die verschiedenen Auslastungs- und Konfigurationsoptionen zu suchen. Unter "Konfiguration" können Sie zwei Optionen auswählen. Sie können mit der Option "Immer kostenlos" beginnen (nur in der Region Phoenix verfügbar), oder Sie können Ihrer Instanz die gewünschte Konfiguration bereitstellen.
- Schritt 4a: Wenn Sie eine Option vom Typ "Immer kostenlos" verwenden möchten, erweitern Sie unter "Konfiguration" Oracle NoSQL Database Cloud - Lesen, Oracle NoSQL Database Cloud Service - Speicher und Oracle NoSQL Database Cloud Service - Schreiben und ändern Sie die Lese-, Speicher- und Schreibkapazität als 0. Anschließend wird die Gesamtkostenschätzung als 0 angezeigt. Sie können mit der Option Immer kostenlos fortfahren.
-
Schritt 5: Wenn Sie eine höhere Lese-, Schreib- und Speicherkapazität bereitstellen möchten als in "Immer kostenlos" verfügbar, können Sie dies auch tun, indem Sie die Konfigurationswerte unter "Datenbank-NoSQL" eingeben.
- Schritt 5a: Ändern Sie unter "Nutzung" die Standardwerte nicht, da Oracle NoSQL Database Cloud Service keinen dieser Werte verwendet.
- Schritt 5 b: Fügen Sie unter "Konfiguration" die Anzahl der Leseeinheiten, Schreibeinheiten und Speicherkapazität hinzu, die Sie im vorherigen Schritt geschätzt haben. Die Kosten werden anhand Ihrer Eingabewerte geschätzt und auf der Seite angezeigt.
Hinweis:
Wenn Sie das automatische Skalierungsfeature verwenden, wird eine Rechnung am Monatsende für den tatsächlichen Verbrauch von Lese- und Schreibeinheiten in Echtzeit generiert. Sie können also Ihre eigenen Auditlogs in der Anwendung erfassen, um die Abrechnung am Monatsende zu überprüfen. Es wird empfohlen, die verbrauchten Lese- und Schreibeinheiten, die vom NoSQL Database Cloud-Service zurückgegeben werden, mit jedem API-Aufruf zu protokollieren. Mit diesen Daten können Sie mit Abrechnungsdaten am Monatsende aus dem Oracle Cloud-Mess- und Abrechnungssystem korrelieren.
Ausführliche Informationen zu den verschiedenen verfügbaren Preismodellen finden Sie unter NoSQL Database Cloud Service - Preise.
Kosten/Abrechnung für globale aktive Tabellen
Die Kosten/Fakturierung für eine globale aktive Tabelle enthält zwei Komponenten. Die erste Komponente ist das Preismodell, das für Singleton-Tabellen befolgt wird. Dabei werden die Leseeinheiten pro Monat, Schreibeinheiten pro Monat und Gigabyte (GB) Speicherkapazität pro Monat berücksichtigt. Die zweite Komponente bezieht sich auf die replizierten Schreibvorgänge für jedes regionale Tabellenreplikat für die globale aktive Tabelle. Eingehende replizierte Schreibvorgänge werden basierend auf konsumierten Schreibvorgängen berechnet.