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á. # Configurar o modo de capacidade sob demanda O modo de capacidade *sob demanda* do Amazon Keyspaces (para Apache Cassandra) é uma opção de faturamento flexível capaz de servir centenas de solicitações por segundo sem planejamento de capacidade. Essa opção oferece pay-per-request preços para solicitações de leitura e gravação, de forma que você pague somente pelo que usar. Quando você seleciona o modo sob demanda, o Amazon Keyspaces pode escalar instantaneamente a capacidade de throughput de sua tabela para qualquer nível de tráfego previamente registrado e, em seguida, voltar para baixo quando o tráfego do aplicativo diminuir. Se o nível de tráfego de uma workload atingir um novo pico, o serviço se adapta rapidamente para aumentar a capacidade de throughput de sua tabela. Você pode ativar o modo de capacidade sob demanda para tabelas novas e existentes. Modo sob demanda é uma boa opção se qualquer uma das declarações a seguir for verdadeira: + Você cria novas tabelas com workloads desconhecidas. + Você tem tráfego de aplicativos imprevisível. + Você prefere a facilidade de pagar somente pelo que usar. Para começar com o modo sob demanda, você pode criar uma nova tabela ou atualizar uma tabela existente para usar o modo de capacidade sob demanda usando o console ou com algumas linhas do código Cassandra Query Language (CQL). Para obter mais informações, consulte [Tabelas](cql.ddl.table.md). **Topics** + [Unidades de solicitação de leitura e unidades de solicitação de gravação](#ReadWriteCapacityMode.requests) + [Tráfego de pico e propriedades de dimensionamento](#ReadWriteCapacityMode.PeakTraffic) + [Throughput inicial para modo de capacidade sob demanda](#ReadWriteCapacityMode.InitialThroughput) ## Unidades de solicitação de leitura e unidades de solicitação de gravação Com tabelas de modo de capacidade sob demanda, você não precisa especificar antecipadamente quanto de throughput de leitura e gravação espera que seu aplicativo use. O Amazon Keyspaces cobra pelas leituras e gravações que você executa em suas tabelas em termos de unidades de solicitação de leitura (RRUs) e unidades de solicitação de gravação (WRUs). + Um *RRU* representa uma solicitação de leitura `LOCAL_QUORUM` ou duas solicitações de leitura ` LOCAL_ONE` para uma linha com até 4 KB de tamanho. Se você precisar ler uma linha maior que 4 KB, a operação de leitura usará mais RRUs. O número total RRUs necessário depende do tamanho da linha e se você deseja usar `LOCAL_QUORUM` ou `LOCAL_ONE` ler a consistência. Por exemplo, a leitura de uma linha de 8 KB requer 2 RRUs usando a consistência de `LOCAL_QUORUM` leitura e 1 RRU se você escolher a consistência de `LOCAL_ONE` leitura. + Um *WRU* representa uma gravação para uma linha com até 1 KB de tamanho. Todas as gravações estão usando `LOCAL_QUORUM` consistência e não há cobrança adicional pelo uso de transações leves (LWTs). Se você precisar gravar uma linha maior que 1 KB, a operação de gravação usa mais WRUs. O número total WRUs necessário depende do tamanho da linha. Por exemplo, se o tamanho da linha for de 2 KB, você precisará de 2 WRUs para realizar uma solicitação de gravação. Para obter informações sobre os níveis de consistência suportados, consulte [Níveis de consistência de leitura e gravação do Apache Cassandra suportados e custos associados](consistency.md). ## Tráfego de pico e propriedades de dimensionamento As tabelas do Amazon Keyspaces que usam modo de capacidade sob demanda automaticamente adaptam-se ao volume de tráfego da sua aplicação. O modo de capacidade sob demanda acomoda instantaneamente até o dobro do pico de tráfego anterior em uma tabela. Por exemplo, o padrão de tráfego do seu aplicativo pode variar entre 5 mil e 10 mil leituras `LOCAL_QUORUM` por segundo, sendo 10 mil leituras por segundo o pico de tráfego anterior. Com esse padrão, o modo de capacidade sob demanda acomoda instantaneamente o tráfego sustentado de até 20 mil leituras por segundo. Se a sua aplicação sustentar o tráfego de 20 mil leituras por segundo, esse pico torna-se o novo pico anterior, habilitando o tráfego subsequente de até 40 mil leituras por segundo. Se você precisar de mais que o dobro do pico anterior em uma tabela, o Amazon Keyspaces alocará automaticamente mais capacidade à medida que o volume de tráfego aumentar. Isso ajuda a garantir que sua tabela tenha capacidade de throughput suficiente para processar as solicitações adicionais. No entanto, você pode observar erros de capacidade de throughput insuficientes se exceder o dobro do pico anterior em 30 minutos. Por exemplo, suponha que o padrão de tráfego do seu aplicativo varie entre 5 mil e 10 mil leituras altamente consistentes por segundo, onde 20 mil leituras por segundo é o pico de tráfego atingido anteriormente. Nesse caso, o serviço recomenda que você espace o crescimento do tráfego em pelo menos 30 minutos antes de gerar até 40 mil leituras por segundo. Para saber como estimar o consumo da capacidade de leitura e gravação de uma tabela, consulte [Estimar o consumo de capacidade do throughput de leitura e gravação no Amazon Keyspaces](capacity-examples.md). Para saber mais sobre as cotas padrão da sua conta e como aumentá-las, consulte [Cotas para Amazon Keyspaces (para Apache Cassandra)](quotas.md). ## Throughput inicial para modo de capacidade sob demanda Se você criar uma nova tabela com o modo de capacidade sob demanda habilitado ou alternar uma tabela existente para o modo de capacidade sob demanda pela primeira vez, a tabela terá as configurações de pico anteriores a seguir, mesmo que não tenha servido tráfego anteriormente usando o modo de capacidade sob demanda: + **Tabela recém-criada com modo de capacidade sob demanda:** o pico anterior era de 2.000 WRUs e RRUs 6.000. Você pode originar até o dobro do pico anterior imediatamente. Isso permite que tabelas sob demanda recém-criadas atendam até 4.000 WRUs e 12.000. RRUs + **Tabela existente alterada para o modo de capacidade sob demanda:** o pico anterior é metade do anterior WCUs e RCUs provisionado para a tabela ou para as configurações de uma tabela recém-criada com modo de capacidade sob demanda, o que for maior.