Conception d'une table dans Oracle NoSQL Database Cloud Service

En savoir plus sur la conception et la configuration des tables dans Oracle NoSQL Database Cloud Service.

Cet article comprend les rubriques suivantes :

Champs de table

En savoir plus sur la conception et la configuration de données à l'aide de champs de table.

Une application peut choisir d'utiliser des tables sans schéma, dans lesquelles une ligne comprend des champs de clés et un champ de données JSON unique. Une table sans schéma offre une flexibilité quant aux éléments pouvant être stockés dans une ligne.

L'application peut également choisir d'utiliser des tables de schéma fixes dans lesquelles tous les champs de table sont définis en tant que types spécifiques.

Les tables de schéma fixe contenant des données saisies sont plus sûres du point de vue de l'application et l'efficacité du stockage. Bien qu'il soit possible de modifier le schéma de ces tables, la structure des tables ne peut pas être facilement modifiée. Une table sans schéma est flexible et la structure de la table peut être facilement modifiée.

Enfin, l'application peut également utiliser une approche de modèle de données hybride dans laquelle une table peut disposer de champs de données JSON et de données saisies.

Les exemples suivants illustrent la conception et la configuration des données pour les trois approches.

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, vous disposez d'un champ de clé et de deux champs de données. Vos données sont plus compactes et vous pouvez garantir l'exactitude de tous vos champs de données.

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 et clés de shard

Découvrez l'objectif des clés primaires et des clés de shard pendant la conception de l'application.

Les clés primaires et les clés de partage sont des éléments importants dans le schéma. Elles vous aident à accéder aux données et à les distribuer efficacement. Vous créez des clés primaires et des clés de shard uniquement lorsque vous créez une table. Elles sont conservées pendant toute la durée de vie de la table et ne peuvent être modifiées ou supprimées.

Clés primaires

Vous devez désigner des colonnes de clé primaire lors de la création de la table. Chaque ligne de la table est identifiée par une clé primaire. 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

Sachant que le nom du produit est important et qu'il est unique pour chaque ligne, vous devez 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 à ceci 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 but principal 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 principales 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'évolution, 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.

Supposons, par exemple, que vous définissez 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 shard.

Les clés de shard désignent le stockage sur le même shard afin de faciliter l'efficacité des requêtes pour les valeurs de clé. Toutefois, comme vous voulez que vos données soient distribuées sur les shards pour de meilleures performances, évitez les clés de shard ayant peu de valeurs uniques.

Remarques :

Si vous n'indiquez pas de clés de shard lors de la création d'une table, Oracle NoSQL Database Cloud Service utilise les clés primaires pour l'organisation de 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 partage doit avoir une cardinalité élevée, où la clé de partage 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.

• Isolation 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 réduit et augmente leur latence.

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

Durée de vie

Découvrez comment indiquer un délai d'expiration pour les tables et les lignes à l'aide de la fonctionnalité Durée de vie.

De nombreuses applications gèrent des données qui ont une durée de vie utile limitée. La durée de vie est un mécanisme qui vous permet de définir sur les lignes de la table une période après laquelle les lignes arrivent à expiration automatiquement et ne sont plus disponibles. C'est la durée pendant laquelle les données sont autorisées à rester dans Oracle NoSQL Database Cloud Service. Les données qui atteignent le délai d'expiration ne peuvent plus être extraites et n'affichent pas dans les statistiques de stockage.

Par défaut, la valeur de durée de vie de chaque table que vous créez est zéro, ce qui indique l'absence de délai d'expiration. Lorsque vous créez une table, vous pouvez en indiquer un, suivi de HOURS ou DAYS. Les lignes de table héritent de la valeur de durée de vie de la table dans laquelle elles résident, à moins que vous n'en définissiez explicitement une. La définition de la valeur de durée de vie d'une ligne remplace la valeur de durée de vie de la table. Si vous modifiez la valeur de durée de vie de la table une fois que la ligne a une valeur de durée de vie, la valeur de durée de vie de la ligne est conservée.

Vous pouvez mettre à jour la valeur de durée de vie d'une ligne de table à tout moment avant que la ligne n'arrive à expiration. Les données arrivées à expiration ne sont plus accessibles. Par conséquent, l'utilisation de valeurs TTL est plus efficace que la suppression manuelle de lignes, car le temps système de l'écriture d'une entrée de journal de base de données pour la suppression de données est évité. Les données arrivées à expiration sont supprimées du disque après la date d'expiration.

Cycles de vie et états de table

Apprenez-en davantage sur les différents états de table et sur leur signification (processus de cycle de vie des tables).

Chaque table passe par une série d'états différents de sa création à sa suppression. Par exemple, une table à l'état DROPPING ne peut pas passer à l'état ACTIVE, tandis qu'une table à l'état ACTIVE peut passer à l'état UPDATING. Vous pouvez suivre les différents états d'une table en surveillant son cycle de vie. Cette section décrit les différents états d'une table.

Description du tableau de l'illustration : state.png

Etat de la table	Description
CREATING	La table est en cours de création. Elle n'est pas encore prête à l'emploi.
UPDATING	La table est en cours de mise à jour. Vous ne pouvez pas apporter d'autres modifications à la table tant qu'elle est dans cet état. Une table a l'état UPDATING : Les limites de la table sont en cours de modification l'évolution du schéma de la table, en ajoutant ou en supprimant un index.
ACTIVE	La table peut être utilisée lorsqu'elle est dans cet état. La table a peut-être été récemment créée ou modifiée, mais l'état de la table est désormais stable.
DROPPING	La table est en cours de suppression et n'est pas accessible.
DROPPED	La table a été supprimée et n'existe plus pour les activités de lecture, d'écriture ou de requête. Remarques : Une fois supprimée, vous pouvez recréer une table du même nom.

Hiérarchies de table

Oracle NoSQL Database permet aux tables d'exister dans une relation parent-enfant. Il s'agit des hiérarchies de table.

L'instruction create table permet de créer une table en tant qu'enfant d'une autre table, qui devient alors le parent de la nouvelle table. Pour ce faire, utilisez un nom de composite (name_path) pour la table enfant. Un nom composite est constitué d'un nombre N (N > 1) d'identificateurs séparés par des points. Le dernier identificateur est le nom local de la table enfant et les N-1 premiers identifiants pointent vers le nom du parent.

Caractéristiques des tables parent-enfant :

• Une table enfant hérite des colonnes de clé primaire de sa table parent.
• Toutes les tables de la hiérarchie ont les mêmes colonnes de clé de shard, spécifiées dans l'instruction de création de table de la table racine.
• Une table parent ne peut pas être supprimée avant que ses enfants ne soient supprimés.
• Une contrainte d'intégrité référentielle n'est pas appliquée dans une table parent-enfant.

Vous devez envisager d'utiliser des tables enfant lorsqu'une certaine forme de normalisation des données est requise. Les tables enfant peuvent également être un bon choix lors de la modélisation de relations 1 à N et fournir une sémantique de transaction ACID lors de l'écriture de plusieurs enregistrements dans une hiérarchie parent-enfant.

---

Informations relatives au titre et au copyright

Conception d'une table dans Oracle NoSQL Database Cloud Service

Copyright ©2022,2024,

Oracle et/ou ses affiliés.