Conceitos Básicos sobre o Cálculo

Antes de aprender a estimar o throughput e o armazenamento do serviço, vamos verificar o throughput e as definições da unidade de armazenamento.

• Unidade de Gravação (WU): uma Unidade de Gravação é definida com um throughput para até 1 kilobyte (KB) de dados por segundo. Uma operação de gravação é qualquer chamada de API do Oracle NoSQL Database Cloud Service que resulta na inserção, atualização ou exclusão de um registro. Uma tabela NoSQL tem um valor de limite de gravação que especifica o número de unidades de gravação que podem ser usadas a cada segundo. As atualizações de índice também consomem unidades de gravação.

  Por exemplo, um tamanho de registro de menos de 1 KB requer uma WU para uma operação de gravação. Um tamanho de registro de 1,5 KB requer duas WUs para a operação de gravação.

• Unidade de Leitura (RU): uma Unidade de Leitura é definida com um throughput para até 1 KB de dados por segundo para uma operação de leitura eventualmente consistente. Sua tabela NoSQL tem um valor de limite de leitura que especifica o número de unidades de leitura que podem ser usadas a cada segundo.

  Por exemplo, um tamanho de registro de menos de 1 KB requer uma RU para uma operação de leitura eventualmente consistente. Um tamanho de registro de 1,5 KB exige duas RUs para uma operação de leitura eventualmente consistente e quatro RUs para uma operação de leitura absolutamente consistente.

• Capacidade de Armazenamento: uma unidade de armazenamento é um único gigabyte (GB) de armazenamento de dados.

• Consistência Absoluta: espera-se que os dados retornados sejam os dados gravados mais recentemente no banco de dados.

• Consistência Eventual: os dados retornados podem não ser os dados gravados mais recentemente no banco de dados; se nenhuma nova atualização for feita nos dados, eventualmente todos os acessos a esses dados retornarão o valor atualizado mais recente.

Fatores Que Afetam a Unidade de Capacidade

Antes de provisionar as unidades de capacidade, é importante considerar os fatores a seguir que impactam as capacidades de leitura, gravação e armazenamento.

• Tamanho do registro: à medida que o tamanho do registro aumenta, o número de unidades de capacidade consumidas para gravar ou ler dados também aumenta.

• Consistência de dados: leituras de consistência absoluta são duas vezes o custo de leituras de consistência eventual.

• Índices Secundários: em uma tabela, quando um registro existente é modificado (adicionado, atualizado ou excluído), os índices secundários de atualização consomem Unidades de Gravação. O custo total de throughput provisionado para uma operação de gravação é a soma das unidades de gravação consumidas pela gravação na tabela e atualização dos índices secundários locais.

• Escolha de modelagem de dados: com o JSON sem esquema, cada documento é uma descrição automática que adiciona o overhead de metadados ao tamanho geral do registro. Com tabelas de esquema fixo, o overhead para cada registro é de exatamente 1 byte.

• Padrão de consulta: o custo de uma operação de consulta depende do número de linhas recuperadas, do número de predicados, do tamanho dos dados de origem, das projeções e da presença de índices. As consultas menos dispendiosas especificam uma chave de partição ou chave de índice (com um índice associado) para permitir que o sistema aproveite índices principais e secundários. Um aplicativo pode experimentar diferentes consultas e avaliar o throughput consumido para ajudar a ajustar as operações.

Exemplo Real: Como Estimar a Carga de Trabalho do Seu Aplicativo

Considere um exemplo de aplicativo de E-commerce para saber como estimar leituras e gravações por segundo. Neste exemplo, o Oracle NoSQL Database Cloud Service é usado para armazenar as informações do catálogo de produtos do aplicativo.

1. Identifique o modelo de dados (JSON ou tabela fixa), o tamanho do registro e o tamanho da chave do aplicativo.

   Suponha que o aplicativo E-commerce siga o modelo de dados JSON e o desenvolvedor tenha criado uma tabela simples com duas colunas. Um identificador de registro (chave primária) e um documento JSON para os recursos e atributos do produto. O documento JSON, com menos de 1 KB (0,8 KB), é o seguinte:

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

   Suponha que o aplicativo tenha 100.000 registros e que a chave primária tenha cerca de 20 bytes. Além disso, suponha que há consultas que leem registros via índice secundário. Por exemplo, para localizar todos os registros que tenham tamanho de tela de 13 polegadas. Portanto, um índice é criado no campo screenSize.

   As informações estão resumidas da seguinte forma:

   Tabelas	Linhas por Tabela	Colunas por Tabela	Tamanho da Chave em Bytes	Tamanho do Valor em Bytes (soma de todas as colunas)	Índices	Tamanho da Chave de Índice em Bytes
   1	100000	2	20	1 KB	1	20

