Planifier votre service

Prenez le temps de planifier votre service Oracle NoSQL Database Cloud Service avant de le créer. Pensez aux questions présentées ici et décidez de ce que vous voulez faire avant de commencer.

Cet article contient les rubriques suivantes :

Aperçu pour les développeurs

Obtenez un aperçu général de l'architecture de service et sélectionnez une trousse SDK/un pilote qui répondra à vos besoins de développement d'applications.

Tâches de développeur NDCS

Oracle NoSQL Database Cloud Service (NDCS) est un service entièrement haute disponibilité. Il est conçu pour les applications très exigeantes qui nécessitent des temps de réponse à faible latence, un modèle de données flexible et une mise à l'échelle élastique pour les charges de travail dynamiques. En tant que service entièrement géré, Oracle gère toutes les tâches administratives, telles que les mises à niveau logicielles, les correctifs de sécurité, les défaillances matérielles et l'application de correctifs.

Description de l'illustration developer_overview.png

Trousses SDK/pilotes NoSQL Database - Ces trousses SDK sont sous licence Universal Permissive License (UPL) et peuvent être utilisées sur NoSQL Cloud Service ou sur la base de données sur place. Ce sont des SDK complets et offrent un riche ensemble de fonctionnalités. Ces pilotes peuvent également être utilisés dans les applications s'exécutant sur des grappes Oracle NoSQL exécutées dans d'autres fournisseurs de nuage.

Vous pouvez consulter le tableau ci-dessous pour obtenir des liens vers les trousses SDK, les guides d'API et des exemples :

• Trousse SDK (GitHub) - Fournit des détails sur l'installation, la connexion et le démarrage de la trousse SDK

• Guide API - Fournit les packages, les classes, les méthodes et les interfaces disponibles dans la trousse SDK

• Exemples - Fournit des exemples de code que vous pouvez essayer

TROUSSE SDK (GitHub)	Guide sur l'API	Exemples
Trousse SDK Java pour Oracle NoSQL	Guide sur l'API de la trousse SDK Java	Exemples Java
Trousse SDK Python pour Oracle NoSQL	Guide d'API de la trousse SDK Python	Exemples Python
Trousse SDK Oracle NoSQL Go	Guide d'API Go SDK	Exemples de Go
Trousse SDK Node.js d'Oracle NoSQL	Guide d'API de la trousse SDK Node.js	Exemples Node.js
Trousse SDK .NET pour Oracle NoSQL	Guide d'API de trousse SDK .NET	Exemples .NET
Trousse SDK Oracle NoSQL Rust	Guide d'API Rust SDK	Exemples de rouille
Trousse SDK Oracle NoSQL Spring	Guide d'API Spring SDK	Exemples de printemps

Console OCI - Permet de créer rapidement des tables, de modifier des tables, de supprimer des tables, de charger des données, de créer rapidement des index, de supprimer des index, des interrogations de base, de modifier les capacités des tables et de voir les mesures.

Trousses SDK/pilotes OCI - Oracle Cloud Infrastructure fournit un certain nombre de trousses de développement logiciel (SDK) pour faciliter le développement de solutions personnalisées. Ceux-ci sont généralement sous licence UPL.

1. API REST

2. Trousse SDK pour Java

3. Trousse SDK pour Python

4. Trousse SDK pour Javascript

5. Trousse SDK pour .NET

6. Trousse SDK pour Go

7. Trousse SDK pour Ruby

8. Trousse SDK pour PL/SQL

Différence entre les trousses SDK/pilotes de base de données NoSQL et les trousses SDK/pilotes OCI :

Les trousses SDK pour OCI sont basées sur REST. Ils sont faciles à utiliser mais ont une fonctionnalité limitée. D'autre part, les trousses SDK NoSQL Database offrent un jeu étoffé de fonctionnalités. Il est recommandé d'utiliser des trousses SDK pour NoSQL Database car elles offrent les avantages suivants par rapport aux trousses SDK pour OCI.

