Informations de référence sur Oracle NoSQL Database Cloud Service

Découvrez les types de données pris en charge, les énoncés LDD et les paramètres et mesures du service Oracle NoSQL Database Cloud Service.

Cet article contient les informations suivantes :

Types de données pris en charge

Le service Oracle NoSQL Database Cloud Service prend en charge de nombreux types de données communs.

Type de données Description

BINARY

Une séquence de zéro octet ou plus. La taille de stockage est le nombre d'octets plus un encodage de la taille du tableau d'octets, qui est une variable, en fonction de la taille du tableau.

FIXED_BINARY Tableau d'octets de taille fixe. Il n'y a pas de surcharge d'encodage supplémentaire pour ce type de données.

BOOLEAN

Type de données dont la valeur peut être TRUE ou FALSE. La taille de stockage du booléen est de 1 octet.

DOUBLE

Nombre à virgule flottante long, encodé à l'aide de 8 octets de stockage pour les clés d'index. S'il s'agit d'une clé primaire, elle utilise 10 octets de stockage.

FLOAT

Nombre à virgule flottante long, encodé à l'aide de 4 octets de stockage pour les clés d'index. S'il s'agit d'une clé primaire, elle utilise 5 octets de stockage.

LONG

Un nombre entier long a un encodage de longueur variable qui utilise 1-8 octets de stockage en fonction de la valeur. S'il s'agit d'une clé primaire, elle utilise 10 octets de stockage.

INTEGER

Un nombre entier long a un encodage de longueur variable qui utilise 1-4 octets de stockage en fonction de la valeur. S'il s'agit d'une clé primaire, elle utilise 5 octets de stockage.

STRING

Séquence de zéro caractère ou plus. Le type String est encodé en UTF-8 et stocké dans cet encodage. La taille de stockage est le nombre d'octets UTF-8 plus la longueur, qui peut être de 1-4 octets selon le nombre d'octets dans l'encodage. Lorsqu'elle est stockée dans une clé d'index, la taille de stockage est le nombre d'octets UTF-8 plus un seul octet d'arrêt nul.

NUMBER

Numéro décimal signé avec précision arbitraire.

Il est sérialisé dans un format de tableau d'octets qui peut être utilisé pour les comparaisons ordonnées. Le format comporte 2 parties :
  1. Le signe et l'exposant plus un chiffre. Cela prend de 1 à 6 octets, mais est normalement de 2, sauf si l'exposant est assez grand
  2. La mantisse de la valeur qui est d'environ un octet pour chaque 2 chiffres

Exemples :

12.345678 sérialise en 6 octets

1.234E+102 sérialise en 5 octets

Note :

Lorsque vous devez utiliser des valeurs numériques dans votre schéma, il est recommandé de décider des types de données dans l'ordre indiqué ci-dessous : INTEGER, LONG, FLOAT, DOUBLE, NUMBER Évitez NUMBER sauf si vous en avez vraiment besoin pour votre cas d'utilisation, car NUMBER est coûteux à la fois en termes de puissance de stockage et de traitement utilisée.
TIMESTAMP

Point dans le temps avec une précision. La précision a une incidence sur la taille et l'utilisation du stockage. L'heure est stockée et gérée en UTC (Temps universel coordonné). Le type de données Horodatage nécessite entre 3 et 9 octets en fonction de la précision utilisée.

La répartition suivante illustre le stockage utilisé par ce type de données :
  • bit[0~13] année - 14 bits
  • bit[14~17] mois - 4 bits
  • bit[18~22] jour - 5 bits
  • bit[23~27] heure - 5 bits [facultatif]
  • bit[28~33] minute - 6 bits [facultatif]
  • bit[34~39] seconde - 6 bits [facultatif]
  • bit[40~71] fractionnaire seconde [facultatif avec longueur variable]

UUID

Remarque : Le type de données UUID est considéré comme un sous-type du type de données STRING. La taille du stockage est de 16 octets en tant que clé d'index. Si elle est utilisée comme clé primaire, la taille du stockage est de 19 octets.

ENUM

Une énumération est représentée sous forme de tableau de chaînes. Les valeurs ENUM sont des identificateurs symboliques (jetons) et sont stockées en tant que petite valeur entière représentant une position dans l'énumération.

ARRAY

Collection ordonnée de zéro ou plus dactylographiés. Les tableaux qui ne sont pas de type JSON ne peuvent pas contenir de valeurs NULL.

Les tableaux déclarés avec le type JSON peuvent contenir des données JSON valides, y compris la valeur spéciale, null, qui est pertinente pour JSON.

MAP

