Aspectos básicos sobre el cálculo

Antes de obtener información sobre cómo estimar el rendimiento y el almacenamiento del servicio, revise las definiciones de las unidades de almacenamiento y rendimiento.

• Unidad de escritura (WU): una unidad de escritura corresponde al rendimiento de hasta 1 kilobyte (kB) de datos por segundo. Una operación de escritura es cualquier llamada de API de Oracle NoSQL Database Cloud Service que da como resultado la inserción, actualización o supresión de un registro. Una tabla NoSQL tiene un valor de límite de escritura que especifica el número de unidades de escritura que se pueden utilizar cada segundo. Las actualizaciones de índice también consumen unidades de escritura.

  Por ejemplo, un tamaño de registro inferior a 1 kB necesita una WU para una operación de escritura. Un tamaño de registro de 1,5 kB necesita dos W para la operación de escritura.

• Unidad de lectura (RU): una unidad de lectura se corresponde con un rendimiento de hasta 1 kB de datos por segundo para una operación de lectura finalmente coherente. La tabla NoSQL tiene un valor de límite de lectura que especifica el número de unidades de lectura que se pueden utilizar cada segundo.

  Por ejemplo, un tamaño de registro de menos de 1 kB requiere una RU para una operación de lectura finalmente coherente. Un tamaño de registro de 1,5 kB necesita dos RU para una operación de lectura finalmente coherente y cuatro RU para una operación de lectura totalmente coherente.

• Capacidad de almacenamiento: una unidad de almacenamiento corresponde a un solo gigabyte (GB) de almacenamiento de datos.

• Coherencia absoluta: se espera que los datos devueltos sean los datos escritos más recientemente en la base de datos.

• Coherencia final: puede que los datos devueltos no sean los escritos más recientemente en la base de datos; si no se realizan nuevas actualizaciones en los datos, finalmente todos los accesos a dichos datos devuelven el último valor actualizado.

Factores que afectan a la unidad de capacidad

Antes de aprovisionar las unidades de capacidad, es importante tener en cuenta los siguientes factores que afectan a las capacidades de lectura, escritura y almacenamiento.

• Tamaño de registro: a medida que aumenta el tamaño del registro, también aumenta el número de unidades de capacidad consumidas para escribir o leer datos.

• Coherencia de datos: las lecturas absolutamente coherentes duplican el coste de las lecturas finalmente coherentes.

• Índices secundarios: en una tabla, cuando se modifica un registro existente (se agrega, actualiza o suprime), la actualización de índices secundarios consume unidades de escritura. El costo del rendimiento total aprovisionado para una operación de escritura es la suma de las unidades de escritura consumidas por la escritura en la tabla y la actualización de los índices secundarios locales.

• Selección de modelado de datos: con JSON sin esquema, cada documento se describe automáticamente, lo que supone un exceso de metadatos en el tamaño general del registro. Con tablas de esquema fijo, el exceso de cada registro equivale exactamente a 1 byte.

• Patrón de consulta: el costo de una operación de consulta depende del número de filas recuperadas, el número de predicados, el tamaño de los datos de origen, las previsiones y la presencia de índices. Las consultas menos costosas especifican una clave de partición horizontal o una clave de índice (con un índice asociado) para permitir al sistema aprovechar los índices primarios y secundarios. Una aplicación puede probar diferentes consultas y examinar el rendimiento consumido para ayudar a ajustar las operaciones.

Ejemplo en el mundo real: cómo estimar la carga de trabajo de la aplicación

Considere un ejemplo de aplicación de ecommerce para aprender a estimar las lecturas y escrituras por segundo. En este ejemplo, Oracle NoSQL Database Cloud Service se utiliza para almacenar la información del catálogo de productos de la aplicación.

1. Identifique el modelo de datos (JSON o tabla fija), el tamaño de registro y el tamaño de clave para la aplicación.

   Supongamos que la aplicación de e-commerce sigue el modelo de datos JSON y el desarrollador ha creado una tabla simple con dos columnas. Un identificador de registro (clave primaria) y un documento JSON para los atributos y las funciones del producto. El documento JSON, que tiene menos de 1 KB (0,8 KB), es el siguiente:

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

   Suponga que la aplicación tiene 100 000 registros de ese tipo y que la clave primaria tiene aproximadamente 20 bytes de tamaño. Además, suponga que hay consultas que leen registros a través de un índice secundario. Por ejemplo, para buscar todos los registros que tengan un tamaño de pantalla de 13 pulgadas. Por lo tanto, se crea un índice en el campo screenSize.

   Podría resumirse así:

   Tablas	Filas por tabla	Columnas por tabla	Tamaño de la clave en bytes	Tamaño de valor en bytes (suma de todas las columnas)	Índices	Tamaño de clave de índice en bytes
   1	100 000	2	20	1 KB	1	20

