Planification du service

Consacrez du temps à la planification du service Oracle NoSQL Database Cloud Service avant de le créer. Avant de commencer, prenez en compte les questions indiquées ici et décidez de ce que vous souhaitez faire.

Cet article comprend les rubriques suivantes :

Généralités sur le développement

Obtenez une présentation générale de l'architecture de service et sélectionnez un kit SDK/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 hautement disponible. Il est conçu pour les applications extrêmement exigeantes qui nécessitent des temps de réponse à faible latence, un modèle de données flexible et une évolutivité é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 patches de sécurité, les pannes matérielles et l'application de patches.

Description de l'illustration developer_overview.png

Kit SDK/pilotes NoSQL Database : ces kits SDK sont sous licence UPL (Universal Permissive License) et peuvent être utilisés sur NoSQL Cloud Service ou la base de données sur site. Ce sont des SDK complets et offrent un riche ensemble de fonctionnalités. Ces pilotes peuvent également être utilisés dans les applications exécutées sur des clusters Oracle NoSQL exécutés dans le cloud d'autres fournisseurs.

Vous pouvez vous reporter au tableau ci-dessous pour obtenir des liens vers les kits SDK, les guides d'API et des exemples :

• SDK (GitHub) - Fournit des détails sur l'installation, la connexion et la prise en main du SDK

• Guide de l'API : fournit les packages, classes, méthodes et interfaces disponibles dans le kit SDK

• Exemples : fournit des exemples de code que vous pouvez essayer

SDK (GitHub)	Guide d'API	Exemples
Kit SDK Java Oracle NoSQL	Guide de l'API du kit SDK Java	Exemples Java
Kit SDK Python Oracle NoSQL	Guide de l'API du kit SDK Python	Exemples Python
Kit SDK Go Oracle NoSQL	Guide de l'API Go SDK	Exemples Go
Kit SDK Node.js Oracle NoSQL	Guide de l'API du SDK Node.js	Exemples Node.js
SDK .NET Oracle NoSQL	Guide de l'API du kit SDK .NET	Exemples .NET
Kit SDK Oracle NoSQL Rust	Guide de l'API SDK Rust	Exemples de rouille
SDK Oracle NoSQL Spring	Guide de l'API SDK Spring	Exemples de printemps

Console OCI - Offre la possibilité de créer des tables rapidement, de modifier des tables, de supprimer des tables, de charger des données, de créer des index rapidement, de supprimer des index, des requêtes de base, de modifier les capacités des tables et de visualiser des mesures.

SDK/pilotes OCI : Oracle Cloud Infrastructure fournit plusieurs kits SDK pour faciliter le développement de solutions personnalisées. Ils sont généralement sous licence UPL.

1. API REST

2. Kit SDK pour Java

3. Kit SDK pour Python

4. kit SDK pour Javascript,

5. Kit SDK pour .NET

6. Kit SDK pour Go

7. Kit SDK pour Ruby

8. SDK pour PL/SQL

Différence entre les kits SDK/conducteurs de base de données NoSQL et les kits SDK/conducteurs OCI :

Les kits SDK OCI sont basés sur REST. Ils sont faciles à utiliser mais ont des fonctionnalités limitées. Les SDK NoSQL Database, quant à eux, offrent un riche ensemble de fonctionnalités. Il est recommandé d'utiliser les kits SDK NoSQL Database car ils offrent les avantages suivants par rapport aux kits SDK OCI.

• Les kits SDK NoSQL Database peuvent être utilisés dans des applications se connectant au service cloud, aux banques de données on-premise et au simulateur NoSQL Cloud.

• Les SDK NoSQL Database offrent une expérience de développement beaucoup plus riche. Ils prennent en charge davantage de fonctionnalités SQL qui ne sont pas prises en charge via REST.

• Vous pouvez utiliser des implémentations tierces telles que Jakarta NoSQL ou Eclipse TopLink avec des kits SDK NoSQL Database.

Références:

• Documentation SQL for NoSQL

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

Limites Oracle NoSQL Database Cloud Service

