Planification de votre service

Prenez le temps de planifier votre 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 NDCS Developer

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 é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'image developer_overview.png

NoSQL SDK/pilotes de base de données : ces kits SDK sont sous licence UPL (Universal Permissive License) et peuvent être utilisés sur NoSQL Cloud Service ou sur la base de données on-premise. 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 d'autres fournisseurs cloud.

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. Elles offrent des fonctionnalités similaires à la console OCI via une interface de programmation.

Références:

Limites Oracle NoSQL Database Cloud Service

Oracle NoSQL Database Cloud Service présente différentes limites par défaut. Lorsque vous créez une table Oracle NoSQL Database Cloud Service, le système vérifie que vos demandes sont dans les limites du seuil spécifié. 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 comment 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 la 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.5TB
Noms de table	Table	Nombre maximal de caractères, y compris les caractères autorisés et le caractère initial des 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). Les caractères suivants peuvent être des lettres (a-z, 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é à 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 une capacité On Demand.	3	Non autorisé/nécessaire dans un environnement hébergé
Modifier le mode de provisionnement	Table	Remplacez le mode de provisionnement de la table par Provisioned (Provisionné) par On Demand (On Demand), ou inversement.	Ne peut être modifié qu'une fois par jour.	S/O
Nombre maximal de tables	Région	Nombre maximal de tables.	30	Elle peut être personnalisée à l'aide de l'option Demander la mise à jour des limites de service
Nombre maximal de colonnes.	Table	Nombre maximal de colonnes.	50	Elle peut être personnalisée à l'aide de l'option Demander la mise à jour des limites de service
Nombre maximal de mises à jour de schéma de table	Table	Nombre maximal de mises à jour de schéma de table.	100	Elle peut être personnalisée à l'aide de l'option 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 l'option Demander la mise à jour des limites de service
Nombre maximal de modifications pour les limites de débit et de stockage	Table	Nombre maximal de modifications pour les limites de débit et de stockage.	Oracle autorise : Nombre illimité d'augmentations de stockage et de débit par jour Jusqu'à quatre réductions de débit ou de stockage par période de 24 heures.	Elle peut être personnalisée à l'aide de l'option Demander la mise à jour des limites de service
Noms d'index	Index	Nombre maximal de caractères, y compris les caractères autorisés et le 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). Les caractères suivants peuvent être des lettres (a-z, A-Z), des chiffres (0-9) ou un trait de soulignement.	Elle peut être personnalisée à l'aide de l'option Demander la mise à jour des limites de service
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é. Vous pouvez également l'augmenter à l'aide de la mise à jour des limites de service de demande
Taille maximale des données pour la demande `WriteMultiple`	Demande	Taille maximale des données pour la demande `WriteMultiple`	25 MB	Identique à un environnement non hébergé. Vous pouvez également l'augmenter à l'aide de la mise à jour des limites de service de demande
Noms de colonne	Colonne	Nombre maximal de caractères, y compris les caractères autorisés et le caractère initial.	Les noms de champ peuvent contenir au maximum 64 caractères. 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 un trait de soulignement.	Identique à un environnement non hébergé.
Taille maximale de clé d'index secondaire	Index	Taille maximale de clé d'index	64 octets	Elle peut être personnalisée à l'aide de l'option Demander la mise à jour des limites de service
Taille maximale de clé d'index principal	Index	Taille maximale de la clé primaire	64 octets	Elle peut être personnalisée à l'aide de l'option Demander la mise à jour des limites de service
Taille maximale de ligne	Ligne	Taille maximale de ligne	512 ko	Elle peut être personnalisée à l'aide de l'option 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 l'option 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 l'option 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 autorise : 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 une taille de stockage de 5 To. Dans ce cas la région ne peut pas créer d'autre table. Vous pouvez également disposer de plusieurs tables en vous assurant que les données contenues dans 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é

En savoir plus sur l'estimation du débit et des capacités de stockage de votre service Oracle NoSQL Database Cloud Service.

Notions de base pour le calcul

Avant d'apprendre à évaluer le débit et le stockage du service, examinez les définitions d'une unité de stockage et du débit.

Unité d'écriture : une unité d'écriture correspond au débit maximal d'1 kg de données par seconde. Il s'agit de 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, un enregistrement d'une taille inférieure à 1 ko nécessite une unité 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 lecture : une unité de lecture correspond au débit maximal d'1 ko de données par seconde pour une opération de lecture cohérente à terme. 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 données renvoyées doivent être les données les plus récentes écrites dans la base de données.
Cohérence à terme : les données renvoyées peuvent ne pas être les données les plus récentes é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 retournent la dernière valeur mise à jour à terme.

Remarques :

Oracle NoSQL Database Cloud Service gère automatiquement les capacités de lecture et d'écriture afin de 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é On Demand. Pour plus d'informations, reportez-vous aux limites Oracle NoSQL Database Cloud Service.

Facteurs d'impact 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 : avec l'augmentation de la taille de l'enregistrement, le nombre d'unités de capacité utilisées pour écrire ou lire les données augmente également.
Cohérence des données : la cohérence absolue des opérations de lecture correspond à deux fois le coût de la cohérence à terme des opérations de lecture.
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 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 des données : avec le format JSON sans schéma, chaque document est auto-documenté, ce qui ajoute une surcharge de métadonnées à la taille globale de l'enregistrement. Avec les tables de schéma fixe, les frais généraux de chaque enregistrement sont exactement de 1 octet.
Motif de requête : le coût d'une opération de requête dépend du nombre de lignes extraites, du nombre de prédicats, de la taille des données source, des projections et de 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 évaluer 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 de produits de l'application.

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

Considérons que l'application de commerce électronique suit le modèle de données JSON et que le développeur a créé une table simple avec deux colonnes. 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), 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" }
}