2. Identifique la lista de operaciones (normalmente operaciones de creación, lectura, actualización y supresión, y lecturas de índice) en la tabla y la velocidad prevista de dichas operaciones (por segundo).

   Operación	Número de operaciones (por segundo)	Ejemplo
   Crear registros.	3	Para crear un producto.
   Leer registros mediante la clave primaria.	200	Para leer los detalles del producto mediante el ID de producto.
   Leer registros mediante el índice secundario.	1	Para recuperar todos los productos con un tamaño de pantalla de 13 pulgadas.
   Actualizar o agregar un atributo a un registro.	5	Para actualizar la descripción del producto de una cámara o bien Para agregar información sobre el peso de una cámara.
   Suprimir registro.	5	Para suprimir un producto existente.

3. Determine el consumo de lectura y escritura en kB.

   Operación	Suposiciones (si las hay)	Fórmula	Consumo de lectura (KB)	Consumo de escritura (KB)	Notas/Explicación
   Crear registros.	Suponga que los registros se crean sin realizar ninguna comprobación de condición (si la hubiera).	Record size (rounded to next KB) + 1 KB(index) * (number of indexes)	0	1 kB + 1 kB (1 ) = 2 kB	El tamaño del registro es de 1 KB (0,8 KB para la columna JSON y 20 bytes para la columna de clave) y hay un índice de tamaño 1 KB. Una operación de creación genera un costo de unidad de lectura si ejecuta los comandos put con algunas opciones. Puesto que necesita garantizar que está leyendo la versión más actual de la fila, se utilizan lecturas consistentes absolutas. En estos casos, se utiliza el multiplicador 2 en la fórmula de unidad de lectura. A continuación se muestran las diferentes opciones para determinar los costos de unidad de lectura: Si se utiliza Option.IfAbsent o Option.IfPresent, consulte Consumo = 2 Si se utiliza setReturnRow, Consumo de lectura = 2 * Tamaño de registro Si se utiliza Option.IfAbsent y setReturnRow, Consumo de lectura = 2 * Tamaño de registro
   Leer registros mediante la clave primaria.		Record size round up to KB	Tamaño de registro = 1 kB	0	El tamaño del registro es de 1 KB
   Leer registros mediante el índice secundario.	Suponga que se devuelven 100 registros.	record_size * number_of_records_matched	11 KB * 100 = 100 KB 100 KB + 10 KB = 110 KB	0	No hay ningún cargo por el índice secundario. El tamaño del registro es de 1 KB. Para 100 registros, es de 100 KB. Otros 10 KB representan la sobrecarga variable que se puede producir según el número de lotes devueltos y el límite de tamaño definido para la consulta. La sobrecarga es el costo de la lectura de la última clave en un lote. Esta es una variable que depende del tamaño de registro y maxReadKB. La sobrecarga es de hasta (numBatches - 1) * costo de lectura de clave (1 KB).
   Actualizar registros existentes	Suponga que el registro actualizado tiene el mismo tamaño que el registro antiguo (1 kB).	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 + 1 KB(1) *(2) = 4 KB	Cuando las filas se actualizan mediante una consulta (sentencia SQL), se consumen tanto las unidades de lectura como las de escritura. Según la actualización, puede que necesite leer la clave primaria, la clave secundaria o incluso el propio registro. Se necesitan lecturas consistentes absolutas para garantizar que estamos leyendo el registro más reciente. Las lecturas de consistencia absoluta duplican el costo de las lecturas de consistencia eventuales. Es el motivo de multiplicar por 2 en la fórmula. Consumo de lectura: ningún cargo por índice y tamaño de registro es de 1 KB. Si se ejecuta con la opción setReturnRow, Consumo de lectura = 2 * Tamaño de registro Consumo de escritura: el tamaño de registro original y nuevo es de 1 KB y 1 KB para un índice.
   Suprimir registro		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	Una supresión tiene costos de unidad de lectura y escritura. Puesto que tiene que garantizar que está mirando la versión más actual de la fila, se utilizan lecturas consistentes absolutas, es decir, el motivo por el que se utiliza el multiplicador 2 en la fórmula de unidad de lectura. Si se ejecuta con la opción setReturnRow, Consumo de lectura = 2 * Tamaño de registro. De lo contrario, Leer consumo= 1 KB para un índice Consumo de escritura: el tamaño del registro es de 1 KB y 1 KB para el índice. El número de índice es 1.

   Con los pasos 2 y 3, vamos a determinar las unidades de lectura y escritura para la carga de trabajo de la aplicación.

   Operaciones	Velocidad de las operaciones	Lecturas por segundo	Escrituras por segundo
   Crear registros	3	0	6
   Leer registros mediante la clave primaria	300	300	0
   Leer registros mediante el índice secundario	10	1100	0
   Actualizar un registro existente	5	10	20
   Suprimir registro	1	2	2

   Total de unidades de lectura: 1412

   Total de unidades de escritura: 28

   Por lo tanto, se estima que la aplicación de e-commerce tiene una carga de trabajo de 1412 lecturas por segundo y 28 escrituras por segundo. Descargue el estimador de capacidad de Oracle Technology Network para introducir estos valores y calcular el rendimiento y el almacenamiento de la aplicación.