Concevoir une table dans Oracle NoSQL Database Cloud Service

Voyez comment concevoir et configurer des tables dans Oracle NoSQL Database Cloud Service.

Cet article contient les informations suivantes :

Champs de table

Voyez comment concevoir et configurer des données à l'aide de champs de table.

Une application peut choisir d'utiliser des tables sans schéma, où une rangée est composée de champs de clé et d'un seul champ de données JSON. Une table sans schéma offre une grande flexibilité concernant ce qui peut être stocké dans une rangée.

L'application peut également choisir d'utiliser des tables à schéma fixe, où tous les champs de table sont définis avec des types spécifiques.

Sur le plan de l'application et de l'efficacité du stockage, les tables à schéma fixe avec des données de type défini sont plus sûres. Bien qu'il soit possible de modifier le schéma des tables à schéma fixe, il n'est pas facile de modifier leur structure. Une table sans schéma est flexible et la structure de la table peut être modifiée facilement.

Enfin, une application peut également utiliser une approche hybride de modèle de données dans laquelle une table peut contenir des données de type défini et des champs de données JSON.

Les exemples suivants montrent comment concevoir et configurer des données pour les trois approches.

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

Il existe plusieurs options pour stocker des informations sur les modèles de navigation dans une table. Une option consiste à définir une table qui utilise un ID témoin comme clé et qui conserve les données de segmentation du public en tant que champ JSON unique.

// 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 comme celui-ci :

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

Votre application aura un champ clé et un champ de données pour cette table. Ce que vous avez choisi de stocker en tant qu'informations est flexible dans le champ audience_data. Vous pouvez donc modifier facilement les types d'informations disponibles.

Exemple 2 : Conception d'une table à 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 de manière plus explicite :

// 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, la table comporte un champ clé et deux champs de données. Les données sont plus compactes et vous pouvez 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 en utilisant à la fois des champs de données de type défini et des champs de données JSON de votre 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é primaire et clé de partition

Découvrez le rôle des clés primaires et des clés de partition lors de la conception de votre application.

Les clés primaires et les clés de partition sont des éléments importants de votre schéma, qui vous aident à accéder aux données et à les distribuer de manière efficace. Vous créez des clés primaires et des clés de partition seulement lors de la création d'une table. Elles demeurent en place pendant toute la vie de la table et ne peuvent pas être modifiées ou supprimées.

Clés primaires

Lorsque vous créez une table, vous devez désigner une ou plusieurs colonnes de clé primaire. Une clé primaire identifie uniquement chaque rangée de la table. Pour les opérations CRUD simples, Oracle NoSQL Database Cloud Service utilise la clé primaire pour extraire une rangée spécifique à lire ou à modifier. Prenons, par exemple, une table ayant les champs suivants :

• productName

• productType

• productLine

Par expérience, vous savez que le nom du produit est important et unique pour chaque rangée, donc vous désignez productName comme clé primaire. Puis, vous extrayez les rangées d'intérêt basées sur productName. Dans un tel cas, utilisez un énoncé semblable au suivant :

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

Clés de partition

L'objectif principal des clés de partition est de distribuer les données dans la grappe Oracle NoSQL Database Cloud Service pour une efficacité accrue et de positionner les enregistrements qui partagent la clé de partition localement pour faciliter les références et l'accès. Les enregistrements qui partagent la clé de partition sont stockés dans le même emplacement physique et sont accessibles individuellement et de manière efficace.

La conception de la clé primaire et de la clé de partition a une incidence sur la mise à l'échelle et sur l'obtention du débit provisionné. Par exemple, lorsque des enregistrements partagent des clés de partition, vous pouvez supprimer plusieurs rangées de table dans une opération ou extraire un sous-ensemble de rangées dans votre table en une seule opération. En plus de favoriser l'évolutivité, des clés de partition bien conçues peuvent améliorer la performance, car elles nécessitent moins de cycles pour écrire des données dans une partition horizontale ou en obtenir.

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

PRIMARY KEY (productName, productType, productLine)

Comme vous savez que votre application exécute souvent des interrogations avec les colonnes productName et productType, il est préférable de désigner ces champs comme clés de partition. La désignation des clés de partition garantit que toutes les rangées de ces deux colonnes sont stockées dans la même partition horizontale. Si ces deux champs ne sont pas des clés de partition, les colonnes les plus fréquemment interrogées pourraient être stockées dans n'importe quelle partition. Pour localiser toutes les rangées de ces deux champs, il faut balayer tout le stockage de données, plutôt qu'une seule partition.

Des clés de partition désignent le stockage sur la même partition pour accroître l'efficacité des interrogations sur des valeurs de clé. Toutefois, comme vous voulez que vos données soient réparties dans l'ensemble des partitions pour un meilleur rendement, vous devez éviter les clés de partition ayant quelques valeurs uniques.

Note :