• Les trousses SDK NoSQL Database peuvent être utilisées dans les applications qui se connectent au service en nuage, aux magasins de données sur place et au simulateur NoSQL Cloud.

• Les trousses SDK NoSQL Database offrent une expérience de développement beaucoup plus riche. Ils prennent en charge d'autres fonctions SQL qui ne sont pas prises en charge au moyen de REST.

• Vous pouvez utiliser des mises en oeuvre de tierce partie telles que Jakarta NoSQL ou Eclipse TopLink avec des trousses SDK de base de données NoSQL.

Références :

• Documentation SQL pour NoSQL

• Différence fonctionnelle entre NoSQL Cloud Service et la base de données sur place

Limites du service Oracle NoSQL Database Cloud

Oracle NoSQL Database Cloud Service a diverses limites par défaut. Chaque fois que vous créez une table Oracle NoSQL Database Cloud Service, le système s'assure que vos demandes respectent la limite spécifiée. Certaines limites sont imposées au niveau de la table et d'autres au niveau de la région.

Pour en savoir plus sur les limites de service, leur portée et la façon d'augmenter vos limites de service en soumettant une demande, consultez Limites de service. Les limites actuelles d'Oracle NoSQL Database Cloud Service sont répertoriées ci-dessous.

Limite	Portée	Description	Valeur dans un environnement non hébergé	Valeur dans un environnement hébergé
Taille maximale de stockage de table	Table	Taille de stockage totale maximale par client. L'espace total utilisé pour une ou plusieurs tables ne peut pas dépasser cette valeur.	5 To	17.5TB
Table Names (Noms de table)	Table	Nombre maximal de caractères, caractères permis et caractère initial pour les noms de table.	Les noms de table peuvent comporter 256 caractères au maximum. Tous les noms doivent commencer par une lettre (a-z, A-Z). Les caractères suivants peuvent être des lettres (a-z), des chiffres (0-9) ou un trait de soulignement.	Identique à un environnement non hébergé
Capacité provisionnée - Débit maximal de lecture et d'écriture	Table	Débit maximal de lecture et d'écriture lors du provisionnement d'une table.	40 000 unités de lecture et 20 000 unités d'écriture par table.	Jusqu'à 420 000 unités de lecture et 280 000 unités d'écriture au total pour toutes les tables de l'environnement hébergé
Capacité sur demande - Débit de lecture et d'écriture maximal	Table	Débit maximal de lecture et d'écriture lors de l'utilisation de la capacité sur demande pour provisionner des tables.	10 000 unités de lecture et 5 000 unités d'écriture par table.	Non autorisé ou nécessaire dans un environnement hébergé
Capacité sur demande - Nombre de tables	Région	Nombre de tables avec capacité sur demande.	3	Non autorisé ou nécessaire dans un environnement hébergé
Modifier le mode de provisionnement	Table	Modifiez le mode de provisionnement de la table de Provisioned à On Demand ou vice-versa.	Ne peut être modifié qu'une fois par jour.	s. o.
Nombre maximal de tables.	Région	Nombre maximal de tables.	30	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Nombre maximal de colonnes.	Table	Nombre maximal de colonnes.	50	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Nombre maximal de mises à jour de schéma de table	Table	Nombre maximal de mises à jour de schéma de table.	100	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Nombre maximum d'index	Table	Le nombre maximum d'index.	5	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Nombre maximum de modifications des limites de débit et de stockage	Table	Nombre maximum de modifications des limites de débit et de stockage.	Oracle permet : Nombre illimité d'augmentations de débit et de stockage par jour Jusqu'à quatre réductions du débit ou du stockage par période de 24 heures.	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Noms des index	Indexer	Le nombre maximal de caractères, les caractères permis et le caractère initial.	Les noms d'index peuvent comporter 64 caractères au maximum. Tous les noms doivent commencer par une lettre (a-z, A-Z). Les caractères suivants peuvent être des lettres (a-z), des chiffres (0-9) ou un trait de soulignement.	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Nombre maximal d'opérations individuelles par demande WriteMultiple	Demande	Nombre maximal d'opérations individuelles par demande WriteMultiple.	50	Identique à un environnement non hébergé. Cela peut également être augmenté à l'aide de Request Service Limits Update
Taille de données maximale pour une demande WriteMultiple.	Demande	Taille de données maximale pour une demande WriteMultiple.	25 Mo	Identique à un environnement non hébergé. Cela peut également être augmenté à l'aide de Request Service Limits Update
Noms de colonne	Colonne	Le nombre maximal de caractères, les caractères permis et le caractère initial.	Les noms de champ peuvent comporter 64 caractères au maximum. Tous les noms doivent commencer par une lettre (a-z, A-Z). Les caractères suivants peuvent être des lettres (a-z), des chiffres (0-9) ou un trait de soulignement.	Identique à un environnement non hébergé.
Taille maximale de la clé d'index secondaire	Indexer	Taille maximale de la clé d'index.	64 bytes	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Taille maximale de la clé d'index principale	Indexer	Taille maximale de la clé primaire.	64 bytes	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Taille de rangée maximale	Rangée	Taille de rangée maximale.	512 KO	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Longueur maximale de la chaîne d'interrogation.	Interrogation	Longueur maximale de la chaîne d'interrogation.	10 Ko	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Taux maximal pris en charge pour les opérations LDD.	Région	Taux maximal pris en charge pour les opérations LDD.	4 par minute	Cela peut être personnalisé à l'aide de la mise à jour des limites de service de demande
Valeurs maximales pour le débit et les ressources de stockage des données.	Région	Valeurs maximales pour le débit et les ressources de stockage des données.	Par région, Oracle permet ce qui suit : Un maximum de 100 000 unités de lecture Un maximum de 40 000 unités d'écriture Oracle permet une taille de stockage maximale de 5 To par client. La région peut avoir une seule table avec une taille de stockage de 5 To, auquel cas elle ne peut pas créer une autre table. Ou, si vous avez plusieurs tables, assurez-vous que les données de toutes ces tables ne dépassent pas la taille de stockage maximale de 5 To.	420 000 unités d'écriture, 280 000 unités de lecture, 17,5 To de stockage