Collection non triée de zéro ou plusieurs paires clé-élément, où toutes les clés sont des chaînes et tous les éléments sont de même type. Toutes les clés doivent être uniques. Les paires clé-élément sont appelées champs, les clés étant les noms de champ et les éléments associés étant les valeurs de champ. Les valeurs de champ peuvent être de différents types, mais les mappages ne peuvent pas contenir de valeurs de champ NULL.

RECORD

Collection fixe d'une ou de plusieurs paires clé-élément, où toutes les clés sont des chaînes. Chaque clé d'enregistrement doit être unique.

JSON

Toute donnée JSON valide.

É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 du tableau-state.png :
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.

Débogage des erreurs d'énoncé SQL dans la console OCI

Lorsque vous utilisez la console OCI pour créer une table à l'aide d'un énoncé LDD ou d'un énoncé LMD pour insérer ou mettre à jour des données ou à l'aide d'une interrogation SELECT pour extraire des données, vous pouvez obtenir une erreur indiquant que votre énoncé est incomplet ou défectueux dans l'un des scénarios courants suivants :
  • Si vous avez un point-virgule à la fin de l'énoncé SQL.
  • S'il y a une erreur de syntaxe dans votre instruction SQL, comme l'utilisation incorrecte de virgules, l'utilisation de tout caractère inutile dans l'instruction, etc.
  • S'il y a une erreur d'orthographe dans votre instruction SQL dans l'un des mots clés SQL ou dans votre définition de type de données.
  • Si vous avez défini la colonne comme NOT NULL mais que vous ne lui avez pas affecté de valeur DEFAULT.
  • Si vous avez défini la colonne comme NOT NULL mais que vous ne lui avez pas affecté de valeur DEFAULT.
Comment gérer certaines erreurs incomplets ou erronées lors de l'utilisation de la console OCI pour créer ou gérer des données :
  • Supprimez le point-virgule (le cas échéant) à la fin de l'énoncé SQL.
  • Vérifiez s'il existe un caractère indésirable ou une ponctuation incorrecte dans l'instruction SQL.
  • Recherchez les erreurs d'orthographe dans votre instruction SQL.
  • Vérifiez si toutes vos définitions de colonne sont complètes et correctes.
  • Vérifiez si vous avez défini une clé primaire pour votre table.

Si vous obtenez toujours une erreur après avoir éliminé certaines des situations possibles décrites ci-dessus, vous pouvez utiliser Cloud Shell pour exécuter votre interrogation et saisir l'erreur exacte, comme illustré dans l'exemple ci-dessous.

Exemple : Obtention du message d'erreur pour une instruction SELECT à partir de l'interpréteur de commandes en nuage

La commande summarize (Sommaire) vérifie la syntaxe et retourne un bref sommaire d'un énoncé SQL.
  1. Dans la console OCI, ouvrez Cloud Shell dans le menu supérieur droit.
  2. Copiez votre énoncé SQL SELECT (par exemple, query1.sql) dans une variable (SQL_SELECTSTMT).
    Exemple :
    SQL_SELECTSTMT=$(cat ~/query1.sql | tr '\n' ' ')
  3. Appelez la commande oci ci-dessous pour vérifier la syntaxe de votre instruction SQL SELECT.

    Note :

    Vous devez indiquer compartment_id pour cet énoncé SELECT.
    oci raw-request --http-method GET --target-uri 
    https://nosql.${OCI_REGION}.oci.oraclecloud.com/20190828/query/summarize?compartmentId=$NOSQL_COMPID\
    &statement="$SQL_SELECTSTMT" | jq '.data'

Cela vous donnera l'erreur exacte dans votre instruction SQL.

Informations de référence sur le langage de définition de données

Voyez comment utiliser le langage LDD dans Oracle NoSQL Database Cloud Service.

Utilisez le langage LDD d'Oracle NoSQL Database Cloud Service pour créer, modifier et supprimer des tables et des index.

Pour plus d'informations sur la syntaxe du langage LDD, voir le Guide sur l'utilisation du langage de définition de données avec les tables. Ce guide documente le langage LDD pris en charge par le produit Oracle NoSQL Database sur place. Oracle NoSQL Database Cloud Service prend en charge un sous-ensemble de cette fonctionnalité et les différences sont documentées dans la section Différences LDD dans le nuage.

De plus, chaque pilote NoSQL <language> fournit une API permettant d'exécuter un énoncé LDD. Pour écrire votre application, voir Utilisation d'API pour créer des tables et des index dans Oracle NoSQL Database Cloud Service.

Énoncés LDD types

Voici quelques exemples d'énoncés LDD :

