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.

Beschreibung von developer_overview.png folgt

Beschreibung der Abbildung developer_overview.png

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.

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.

OCI-SDKs/Treiber - Oracle Cloud Infrastructure bietet eine Reihe von Software Development Kits (SDKs), um die Entwicklung benutzerdefinierter Lösungen zu vereinfachen. Diese sind in der Regel unter UPL lizenziert. Diese bieten ähnliche Funktionen wie die OCI-Konsole über eine programmgesteuerte Schnittstelle.

Unterschied zwischen NoSQL-Datenbank-SDKs/Treibern und OCI-SDKs/Treibern:

OCI-SDKs sind REST-basiert. Sie sind einfach zu bedienen, haben aber begrenzte Funktionalität. Die NoSQL-Datenbank-SDKs hingegen bieten zahlreiche Funktionen. Es wird empfohlen, NoSQL-Datenbank-SDKs zu verwenden, da diese die folgenden Vorteile gegenüber OCI-SDKs bieten.

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.

Referenzen:

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: unbegrenzte Anzahl von Durchsatz- und Speichererhöhungen pro Tag Bis zu vier Durchsatz- oder Speicherreduzierungen innerhalb von 24 Stunden.	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 `WriteMultiple`-Anforderung	Anforderungs-	Die maximale Anzahl der einzelnen Vorgänge pro `WriteMultiple`-Anforderung.	50	Entspricht einer nicht gehosteten Umgebung. Dies kann auch mit der Aktualisierung von Servicelimits anfordern erhöht werden
Maximale Datengröße pro `WriteMultiple`-Anforderung.	Anforderungs-	Die maximale Datengröße pro `WriteMultiple`-Anforderung.	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: Maximal 100.000 Leseeinheiten Maximal 40.000 Schreibeinheiten 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ätstimator-Tool von Oracle Technology Network herunter, um diese Werte einzugeben und Durchsatz und Speicher Ihrer Anwendung zu 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: Datenbank einblenden - NoSQL, um die verschiedenen Nutzungs- und Konfigurationsoptionen anzuzeigen. Unter "Konfiguration" stehen zwei Optionen zur Verfügung. Sie können mit der Option "Immer kostenlos" beginnen oder Ihre Instanz mit der gewünschten 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.

Titel und Copyright-Informationen

Service planen

Oracle und/oder verbundene Unternehmen.