Capacité d'estimation

Voyez comment estimer les capacités de débit et de stockage pour votre service Oracle NoSQL Database Cloud.

Concepts de base pour le calcul

Avant d'apprendre à estimer le débit et le stockage pour le service, révisons les définitions d'unité de débit et de stockage.

• Unité d'écriture : Débit allant jusqu'à 1 kilo-octet (Ko) de données par seconde. Une opération d'écriture est tout appel d'API Oracle NoSQL Database Cloud Service qui entraîne l'insertion, la mise à jour ou la suppression d'un enregistrement. Une valeur limite d'écriture est associée à votre table NoSQL et précise le nombre d'unités d'écriture pouvant être utilisées à chaque seconde. Les mises à jour d'index consomment également des unités d'écriture.

  Par exemple, un enregistrement de moins de 1 Ko nécessite une unité d'écriture pour une opération d'écriture. Un enregistrement de 1,5 Ko nécessite deux unités d'écriture pour l'opération d'écriture.

• Unité de lecture : Débit allant jusqu'à 1 Ko de données par seconde pour une opération de lecture avec cohérence à terme. Une valeur limite de lecture est associée à votre table NoSQL et précise le nombre d'unités de lecture pouvant être utilisées à chaque seconde.

  Par exemple, un enregistrement de moins de 1 Ko nécessite une unité de lecture pour une opération de lecture avec cohérence à terme. Un enregistrement de 1,5 Ko nécessite deux unités de lecture pour une opération de lecture avec cohérence à terme et quatre unités de lecture pour une opération de lecture avec cohérence absolue.

• Capacité de stockage : Une unité de stockage est un gigaoctet unique (Go) de stockage de données.

• Cohérence absolue : Les données retournées sont les données les plus récentes écrites dans la base de données.

