Tabellen in Oracle NoSQL Database Cloud Service entwerfen

Tabellenfelder

Informationen zum Entwerfen und Konfigurieren von Daten unter Verwendung von Tabellenfeldern

Eine Anwendung kann schemalose Tabellen verwenden, bei denen eine Zeile aus Schlüsselfeldern und einem einzelnen JSON-Datenfeld besteht. Eine schemalose Tabelle bietet Flexibilität hinsichtlich der Daten, die in einer Zeile gespeichert werden können.

Alternativ kann die Anwendung Tabellen mit festem Schema verwenden, bei denen alle Tabellenfelder als bestimmte Typen definiert sind.

Tabellen mit festem Schema mit typisierten Daten bieten hinsichtlich Durchsetzung und Speichereffizienz höhere Sicherheit. Das Schema dieser Tabellen kann zwar bearbeitet werden, seine Tabellenstruktur kann jedoch nicht einfach geändert werden. Eine schemalose Tabelle ist flexibel, und die Tabellenstruktur kann einfach geändert werden.

Schließlich kann eine Anwendung auch einen hybriden Datenmodellansatz verwenden, bei dem eine Tabelle Daten- und JSON-Datenfelder eingeben kann.

In den folgenden Beispielen wird veranschaulicht, wie Daten für alle drei Ansätze entworfen und konfiguriert werden.

Beispiel 1: Schemalose Tabelle entwerfen

Sie haben mehrere Möglichkeiten, Informationen zu Navigationsmustern in Ihrer Tabelle zu speichern. Eine Möglichkeit ist es, eine Tabelle zu definieren, die eine Cookie-ID als Schlüssel verwendet und Zielgruppensegmentierungsdaten als ein einzelnes JSON-Feld speichert.

// schema less, data is stored in a JSON field
CREATE TABLE audience_info (
       cookie_id LONG,
       audience_data JSON,
       PRIMARY KEY(cookie_id))

In diesem Fall kann die Tabelle audience_info ein JSON-Objekt enthalten. Beispiel:

{
  "cookie_id": "",
  "audience_data": {
    "ipaddr" : "10.0.00.xxx",
    "audience_segment: {
       "sports_lover" : "2018-11-30",
       "book_reader" :  "2018-12-01"
    }
  }
}

Die Anwendung verfügt über ein Schlüssel- und ein Datenfeld für diese Tabelle. Das Feld audience_data ist so flexibel, dass beliebige Daten gespeichert werden können. Daher können Sie die verfügbaren Typen von Daten einfach ändern.

Beispiel 2: Tabelle mit festem Schema entwerfen

Sie können Informationen zu Navigationsmustern speichern, indem Sie Ihre Tabelle mit stärker deklarierten Feldern erstellen:

// fixed schema, data is stored in typed fields.
CREATE TABLE audience_info(
       cookie_id LONG,
       ipaddr STRING,
       audience_segment RECORD(sports_lover TIMESTAMP(9),
                               book_reader TIMESTAMP(9)),
       PRIMARY KEY(cookie_id))

In diesem Beispiel weist die Tabelle ein Schlüsselfeld und zwei Datenfelder auf. Ihre Daten sind kompakter, und Sie können sicherstellen, dass alle Datenfelder korrekt sind.

Beispiel 3: Hybridtabelle entwerfen

Sie können Informationen zu Navigationsmustern speichern, indem Sie sowohl typisierte Datenfelder als auch JSON-Datenfelder in der Tabelle verwenden.

// mixed, data is stored in both typed and JSON fields.
CREATE TABLE audience_info (
       cookie_id LONG,
       ipaddr STRING,
       audience_segment JSON,
       PRIMARY KEY(cookie_id))

Primärschlüssel und Shard-Schlüssel

Finden Sie heraus, welchen Zweck Primärschlüssel und Shard-Schlüssel beim Entwerfen Ihrer Anwendung haben.

Primärschlüssel und Shard-Schlüssel sind wichtige Elemente in Ihrem Schema. Mit ihnen können Sie Daten effizient aufrufen und verteilen. Sie erstellen Primärschlüssel und Shard-Schlüssel nur beim Erstellen einer Tabelle. Sie bleiben für die Lebensdauer der Tabelle erhalten und können nicht geändert oder gelöscht werden.

Primärschlüssel

Sie müssen beim Erstellen der Tabelle mindestens eine Primärschlüsselspalte angeben. Ein Primärschlüssel identifiziert jede Zeile in der Tabelle eindeutig. Für einfache CRUD-Vorgänge verwendet Oracle NoSQL Database Cloud Service den Primärschlüssel, um bestimmte Zeilen für Lese- oder Bearbeitungsvorgänge abzurufen. Beispiel: Eine Tabelle enthält die folgenden Felder:

productName
productType
productLine

Aus Erfahrung wissen Sie, dass der Produktname wichtig und für jede Zeile eindeutig ist. Sie setzen also productName als Primärschlüssel. Anschließend abrufen Sie die gewünschten Zeilen basierend auf productName. Verwenden Sie in einem solchen Fall eine Anweisung wie diese, um die Tabelle zu definieren.

/* Create a new table called users. */
CREATE TABLE if not exists myProducts 
(
  productName STRING,
  productType STRING,
  productLine INTEGER,
  PRIMARY KEY (productName)
)"

Shard-Schlüssel

Der Hauptzweck von Shard-Schlüsseln ist es, Daten zur Effizienzsteigerung über das Oracle NoSQL Database Cloud Service-Cluster zu verteilen und Datensätze mit demselben Shard-Schlüssel zur einfachen Referenz und schnellem Zugriff lokal abzulegen. Datensätze mit demselben Shard-Schlüssel werden am selben physischen Speicherort gespeichert und können atomar und effizient aufgerufen werden.

Das Design der primären und Shard-Schlüssel hat Auswirkungen auf die Skalierung und das Erreichen des bereitgestellten Durchsatzes. Beispiel: Wenn Datensätze denselben Shard-Schlüssel verwenden, können Sie mehrere Tabellenzeilen in einem atomaren Vorgang löschen oder eine Teilmenge von Zeilen in der Tabelle in einem einzigen atomaren Vorgang abrufen. Gut konzipierte Shard-Schlüssel ermöglichen nicht nur die Skalierung, sondern können auch die Performance verbessern, da weniger Zyklen erforderlich sind, um Daten einem einzelnen Shard zuzuweisen oder Daten aus einem einzelnen Shard abzurufen.

Beispiel: Sie geben drei Primärschlüsselfelder an:

PRIMARY KEY (productName, productType, productLine)

Da Ihre Anwendung häufig Abfragen mit den Spalten productName und productType ausführt, ist die Angabe dieser Felder als Shard-Schlüssel angebracht. Die Festlegung als Shard-Schlüssel stellt sicher, dass alle Zeilen für diese beiden Spalten im selben Shard gespeichert werden. Wenn es sich bei diesen beiden Feldern nicht um Shard-Schlüssel handelt, könnten die am häufigsten abgefragten Spalten in einem beliebigen Shard gespeichert werden. Bei der Suche nach allen Zeilen für beide Felder muss dann der gesamte Datenspeicher anstelle eines einzigen Shards gescannt werden.

Shard-Schlüssel definieren die Speicherung im selben Shard, um effiziente Abfragen für Schlüsselwerte zu ermöglichen. Da Ihre Daten jedoch für eine optimale Performance auf die Shards verteilt werden sollen, müssen Sie Shard-Schlüssel vermeiden, die wenige eindeutige Werte aufweisen.

Hinweis:

Wenn Sie beim Erstellen einer Tabelle keine Shard-Schlüssel angeben, verwendet Oracle NoSQL Database Cloud Service die Primärschlüssel zur Shard-Organisation.

Wichtige Faktoren bei der Auswahl eines Shard-Schlüssel

Kardinalität: Bei Feldern mit niedriger Kardinalität (Beispiel: Heimatland eines Benutzers) werden Datensätze in wenigen Shards gruppiert. Im Gegenzug erfordern diese Shards ein häufiges Rebalancing der Daten, was die Wahrscheinlichkeit des Auftretens von Problemen mit hochfrequentierten Shards erhöht. Stattdessen sollte jeder Shard-Schlüssel eine hohe Kardinalität aufweisen, mit der der Shard-Schlüssel einen geraden Datensatzbereich im Datensatz ausdrücken kann. Beispiel: ID-Nummern wie customerID, userID oder productID sind gute Kandidaten für einen Shard-Schlüssel.
Atomarität: Nur Objekte mit demselben Shard-Schlüssel können an einer Transaktion teilnehmen. Wenn Sie ACID-Transaktionen benötigen, die mehrere Datensätze umfassen, wählen Sie einen Shard-Schlüssel aus, um diese Anforderung zu erfüllen.

Welche Best Practices sind zu befolgen?

