As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Estimar o tamanho da linha no Amazon Keyspaces
O Amazon Keyspaces fornece armazenamento totalmente gerenciado que oferece desempenho de leitura e gravação de milissegundos de um dígito e armazena dados de forma durável em várias zonas de disponibilidade. AWS O Amazon Keyspaces anexa metadados a todas as linhas e colunas de chave primária para oferecer suporte ao acesso eficiente aos dados e à alta disponibilidade.
Este tópico fornece detalhes sobre como estimar o tamanho codificado das linhas no Amazon Keyspaces. O tamanho codificado das linhas é usado ao calcular o uso da fatura e da cota. Você também pode usar o tamanho da linha codificada ao estimar os requisitos de capacidade de taxa de transferência provisionada para tabelas.
Para calcular o tamanho codificado das linhas no Amazon Keyspaces, é possível usar as diretrizes a seguir.
**Topics**
+ [Estime o tamanho codificado das colunas](#calculating-row-size-columns)
+ [Estime o tamanho codificado dos valores de dados com base no tipo de dados](#calculating-row-size-data-types)
+ [Considere o impacto dos recursos do Amazon Keyspaces no tamanho da linha](#calculating-row-size-features)
+ [Escolha a fórmula certa para calcular o tamanho codificado de uma linha](#calculating-row-size-formula)
+ [Exemplo de cálculo do tamanho da linha](#calculating-row-size-example)
## Estime o tamanho codificado das colunas
Esta seção mostra como estimar o tamanho codificado das colunas no Amazon Keyspaces.
+ **Colunas regulares** — Para colunas regulares, que não são chaves primárias, colunas de agrupamento ou `STATIC` colunas, use o tamanho bruto dos dados da célula com base no [tipo de dados](cql.elements.md#cql.data-types) e adicione os metadados necessários. Os tipos de dados e algumas diferenças importantes na forma como o Amazon Keyspaces armazena valores de tipos de dados e metadados estão listados na próxima seção.
+ **Colunas de chave** de partição — As chaves de partição podem conter até 2048 bytes de dados. Cada coluna de chave na chave de partição requer até 3 bytes de metadados. Ao calcular o tamanho da sua linha, você deve assumir que cada coluna de chave de partição usa os 3 bytes completos de metadados.
+ **Colunas de agrupamento — As colunas** de agrupamento podem armazenar até 850 bytes de dados. Além do tamanho do valor dos dados, cada coluna de clustering exige até 20% do tamanho do valor dos dados para metadados. Ao calcular o tamanho da sua linha, você deve adicionar 1 byte de metadados para cada 5 bytes do valor dos dados da coluna de clustering.
**nota**
Para oferecer suporte a consultas eficientes e indexação integrada, o Amazon Keyspaces armazena o valor dos dados de cada chave de partição e coluna de chave de agrupamento duas vezes.
+ **Nomes de coluna** — O espaço necessário para cada nome de coluna é armazenado usando um identificador de coluna e adicionado a cada valor de dados armazenado na coluna. O valor de armazenamento do identificador da coluna depende do número geral de colunas em sua tabela:
+ 1 a 62 colunas: 1 byte
+ 63 a 124 colunas: 2 bytes
+ 125 a 186 colunas: 3 bytes
Para cada 62 colunas adicionais, adicione 1 byte. Observe que, no Amazon Keyspaces, até 225 colunas regulares podem ser modificadas com uma única instrução `INSERT` ou `UPDATE`. Para obter mais informações, consulte [Service Quotas do Amazon Keyspaces](quotas.md#table).
## Estime o tamanho codificado dos valores de dados com base no tipo de dados
Esta seção mostra como estimar o tamanho codificado de diferentes tipos de dados no Amazon Keyspaces.
+ **Tipos de string — Os tipos** de dados Cassandra `ASCII``TEXT`,, e `VARCHAR` string são todos armazenados no Amazon Keyspaces usando Unicode com codificação binária UTF-8. O tamanho de uma string no Amazon Keyspaces é igual ao número de bytes codificados em UTF-8.
+ **Tipos numéricos** — Cassandra`INT`,,, `BIGINT` `SMALLINT``TINYINT`, e `VARINT` os tipos de dados são armazenados no Amazon Keyspaces como valores de dados com comprimento variável, com até 38 dígitos significativos. Zeros iniciais e finais são cortados. O tamanho de qualquer um desses tipos de dados é de aproximadamente 1 byte por dois dígitos significativos \$1 1 byte.
+ **Tipo de blob** — A `BLOB` no Amazon Keyspaces é armazenado com o comprimento bruto do byte do valor.
+ **Tipo booleano** — O tamanho de um `Boolean` valor ou `Null` valor é de 1 byte.
+ **Tipos de coleção** — Uma coluna que armazena tipos de dados de coleta como `LIST` ou `MAP` exige 3 bytes de metadados, independentemente de seu conteúdo. O tamanho de um `LIST` ou `MAP` é (id da coluna) \$1 soma (tamanho dos elementos aninhados) \$1 (3 bytes). O tamanho de um `LIST` ou `MAP` vazio é (id da coluna) \$1 (3 bytes). Cada elemento individual `LIST` ou `MAP` também exige 1 byte de metadados.
+ **Tipos definidos pelo usuário** — Um [tipo definido pelo usuário (UDT)](udts.md) requer 3 bytes para metadados, independentemente de seu conteúdo. Para cada elemento do UDT, o Amazon Keyspaces exige um byte adicional de metadados.
Para calcular o tamanho codificado de um UDT, comece com o `field name` e o `field value` para os campos de um UDT:
+ **nome do campo** — Cada nome de campo do UDT de nível superior é armazenado usando um identificador. O valor de armazenamento do identificador depende do número geral de campos em seu UDT de nível superior e pode variar entre 1 e 3 bytes:
+ 1—62 campos: 1 byte
+ 63—124 campos: 2 bytes
+ 125— campos máximos: 3 bytes
+ **valor do campo** — Os bytes necessários para armazenar os valores de campo do UDT de nível superior dependem do tipo de dados armazenado:
+ **Tipo de dados escalar** — Os bytes necessários para armazenamento são os mesmos do mesmo tipo de dados armazenado em uma coluna normal.
+ **UDT congelada** — Para cada UDT aninhada congelada, a UDT aninhada tem o mesmo tamanho que teria no protocolo binário CQL. Para um UDT aninhado, 4 bytes são armazenados para cada campo (incluindo campos vazios) e o valor do campo armazenado é o formato de serialização do protocolo binário CQL do valor do campo.
+ **Coleções Frozen**:
+ **LIST** **e SET** — Para um congelado aninhado `LIST` ou`SET`, 4 bytes são armazenados para cada elemento da coleção mais o formato de serialização do protocolo binário CQL do valor da coleção.
+ **MAP** — Para um congelado aninhado`MAP`, cada par de valores-chave tem os seguintes requisitos de armazenamento:
+ Para cada chave, aloque 4 bytes e, em seguida, adicione o formato de serialização do protocolo binário CQL da chave.
+ Para cada valor, aloque 4 bytes e, em seguida, adicione o formato de serialização do protocolo binário CQL do valor.
+ **Palavra-chave FROZEN** — Para coleções congeladas aninhadas em coleções congeladas, o Amazon Keyspaces não exige nenhum byte adicional para metadados.
+ **Palavra-chave STATIC** — os dados da `STATIC` coluna não contam para o tamanho máximo da linha de 1 MB. Para calcular o tamanho dos dados das colunas estáticas, consulte [Calcular o tamanho da coluna estática por partição lógica no Amazon Keyspaces](static-columns-estimate.md).
## Considere o impacto dos recursos do Amazon Keyspaces no tamanho da linha
Esta seção mostra como os recursos no Amazon Keyspaces afetam o tamanho codificado de uma linha.
+ Carimbos de **data/hora do lado do cliente — Os carimbos** de data/hora do lado do cliente são armazenados para cada coluna em cada linha quando o recurso é ativado. Esses carimbos de data/hora ocupam aproximadamente 20 a 40 bytes (dependendo dos seus dados) e contribuem para o custo de armazenamento e throughput da linha. Para obter mais informações sobre carimbos de data/hora do lado do cliente, consulte. [Carimbos de data/hora do lado do cliente no Amazon Keyspaces](client-side-timestamps.md)
+ **Time to Live (TTL)** — Os metadados TTL ocupam aproximadamente 8 bytes por linha quando o recurso é ativado. Além disso, os metadados TTL são armazenados para cada coluna de cada linha. Os metadados TTL ocupam aproximadamente 8 bytes para cada coluna que armazena um tipo de dados escalar ou uma coleção congelada. Se a coluna armazenar um tipo de dados de coleta que não esteja congelado, para cada elemento da coleção, o TTL exigirá aproximadamente 8 bytes adicionais para metadados. Para uma coluna que armazena um tipo de dados de coleta quando o TTL está ativado, você pode usar a fórmula a seguir.
```
total encoded size of column = (column id) + sum (nested elements + collection metadata (1 byte) + TTL metadata (8 bytes)) + collection column metadata (3 bytes)
```
Os metadados TTL contribuem para o custo de armazenamento e taxa de transferência da linha. Para mais informações sobre TTL, consulte [Dados expirados com vida útil (TTL) para Amazon Keyspaces (para Apache Cassandra)](TTL.md).
## Escolha a fórmula certa para calcular o tamanho codificado de uma linha
Esta seção mostra as diferentes fórmulas que você pode usar para estimar os requisitos de armazenamento ou capacidade de transferência para uma linha de dados no Amazon Keyspaces.
O tamanho total codificado de uma linha de dados pode ser estimado com base em uma das seguintes fórmulas, com base em sua meta:
+ **Capacidade de processamento** — Para estimar o tamanho codificado de uma linha para avaliar as unidades de read/write solicitação necessárias ()RRUs/WRUs) or read/write capacity units (RCUs/WCUs:
```
total encoded size of row = partition key columns + clustering columns + regular columns
```
+ **Tamanho do armazenamento** — Para estimar o tamanho codificado de uma linha para prever a`BillableTableSizeInBytes`, adicione os metadados necessários para o armazenamento da linha:
```
total encoded size of row = partition key columns + clustering columns + regular columns + row metadata (100 bytes)
```
**Importante**
Todos os metadados da coluna, por exemplo, ids de coluna, metadados de chave de partição, metadados de colunas de agrupamento, bem como carimbos de data/hora do lado do cliente, TTL e metadados de linha, contam para o tamanho máximo de linha de 1 MB.
## Exemplo de cálculo do tamanho da linha
Considere o exemplo a seguir de uma tabela em que todas as colunas são do tipo inteiro. A tabela tem duas colunas de chave de partição, duas colunas de clustering e uma coluna regular. Como essa tabela tem cinco colunas, o espaço necessário para o identificador do nome da coluna é de 1 byte.
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
Neste exemplo, calculamos o tamanho dos dados quando escrevemos uma linha na tabela, conforme mostrado na instrução a seguir:
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1) values(1,2,3,4,5);
```
Para estimar o total de bytes exigidos por essa operação de gravação, você pode usar as etapas a seguir.
1. Calcule o tamanho de uma coluna de chave de partição adicionando os bytes do tipo de dados armazenado na coluna e os bytes de metadados. Repita isso para todas as colunas da chave de partição.
1. Calcule o tamanho da primeira coluna da chave de partição (pk\$1col1):
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. Calcule o tamanho da segunda coluna da chave de partição (pk\$1col2):
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. Adicione as duas colunas para obter o tamanho total estimado das colunas da chave de partição:
```
8 bytes + 8 bytes = 16 bytes for the partition key columns
```
1. Calcule o tamanho de uma coluna de clustering adicionando os bytes do tipo de dados armazenado na coluna e os bytes de metadados. Repita isso para todas as colunas de clustering.
1. Calcule o tamanho da primeira coluna de clustering (ck\$1col1):
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. Calcule o tamanho da segunda coluna de clustering (ck\$1col2):
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. Adicione as duas colunas para obter o tamanho total estimado das colunas de clustering:
```
6 bytes + 6 bytes = 12 bytes for the clustering columns
```
1. Adicione o tamanho das colunas regulares. Neste exemplo, temos apenas uma coluna que armazena um número inteiro de um único dígito, o que requer 2 bytes com 1 byte para o id da coluna.
1. Por fim, para obter o tamanho total da linha codificada, some os bytes de todas as colunas. Para estimar o tamanho faturável do armazenamento, adicione os 100 bytes adicionais para os metadados da linha:
```
16 bytes for the partition key columns + 12 bytes for clustering columns + 3 bytes for the regular column + 100 bytes for row metadata = 131 bytes.
```
Para saber como monitorar recursos sem servidor com a Amazon CloudWatch, consulte. [Monitorando o Amazon Keyspaces com a Amazon CloudWatch](monitoring-cloudwatch.md)