Oracle NoSQL Database Cloud Service

Unterstützte Datentypen

Oracle NoSQL Database Cloud Service unterstützt viele gängige Datentypen.

Datentyp	Beschreibung
`BINARY`	Eine Folge von null oder mehr Byte. Die Speichergröße ist die Anzahl der Byte plus eine Codierung der Größe des Bytearrays, die abhängig von der Größe des Arrays eine Variable ist.
`FIXED_BINARY`	Ein Bytearray mit fester Größe. Für diesen Datentyp ist keine zusätzliche Codierung erforderlich.
`BOOLEAN`	Ein Datentyp mit einem von zwei möglichen Werten: `TRUE` oder `FALSE`. Die Speichergröße des booleschen Wertes beträgt 1 Byte.
`DOUBLE`	Eine lange Gleitkommazahl, die mit 8 Byte Speicher für Indexschlüssel codiert ist. Wenn es sich um einen Primärschlüssel handelt, verwendet er 10 Byte Speicher.
`FLOAT`	Eine lange Gleitkommazahl, die mit 4 Byte Speicher für Indexschlüssel codiert ist. Wenn es sich um einen Primärschlüssel handelt, verwendet er 5 Byte Speicher.
`LONG`	Eine lange Ganzzahl hat eine Codierung mit variabler Länge, die je nach Wert 1-8 Byte Speicher verwendet. Wenn es sich um einen Primärschlüssel handelt, verwendet er 10 Byte Speicher.
`INTEGER`	Eine lange Ganzzahl hat eine Codierung mit variabler Länge, die je nach Wert 1-4 Byte Speicher verwendet. Wenn es sich um einen Primärschlüssel handelt, verwendet er 5 Byte Speicher.
`STRING`	Eine Folge von null oder mehr Unicode-Zeichen. Der Stringtyp wird als UTF-8 codiert und in dieser Codierung gespeichert. Die Speichergröße ist die Anzahl der UTF-8 Byte plus die Länge, die je nach Anzahl der Byte in der Codierung 1-4 Byte betragen kann. Bei einem Indexschlüssel entspricht die Speichergröße der Anzahl von UTF-8 Byte plus einem einzelnen Null-Beendigungsbyte.
`NUMBER`	Eine mit Vorzeichen versehene Dezimalzahl mit beliebiger Gesamtstellenzahl. Es wird in einem Bytearrayformat serialisiert, das für geordnete Vergleiche verwendet werden kann. Das Format besteht aus 2 Teilen: Vorzeichen und Exponent plus eine einzelne Ziffer. Dies dauert 1-6 Byte, ist aber normalerweise 2, es sei denn, der Exponent ist ziemlich groß Die Mantisse des Wertes, der etwa ein Byte pro 2 Stellen beträgt Beispiele: 12.345678 serialisiert in 6 Bytes 1.234E+102 serialisiert in 5 Byte Hinweis: Wenn Sie numerische Werte in Ihrem Schema verwenden müssen, wird empfohlen, die Datentypen in der unten angegebenen Reihenfolge zu wählen: INTEGER, LONG, FLOAT, DOUBLE, NUMBER Vermeiden Sie NUMBER, es sei denn, Sie benötigen es wirklich für Ihren Anwendungsfall, da NUMBER sowohl in Bezug auf die Speicher- als auch in Bezug auf die Verarbeitungsleistung teuer ist.
`TIMESTAMP`	Ein Zeitpunkt mit einer Gesamtstellenzahl. Die Gesamtstellenzahl wirkt sich auf die Speichergröße und -nutzung aus. Timestamp wird in UTC ( koordinierte Weltzeit) gespeichert und verwaltet. Der Datentyp "Zeitstempel" erfordert je nach verwendeter Genauigkeit 3 bis 9 Byte. Die folgende Aufschlüsselung veranschaulicht den von diesem Datentyp verwendeten Speicher: Bit[0~13] Jahr - 14 Bit bit[14~17] Monat - 4 Bit Bit[18~22] Tag - 5 Bit bit[23~27] Stunde - 5 Bit [optional] Bit[28~33] Minute - 6 Bit [optional] Bit[34~39] Sekunde - 6 Bit [optional] Bit[40~71] Sekundenbruchteil [optional mit variabler Länge]
`UUID`	Hinweis: Der Datentyp UUID wird als Subtyp des Datentyps STRING betrachtet. Die Speichergröße beträgt 16 Byte als Indexschlüssel. Bei Verwendung als Primärschlüssel beträgt die Speichergröße 19 Byte.
`ENUM`	Eine Enumeration wird als Array von Zeichenfolgen dargestellt. `ENUM`-Werte sind symbolische IDs. Sie werden als kleiner Ganzzahlwert gespeichert, der eine bestimmte Position in der Enumerationsreihenfolge darstellt.
`ARRAY`	Eine sortierte Collection mit null oder mehr typisierten Elementen. Arrays, die nicht als JSON definiert sind, können keine `NULL`-Werte enthalten. Arrays, die als JSON deklariert sind, können ein beliebiges gültiges JSON enthalten, einschließlich dem speziellen Wert NULL, der für JSON relevant ist.
`MAP`	Eine nicht sortierte Collection mit null oder mehr Schlüssel/Elementpaaren, wobei alle Schlüssel Zeichenfolgen sind und alle Elemente denselben Typ aufweisen. Alle Schlüssel müssen eindeutig sein. Die Schlüsselelementpaare werden als Felder bezeichnet, wobei es sich bei den Schlüsseln um Feldnamen und bei den zugeordneten Elementen um Feldwerte handelt. Feldwerte können unterschiedliche Typen aufweisen, Zuordnungen dürfen jedoch keine NULL-Feldwerte enthalten.
`RECORD`	Eine feste Collection aus einem oder mehreren Schlüssel/Elementpaaren, wobei alle Schlüssel Zeichenfolgen sind. Alle Schlüssel in einem Datensatz müssen eindeutig sein.
`JSON`	Alle gültigen JSON-Daten.