Les limites par défaut d'Oracle NoSQL Database Cloud Service sont différentes. Lorsque vous créez une table Oracle NoSQL Database Cloud Service, le système vérifie que vos demandes sont dans les limites de 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, reportez-vous à Limites de service. Les limites actuelles qui s'appliquent à Oracle NoSQL Database Cloud Service sont répertoriées ci-dessous.

Limite	Périmètre	Description	Valeur dans un environnement non hébergé	Valeur dans un environnement hébergé
Taille maximale de stockage de table	Table	Taille maximale totale de stockage par locataire. L'espace total utilisé pour des tables ne peut pas dépasser cette valeur.	5 To	17,5 TO
Noms de table	Table	Nombre maximal de caractères, de caractères autorisés et de caractères initiaux pour les noms de table.	Les noms de table peuvent contenir 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, A-Z), des chiffres (0-9) ou des traits 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é à la demande - Débit maximal de lecture et d'écriture	Table	Débit maximal de lecture et d'écriture lors de l'utilisation de la capacité On Demand pour provisionner des tables.	10 000 unités de lecture et 5 000 unités d'écriture par table.	Non autorisé/nécessaire dans un environnement hébergé
Capacité à la demande - Nombre de tables	Région	Nombre de tables avec capacité à la demande.	3	Non autorisé/nécessaire dans un environnement hébergé
Modifier le mode de provisionnement	Table	Modifiez le mode de provisionnement de la table de Provisionné à On Demand ou inversement.	Ne peut être modifié qu'une fois par jour.	S/O
Nombre maximal de tables	Région	Le nombre maximum de tables.	30	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximum de colonnes.	Table	Nombre maximum de colonnes.	50	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximal de mises à jour de schéma de table	Table	Nombre maximal d'mises à jour de schéma de table.	100	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximal d'index	Table	Nombre maximal d'index.	5	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximal de modifications pour les limites de débit et de stockage	Table	Nombre maximum de modifications pour les limites du débit et du stockage.	Oracle autorise les modifications suivantes : Nombre illimité d'augmentations de stockage et de débit par jour Jusqu'à quatre diminutions de débit ou de stockage par période de 24 heures.	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Noms d'index	Index	Nombre maximum de caractères, y compris le caractère autorisé et le caractère initial.	Les noms d'index peuvent contenir 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, A-Z), des chiffres (0-9) ou des traits de soulignement.	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximal d'opérations individuelles par demande WriteMultiple	Demande	Nombre maximum d'opérations individuelles par demande WriteMultiple.	50	Tout comme un environnement non hébergé. Cette valeur peut également être augmentée à l'aide de la mise à jour des limites de service de demande
Taille maximale des données pour la demande WriteMultiple	Demande	Taille maximale de données pour la demande WriteMultiple.	25 Mo	Tout comme un environnement non hébergé. Cette valeur peut également être augmentée à l'aide de la mise à jour des limites de service de demande
Noms de colonne	Colonne	Nombre maximum de caractères, y compris le caractère autorisé et le caractère initial.	Les noms de champ peuvent contenir 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, A-Z), des chiffres (0-9) ou des traits de soulignement.	Tout comme un environnement non hébergé.
Taille maximale de la clé d'index secondaire	Index	Taille maximale de clé d'index	64 octets	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Taille maximale de la clé d'index principal	Index	Taille maximale de la clé primaire	64 octets	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Taille de ligne maximale	Ligne	Taille maximale de ligne	512 ko	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Longueur maximale de chaîne de requête	Requête	Longueur maximale de chaîne de requête	10 ko	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Taux maximal d'opérations DDL pris en charge	Région	Taux maximal d'opérations DDL pris en charge	4 par minute	Elle peut être personnalisée à l'aide de la fonction Demander la mise à jour des limites de service
Valeurs maximales pour les ressources de débit et de stockage des données	Région	Valeurs maximales pour les ressources de débit et de stockage des données	Par région, Oracle permet : 100 000 unités de lecture maximum 40 000 unités d'écriture maximum Oracle autorise une taille de stockage maximale de 5 To par locataire. La région peut avoir une seule table avec la taille de stockage de 5 To, auquel cas elle ne peut pas créer d'autre table. Il peut également disposer des tables multiples et s'assurer que les données contenues dans toutes ces tables dépassent 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

