Beispiel 1: Schemalose Tabelle entwerfen

Sie haben mehrere Möglichkeiten, Informationen zu Navigationsmustern in Ihrer Tabelle zu speichern. Eine Möglichkeit besteht darin, 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üsselfeld 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 eindeutiger 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

Sie müssen beim Erstellen der Tabelle mindestens eine Primärschlüsselspalte angeben. Ein Primärschlüssel identifiziert jede Zeile in der Tabelle eindeutig. Bei einfachen CRUD-Vorgängen ruft Oracle NoSQL Database Cloud Service bestimmte Zeilen anhand ihrer Primärschlüssel für Lese- oder Bearbeitungsvorgänge ab. Angenommen, eine Tabelle enthält die folgenden Felder:

• productName

• productType

• productLine

Erfahrungsgemäß ist der Produktname wichtig und für jede Zeile eindeutig. Sie legen also productName als Primärschlüssel fest. Anschließend rufen Sie die gewünschten Zeilen basierend auf productName ab. 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 besteht darin, Daten zur Effizienzsteigerung über das Oracle NoSQL Database Cloud Service-Cluster zu verteilen und Datensätze mit demselben Shard-Schlüssel zwecks einfacher 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ärschlüssel 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. Optimal 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.

Angenommen, 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, empfiehlt es sich, diese Felder als Shard-Schlüssel anzugeben. 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 in solch einem Fall der gesamte Datenspeicher anstatt nur ein einziges Shard gescannt werden.

Wichtige Faktoren beim Auswählen eines Shard-Schlüssels

• Kardinalität: Bei Feldern mit niedriger Kardinalität (Beispiel: Heimatland eines Benutzers) werden Datensätze in wenigen Shards gruppiert. Diese Shards erfordern ein häufiges Rebalancing der Daten, was die Wahrscheinlichkeit des Auftretens von Problemen aufgrund hochfrequentierter Shards erhöht. Stattdessen sollte jeder Shard-Schlüssel eine hohe Kardinalität aufweisen, mit der der Shard-Schlüssel ein gleichmäßiges Datensatzsegment im Dataset 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, mit dem Sie diese Anforderung erfüllen können.

Welche Best Practices sind zu befolgen?

• Gleichmäßige 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 höchste 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 Abfragelatenz.

Unter Tabellen und Indizes erstellen erhalten Sie weitere Informationen zum Zuweisen von Primärschlüsseln und Shard-Schlüsseln mit dem TableRequest-Objekt.