Tabellenstatus und Lebenszyklus

Erfahren Sie mehr über die verschiedenen Tabellenstatus und ihre Bedeutung (Tabellenlebenszyklusprozess).

Jede Tabelle durchläuft eine Reihe von verschiedenen Status von ihrer Erstellung bis zum Löschen. Beispiel: Eine Tabelle im Status DROPPING kann nicht in den Status ACTIVE versetzt werden, während eine Tabelle im Status ACTIVE in den Status UPDATING versetzt werden kann. Sie können die verschiedenen Tabellenstatus verfolgen, indem Sie den Tabellenlebenszyklus überwachen. In diesem Abschnitt werden die einzelnen Tabellenstatus beschrieben.

Beschreibung der Tabelle state.png:
Beschreibung der Abbildungstabelle - state.png

Tabellenstatus	Beschreibung
`CREATING`	Die Tabelle wird gerade erstellt. Sie kann noch nicht verwendet werden.
`UPDATING`	Die Tabelle wird gerade aktualisiert. Es sind keine weiteren Tabellenänderungen möglich, solange die Tabelle diesen Status aufweist. In folgenden Fällen befindet sich eine Tabelle im Status `UPDATING`: Die Tabellenlimits werden geändert Das Tabellenschema wird optimiert Ein Tabellenindex wird hinzugefügt oder gelöscht
`ACTIVE`	Die Tabelle kann im aktuellen Status verwendet werden. Die Tabelle wurde möglicherweise vor kurzem erstellt oder geändert, ihr Status ist jetzt jedoch stabil.
`DROPPING`	Die Tabelle wird gelöscht und kann nicht aufgerufen werden (egal, zu welchem Zweck).
`DROPPED`	Die Tabelle wurde gelöscht und ist nicht mehr für Lese-, Schreib- oder Abfrageaktivitäten verfügbar. Hinweis: Nachdem eine Tabelle gelöscht wurde, kann sie erneut erstellt werden.

Fehler in SQL-Anweisungen in der OCI-Konsole debuggen

Wenn Sie mit der OCI-Konsole eine Tabelle mit einer DDL-Anweisung erstellen oder mit einer DML-Anweisung Daten einfügen oder aktualisieren oder Daten mit einer SELECT-Abfrage abrufen, wird in einem der folgenden allgemeinen Szenarios möglicherweise ein Fehler angezeigt, dass Ihre Anweisung unvollständig oder fehlerhaft ist:

Wenn Sie am Ende der SQL-Anweisung ein Semikolon haben.
Wenn in Ihrer SQL-Anweisung ein Syntaxfehler vorliegt, wie die falsche Verwendung von Kommas, die Verwendung unnötiger Zeichen in der Anweisung usw.
Wenn die SQL-Anweisung in einem der SQL-Schlüsselwörter oder in der Datentypdefinition einen Rechtschreibfehler enthält.
Wenn Sie die Spalte als NOT NULL definiert, ihr jedoch keinen DEFAULT-Wert zugewiesen haben.
Wenn Sie die Spalte als NOT NULL definiert, ihr jedoch keinen DEFAULT-Wert zugewiesen haben.

