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 informations 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 aux besoins de développement d'applications.

Tâches du développeur NDCS

Oracle NoSQL Database Cloud Service (NDCS) est un service entièrement haute disponibilité. Il est conçu pour les applications hautement 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, comme 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

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

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 des mesures.

Trousses SDK/pilotes OCI - Oracle Cloud Infrastructure fournit un certain nombre de trousses SDK pour faciliter le développement de solutions personnalisées. Ils sont généralement sous licence UPL. Elles offrent des fonctionnalités similaires à celles de la console OCI au moyen d'une interface de programmation.

Références :

Limites du service Oracle NoSQL Database Cloud Service

Oracle NoSQL Database Cloud Service comporte diverses limites par défaut. Lorsque vous créez une table Oracle NoSQL Database Cloud Service, le système vérifie 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, voir Limites de service. Vous trouverez ci-dessous la liste des limites courantes applicables à Oracle NoSQL Database Cloud Service.

Limite	Portée	Description	Valeur dans un environnement non hébergé	Valeur dans un environnement hébergé
Stockage de table maximum	Table	Taille de stockage maximale totale par client. L'espace total utilisé pour au moins une table 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 ne peuvent pas dépasser 256 caractères. Tous les noms doivent commencer par une lettre (a-z, A-Z). Il peut s'agir de lettres (A-Z, A à Z), de chiffres (0 à 9) ou de traits de soulignement.	Identique à un environnement non hébergé
Capacité provisionnée - Débit de lecture et d'écriture maximal	Table	Débit de lecture et d'écriture maximal 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é/besoin dans un environnement hébergé
Capacité sur demande - Nombre de tables	Région	Nombre de tables avec capacité sur demande.	3	Non autorisé/besoin dans un environnement hébergé
Modifier le mode de provisionnement	Table	Modifiez le mode de provisionnement de la table de Provisioned à On Demand ou inversement.	Ne peut être modifié qu'une fois par jour.	S.O
Nombre maximal de tables.	Région	Le nombre maximal de tables.	30	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximal de colonnes.	Table	Nombre maximal de colonnes.	50	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximal de mises à jour de schéma	Table	Nombre maximal de mises à jour de schéma de table.	100	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximum d'index	Table	Le nombre maximum d'index.	5	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
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.	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Noms des index	Indexer	Nombre maximal de caractères, caractères permis et caractère initial.	Les noms d'index ne peuvent pas dépasser 64 caractères. Tous les noms doivent commencer par une lettre (a-z, A-Z). Il peut s'agir de lettres (A-Z, A à Z), de chiffres (0 à 9) ou de traits de soulignement.	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Nombre maximal d'opérations individuelles par demande `WriteMultiple`	Demande	Le nombre maximal d'opérations individuelles par demande `WriteMultiple`.	50	Identique à un environnement non hébergé. Cela peut également être augmenté à l'aide de la mise à jour des limites de service de demande.
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 la mise à jour des limites de service de demande.
Noms de colonne	Colonne	Nombre maximal de caractères, caractères permis et caractère initial.	Les noms de champ ne peuvent pas dépasser 64 caractères. Tous les noms doivent commencer par une lettre (a-z, A-Z). Il peut s'agir de lettres (A-Z, A à Z), de chiffres (0 à 9) ou de traits 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	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Taille maximale de la clé d'index principale	Indexer	Taille maximale de la clé primaire.	64 bytes	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Taille de rangée maximale	rangée	Taille de rangée maximale.	512 KO	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Longueur maximale de la chaîne d'interrogation.	Interrogation	Longueur maximale de la chaîne d'interrogation.	10 Ko.	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
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	Vous pouvez le personnaliser à l'aide de la fonction Demander la mise à jour des limites de service
Valeur maximale pour le débit et les ressources de stockage des données.	Région	Valeur maximale pour le débit et les ressources de stockage des données.	Par région, Oracle permet : 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, ce qui signifie que la région 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

Rubriques connexes

Estimation de la capacité

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

Concepts de base pour le calcul

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

Unité d'écriture : Une unité d'écriture est définie comme le débit pour un maximum de 1 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 de limite d'écriture est associée à une 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'

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 pour une opération de lecture avec cohérence à terme jusqu'à 1 Ko de données par seconde. Votre table NoSQL a une valeur limite de lecture qui spécifie 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 seul gigaoctet (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.
Unité à terme : Les données retournées ne peuvent pas être 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é, vous devez prendre en compte les 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.
Unité des données : Le coût des lectures avec cohérence absolue est le double du coût des 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 utilise 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.
Sélection 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 octets.
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 évaluer la charge de travail d'une application

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

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" }
}

