Exemple 1 : Conception d'une table sans schéma

Vous disposez de plusieurs options pour stocker des informations à propos des modèles de navigation dans votre table. L'une des options consiste à définir une table qui utilise un ID de cookie en tant que clé et qui conserve les données de segmentation de l'audience sous la forme d'un seul champ JSON.

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

Dans ce cas, la table audience_info peut contenir un objet JSON tel que :

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

Votre application disposera d'un champ de clé et d'un champ de données pour cette table. Les éléments que vous choisissez de stocker en tant qu'informations dans le champ audience_data sont flexibles. Vous pouvez donc facilement modifier les types d'informations disponibles.

Exemple 2 : Conception d'une table de schéma fixe

Vous pouvez stocker des informations sur les modèles de navigation en créant une table avec des champs déclarés plus explicitement :

// 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));

Dans cet exemple, votre table comporte un champ de clé et deux champs de données. Vos données sont plus compactes et vous pouvez vous assurer que tous les champs de données sont exacts.

Exemple 3 : Conception d'une table hybride

Vous pouvez stocker des informations sur les modèles de navigation à l'aide des champs de données saisis et des champs de données JSON dans la table.

// 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));

Clés primaires

Vous devez désigner des colonnes de clé primaire lors de la création de la table. Une clé primaire identifie chaque ligne de la table de façon unique. Pour les opérations CRUD simples, Oracle NoSQL Database Cloud Service utilise la clé primaire pour extraire une ligne spécifique à lire ou à modifier. Par exemple, supposons qu'une table comporte les champs suivants :

• productName

• productType

• productLine

D'expérience, vous savez que le nom du produit est important et qu'il est unique pour chaque ligne. Vous devez donc définir productName comme clé primaire. Ensuite, vous extrayez les lignes qui vous intéressent en fonction de productName. Dans un tel cas, utilisez une instruction semblable à celle-ci pour définir la table.

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

Clés de shard

Le principal objectif des clés de shard est de distribuer des données dans le cluster Oracle NoSQL Database Cloud Service pour améliorer l'efficacité, et de placer des enregistrements qui partagent la clé de shard localement pour faciliter l'accès et le référencement. Les enregistrements partageant la clé de shard sont stockés dans le même emplacement physique, et vous pouvez y accéder de manière atomique et efficace.

La conception des clés primaires et de shard a des conséquences sur l'ajustement et l'atteinte du débit provisionné. Par exemple, lorsque des enregistrements partagent des clés de shard, vous pouvez supprimer plusieurs lignes de table en une opération atomique, ou extraire un sous-ensemble de lignes dans votre table en une seule opération atomique. En plus de permettre l'évolutivité, des clés de shard bien conçues peuvent améliorer les performances car elles exigent moins de cycles pour mettre en place des données ou obtenir des données à partir d'un seul shard.

Par exemple, supposons que vous désignez trois champs de clé primaire :

PRIMARY KEY (productName, productType, productLine)

Vous savez que votre application effectue fréquemment des requêtes à l'aide des colonnes productName et productType. Vous pouvez donc indiquer ces champs comme clés de shard. La désignation de clé de shard garantit que toutes les lignes de ces deux colonnes sont stockées sur le même shard. Si ces deux champs ne sont pas des clés de shard, les colonnes les plus fréquemment interrogées peuvent être stockées sur n'importe quel shard. Ensuite, la localisation de toutes les lignes pour les deux champs nécessite l'analyse de l'ensemble du stockage de données, plutôt que d'un seul shard.

Facteurs importants à prendre en compte lors du choix d'une clé de shard

• Cardinalité : des champs de cardinalité faible, tels qu'un pays de résidence d'utilisateur, regroupent les enregistrements sur quelques shards. A leur tour, ces shards nécessitent un rééquilibrage fréquent des données, ce qui augmente la probabilité des problèmes de shard à chaud. En revanche, chaque clé de shard doit avoir une cardinalité élevée, où la clé de shard peut exprimer une tranche égale d'enregistrements dans l'ensemble de données. Par exemple, les numéros d'identité comme customerID, userID ou productID sont de bons candidats pour une clé de shard.

• Atomicité : seuls les objets partageant la clé de shard peuvent participer à une transaction. Si vous avez besoin de transactions ACID qui couvrent plusieurs enregistrements, choisissez une clé de shard qui vous permet de répondre à cette exigence.

Quelles sont les meilleures pratiques à suivre ?

• Distribution uniforme des clés de shard : lorsque les clés de shard sont distribuées uniformément, aucun shard unique ne limite la capacité du système.

• Isolement de requête : les requêtes doivent être ciblées sur un shard spécifique afin d'optimiser l'efficacité et les performances. Si les requêtes ne sont pas isolées sur un seul shard, la requête est appliquée à tous les shards, ce qui les rend moins efficaces et augmente leur latence.

Reportez-vous à Création de tables et d'index pour découvrir comment affecter des clés primaires et des clés de shard à l'aide de l'objet TableRequest.