• Cohérence à terme : Les données retournées ne sont peut-être pas les dernières données écrites dans la base de données; si aucune nouvelle mise à jour n'est effectuée sur les données, les accès à ces données finissent par retourner la dernière valeur mise à jour.

Note : Oracle NoSQL Database Cloud Service gère automatiquement les capacités de lecture et d'écriture pour répondre aux besoins des charges de travail dynamiques lors de l'utilisation de la capacité sur demande. Il est recommandé de valider que les besoins en capacité ne dépassent pas les limites de capacité sur demande. Pour plus de détails, voir Limites du service Oracle NoSQL Database Cloud Service.

Facteurs ayant une incidence sur l'unité de capacité

Avant de provisionner les unités de capacité, il est important de tenir compte des facteurs suivants qui ont une incidence sur les capacités de lecture, d'écriture et de stockage.

• Taille d'enregistrement : Lorsque la taille d'enregistrement augmente, le nombre d'unités de capacité consommées pour écrire ou lire des données augmente également.

• Cohérence des données : Les lectures avec cohérence absolue consomment deux fois plus que les lectures avec cohérence à terme.

• Index secondaires : Dans une table, lorsqu'un enregistrement existant est modifié (ajouté, mis à jour ou supprimé), la mise à jour des index secondaires consomme des unités d'écriture. Le coût total du débit provisionné pour une opération d'écriture est la somme des unités d'écriture consommées en écrivant dans la table et en mettant à jour les index secondaires locaux.

• Choix de modélisation des données : Avec JSON sans schéma, chaque document se décrit lui-même, ce qui ajoute des métadonnées à la taille globale de l'enregistrement. Avec les tables à schéma fixe, la surcharge pour chaque enregistrement est exactement de 1 octet.

• Modèle d'interrogation : Le coût d'une opération d'interrogation dépend du nombre de rangées extraites, du nombre de prédicats, de la taille des données sources, des projections et de la présence d'index. Les interrogations les moins coûteuses fournissent une clé de partition ou une clé d'index (avec un index associé) pour permettre au système de tirer parti des index principaux et secondaires. Vous pouvez essayer différentes interrogations pour une application et examiner le débit consommé afin d'ajuster les opérations.

Exemple réel : Comment estimer la charge de travail d'une application

Prenez un exemple d'application de commerce électronique pour apprendre à estimer les lectures et les écritures par seconde. Dans cet exemple, Oracle NoSQL Database Cloud Service est utilisé pour stocker les informations sur le catalogue de produits de l'application.

1. Identifiez le modèle de données (JSON ou table fixe), la taille de l'enregistrement et la taille de la clé pour l'application.

   Supposons que l'application de commerce électronique suit le modèle de données JSON et que le développeur a créé une table simple contenant deux colonnes : Un Identificateur d'enregistrement (clé primaire) et document JSON pour les caractéristiques et les attributs du produit. Le document JSON, qui est de moins de 1 Ko (0,8 Ko), est le suivant :

   {
     "additionalFeatures": "Front Facing 1.3MP Camera",
     "os": "Macintosh OS X 10.7",
     "battery": {
       "type": "Lithium Ion (Li-Ion) (7000 mAH)",
       "standbytime" : "24 hours" },
     "camera": {
       "features": ["Flash","Video"],
       "primary": "5.0 megapixels" },
     "connectivity": {
       "bluetooth": "Bluetooth 2.1",
       "cell": "T-mobile HSPA+ @ 2100/1900/AWS/850 MHz",
       "gps": true,
       "infrared": false,
       "wifi": "802.11 b/g" },
     "description": "Apple iBook is the best in class computer
               for your professional and personal work.",
     "display": {
       "screenResolution": "WVGA (1280 x 968)",
       "screenSize": "13.0 inches" },
     "hardware": {
       "accelerometer": true,
       "audioJack": "3.5mm",
       "cpu": "Intel i7 2.5 GHz",
       "fmRadio": false,
       "physicalKeyboard": false,
       "usb": "USB 3.0" },
     "id": "appleproduct_1",
     "images": ["img/apple-laptop.jpg"],
     "name": "Myshop.com : Apple iBook",
     "sizeAndWeight": {
       "dimensions": [
         "300 mm (w)",
         "300 mm (h)",
         "12.4 mm (d)" ],
       "weight": "1250.0 grams" },
     "storage": {
       "hdd": "750GB",
       "ram": "8GB" }
   }

   Supposons que l'application compte 100 000 enregistrements de ce type et que la taille de la clé primaire soit d'environ 20 octets. En outre, supposons que des interrogations liront les enregistrements à l'aide d'un index secondaire. Par exemple, pour rechercher tous les enregistrements ayant une taille d'écran de 13 pouces. Un index est alors créé sur le champ screenSize.

   Les informations sont résumées de la manière suivante :

   Tables	Rangées par table	Colonnes par table	Taille de la clé en octets	Taille de la valeur en octets (somme de toutes les colonnes)	Index	Taille de la clé d'index en octets
   1	100 000	2	20	1 Ko	1	20

