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 Kilobyte (KB) pro Sekunde definiert. Ein Schreibvorgang ist ein beliebiger Oracle NoSQL Database Cloud Service-API-Aufruf, der dazu führt, dass ein Datensatz eingefügt, aktualisiert oder gelöscht wird. Für eine NoSQL-Tabelle gilt ein Schreibgrenzwert, der die Anzahl der Schreibeinheiten angibt, die pro Sekunde verwendet werden können. Indexaktualisierungen konsumieren 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 benötigt.

• Leseeinheit: 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: Eine Datensatzgröße von weniger als 1 KB erfordert eine Leseeinheit für einen Lesevorgang mit Eventual Consistency. 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.

• Speicherkapazität: Eine Speichereinheit ist ein einzelnes Gigabyte (GB) des Datenspeichers.

• Absolute Consistency: Es wird erwartet, dass die Daten zurückgegeben werden, die zuletzt in die Datenbank geschrieben wurden.

• Eventual Consistency: Die zurückgegebenen Daten sind u. U. nicht die Daten, die zuletzt in die Datenbank geschrieben wurden. Wenn keine neuen Aktualisierungen an den Daten vorgenommen werden, geben alle Zugriffe auf die betreffenden Daten letztendlich den zuletzt aktualisierten Wert zurück.

Faktoren mit Auswirkung auf die Kapazitätseinheit

Vor dem Bereitstellen der Kapazitätseinheiten sind die folgenden Faktoren zu berücksichtigen, die sich auf Lese-, Schreib- und Speicherkapazitäten 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 Absolute Consistency sind doppelt so hoch wie die von Lesezugriffen 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ären Indizes belegt werden.

• Auswahl der Datenmodellierung: Bei schemalosem JSON enthält jedes Dokument eine Eigenbeschreibung, wodurch Metadaten-Overhead auf die Gesamtgröße des Datensatzes aufgeschlagen wird. Bei festen Schematabellen beträgt der Overhead für jeden Datensatz genau 1 Byte.

• Abfragemuster: Die Kosten eines Abfragevorgangs hängen von der Anzahl der abgerufenen Zeilen, der Anzahl der Prädikate, der Größe der Quelldaten, den Projektionen und dem Vorhandensein von Indizes ab. Die Abfragen mit geringstem 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 Anwendungs-Workload

Im praktischen Beispiel einer E-Commerce-Anwendung erfahren Sie, wie Lese- und Schreibvorgänge pro Sekunde geschätzt werden. In diesem Beispiel werden die Produktkataloginformationen der Anwendung mit Oracle NoSQL Database Cloud Service gespeichert.

1. 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ärschlü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" }
   }

   Angenommen, die Anwendung verfügt über 100.000 derartiger Datensätze, und der Primärschlüssel hat eine Größe von etwa 20 Byte. Nehmen wir außerdem an, dass Abfragen vorhanden sind, die Datensätze über den sekundären Index lesen. Beispiel: Sie können alle Datensätze mit einer Bildschirmgröße von 13 Zoll suchen. Daher wird ein Index im Feld screenSize erstellt.

   Die Informationen werden wie folgt 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	100.000	2	20	1 KB	1	20

2. Identifizieren Sie die Liste der Vorgänge (im Allgemeinen CRUD-Vorgänge und Indexlesevorgänge) in der Tabelle sowie deren zu erwartende Rate (pro Sekunde).

   Vorgang	Anzahl von Vorgängen (pro Sekunde)	Beispiel
   Datensätze erstellen.	3	Erstellen eines Produkts
   Datensätze anhand des Primärschlüssels lesen	200	Lesen von Produktdetails anhand der Produkt-ID
   Datensätze anhand des sekundären Index lesen	1	Abrufen aller Produkte mit einer Bildschirmgröße von 13 Zoll
   Datensatz aktualisieren oder einem Datensatz ein Attribut hinzufügen	5	Aktualisierung der Produktbeschreibung einer Kamera oder Hinzufügen von Informationen zum Gewicht einer Kamera
   Datensatz löschen.	5	Löschen eines vorhandenen Produkts

