Notions de base pour le calcul

Avant d'apprendre à estimer 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 kilo-octet (ko) de données par seconde. 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 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 renvoient la dernière valeur mise à jour à terme.

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 de l'enregistrement augmente, 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 un temps système de 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 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 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 de 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 de données JSON et que le 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 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 :

   Tables	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	100 000	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	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.

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

   Opération	Hypothèses (le cas échéant)	Formule	Consommation en lecture (ko)	Consommation en écriture (ko)	Notes/Explication
   Créer des enregistrements.	Supposons que les enregistrements soient créés sans effectuer de vérification de condition (si des vérifications existent).	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 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é, la consommation de lecture = 2 Si setReturnRow est utilisé, la consommation des lectures = 2 * Taille de l'enregistrement Si Option.IfAbsent et setReturnRow sont utilisés, consommation des lectures = 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	La taille d'enregistrement est de 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	Il n'y a pas de frais pour l'index secondaire. La taille d'enregistrement est de 1 ko. Pour 100 enregistrements, il est de 100 Ko. Des 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. La surcharge correspond au coût de lecture de la dernière clé dans un lot. Il s'agit d'une variable qui dépend de maxReadKB et de la taille de l'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 Consommation en écriture = taille_enregistrement_origine + nouvelle_taille_enregistrement + 1 ko (index) * (nombre d'écritures)	1 ko * 2	1 ko + 1 ko + 1 ko(1) *(2) = 4 ko	Lorsque des lignes sont mises à jour à l'aide d'une interrogation (instruction SQL), les unités de lecture et d'écriture sont consommées. Selon la mise à jour, il peut être nécessaire de lire la clé primaire, la clé secondaire, voire l'enregistrement lui-même. Des lectures cohérentes absolues sont nécessaires pour garantir que nous lisons le dernier enregistrement. La cohérence absolue des lectures correspond à deux fois le coût des lectures de cohérence à terme. C'est la raison de la multiplication par 2 dans la formule. Consommation en lecture : aucun frais pour l'index et la taille de l'enregistrement n'est de 1 ko. En cas d'exécution à l'aide de l'option setReturnRow, la consommation des lectures = 2 * Taille de l'enregistrement Consommation en écriture : les tailles d'enregistrement d'origine et de nouvel enregistrement sont de 1 ko et 1 ko pour un index.
   Supprimer un enregistrement		Consommation en lecture = 1 ko (index) * 2 Consommation en écriture = taille_enregistrement + 1 ko (index) * (nombre_index)	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 vous assurer que vous examinez la version la plus récente de la ligne, des lectures cohérentes absolues sont utilisées, c'est la raison pour laquelle vous utilisez le multiplicateur 2 dans la formule d'unité de lecture. En cas d'exécution à l'aide de l'option setReturnRow, consommation en lecture = 2 * Taille de l'enregistrement. Sinon, la 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 égal à 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	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	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, la charge globale de l'application de commerce électronique est estimée à 1412 lectures et 28 écritures par seconde. Téléchargez l'outil Evaluateur de capacité sur Oracle Technology Network pour entrer ces valeurs, et estimer le débit et le stockage de votre application.