Einheitliche Verteilung von Shard-Schlüsseln: Wenn Shard-Schlüssel gleichmäßig verteilt werden, wird die Kapazität des Systems nicht durch ein einzelnes Shard begrenzt.
Isolation von Abfragen: Für maximale Effizienz und Performance müssen Abfragen auf ein bestimmtes Shard ausgerichtet werden. Wenn keine Isolation von Abfragen auf ein einzelnes Shard gegeben ist, wird die Abfrage auf alle Shards angewendet. Dies ist weniger effizient und erhöht die Abellatenz.

Unter Tabellen erstellen erfahren Sie, wie Sie Primärschlüssel und Shard-Schlüssel mit dem TableRequest-Objekt zuweisen.

Gültigkeitsdauer

Erfahren Sie, wie Sie mit dem Feature "TTL" Ablaufzeiten für Tabellen und Zeilen angeben.

In vielen Anwendungen werden Daten mit einer begrenzten Nutzungsdauer verwaltet. Die Gültigkeitsdauer (TTL) ist ein Verfahren, mit dem Sie einen Zeitraum für Tabellenzeilen festlegen können, nach welchem die Zeilen automatisch ablaufen und nicht mehr verfügbar sind. Sie gibt an, wie lange die Daten in Oracle NoSQL Database Cloud Service bleiben dürfen. Daten mit erreichter Ablaufzeit können nicht mehr abgerufen werden und werden nicht mehr in Speicherstatistiken angezeigt.

Standardmäßig weist jede Tabelle, die Sie erstellen, einen TTL-Wert von null auf, das heißt, es wird keine Ablaufzeit angegeben. Sie können einen TTL-Wert beim Erstellen einer Tabelle angeben. Dabei geben Sie die Gültigkeitsdauer mit einer Zahl an, gefolgt von HOURS oder DAYS. Tabellenzeilen erben den TTL-Wert der Tabelle, in der sie enthalten sind, sofern Sie nicht explizit einen TTL-Wert für Tabellenzeilen festlegen. Wenn Sie einen TTL-Wert für eine Zeile festlegen, wird der TTL-Wert der Tabelle überschrieben. Wenn Sie den TTL-Wert der Tabelle ändern, nachdem für die Zeile ein TTL-Wert festgelegt wurde, wird der TTL-Wert der Zeile beibehalten.

Sie können den TTL-Wert für eine Tabellenzeile jederzeit aktualisieren, bevor die Ablaufzeit der Zeile erreicht wurde. Auf abgelaufene Daten kann nicht mehr zugegriffen werden. Daher ist die Verwendung von TTL-Werten effizienter als das manuelle Löschen von Zeilen, weil das Schreiben eines Datenbanklogeintrags für die Datenlöschung vermieden wird. Die abgelaufenen Daten werden nach dem Ablaufdatum vom Datenträger gelöscht.

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.

Tabellenhierarchien

Mit Oracle NoSQL Database können Tabellen in einer Parent-Child-Beziehung vorhanden sein. Dies wird als Tabellenhierarchien bezeichnet.

Mit der Anweisung "Tabelle erstellen" kann eine Tabelle als untergeordnetes Element einer anderen Tabelle erstellt werden, die dann zum übergeordneten Element der neuen Tabelle wird. Dazu wird ein zusammengesetzter Name (name_path) für die untergeordnete Tabelle verwendet. Ein zusammengesetzter Name besteht aus einer Zahl N (N > 1) von durch Punkte getrennten Kennungen. Die letzte ID ist der lokale Name der untergeordneten Tabelle, und die ersten N-1-IDs zeigen auf den Namen des übergeordneten Elements.

Eigenschaften von übergeordneten/untergeordneten Tabellen:

Eine untergeordnete Tabelle erbt die Primärschlüsselspalten ihrer übergeordneten Tabelle.
Alle Tabellen in der Hierarchie haben dieselben Shard-Schlüsselspalten, die in der Anweisung "Tabelle erstellen" der Root-Tabelle angegeben sind.
Eine übergeordnete Tabelle kann nicht gelöscht werden, bevor ihre untergeordneten Tabellen gelöscht werden.
Ein referenzielles Integritäts-Constraint wird in einer über-/untergeordneten Tabelle nicht durchgesetzt.

Sie sollten die Verwendung von untergeordneten Tabellen in Betracht ziehen, wenn eine Form der Datennormalisierung erforderlich ist. Untergeordnete Tabellen können auch bei der Modellierung von 1-zu-N-Beziehungen eine gute Wahl sein und auch ACID-Transaktionssemantik beim Schreiben mehrerer Datensätze in eine hierarchische Hierarchie bereitstellen.