Informations de référence sur le service Oracle NoSQL Database Cloud

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

Cet article contient les rubriques suivantes :

Types de données pris en charge

Oracle NoSQL Database Cloud Service prend en charge de nombreux types de données courants.

Type de données Description
BINARY Séquence de zéro octet ou plus. La taille de stockage est le nombre d'octets plus un codage de la taille de la matrice d'octets, qui est une variable, en fonction de la taille de la matrice.
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 long à virgule flottante, codé à 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 long à virgule flottante, codé à 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 Unicode 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 en fonction du 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 Nombre décimal signé avec précision arbitraire.

Il est sérialisé dans un format de tableau d'octets qui peut être utilisé pour des comparaisons ordonnées. Le format comporte 2 parties :

1. Le signe et l'exposant plus un seul chiffre. Cela prend 1-6 octets mais est normalement 2 sauf si l'exposant est assez grand
2. Mantisse de la valeur qui est d'environ un octet pour tous les 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 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 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'horodatage est stocké et géré en UTC (Temps universel coordonné). The Timestamp datatype requires anywhere from 3 to 9 bytes depending on the precision used.

The following breakdown illustrates the storage used by this datatype:

- bit[0~13] year - 14 bits
- bit[14~17] month - 4 bits
- bit[18~22] day - 5 bits
- bit[23~27] hour - 5 bits [optional]
- bit[28~33] minute - 6 bits [optional]
- bit[34~39] second - 6 bits [optional]
- bit[40~71] fractional second [optional with variable length]
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 en tant que 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 d'éléments typés. Les tableaux qui ne sont pas définis comme JSON ne peuvent pas contenir de valeurs NULL.

Les tableaux déclarés en tant que 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 de 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. Toutes les clés d'un enregistrement doivent être uniques.
JSON Toute donnée JSON valide.

É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. D'autres modifications de table ne sont pas possibles tant que la table est dans 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 les activités de lecture, d'écriture ou d'interrogation.

Note : Une fois supprimée, une table du même nom peut être créée à nouveau.

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 erroné dans l'un des scénarios courants suivants :

Comment traiter certaines erreurs inachevées ou erronées lors de l'utilisation de la console OCI pour créer ou gérer des données :

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 vérifie la syntaxe et retourne un bref sommaire d'un énoncé SQL.

  1. Dans votre 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'

Vous obtiendrez ainsi 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 de définition de données avec le service Oracle NoSQL Database Cloud.

Utilisez le code 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é. Ces différences sont documentées dans la section DDL Differences in the Cloud.

De plus, chaque pilote de langage NoSQL 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 la 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)

Concepts non pris en charge

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 le service Oracle NoSQL Database Cloud.

Oracle NoSQL Database utilise le langage d'interrogation SQL pour mettre à jour et interroger les données dans les tables NoSQL. Voir Informations de référence SQL sur Oracle NoSQL Database pour plus de détails sur la syntaxe du langage d'interrogation.

Interrogations courantes

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

Par exemple :

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>];

Par exemple :

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 du service en nuage diffère de ce qui est décrit dans le guide de référence du langage d'interrogation de la manière suivante :

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. Aucun autre type d'expression n'est autorisé 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.

Référence du 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 une arborescence d'itérateurs de plan. Chaque type d'itérateur évalue un type d'expression différent 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 drastique sur les performances des interrogations. Par conséquent, en tant qu'utilisateur, vous voulez souvent voir quel index est utilisé par une interrogation et quels prédicats ont été poussés vers le bas. 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 NoSQL d'Oracle fournissent des API permettant d'afficher le plan d'exécution d'une interrogation.

Voici quelques-uns des itérateurs les plus courants et les plus importants utilisés dans les requêtes :

Itérateur de TABLE : Un itérateur de TABLE est responsable des éléments suivants :

Note : Un index est appelé index couvrant par rapport à une interrogation si l'interrogation peut être évaluée en utilisant uniquement les entrées de cet index, c'est-à-dire sans avoir à extraire les rangées associées.

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

Chaque requête contient une clause SELECT. Ainsi, chaque plan de requête aura 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.

Itérateur RECEIVE : 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'arborescence de l'itérateur sont exécutés au niveau du pilote.

  2. Tous les itérateurs sous l'itérateur RECEIVE sont exécutés sur les 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 sous-plan 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 la façon dont l'interrogation sera distribuée pour être exécutée sur les adresses RN participant à une base de données Oracle NoSQL (un magasin). Le type de distribution est une propriété de l'itérateur RECEIVE.

Différents choix de types de distribution sont :

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

L'exécution de l'interrogation a lieu par lots. Lorsqu'un sous-plan d'interrogation est envoyé à une partition ou à une partition pour exécution, il s'exécute là 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 diminuée qu'au moyen d'une option de niveau interrogation.

Lorsque la limite de lot est atteinte, tous les résultats locaux qui ont été produits sont renvoyés à l'itérateur RECEIVE pour traitement ultérieur avec un indicateur booléen qui indique si d'autres résultats locaux peuvent être disponibles. Si l'indicateur est réglé à Vrai, la réponse contiendra des données sur le curriculum vitæ. Si l'itérateur RECEIVE décide de renvoyer l'interrogation à la même partition/ partition, il inclura ces informations de reprise dans sa demande, de sorte que l'exécution de l'interrogation redémarrera au point où elle s'est arrêtée lors du lot précédent. En effet, aucun état d'interrogation n'est mis à jour au niveau du 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.