Si vous ne désignez pas de clés de partition lors de la création d'une table, Oracle NoSQL Database Cloud Service utilise les clés primaires pour l'organisation de partition.

Facteurs importants à considérer lors de la sélection d'une clé de partition

• Cardinalité : Les champs de cardinalité faible, tels que le pays de résidence d'un utilisateur, regroupent les enregistrements sur quelques partitions. À leur tour, ces partitions ont besoin d'un rééquilibre fréquent des données, ce qui augmente la probabilité de problèmes de partition. Chaque clé de partition doit plutôt avoir une cardinalité élevée, et ainsi pouvoir exprimer une tranche régulière d'enregistrements dans le jeu de données. Par exemple, les numéros d'identité tels que customerID, userID ou productID, sont de bons candidats pour une clé de partition.

• Atomicité : Seuls les objets qui partagent la clé de partition peuvent participer à une transaction. Si vous avez besoin de transactions ACID couvrant de multiples enregistrements, choisissez une clé de partition qui vous permet de satisfaire à cette exigence.

Quelles sont les meilleures pratiques à suivre?

• Répartition uniforme des clés de partition : Lorsque les clés de partition sont réparties uniformément, aucune partition particulière ne peut limiter la capacité du système.

• Isolation des requêtes : Les requêtes doivent cibler une partition spécifique afin d'optimiser l'efficacité et la performance. S'il n'y a pas d'interrogation isolée à une seule partition, elle est appliquée à toutes les partitions, ce qui est moins efficace et augmente la latence des interrogations.

Voir Création de tables pour savoir comment affecter des clés primaires et des clés de partition à l'aide de l'objet TableRequest.

Durée de vie

Voyez comment spécifier les temps d'expiration pour les tables et les rangées à l'aide de la fonctionnalité de durée de vie.

Beaucoup d'applications gèrent des données ayant une vie utile limitée. La durée de vie est un mécanisme qui permet de définir une durée après laquelle les rangées d'une table expirent automatiquement et ne sont plus disponibles. Il s'agit de la durée pendant laquelle les données sont autorisées à rester dans Oracle NoSQL Database Cloud Service. Les données arrivées à expiration ne peuvent plus être extraites et n'affichent plus dans les statistiques de stockage.

Par défaut, chaque table que vous créez a une valeur de durée de vie de zéro, ce qui signifie qu'il n'y a pas de délai d'expiration. Lorsque vous créez une table, vous pouvez déclarer une valeur, suivie de HOURS ou DAYS. Les rangées de table héritent de la valeur de durée de vie de la table dans laquelle elles se trouvent, à moins que vous n'en définissiez explicitement une. La valeur de durée de vie définie pour une rangée remplace celle de la table. Si vous modifiez la valeur de durée de vie de la table une fois que la rangée a une valeur de durée de vie, la valeur de la rangée persiste.

Vous pouvez mettre à jour la valeur de durée de vie pour une rangée de table à tout moment avant l'expiration de celle-ci. Les données expirées ne sont plus accessibles. Par conséquent, l'utilisation de valeurs de durée de vie est plus efficace que la suppression manuelle de rangées, car cela évite la surcharge que représente l'écriture d'une entrée de journal de base de données pour la suppression de données. Les données expirées sont épurées du disque après la date d'expiration.

États des tables et cycles de vie

En savoir plus sur les différents états des tables et leur importance (processus de cycle de vie de table).

Chaque table passe par une série d'États différents de sa création à sa suppression. For example, a table in the DROPPING state cannot proceed to the ACTIVE state, while a table in the ACTIVE state can change to the UPDATING state. Vous pouvez suivre les différents états d'une table en surveillant le cycle de vie de la table. Cette section décrit les différents états de table.

Description de l'illustration du tableau-state.png

État de table	Description
CREATING	La table est en cours de création. Elle n'est pas encore disponible.
UPDATING	Mise à jour de la table en cours. Il n'est pas possible d'effectuer d'autres modifications lorsque la table est à cet état. Une table est à l'état UPDATING lorsque : Les limites de la table sont en cours de modification Le schéma de la table évolue Ajouter ou supprimer un index de table
ACTIVE	La table peut être utilisée à l'état courant. La table a peut-être été créée récemment ou modifiée, mais l'état de la table est maintenant 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 des activités de lecture, d'écriture ou d'interrogation. Note : Une fois qu'une table est supprimée, une nouvelle table portant le même nom peut être créée.

Hiérarchies de la table

Oracle NoSQL Database permet aux tables d'exister dans une relation parent-enfant. C'est ce qu'on appelle les 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 identificateurs 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 partition, qui sont spécifiées dans l'énoncé 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 enfants lorsqu'une forme quelconque de normalisation des données est requise. Les tables enfants 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.

---

Titre et droits d'auteur

Concevoir une table dans Oracle NoSQL Database Cloud Service

Copyright ©2022,2024,

Oracle et/ou ses sociétés affiliées.