2. Identifique a lista de operações (geralmente operações CRUD e leituras de Índice) na tabela e em qual taxa (por segundo) são esperadas.

   Operação	Número de Operações (por segundo)	Exemplo
   Criar Registros.	3	Para criar um produto.
   Ler registros usando a chave primária.	200	Para ler detalhes do produto usando o ID do produto.
   Ler registros usando o índice secundário.	1	Para extrair todos os produtos com tamanho de tela de 13 polegadas.
   Atualizar ou adicionar um atributo a um registro.	5	Para atualizar a descrição do produto de uma câmera ou Para adicionar informações sobre o peso de uma câmera.
   Excluir registro.	5	Para excluir um produto existente.

3. Identifique o consumo de leitura e gravação em KB.

   Operação	Premissas (Se houver)	Fórmula	Consumo de Leitura (KB)	Consumo de Gravação (KB)	Observações/Explicação
   Criar Registros.	Suponha que os registros sejam criados sem que nenhuma verificação de condição seja executada (se existir).	Record size (rounded to next KB) + 1 KB(index) * (number of indexes)	0	1 KB + 1 KB (1 ) = 2 KB	O tamanho do registro é de 1 KB (0,8 KB para a coluna JSON e 20 bytes para a coluna-chave) e há um índice de tamanho de 1 KB. Uma operação de criação incorre em um custo de unidade de leitura se você executar os comandos de colocação com algumas opções. Como você precisa garantir que está lendo a versão mais atual da linha, leituras consistentes absolutas são usadas. Nesses casos, você utiliza o multiplicador 2 na fórmula de unidade de leitura. Estas são as diferentes opções para determinar os custos unitários de leitura: Se Option.IfAbsent ou Option.IfPresent for usado, Consumo de Leitura = 2 Se setReturnRow for usado, Consumo de Leitura = 2 * Tamanho do registro Se Option.IfAbsent e setReturnRow forem usados, Consumo de Leitura = 2 * Tamanho do registro
   Ler registros usando a chave primária.		Record size round up to KB	Tamanho do registro = 1 KB	0	O tamanho do registro é de 1 KB
   Ler registros usando o índice secundário.	Suponha que 100 registros sejam retornados.	record_size * number_of_records_matched	11KB *100 = 100KB 100 KB + 10 KB = 110 KB	0	Não há cobrança pelo índice secundário. O tamanho do registro é de 1 KB. Para 100 registros, é de 100 KB. Mais 10 KB abrange o overhead variável que pode ocorrer dependendo do número de batches retornados e do limite de tamanho definido para a consulta. O custo indireto é o custo de leitura da última chave em um lote. Essa é uma variável que depende do maxReadKB e do tamanho do registro. A sobrecarga é de até (numBatches - 1) * custo de leitura da chave (1KB).
   Atualizar registros existentes	Suponha que o tamanho do registro atualizado seja igual ao tamanho do antigo registro (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	Quando as linhas são atualizadas usando uma consulta (instrução SQL), as unidades de leitura e gravação são consumidas. Dependendo da atualização, talvez seja necessário ler a chave primária, a chave secundária ou até mesmo o próprio registro. Leituras consistentes absolutas são necessárias para garantir que estamos lendo o registro mais recente. Consistência absoluta são duas vezes o custo de eventuais leituras de consistência. Essa é a razão da multiplicação por 2 na fórmula. Consumo de Leitura: Nenhum encargo para o índice e o tamanho do Registro é de 1 KB. Se estiver sendo executado usando a opção setReturnRow, então Ler Consumo = 2 * Tamanho do registro Consumo de Gravação: O tamanho do registro original e novo é de 1 KB e 1 KB para um índice.
   Excluir 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	A exclusão incorre em custos unitários de leitura e gravação. Como você precisa garantir que está examinando a versão mais atual da linha, são usadas leituras consistentes absolutas, ou seja, o motivo para usar o multiplicador 2 na fórmula da unidade de leitura. Se estiver sendo executado usando a opção setReturnRow, Consumo de Leitura = 2 * Tamanho do registro. Caso contrário, Consumo de Leitura= 1 KB para um índice Consumo de Gravação: O tamanho do registro é de 1 KB e 1 KB para o índice. O número do índice é 1.

   Usando as etapas 2 e 3, vamos determinar as unidades de leitura e gravação para a carga de trabalho do aplicativo.

   Operações	Taxa de Operações	Leituras por Segundo	Gravações por Segundo
   Criar registros	3	0	6
   Ler registros usando a Chave primária	300	300	0
   Ler registros usando o índice secundário	10	1100	0
   Atualizar registro existente	5	10	20
   Excluir registro	1	2	2

   Total de Unidades de Leitura: 1412

   Total de Unidades de Gravação: 28

   Portanto, estima-se que o aplicativo de eCommerce tenha uma carga de trabalho de 1412 leituras por segundo e 28 gravações por segundo. Faça o download da ferramenta Estimativa de Capacidade disponível no Oracle Technology Network para inserir esses valores e estimar o throughput e o armazenamento do seu aplicativo.