Conception d'une table dans le service Oracle NoSQL Database Cloud

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

Cet article contient les rubriques 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.

Les tables à schéma fixe avec des données de type défini sont plus sûres sur le plan de l'application et de l'efficacité du stockage. Bien que le schéma des tables à schéma fixe puisse être modifié, 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. Cette option offre une grande souplesse concernant les informations pouvant être stockées 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és primaires et clés 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 restent en place pendant toute la durée de vie de la table et ne peuvent pas être modifiées ou supprimées.

Clés primaires

Vous devez désigner une ou plusieurs colonnes de clé primaire lorsque vous créez votre table. Une clé primaire identifie de manière unique chaque rangée de la table. Pour des opérations simples de création, lecture et modification, 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 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 partition

L'objectif principal des clés de partition est de répartir 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 de manière atomique et efficace.

La conception de la clé principale 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 même opération ou extraire un sous-ensemble de rangées dans votre table en une seule opération. En plus de favoriser l'extensibilité, 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 approprié 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 faudrait 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 rendement optimal, 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 à prendre en compte lors de la sélection d'une clé de partition

Cardinalité : Les champs de cardinalité faibles, tels que le pays de résidence d'un utilisateur, regroupent les enregistrements sur quelques partitions. Ces partitions peuvent toutefois nécessiter un rééquilibrage fréquent des données, ce qui améliore 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 de manière uniforme, aucune partition particulière ne peut limiter la capacité du système.
Isolation des interrogations : Les interrogations doivent cibler une partition spécifique afin d'optimiser l'efficacité et la performance. Si les interrogations ne sont pas isolées à une seule partition, elles sont appliquées à 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.

De nombreuses applications gèrent des données ayant une durée de vie utile limitée. La durée de vie est un mécanisme qui permet de définir une limite après laquelle les rangées d'une table expirent automatiquement et ne sont plus disponibles. C'est le temps pendant lequel 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'apparaissent 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. Vous pouvez déclarer une valeur de durée de vie lorsque vous créez une table, en indiquant un nombre suivi 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, sauf si vous définissez explicitement une valeur de durée de vie pour des rangées de table. La définition de la valeur de durée de vie d'une rangée remplace la valeur de durée de vie de la table. Si vous modifiez la valeur de durée de vie de la table après avoir défini une valeur de durée de vie pour la rangée, 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 qu'elle n'arrive à expiration. 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

Découvrez 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. Par exemple, une table à l'état DROPPING ne peut pas passer à l'état ACTIVE, alors qu'une table à l'état ACTIVE peut passer à l'état UPDATING. 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.

Une description de table-state.png suit

Description de l'illustration table-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 Ajout ou suppression d'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 tables

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

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'identifiants séparés par des points. Le dernier identificateur est le nom local de la table enfant et les premiers identificateurs N-1 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'instruction de création de table de la table racine.
Une table parent ne peut pas être supprimée avant que ses enfants ne le soient.
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 normalisation des données est nécessaire. Les tables enfants peuvent également être un bon choix lors de la modélisation de relations 1 à N et fournissent également une sémantique de transaction ACID lors de l'écriture de plusieurs enregistrements dans une hiérarchie parent-enfant.