Estimation de la capacité

Découvrez comment estimer le débit et les capacités de stockage de votre serveur Oracle NoSQL Database Cloud Service.

Notions de base pour le calcul

Avant d'apprendre à estimer la capacité de traitement et de stockage du service, examinons les définitions d'une unité de stockage et de débit.

• Unité d'écriture : une unité d'écriture correspond à un débit d'1 kilo-octets (ko) de données par seconde maximum. Une opération d'écriture correspond à tout appel d'API Oracle NoSQL Database Cloud Service qui entraîne l'insertion, la mise à jour ou la suppression d'un enregistrement. La table NoSQL a une valeur de limite d'écriture qui spécifie le nombre d'unités d'écriture qui peuvent être utilisées chaque seconde. Les mises à jour d'index utilisent également des unités d'écriture.

  Par exemple, une taille d'enregistrement inférieure à 1 ko nécessite une unité d'écriture pour une opération d'écriture. Une taille d'enregistrement de 1,5 ko nécessite deux unités d'écriture pour l'opération d'écriture.

• Unité de consultation (RU) : une unité est définie comme un débit pouvant aller jusqu'à 1 ko de données par seconde pour une opération à terme cohérente. La table NoSQL a une valeur de limite de lecture qui spécifie le nombre d'unités de lecture qui peuvent être utilisées chaque seconde.

  Par exemple, une taille d'enregistrement inférieure à 1 ko nécessite une unité de lecture pour une opération de lecture cohérente à terme. Une taille d'enregistrement de 1,5 ko nécessite deux unités de lecture pour une opération de lecture cohérente à terme et quatre unités de lecture pour une opération de lecture absolument cohérente.

• Capacité de Stockage : une unité de Stockage est un gigaoctet (Go) de Stockage de Données unique.

• Cohérence absolue : les informations renvoyées doivent être les dernières données écrites dans la base de données.

• Cohérence à termes : les données renvoyées peuvent ne pas être Les données les plus récemment écrites dans la base de données. si aucune nouvelle mise à jour n'est effectuée sur les données, tous les accès à ces données renvoient la dernière valeur mise à jour.

Remarque : 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é à la demande. Il est recommandé de vérifier que les besoins en capacité ne dépassent pas les limites de capacité à la demande. Pour plus de détails, reportez-vous à Limites d'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 prendre en compte les facteurs suivants ayant une incidence sur les capacités de lecture, d'écriture et de stockage.

• Taille d'enregistrement : à mesure que la taille d'enregistrement augmente, le nombre d'unités de capacité utilisée pour écrire ou lire des données augmente également.

• Cohérence des données : les lectures de cohérence absolue correspondent à deux fois le coût des lectures de cohérence à terme.

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

• Choix de modélisation de données : avec le format de JSON sans schéma, chaque document est auto-documenté, ce qui ajoute un temps système des métadonnées à la taille globale de l'enregistrement. Avec les tables de schéma fixe, le temps système de chaque enregistrement est exactement de 1 octet.

• Modèle de recherche : le coût d'une opération d'interrogation dépend du nombre de lignes extraites, du nombre de prédicats, de la taille des données source, des projections et la présence des index. Les requêtes les moins coûteuses spécifient une clé de shard ou une clé d'index (avec un index associé) pour permettre au système de tirer parti des index principal et secondaire. Une application peut essayer différentes requêtes et examiner le débit consommé pour vous aider à régler les opérations.

Exemple concret : procédure d'estimation de la charge globale de l'application