So behandeln Sie einige unvollständige oder fehlerhafte Fehler, während Sie mit der OCI-Konsole Daten erstellen oder verwalten:

Entfernen Sie das Semikolon (sofern vorhanden) am Ende der SQL-Anweisung.
Prüfen Sie, ob unerwünschte Zeichen oder falsche Satzzeichen in Ihrer SQL-Anweisung vorhanden sind.
Prüfen Sie in der SQL-Anweisung auf Rechtschreibfehler.
Prüfen Sie, ob alle Spaltendefinitionen vollständig und korrekt sind.
Prüfen Sie, ob Sie einen Primärschlüssel für die Tabelle definiert haben.

Wenn Sie weiterhin einen Fehler erhalten, nachdem Sie einige der oben beschriebenen möglichen Situationen beseitigt haben, können Sie die Abfrage mit Cloud Shell ausführen und den genauen Fehler erfassen, wie im folgenden Beispiel dargestellt.

Beispiel: Fehlermeldung für eine SELECT-Anweisung aus der cloud shell abrufen

Der Befehl summarize prüft die Syntax und gibt eine kurze Zusammenfassung einer SQL-Anweisung zurück.

Öffnen Sie in der OCI-Konsole oben rechts die Cloud Shell.
Kopieren Sie die SQL SELECT-Anweisung (z.B. query1.sql) in eine Variable (SQL_SELECTSTMT).
Beispiel:
```
SQL_SELECTSTMT=$(cat ~/query1.sql | tr '\n' ' ')
```

Rufen Sie den folgenden OCI-Befehl auf, um die Syntax der SQL SELECT-Anweisung zu prüfen.

Hinweis:

Sie müssen compartment_id für diese SELECT-Anweisung angeben.

oci raw-request --http-method GET --target-uri 
https://nosql.${OCI_REGION}.oci.oraclecloud.com/20190828/query/summarize?compartmentId=$NOSQL_COMPID\
&statement="$SQL_SELECTSTMT" | jq '.data'

Dadurch erhalten Sie den genauen Fehler in Ihrer SQL-Anweisung.

Referenz zu Datendefinitionssprache

Weitere Informationen zur Verwendung von DDL in Oracle NoSQL Database Cloud Service.

Verwenden Sie die Oracle NoSQL Database Cloud Service-DDL, um Tabellen und Indexe zu erstellen, zu ändern und zu löschen.

Informationen zur DDL-Syntax finden Sie in der DDL-Dokumentation für Tabellen. In dieser Dokumentation wird die von den On-Premise-Oracle NoSQL Database-Produkten unterstützte Sprache erläutert. Ein Teil dieser Funktionalität wird von Oracle NoSQL Database Cloud Service unterstützt. Die Unterschiede werden im Abschnitt DDL-Differenzen in der Cloud dokumentiert.

Außerdem bietet jeder NoSQL <language>-Treiber eine API zum Ausführen einer DDL-Anweisung. Informationen zum Schreiben Ihrer Anwendung finden Sie unter Tabellen und Indexe in Oracle NoSQL Database Cloud Service mit APIs erstellen.

Typische DDL-Anweisungen

Beispiele für häufig verwendete DDL-Anweisungen:

Tabelle erstellen

CREATE TABLE [IF NOT EXISTS] (
    field-definition, field-definition-2 ...,
    PRIMARY KEY (field-name, field-name-2...),
) [USING TTL ttl]

Beispiel:

CREATE TABLE IF NOT EXISTS audience_info (
    cookie_id LONG,
    ipaddr STRING,
    audience_segment JSON,
    PRIMARY KEY(cookie_id))

Tabelle ändern

ALTER TABLE table-name (ADD field-definition)
ALTER TABLE table-name (DROP field-name)
ALTER TABLE table-name USING TTL ttl

Beispiel:

ALTER TABLE audience_info USING TTL 7 days

Index erstellen

CREATE INDEX [IF NOT EXISTS] index-name ON table-name (path_list)

Beispiel:

CREATE INDEX segmentIdx ON audience_info
       (audience_segment.sports_lover AS STRING)

Tabelle löschen

DROP TABLE [IF EXISTS] table-name

Beispiel:

DROP TABLE audience_info

Eine vollständige Liste finden Sie in der Referenzdokumentation:

DDL - Unterschiede in der Cloud

Die DDL-Sprache des Cloud-Service unterscheidet sich wie folgt von der Beschreibung in der Referenzdokumentation:

Tabellennamen