Créer une table
CREATE TABLE [IF NOT EXISTS] (
    field-definition, field-definition-2 ...,
    PRIMARY KEY (field-name, field-name-2...),
) [USING TTL ttl]
Par exemple :
CREATE TABLE IF NOT EXISTS audience_info (
    cookie_id LONG,
    ipaddr STRING,
    audience_segment JSON,
    PRIMARY KEY(cookie_id))
Modifier la table
ALTER TABLE table-name (ADD field-definition)
ALTER TABLE table-name (DROP field-name)
ALTER TABLE table-name USING TTL ttl 
Par exemple :
ALTER TABLE audience_info USING TTL 7 days
Créer un index
CREATE INDEX [IF NOT EXISTS] index-name ON table-name (path_list)
Par exemple :
CREATE INDEX segmentIdx ON audience_info
       (audience_segment.sports_lover AS STRING)
Supprimer une table
DROP TABLE [IF EXISTS] table-name
Par exemple :
DROP TABLE audience_info

Voir les guides de référence pour une liste complète :

Différences du langage LDD dans le nuage

Le langage LDD pour les services en nuage diffère de ce qui est décrit dans le guide de référence sur les points suivants :

Table Names (Noms de table)

  • Limite de 256 caractères, caractères alphanumériques et trait de soulignement seulement
  • doit commencer par une lettre
  • Impossible d'inclure les caractères spéciaux
  • Les tables enfants ne sont pas prises en charge

Concepts non pris en charge

  • Instructions DESCRIBE et SHOW TABLE.
  • Index en texte intégral
  • Gestion des utilisateurs et des rôles
  • Régions sur place

Informations de référence sur le langage d'interrogation

Voyez comment utiliser des énoncés SQL pour mettre à jour et interroger des données dans Oracle NoSQL Database Cloud Service.

Oracle NoSQL Database utilise le langage d'interrogation SQL pour la mise à jour et l'interrogation des données dans les tables NoSQL. Reportez-vous à la section Référence SQL pour Oracle NoSQL Database pour plus de détails sur la syntaxe du langage d'interrogation.

Requêtes courantes

SELECT <expression>
FROM <table name>
[WHERE <expression>]
[GROUP BY <expression>]
[ORDER BY <expression> [<sort order>]]
[LIMIT <number>]
[OFFSET <number>]; 

For example:
SELECT * FROM Users;
SELECT id, firstname, lastname FROM Users WHERE firstname = "Taylor";
UPDATE <table_name> [AS <table_alias>]
    <update_clause>[, <update_clause>]*
WHERE <expr>[<returning_clause>];

For example:
UPDATE JSONPersons $j
  SET TTL 1 DAYS
  WHERE id = 6
  RETURNING remaining_days($j) AS Expires;

Différences du langage d'interrogation dans le nuage

La prise en charge des interrogations pour les services en nuage diffère de celle décrite dans le guide de référence sur le langage d'interrogation :

Restrictions relatives aux expressions utilisées dans la clause SELECT

Oracle NoSQL Database Cloud Service prend en charge le regroupement d'expressions ou d'expressions arithmétiques entre des fonctions d'agrégation. Tous les autres types d'expression ne sont pas autorisés dans la clause SELECT. Par exemple, les expressions CASE ne sont pas autorisées dans la clause SELECT.

Chaque pilote de base de données NoSQL fournit une API pour exécuter un énoncé d'interrogation.

Informations sur le plan d'interrogation

Un plan d'exécution d'interrogation est la séquence des opérations qu'Oracle NoSQL Database effectue pour exécuter une interrogation.

Un plan d'exécution d'interrogation est un arbre d'itérateurs de plan. Chaque type d'itérateur évalue un autre type d'expression qui peut apparaître dans une interrogation. En général, le choix de l'index et le type de prédicats d'index associés peuvent avoir un effet considérable sur les performances des requêtes. Par conséquent, en tant qu'utilisateur, vous voulez souvent voir quel index est utilisé par une interrogation et quels prédicats y ont été poussés. Sur la base de ces informations, vous pouvez forcer l'utilisation d'un index différent via des conseils d'index. Ces informations sont contenues dans le plan d'exécution de l'interrogation. Tous les pilotes Oracle NoSQL fournissent des API permettant d'afficher le plan d'exécution d'une interrogation.

Certains des itérateurs les plus courants et les plus importants utilisés dans les interrogations sont :

