Concepts de base pour le calcul

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

• Unité d'écriture : Équivaut au débit de 1 kilo-octet (Ko) de données par seconde. Une opération d'écriture est tout appel d'API Oracle NoSQL Database Cloud 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 pour une opération de lecture avec cohérence à terme . Il peut atteindre 1 Ko de données par seconde. 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 correspond à 1 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.

• Cohérence à terme : Les données retournées ne sont pas nécessairement 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.

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, le service Oracle NoSQL Database Cloud est utilisé pour stocker les informations du 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. Supposons en outre que des interrogations liront les enregistrements au moyen 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 (éventuellement)	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).	Taille d'enregistrement (arrondie au Ko suivant) + 1 Ko(index) * (nombre d'index)	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 vous assurer de lire la version la plus récente de la ligne, les 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 pour déterminer les coûts unitaires de lecture : Si Option.IfAbsent ou Option.IfPresent est utilisé, alors Lire la consommation = 2 Si setReturnRow est utilisé, alors Lire la consommation = 2 * Taille de l'enregistrement Si Option.IfAbsent et setReturnRow sont utilisés, alors Lire la consommation = 2 * Taille d'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	11 Ko * 100 = 100 Ko 100 KB + 10 KB = 110 KB	0	Aucuns frais ne s'appliquent pour l'index secondaire. La taille de l'enregistrement est de 1 Ko. Pour 100 enregistrements, elle est de 100 Ko. D'autres comptes de 10 Ko sont responsables de la surcharge variable, selon le nombre de lots retournés et la limite de taille définie pour l'interrogation. Les frais généraux représentent le coût de lecture de la dernière clé d'un lot. Il s'agit d'une variable qui dépend de maxReadKB et de la taille de l'enregistrement. Les frais généraux s'élèvent à (numBatches - 1) * coût de lecture de clé (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 Consommation d'unités d'écriture = original_record_size + new_record_size + 1 Ko (index) * (nombre d'écritures)	1 KO * 2	1 KB + 1 KB + 1KB(1) *(2) = 4 KB	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 cohérentes absolues sont nécessaires pour garantir que nous lisons le dernier enregistrement. Les lectures à cohérence absolue représentent le double du coût des lectures à cohérence éventuelle. C'est la raison de la multiplication par 2 dans la formule. Consommation de lecture : Aucuns frais pour l'index et la taille de l'enregistrement n'est de 1 Ko. Si vous exécutez avec l'option setReturnRow, lisez la consommation = 2 * Taille de l'enregistrement Consommation d'écriture : La taille initiale et la nouvelle taille d'enregistrement sont de 1 Ko et de 1 Ko pour un index.
   Supprimer un enregistrement		Consommation d'unités de lecture = 1 Ko (index) * 2 Consommation d'unités d'écriture = record_size + 1Ko (index) * (number_of_indexes)	1 KO (1) *2 = 2 KO	1 KO + 1 KO(1) * (1) = 2 KO	Une suppression entraîne à la fois des coûts d'unité de lecture et d'écriture. Comme vous devez vous assurer de consulter la version la plus récente de la ligne, les lectures cohérentes absolues sont utilisées, c'est-à-dire la raison d'utiliser le multiplicateur 2 dans la formule d'unité de lecture. En cas d'exécution à l'aide de l'option setReturnRow, Consommation de lecture = 2 * Taille de l'enregistrement. Sinon, Lire la consommation = 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.

   À partir des étapes 2 et 3, déterminons les unités de lecture et d'écriture pour notre 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	1100	0
   Mettre à jour un enregistrement existant	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, l'application de commerce électronique devrait avoir une charge de travail estimative de 1412 lectures par seconde et de 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.