Sind auf 256 Zeichen begrenzt und dürfen nur alphanumerische Zeichen und Unterstriche enthalten
Muss mit einem Buchstaben beginnen
Darf keine Zeichen enthalten
Untergeordnete Tabellen werden nicht unterstützt

Nicht unterstützte Konzepte

DESCRIBE- und SHOW TABLE-Anweisungen
Volltextindizes
Benutzer- und Rollenverwaltung
On-Premise-Regionen

Query Language-Referenz

Erfahren Sie, wie Sie SQL-Anweisungen zum Aktualisieren und Abfragen von Daten in Oracle NoSQL Database Cloud Service verwenden.

Oracle NoSQL Database verwendet die SQL-Abfragesprache, um Daten in NoSQL-Tabellen zu aktualisieren und abzurufen. Siehe SQL-Referenz für Oracle NoSQL Database.

Standardabfragen

SELECT <expression>
FROM <table name>
[WHERE <expression>]
[GROUP BY <expression>]
[ORDER BY <expression> [<sort order>]]
[LIMIT <number>]
[OFFSET <number>]; 

For example:
SELECT * FROM Users;
SELECT id, firstname, lastname FROM Users WHERE firstname = "Taylor";

UPDATE <table_name> [AS <table_alias>]
    <update_clause>[, <update_clause>]*
WHERE <expr>[<returning_clause>];

For example:
UPDATE JSONPersons $j
  SET TTL 1 DAYS
  WHERE id = 6
  RETURNING remaining_days($j) AS Expires;

Unterschiede hinsichtlich der Abfragesprache in der Cloud

Die Abfrageunterstützung im Cloud-Service unterscheidet sich von den Angaben in der Referenzdokumentation zur Abfragesprache wie folgt:

Einschränkungen für in der SELECT-Klausel verwendete Ausdrücke

In Oracle NoSQL Database Cloud Service werden Ausdrücke und arithmetische Ausdrücke in Aggregatfunktionen gruppiert. In der SELECT-Klausel sind keine anderen Arten von Ausdrücken zulässig. Beispiel: CASE-Ausdrücke sind in der SELECT-Klausel nicht zulässig.

Jeder NoSQL-Datenbanktreiber enthält eine API zum Ausführen einer Abfrageanweisung.

Abfrageplanreferenz

Ein Abfrageausführungsplan ist die Reihenfolge der Vorgänge, die Oracle NoSQL Database zur Ausführung einer Abfrage ausführt.

Ein Abfrageausführungsplan ist ein Baum mit Planiteratoren. Jede Art von Iterator wertet eine andere Art von Ausdruck aus, der in einer Abfrage angezeigt werden kann. Im Allgemeinen kann sich die Auswahl des Index und die Art der verknüpften Indexprädikate drastisch auf die Abfrageperformance auswirken. Infolgedessen möchten Sie als Benutzer oft sehen, welcher Index von einer Abfrage verwendet wird und welche Prädikate darauf übertragen wurden. Basierend auf diesen Informationen möchten Sie möglicherweise die Verwendung eines anderen Index über Indexhinweise erzwingen. Diese Informationen sind im Abfrageausführungsplan enthalten. Alle Oracle NoSQL-Treiber stellen APIs zur Anzeige des Ausführungsplans einer Abfrage bereit.

Einige der häufigsten und wichtigsten Iteratoren, die in Abfragen verwendet werden, sind:

TABLE-Iterator: Ein Tabellen-Iterator ist verantwortlich für:

Durchsuchen des von der Abfrage verwendeten Index (der primärer Index sein kann).
Anwenden von Filterprädikaten, die an den Index übertragen werden
Rufen Sie bei Bedarf die Zeilen ab, auf die von den qualifizierenden Indexeinträgen verwiesen wird. Wenn der Index abdeckt, ist die Ergebnismenge des TABLE-Iterators eine Gruppe von Indexeinträgen. Andernfalls handelt es sich um eine Gruppe von Tabellenzeilen.

Hinweis:

Ein Index wird als Deckungsindex für eine Abfrage bezeichnet, wenn die Abfrage nur mit den Einträgen dieses Index ausgewertet werden kann, d.h. ohne die zugehörigen Zeilen abrufen zu müssen.

SELECT-Iterator: Er ist für die Ausführung des SELECT-Ausdrucks verantwortlich.

Jede Abfrage enthält eine SELECT-Klausel. Jeder Abfrageplan verfügt also über einen SELECT-Iterator. Ein SELECT-Iterator hat die folgende Struktur:


"iterator kind" : "SELECT",
"FROM" :
  {
  },
"FROM variable" : "...",
"SELECT expressions" : 
[
  {
  }
]

Der SELECT-Iterator enthält Felder wie "FROM", "WHERE", "FROM-Variable" und "SELECT-Ausdrücke". "FROM" und "FROM variable" stellen die FROM-Klausel des SELECT-Ausdrucks dar, WHERE steht für die Filterklausel und "SELECT expression" für die SELECT-Klausel.

RECEIVE-Iterator: Es handelt sich um einen speziellen internen Iterator, der den Abfrageplan in 2 Teile unterteilt:

Der RECEIVE-Iterator selbst und alle darüber liegenden Iteratoren im Iteratorbaum werden am Treiber ausgeführt.
Alle Iteratoren unter dem Iterator RECEIVE werden an den Replikationsknoten (RNs) ausgeführt. Diese Iteratoren bilden einen Unterbaum, der auf dem eindeutigen untergeordneten Element des Iterators RECEIVE verwurzelt ist.

Im Allgemeinen fungiert der RECEIVE-Iterator als Abfragekoordinator. Er sendet seinen Unterplan zur Ausführung an die entsprechenden RNs und sammelt die Ergebnisse. Sie kann zusätzliche Vorgänge wie das Sortieren und das Entfernen von Duplikaten ausführen und die Ergebnisse zur weiteren Verarbeitung an ihre Vorgängeriteratoren (sofern vorhanden) weitergeben.

Verteilungsarten:

Eine Verteilungsart gibt an, wie die Abfrage zur Ausführung auf die RNs verteilt wird, die an einer Oracle NoSQL-Datenbank (einem Speicher) teilnehmen. Die Verteilungsart ist eine Eigenschaft des Iterators RECEIVE.

Verschiedene Arten der Verteilung sind:

SINGLE_PARTITION: Eine SINGLE_PARTITION-Abfrage gibt einen vollständigen Shard-Schlüssel in der WHERE-Klausel an. Daher ist die gesamte Ergebnismenge in einer einzelnen Partition enthalten, und der Iterator RECEIVE sendet seinen Unterplan an einen einzelnen RN, der diese Partition speichert. Eine SINGLE_PARTITION-Abfrage kann entweder den Primärschlüsselindex oder einen Sekundärindex verwenden.
ALL_PARTITIONS: Abfragen verwenden hier den Primärschlüsselindex, und sie geben keinen vollständigen Shard-Schlüssel an. Wenn der Speicher M-Partitionen enthält, sendet der Iterator RECEIVE M-Kopien seines Unterplans, die jeweils über eine der M-Partitionen ausgeführt werden sollen.
ALL_SHARDS: Abfragen verwenden hier einen sekundären Index, und sie geben keinen vollständigen Shard-Schlüssel an. Infolgedessen sendet der Iterator RECEIVE N Kopien seines Unterplans, die über einen der N Shards ausgeführt werden sollen.

Anatomie eines Abfrageausführungsplans:

Die Abfrageausführung erfolgt in Batches. Wenn ein Abfragesubplan zur Ausführung an eine Partition oder ein Shard gesendet wird, wird er dort ausgeführt, bis ein Batchlimit erreicht ist. Der Batchgrenzwert ist eine Anzahl von Leseeinheiten, die von der Abfrage lokal verbraucht werden. Der Standardwert beträgt 2000 Leseeinheiten (etwa 2 MB Daten), und er kann nur über eine Option auf Abfrageebene verringert werden.

Wenn das Batchlimit erreicht ist, werden alle lokalen Ergebnisse, die produziert wurden, zur weiteren Verarbeitung an den RECEIVE-Iterator zurückgesendet, zusammen mit einem booleschen Kennzeichen, das angibt, ob möglicherweise mehr lokale Ergebnisse verfügbar sind. Bei 'Wahr' enthält die Antwort Lebenslaufinformationen. Wenn der Iterator RECEIVE beschließt, die Abfrage erneut an dieselbe Partition/ denselben Shard zu senden, nimmt er diese Lebenslaufinformationen in seine Anforderung auf, sodass die Abfrageausführung an dem Punkt neu gestartet wird, an dem sie im vorherigen Batch gestoppt wurde. Dies liegt daran, dass kein Abfragestatus an der RN verwaltet wird, nachdem ein Batch beendet wurde. Der nächste Batch für dieselbe Partition/diesen Shard kann bei demselben RN wie der vorherige Batch oder bei einem anderen RN stattfinden, der auch dieselbe Partition/diesen Shard speichert.