Itérateur de TABLE : Un itérateur de TABLE est responsable des éléments suivants :
  • Balayer l'index utilisé par l'interrogation (qui peut être l'index principal).
  • Application de tout prédicat de filtrage poussé à l'index
  • Si nécessaire, extrayez les lignes pointées par les entrées d'index admissibles. Si l'index couvre, l'ensemble de résultats de l'itérateur TABLE est un ensemble d'entrées d'index, sinon il s'agit d'un ensemble de lignes de table.

Note :

Un index est appelé un index de couverture par rapport à une requête si la requête peut être évaluée en utilisant uniquement les entrées de cet index, c'est-à-dire sans qu'il soit nécessaire d'extraire les lignes associées.

Itérateur SELECT : Il est responsable de l'exécution de l'expression SELECT.

Chaque requête contient une clause SELECT. Chaque plan d'interrogation comporte donc un itérateur SELECT. Un itérateur SELECT a la structure suivante :

"iterator kind" : "SELECT",
"FROM" :
  {
  },
"FROM variable" : "...",
"SELECT expressions" : 
[
  {
  }
]

L'itérateur SELECT comporte des champs tels que "FROM", "WHERE", "FROM variable" et "SELECT expressions". "FROM" et "FROM variable" représentent la clause FROM de l'expression SELECT, WHERE représente la clause filter et "SELECT expression" représente la clause SELECT.

RECEIVE itérateur : Il s'agit d'un itérateur interne spécial qui sépare le plan d'interrogation en 2 parties :
  1. L'itérateur RECEIVE lui-même et tous les itérateurs situés au-dessus dans l'arbre des itérateurs sont exécutés au niveau du pilote.
  2. Tous les itérateurs situés sous l'itérateur RECEIVE sont exécutés au niveau des noeuds de réplication (RN); ces itérateurs forment un sous-arbre enraciné au niveau de l'enfant unique de l'itérateur RECEIVE.

En général, l'itérateur RECEIVE agit en tant que coordonnateur d'interrogation. Il envoie sa spécialisation aux RN appropriés pour exécution et collecte les résultats. Il peut effectuer des opérations supplémentaires telles que le tri et l'élimination des doubles et propage les résultats à ses itérateurs ancêtres (le cas échéant) pour un traitement ultérieur.

Types de distribution :

Un type de distribution indique comment l'interrogation sera distribuée pour exécution entre les noms de domaine participant à une base de données Oracle NoSQL (un magasin). Le type de distribution est une propriété de l'itérateur RECEIVE.

Les différents types de distribution sont les suivants :
  • SINGLE_PARTITION : Une interrogation SINGLE_PARTITION spécifie une clé de partition complète dans sa clause WHERE. Par conséquent, son jeu de résultats complet est contenu dans une seule partition, et l'itérateur RECEIVE enverra son sous-plan à un seul RN qui stocke cette partition. Une interrogation SINGLE_PARTITION peut utiliser l'index de clé primaire ou un index secondaire.
  • ALL_PARTITIONS : Les interrogations utilisent l'index de clé primaire ici et n'indiquent pas de clé de partition complète. Par conséquent, si le magasin a M partitions, l'itérateur RECEIVE enverra M copies de son sous-plan à exécuter sur l'une des M partitions chacune.
  • ALL_SHARDS : Les interrogations utilisent un index secondaire ici et n'indiquent pas de clé de partition complète. Par conséquent, si le magasin a N partitions, l'itérateur RECEIVE enverra N copies de son sous-plan à exécuter sur chacune des N partitions.

Anatomie d'un plan d'exécution d'interrogation :

L'exécution de l'interrogation s'effectue par lots. Lorsqu'un sous-plan d'interrogation est envoyé à une partition ou à une partition pour exécution, il s'exécute là-bas jusqu'à ce qu'une limite de lot soit atteinte. La limite de lot est un nombre d'unités de lecture consommées localement par l'interrogation. La valeur par défaut est 2000 unités de lecture (environ 2 Mo de données), et elle ne peut être réduite qu'au moyen d'une option de niveau interrogation.

Lorsque la limite de lot est atteinte, tous les résultats locaux produits sont renvoyés à l'itérateur RECEIVE pour traitement ultérieur, avec un indicateur booléen indiquant si d'autres résultats locaux peuvent être disponibles. Si l'indicateur est vrai, la réponse comprend des données sur le curriculum vitæ. Si l'itérateur RECEIVE décide de renvoyer l'interrogation à la même partition ou partition, il inclura ces informations de reprise dans sa demande, de sorte que l'exécution de l'interrogation redémarre au point où elle s'est arrêtée pendant le lot précédent. En effet, aucun état d'interrogation n'est maintenu au RN après la fin d'un lot. Le lot suivant pour la même partition / partition peut avoir lieu au même RN que le lot précédent ou à un RN différent qui stocke également la même partition / partition.