Partons du principe que l'application possède 100 000 enregistrements de ce type et que la taille de la clé primaire est d'environ 20 octets. En outre, supposons que des requêtes lisent les enregistrements à l'aide d'un 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	Colonne par table	Taille de clé en octets	Taille de valeur en octets (somme de toutes les colonnes)	Index	Taille d'index en octets
1	100000	2	20	1 ko	1	20

Identifiez la liste des opérations (en général 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.
Lire les enregistrements à l'aide de l'index secondaire.	1	Permet d'extraire tous les produits d'un écran de 13 pouces.
Mettre à jour ou ajouter un attribut à un enregistrement.	5	Permet de mettre à jour la description d'un appareil photo ou d'ajouter des informations sur le poids d'un appareil photo.
Supprimer un enregistrement.	5	Permet de supprimer un produit existant.

Identifiez la consommation en lecture/é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.	Imaginons 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 KB + 1 KB (1) = 2 KB	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 de 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é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é, consommation en lecture = 2 Si setReturnRow est utilisé, la consommation en lecture = 2 * taille de l'enregistrement Si Option.IfAbsent et setReturnRow sont utilisés, la consommation en lecture = 2 * taille d'enregistrement
Lire des enregistrements à l'aide de la clé primaire.		`Record size round up to KB`	Taille de l'enregistrement = 1 Ko	0	La taille d'enregistrement est de 1 ko.
Lire les enregistrements à l'aide de l'index secondaire.	Imaginons que 100 enregistrements sont renvoyés.	`record_size * number_of_records_matched`	11 ko *100 = 100 ko 100 KB + 10 KB = 110 KB	0	Il n'y a pas de frais pour l'indice secondaire. La taille d'enregistrement est de 1 ko. Pour 100 enregistrements, c'est 100 Ko. 10 ko supplémentaires représentent le temps système variable pouvant survenir en fonction du nombre de batches renvoyés et de la limite de taille définie pour la requête. Les frais généraux correspondent au coût de lecture de la dernière clé d'un batch. Il s'agit d'une variable qui dépend de maxReadKB et de la taille d'enregistrement. La surcharge peut aller 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 KB * 2	1 KB + 1 KB + 1KB(1) *(2) = 4 KB	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 l'enregistrement le plus récent. La cohérence absolue des opérations de lecture correspond à deux fois le coût final des opérations de lecture. C'est la raison de la multiplication par 2 dans la formule. Consommation en lecture : la taille de l'index et de l'enregistrement est de 1 ko. En cas d'exécution à l'aide de l'option setReturnRow, la consommation en lecture = 2 * taille d'enregistrement Consommation d'écriture : la taille de l'enregistrement d'origine et celle du nouvel enregistrement sont de 1 ko et 1 ko pour un index.
Supprimer enregistrement		`Read consumption = 1 KB (index) * 2` `Write consumption = record_size + 1KB (index) * (number_of_indexes)`	1 KB (1) *2 = 2 KB	1 KB + 1 KB(1) * (1) = 2 KB	Une suppression entraîne des coûts unitaires de lecture et d'é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 devez utiliser 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 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 de travail de l'application.

Opérations	Taux d'opérations	Lecture 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 enregistrement	1	2	2

Nombre total d'unités de lecture : 1412

Nombre total d'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'outil Capacity Estimator sur Oracle Technology Network pour entrer ces valeurs, évaluer le débit et le stockage de votre application.

Remarques :

Les calculs précédents supposent que les demandes de lecture sont cohérentes à terme. Dans le cas d'une demande de cohérence absolue des opérations de lecture, l'opération utilise deux fois plus d'unités de capacité. Par conséquent, les unités de capacité de lecture sont de 4844 unités de lecture.

Estimation des coûts mensuels

Découvrez comment évaluer 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 de déterminer votre utilisation mensuelle et les coûts mensuels 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 :

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.

Etape 2 : téléchargez et utilisez l'évaluateur de capacité d'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 des critères de charge globale de l'application et des opérations de base de données.
Etape 2 : accédez à l'évaluateur de coûts sur le site Web Oracle Cloud. Cochez la case Gestion des données. Accédez à Oracle NoSQL Database Cloud et cliquez sur Ajouter pour ajouter une entrée à Oracle NoSQL Database Cloud sous 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.
Etape 3 : accédez à l'estimateur de coût sur le site Web Oracle Cloud. Dans la liste déroulante, sélectionnez Data Management. Diverses options s'affichent sous Data Management. Faites défiler pour localiser Oracle NoSQL Database Cloud. Cliquez sur Add pour ajouter une entrée pour Oracle NoSQL Database Cloud sous les options de configuration.
Etape 4 : développez Base de données - NoSQL pour rechercher les différentes options d'utilisation et de configuration. Deux options sont disponibles sous Configuration. Vous pouvez commencer avec l'option Always Free (Toujours gratuit) 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 - Ecriture et modifiez la capacité de lecture, de stockage et d'écriture sur 0. L'estimation du coût total est alors affichée avec la valeur 0 et vous pouvez continuer avec l'option Toujours gratuit.
Etape 5 : si vous voulez provisionner une capacité de lecture, d'écriture et de stockage supérieure à celle disponible dans Toujours gratuit, vous pouvez également le faire en saisissant les valeurs de configuration sous Base de données-NoSQL.
- Etape 5a : sous Utilisation, ne modifiez pas les valeurs par défaut car Oracle NoSQL Database Cloud Service n'utilise aucune de ces valeurs.
- Etape 5 b : sous Configuration, ajoutez le nombre d'unités de lecture, d'unités d'écriture et de capacité de stockage estimé à l'étape précédente. Le coût est estimé en fonction des valeurs saisies et affiché sur la page.

Remarques :

Si vous utilisez la fonctionnalité de redimensionnement automatique, une facture est générée en fin de mois pour la consommation réelle des 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é 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 obtenir des informations détaillées sur les différents modèles de tarification disponibles, reportez-vous aux tarifs NoSQL Database Cloud Service.

Coût/facturation pour les tables actives globales

Le coût/la facturation d'une table active globale comporte deux composants. Le premier composant est le modèle de tarification suivi pour les tables uniques, 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 active globale. Les écritures répliquées entrantes sont facturées en fonction des écritures consommées.

Informations relatives au titre et au copyright

Planification de votre service

Oracle et/ou ses affiliés.