Prenons l'exemple d'une application de commerce électronique pour découvrir comment estimer le nombre de lectures et d'écritures par seconde. Dans cet exemple, Oracle NoSQL Database Cloud Service est utilisé pour stocker les informations du catalogue des produits de l'application.

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

   Supposons que l'application de commerce électronique suit le modèle des données JSON et qu'un développeur a créé une table simple avec deux colonnes. Il existe également un identificateur d'enregistrement (clé primaire) et un document JSON pour les fonctionnalités et attributs du produit. Le document JSON, dont la valeur est inférieure à 1 ko (0,8 ko), se présente comme suit :

   {
     "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 possède 100 000 enregistrements de ce type et que la taille de la clé primaire soit d'environ 20 octets. Supposons également que des requêtes lisent les enregistrements via l'index secondaire. Par exemple, vous pouvez rechercher tous les enregistrements d'une taille d'écran de 13 pouces. Par conséquent, un index est créé dans le champ screenSize.

   Les informations sont récapitulées comme suit :

   Tableaux	Lignes par table	Colonnes par table	Taille de clé en octets	Taille de valeur en octets (somme de toutes les colonnes)	Index	Taille de clé d'index en octets
   1	100000	2	20	1 ko	1	20

2. Identifiez la liste des opérations (généralement des opérations CRUD et des lectures d'index) dans la table et le taux (par seconde) auquel elles sont attendues.

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

3. Identifiez la consommation en lecture et en écriture en ko.

   Opération	Hypothèses (le cas échéant)	Formule	Consommation de lecture (ko)	Consommation en écriture (ko)	Notes/Explication
   Créer des enregistrements.	Supposons que les enregistrements soient créés sans effectuer de vérification de condition (si des vérifications existent).	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 garantir que vous lisez la version la plus récente de la ligne, des lectures cohérentes absolues sont utilisées. Dans ce cas, vous utilisez le multiplicateur 2 dans la formule d'unité de lecture. Voici les différentes options de détermination des coûts unitaires de lecture : Si Option.IfAbsent ou Option.IfPresent est utilisé, alors consommation de lecture = 2 Si setReturnRow est utilisé, consommation de lecture = 2 * taille de l'enregistrement Si Option.IfAbsent et setReturnRow sont utilisés, alors Read Consumption = 2 * Taille de l'enregistrement
   Lire des enregistrements à l'aide de la clé primaire.		Record size round up to KB	Taille d'enregistrement = 1 ko	0	Taille d'enregistrement = 1 ko
   Lire les enregistrements à l'aide de l'index secondaire.	Supposons que 100 enregistrements sont renvoyés.	record_size * number_of_records_matched	11 ko *100 = 100 ko 100 KO + 10 KO = 110 KO	0	Aucun frais pour l'index secondaire. La taille d'enregistrement est de 1 ko. Pour 100 enregistrements, la taille est de 100 ko. 10 ko supplémentaires représentent le temps système variable pouvant survenir en fonction du nombre de batches renvoyés et du seuil de taille défini pour la requête. 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 sont jusqu'à (numBatches - 1) * coût de lecture de clé (1 ko).
   Mettre à jour des enregistrements existants	Supposons que la taille d'enregistrement mise à jour soit identique à la taille 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 KO * 2	1 KO + 1 KO + 1 KO(1) *(2) = 4 KO	Lorsque des lignes sont mises à jour à l'aide d'une 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 cohérentes absolues sont nécessaires pour garantir que nous lisons le dernier enregistrement. Les lectures de cohérence absolue correspondent à deux fois le coût des lectures de cohérence à terme. C'est la raison de la multiplication par 2 dans la formule. Consommation de lecture : aucun frais pour l'index et la taille de l'enregistrement n'est de 1 ko. Si vous exécutez l'option setReturnRow, Read Consumption = 2 * Taille de l'enregistrement Consommation d'écriture : la taille d'enregistrement d'origine et de nouvel enregistrement est de 1 ko et de 1 ko pour un index.
   Supprimer l'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 de lecture et d'écriture. Comme vous devez garantir 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 le multiplicateur 2 est utilisé dans la formule d'unité de lecture. En cas d'exécution à l'aide de l'option setReturnRow, Read Consumption = 2 * Taille de l'enregistrement. Sinon, consommation en lecture = 1 ko pour un index Consommation d'é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	Ecritures par seconde
   Créer des enregistrements	3	0	6
   Lire des enregistrements à l'aide de la clé primaire	300	300	0
   Lire des enregistrements à l'aide de l'index secondaire	10	1 100	0
   Mettre à jour un enregistrement existant	5	10	20
   Supprimer l'enregistrement	1	2	2

   Total des 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'estimateur de capacité

Remarque : Les calculs précédents supposent que la lecture des demandes est cohérente à terme. Dans le cas d'une demande de cohérence absolue des opérations de lecture, l'opération consomme le double des unités de capacité. Par conséquent, les unités de capacité de lecture seraient 4844 unités de lecture.

Estimation des coûts mensuels

Découvrez 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ûts afin que vous puissiez déterminer votre utilisation mensuelle et les coûts avant de valider un modèle d'abonnement ou un montant.

L'évaluateur de coûts calcule automatiquement le coût mensuel en fonction de l'entrée des unités de lecture, des unités d'écriture et du stockage. Toutefois, pour comprendre comment calculer les unités de lecture et d'écriture de votre application, procédez comme suit :

1. Etape 1 : accédez à la rubrique Estimation de La capacité. Estimez la charge globale de votre application à l'aide de l'exemple et des formules décrits dans cette rubrique.

   Téléchargez et utilisez l'évaluateur de capacité d'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 du critère de charge globale pour l'application et des opérations de base de données.

2. Etape 2 : accédez à l'évaluateur de coût sur le site Web Oracle Cloud. Cochez la case Gestion des données. Faites défiler l'affichage pour localiser Oracle NoSQL Database Cloud, puis sélectionnez Ajouter afin d'ajouter une entrée pour Oracle NoSQL Database Cloud sous les options de configuration. Développez NoSQL Database pour rechercher les différentes options d'utilisation et d'installation. Valeurs d'entrée des paramètres d'utilisation et de configuration pour estimer le coût d'utilisation d'Oracle NoSQL Database Cloud Service à partir de vos abonnements Oracle Cloud Pay-As-You-Go et Monthly Flex.

3. Etape 3 : accédez à l'évaluateur de coûts sur le site Web Oracle Cloud. Dans la liste déroulante, sélectionnez Data Management. Plusieurs options s'affichent sous Gestion des données. Faites défiler l'affichage pour localiser Oracle NoSQL Database Cloud. Cliquez sur Add pour ajouter une entrée pour Oracle NoSQL Database Cloud sous les options de configuration.

4. Etape 4 : développez Database - NoSQL pour trouver les différentes options d'utilisation et de configuration. Vous avez le choix entre deux options sous Configuration. Vous pouvez commencer par une option Toujours gratuit (disponible uniquement dans la région Phoenix) ou provisionner l'instance avec la configuration souhaitée.

   • Etape 4a : si vous voulez une option Toujours gratuit, sous Configuration, développez Oracle NoSQL Database Cloud - Lecture, Oracle NoSQL Database Cloud Service - Stockage et Oracle NoSQL Database Cloud Service - Ecrivez et modifiez la capacité de lecture, de stockage et d'écriture sur 0. Votre estimation de coût total s'affiche alors sous la forme 0 et vous pouvez continuer avec l'option Toujours gratuit.

5. Etape 5 : si vous souhaitez provisionner une capacité de lecture, d'écriture et de stockage supérieure à celle disponible dans Always Free, vous pouvez également saisir les valeurs de configuration sous Database-NoSQL.

   • Etape 5a : lors de l'utilisation, ne modifiez pas les valeurs par défaut car Oracle NoSQL Database Cloud Service n'utilise aucune de ces valeurs.

   • Etape 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.

Remarque : si vous utilisez la fonction de redimensionnement 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. Nous vous recommandons de consigner les unités de lecture et d'écriture consommées renvoyé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 du système de mesure et de facturation Oracle Cloud.

Pour une présentation détaillée des différents modèles de tarification disponibles, reportez-vous à Tarifs NoSQL Database Cloud Service.

Coût/facturation pour les tables actives globales

Le coût/la facturation d'une table Global Active comporte deux composants. Le premier composant est le modèle de tarification suivi pour les tables singleton, 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 second composant concerne les écritures répliquées pour chaque réplique de table régionale de 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 cloud