Prenons l'exemple d'une application qui compte 100 000 enregistrements de ce type et dont la taille est 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	Lignes 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

Déterminez la liste des opérations (en général, les opérations de création, 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.

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

Opération	hypothèses (le cas échéant)	Formule	Consommation de lecture (Ko)	Consommation d'é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 en 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érence absolue sont utilisées. Dans ce cas, vous utilisez le multiplicateur 2 dans la formule de l'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é, la consommation en lecture = 2 Si setReturnRow est utilisé, la consommation de lecture = 2 * Taille de l'enregistrement Si Option.IfAbsent et setReturnRow sont utilisés, la consommation de lecture = 2 * Taille de l'enregistrement
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`	11Ko *100 = 100Ko 100 KB + 10 KB = 110 KB	0	Il n'y a pas de frais pour l'index secondaire. La taille d'enregistrement est de 1 Ko. Pour 100 enregistrements, elle est de 100 Ko. Compte supplémentaire de 10 Ko pour la surcharge variable qui peut 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 atteindre (numBatches - 1) * coût de lecture de clé (1 Ko).
Modifier 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 KO * 2	1 KO + 1 KO + 1 KO(1) *(2) = 4 KO	Lorsque les 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. Le coût des lectures avec cohérence absolue est le double du coût des lectures avec cohérence à terme. C'est la raison de la multiplication par 2 dans la formule. Consommation en lecture : Aucuns frais pour l'index et la taille de l'enregistrement sont de 1 Ko. Si vous exécutez à l'aide de l'option setReturnRow, la consommation de lecture = 2 * Taille de l'enregistrement 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 KB + 1 KB(1) * (1) = 2 KB	Une suppression entraîne des coûts unitaires en lecture et en écriture. Comme vous devez garantir que vous examinez la version la plus récente de la ligne, des lectures à cohérence absolue 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, Consommation de lecture = 2 * Taille de l'enregistrement. Sinon, consommation en 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.

À partir des étapes 2 et 3, déterminez les unités de lecture et d'écriture pour la charge de travail d'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
Modifier des enregistrements existants	5	10	20
Supprimer un enregistrement	1	2	2

Nombre total d'unités de lecture : 1412

Total des unités d'écriture : 28

Par conséquent, on estime que l'application de commerce électronique a une charge de travail de 1412 lectures par seconde et 28 écritures par seconde. Téléchargez l'évaluateur de capacité depuis Oracle Technology Network pour entrer ces valeurs, ainsi que le débit et le stockage estimatifs de votre application.

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 utilise 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 en fonction de votre entrée d'unités de lecture, d'unités d'écriture et de stockage. Pour comprendre comment calculer les unités de lecture et d'écriture pour votre application :

É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.

Étape 2 : Téléchargez et utilisez l'évaluateur de capacité sur Oracle Technology Network pour évaluer 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.
étape 2 : Accédez à l'évaluateur de coût sur le site Web Oracle Cloud. Cochez la case Data Management. Accédez à Oracle NoSQL Database Cloud, puis cliquez sur Add (Ajouter) pour ajouter une entrée pour Oracle NoSQL Database Cloud dans les options de configuration. Développez NoSQL Base de données 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 Oracle Cloud Pay-As-You-Go et Monthly Flex.
é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 s'affichent sous Data Management. Naviguez jusqu'à Oracle NoSQL Database Cloud. Cliquez sur Ajouter pour ajouter une entrée pour Oracle NoSQL Database Cloud dans les options de configuration.
Étape 4 : Développez la base de données - NoSQL pour rechercher les différentes options d'utilisation et de configuration. Vous avez deux options sous Configuration. Vous pouvez démarrer avec l'option "Toujours gratuit" 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 à 0 et vous pouvez continuer avec l'option Toujours gratuit.
Étape 5 : Vous pouvez également provisionner une capacité de lecture, d'écriture et de stockage supérieure à celle disponible dans l'offre de type Toujours gratuit en entrant 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é dans 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 qui sont 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 une présentation détaillée des différents modèles de tarification disponibles, voir Service NoSQL Database Cloud - Tarifs.

Coût/facturation pour les tables actives globales

Le coût/facturation d'une table globale active comprend deux composants. Le premier composant est le modèle de tarification suivi pour les tables types, 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.

Titre et droits d'auteur

Planifier votre service

Oracle et/ou ses sociétés affiliées.