3. Identifizieren Sie den Verbrauch von Lese- und Schreibvorgängen in KB.

   Vorgang	Annahmen (falls vorhanden)	Formel	Verbrauch bei Lesevorgängen (KB)	Verbrauch bei Schreiben (KB)	Anmerkungen/Erläuterungen
   Datensätze erstellen.	Angenommen, die Datensätze werden ohne Ausführung von Bedingungsprüfungen (sofern vorhanden) erstellt.	Datensatzgröße (auf nächstes KB gerundet) + 1 KB(Index) * (Anzahl Indizes)	0	1 KB + 1 KB (1) = 2 KB	Datensatzgröße ist 1 KB (0,8 KB für JSON-Spalte und 20 Byte für Schlüsselspalte) und ein 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 aktuellste Version der Zeile lesen, werden absolut konsistente Lesevorgänge verwendet. In solchen Fällen verwenden Sie den Multiplikator 2 in der Formel der Leseeinheit. Im Folgenden werden die verschiedenen Optionen zur Ermittlung der Kosten für Leseeinheiten aufgeführt: Wenn Option.IfAbsent oder Option.IfPresent verwendet wird, dann Verbrauch lesen = 2 Wenn setReturnRow verwendet wird, gilt: Lesekonsum = 2 * Datensatzgröße Wenn Option.IfAbsent und setReturnRow verwendet werden, dann Lesekonsum = 2 * Datensatzgröße
   Datensätze anhand des Primärschlüssels lesen		Record size round up to KB	Datensatzgröße = 1 KB	0	Datensatzgröße ist 1 KB
   Datensätze anhand des 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 beträgt sie 100 KB. Zusätzliche 10-KB-Konten für variablen Overhead, der abhängig von der Anzahl der zurückgegebenen Batches und dem für die Abfrage festgelegten Größenlimit auftreten kann. Der Gemeinkosten entspricht den Kosten für das Lesen des letzten Schlüssels in einem Batch. Dies ist eine Variable, die von maxReadKB und Datensatzgröße abhängig ist. Der Overhead liegt bei (numBatches - 1) * Schlüssellesungskosten (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 KB * 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 verbraucht. Je nach Aktualisierung muss 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. Absolute Konsistenz-Lesevorgänge sind die doppelten Kosten von Lesevorgängen mit Eventual Consistency. Dies ist der Grund für die Multiplikation mit 2 in der Formel. Lesekonsum: Für Index- und Datensatzgröße 1 KB fallen keine Gebühren an. Wenn Sie die Ausführung mit der Option setReturnRow ausführen, lautet der Leseverbrauch = 2 * Datensatzgröße Schreibverwendung: Die ursprüngliche und neue Datensatzgröße beträgt 1 KB und 1 KB für einen Index.
   Datensatz löschen		Verbrauch für Lesevorgänge = 1 KB (Index) * 2 Verbrauch für Schreibvorgänge = Datensatzgröße + 1 KB (Index) * (Anzahl_Indizes)	1 KB (1) *2 = 2 KB	1 KB + 1 KB(1) * (1) = 2 KB	Bei einem Löschvorgang fallen sowohl die Kosten für Lese- als auch Schreibeinheiten an. Da Sie sicherstellen müssen, dass Sie die aktuellste Version der Zeile prüfen, werden absolute konsistente Lesevorgänge verwendet, d.h. der Grund für die Verwendung des Multiplikators 2 in der Formel für Leseeinheiten. Wenn Sie die Ausführung mit der Option setReturnRow ausführen, lautet der Leseverbrauch = 2 * Datensatzgröße. Ansonsten ist der Leseverbrauch = 1 KB für einen Index Schreibungsverwendung: Die Datensatzgröße beträgt 1 KB und 1 KB für den Index. Die Anzahl der Indizes ist 1.

   Ermitteln Sie mit den Schritten 2 und 3 die Lese- und Schreibeinheiten für die Anwendungs-Workload.

   Vorgänge	Rate der Vorgänge	Lesevorgänge pro Sekunde	Schreibvorgänge pro Sekunde
   Datensätze erstellen	3	0	6
   Datensätze anhand des Primärschlüssels lesen	300	300	0
   Datensätze anhand des sekundären Index lesen	10	1100	0
   Vorhandenen Datensatz aktualisieren	5	10	20
   Datensatz löschen	1	2	2

   Leseeinheiten insgesamt: 1412

   Schreibeinheiten insgesamt: 28

   Daher wird die E-Commerce-Anwendung voraussichtlich eine Workload von 1412 Lesevorgängen pro Sekunde und 28 Schreibvorgängen pro Sekunde aufweisen. Laden Sie das Kapazitätsrechner-Tool von Oracle Technology Network herunter, um diese Werte einzugeben und Durchsatz und Speicher Ihrer Anwendung zu schätzen.