2. Déterminez la liste des opérations (en général, les opérations de création, lecture, mise à jour et suppression, et les lectures d'index) effectuées sur la table et à quel rythme (par seconde) elles sont attendues.

   Opération	Nombre d'opérations (par seconde)	Exemple
   Créer des enregistrements.	3	Pour créer un produit.
   Lire des enregistrements en utilisant la clé primaire.	200	Pour lire les détails du produit en utilisant l'ID produit.
   Lire des enregistrements en utilisant l'index secondaire.	1	Pour extraire tous les produits ayant une taille d'écran de 13 pouces.
   Mettre à jour ou ajouter un attribut à un enregistrement.	5	Pour mettre à jour la description de produit d'une caméra ou Pour ajouter des informations à propos du poids d'une caméra.
   Supprimer un enregistrement.	5	Pour supprimer un produit existant.

3. Déterminer la consommation en lecture et écriture en Ko.

   Opération	Hypothèses (le cas échéant)	Formule	Consommation en lecture (Ko)	Consommation en écriture (Ko)	Notes/Explication
   Créer des enregistrements.	Supposons que les enregistrements soient créés sans vérifications de conditions (éventuelles).	Record size (rounded to next KB) + 1 KB(index) * (number of indexes)	0	1 KO + 1 KO (1 ) = 2 KO	La taille de l'enregistrement est de 1 Ko (0,8 Ko pour la colonne JSON et 20 octets pour la colonne de clé) et il existe un index de taille 1 Ko. Une opération de création entraîne un coût unitaire de lecture si vous exécutez les commandes put avec certaines options. Comme vous devez vous assurer que vous lisez la version la plus récente de la ligne, des lectures à cohérence absolue sont utilisées. Dans de tels cas, vous utilisez le multiplicateur 2 dans la formule d'unité de lecture. Voici les différentes options pour déterminer les coûts unitaires de lecture : Si Option.IfAbsent ou Option.IfPresent est utilisé, la consommation en lecture = 2 Si setReturnRow est utilisé, alors Read Consumption = 2 * Record size Si Option.IfAbsent et setReturnRow sont utilisés, alors Read Consumption = 2 * Record size
   Lire des enregistrements en utilisant la clé primaire.		Record size round up to KB	Taille d'enregistrement = 1 Ko	0	La taille d'enregistrement est de 1 Ko
   Lire des enregistrements en utilisant l'index secondaire.	Supposons que 100 enregistrements soient retournés.	record_size * number_of_records_matched	11 Ko *100 = 100 Ko 100 KO + 10 KO = 110 KO	0	Il n'y a pas de frais pour l'index secondaire. La taille d'enregistrement est de 1 Ko. Pour 100 enregistrements, il est de 100 Ko. 10 Ko supplémentaires correspondent à la frais généraux variables qui peuvent survenir en fonction du nombre de lots retournés et de la limite de taille définie pour l'interrogation. Les frais généraux correspondent au coût de lecture de la dernière clé d'un lot. Il s'agit d'une variable qui dépend de la taille maxReadKB et de l'enregistrement. Les frais généraux peuvent aller jusqu'à (numBatches - 1) * coût de lecture des clés (1 Ko).
   Mettre à jour des enregistrements existants	Supposons que la taille de l'enregistrement mis à jour soit identique à celle de l'ancien enregistrement (1 Ko).	Read consumption = record_size * 2 Write consumption = original_record_size + new_record_size + 1 KB (index) * (number of writes)	1 X 2	1 KO + 1 KO + 1 KO (1) *(2) = 4 KO	Lorsque des lignes sont mises à jour à l'aide d'une interrogation (instruction SQL), les unités de lecture et d'écriture sont consommées. Selon la mise à jour, il peut être nécessaire de lire la clé primaire, la clé secondaire ou même l'enregistrement lui-même. Des lectures absolument cohérentes sont nécessaires pour garantir que nous lisons l'enregistrement le plus récent. Les lectures de cohérence absolue représentent deux fois plus que les lectures de cohérence à terme. C'est la raison de la multiplication par 2 dans la formule. Consommation en lecture : Les frais pour l'index et la taille de l'enregistrement sont de 1 Ko. En cas d'exécution à l'aide de l'option setReturnRow, Read Consumption = 2 * Record size Consommation en écriture : La taille de l'enregistrement initial et du nouvel enregistrement est de 1 Ko et de 1 Ko pour un index.
   Supprimer un enregistrement		Read consumption = 1 KB (index) * 2 Write consumption = record_size + 1KB (index) * (number_of_indexes)	1 KO (1) *2 = 2 KO	1 KO + 1 KO (1) * (1) = 2 KO	Une suppression entraîne des coûts unitaires en lecture et en écriture. Comme vous devez vous assurer que vous regardez la version la plus récente de la ligne, des lectures cohérentes absolues sont utilisées, c'est la raison pour laquelle vous utilisez le multiplicateur 2 dans la formule de l'unité de lecture. En cas d'exécution à l'aide de l'option setReturnRow, Read Consumption = 2 * Record size. Sinon, consommation de lecture = 1 Ko pour un index Consommation en écriture : La taille de l'enregistrement est de 1 Ko et de 1 Ko pour l'index. Le nombre d'index est 1.

   A l'aide des étapes 2 et 3, déterminez les unités de lecture et d'écriture pour la charge globale de l'application.

   Opérations	Taux d'opérations	Lectures par seconde	Écritures par seconde
   Créer des enregistrements	3	0	6
   Lire des enregistrements en utilisant la clé primaire	300	300	0
   Lire des enregistrements en utilisant l'index secondaire	10	1 100	0
   Mettre à jour des enregistrements existants	5	10	20
   Supprimer un enregistrement	1	2	2

   Nombre total d'unités de lecture : 1412

   Nombre total d'unités d'écriture :28

   Par conséquent, la charge de travail de l'application de commerce électronique est estimée à 1412 lectures par seconde et à 28 écritures par seconde. Télécharger l'évaluateur de capacité

Note : Les calculs précédents supposent des demandes de lecture avec cohérence à terme. Pour une demande de lecture à cohérence absolue, l'opération consomme le double d'unités de capacité. Par conséquent, les unités de capacité de lecture seraient 4844 unités de lecture.

Estimation du coût mensuel

Voyez comment estimer le coût mensuel de votre abonnement Oracle Cloud.

Lorsque vous êtes prêt à commander votre service Oracle Cloud, Oracle vous fournit un évaluateur de coût qui vous permet de déterminer votre utilisation et vos coûts mensuels avant de vous engager pour un modèle d'abonnement ou un montant.

L'évaluateur de coût calcule automatiquement votre coût mensuel du nombre d'unités de lecture, d'unités d'écriture et de stockage que vous entrez. Pour comprendre comment calculer les unités de lecture et d'écriture pour votre application :

1. Étape 1 : Accédez à la rubrique Estimation de la capacité. Estimez la charge de travail de votre application en utilisant l'exemple et les formules présentés sous cette rubrique.

   Télécharger et utiliser l'estimateur de capacité sur Oracle Technology Network pour estimer les unités d'écriture, les unités de lecture et la capacité de stockage de votre application en fonction de la charge de travail de l'application et des critères relatifs aux opérations de base de données.

2. Étape 2 : Accédez à l'évaluateur de coût sur le site Web Oracle Cloud. Cochez la case Gestion des données. Accédez à Oracle NoSQL Database Cloud et sélectionnez Add (Ajouter) pour ajouter une entrée pour Oracle NoSQL Database Cloud dans les options de configuration. Développez NoSQL Database pour rechercher les différentes options d'utilisation et de configuration. Valeurs d'entrée pour les paramètres d'utilisation et de configuration afin d'estimer le coût de l'utilisation d'Oracle NoSQL Database Cloud Service à partir de vos abonnements Pay-As-You-Go et Tarif mensuel flexible Oracle Cloud.

3. Étape 3 : Accédez à l'évaluateur de coût sur le site Web Oracle Cloud. Dans la liste déroulante, sélectionnez Data Management. Les différentes options sont affichées sous Gestion des données. Faites défiler l'affichage pour trouver Oracle NoSQL Database Cloud. Cliquez sur Add pour ajouter une entrée pour Oracle NoSQL Database Cloud dans les options de configuration.

4. Étape 4 : Développez Base de données - NoSQL pour rechercher les différentes options d'utilisation et de configuration. Vous avez deux options sous Configuration. Vous pouvez commencer par une option "Toujours gratuit" (disponible uniquement dans la région Phoenix) ou provisionner votre instance avec la configuration souhaitée.

   • Étape 4a : Si vous voulez une option Toujours gratuit, sous Configuration, développez Oracle NoSQL Database Cloud - Read, Oracle NoSQL Database Cloud Service - Storage et Oracle NoSQL Database Cloud Service - Write et modifiez la capacité de lecture, de stockage et d'écriture en tant que 0. Ensuite, votre estimation du coût total est affichée avec la valeur 0 et vous pouvez passer à l'option Toujours gratuit.

5. Étape 5 : Vous pouvez également, si vous voulez provisionner une capacité de lecture, d'écriture et de stockage supérieure à celle disponible dans Toujours gratuit, entrer les valeurs de configuration sous Database-NoSQL.

   • Étape 5a : Sous Utilisation, ne modifiez pas les valeurs par défaut car Oracle NoSQL Database Cloud Service n'utilise aucune de ces valeurs.

   • Étape 5b : Sous Configuration, ajoutez le nombre d'unités de lecture, d'unités d'écriture et de capacité de stockage que vous avez estimé à l'étape précédente. Le coût est estimé en fonction de vos valeurs d'entrée et affiché sur la page.

Note : Si vous utilisez la fonction d'ajustement automatique, une facture sera générée en fin de mois pour la consommation réelle d'unités de lecture et d'écriture en temps réel. Vous pouvez donc collecter vos propres journaux d'audit dans l'application pour vérifier la facturation de fin de mois. Il est recommandé d'enregistrer les unités de lecture et d'écriture consommées retournées par le service NoSQL Database Cloud à chaque appel d'API. Vous pouvez utiliser ces données pour établir une corrélation avec les données de facturation de fin de mois provenant du système de mesure et de facturation Oracle Cloud.

Pour obtenir une description détaillée des différents modèles de tarification disponibles, voir Tarifs du service NoSQL Database Cloud.

Coût/facturation pour les tables actives globales

Le coût/facturation d'une table active globale comporte deux composants. Le premier composant est le modèle de tarification qui est suivi pour les tables simples, qui prend en compte les unités de lecture par mois, les unités d'écriture par mois et la capacité de stockage en Go par mois. Le deuxième composant concerne les écritures répliquées pour chaque réplique de table régionale pour la table Global Active. Les écritures répliquées entrantes sont facturées en fonction des écritures consommées.

Rubriques connexes

• Limites de service
• concepts liés au nuage;