Projetar chaves de partição para distribuir a workload

A parte de chave de partição da chave primária de uma tabela determina as partições lógicas em que os dados de uma tabela são armazenados. Isso afeta, por sua vez, as partições físicas subjacentes. Um design de chave de partição que não distribui as solicitações de E/S de maneira eficaz pode criar partições “dinâmicas” que resultam em controle de utilização e usam a capacidade provisionada de E/S de maneira ineficiente.

O uso ideal do throughput provisionado de uma tabela depende não apenas dos padrões da workload de itens individuais, mas também do design da chave de partições. Isso não significa que você deve acessar todos os valores de chaves de partição para atingir um nível eficiente de throughput ou que a porcentagem de valores de chaves de partição acessados deve ser alta. Isso significa que quanto mais diferentes forem os valores de chave de partição que sua workload acessa, mais essas solicitações serão espalhadas entre o espaço particionado. Em geral, você utilizará o throughput provisionado de modo mais eficiente à medida que a proporção entre os valores de chave de partição acessados e o número total de valores de chave de partição aumentar.

Veja a seguir uma comparação da eficiência do throughput provisionado de alguns esquemas comuns de chave de partição.

Valor da chave de partição	Uniformidade
ID de usuário, no qual o aplicativo tem muitos usuários.	Bom
Código de status, no qual existem apenas alguns códigos de status possíveis.	Ruim
Data de criação do item, arredondada para o período mais próximo (para, por exemplo, dia, hora ou minuto).	Ruim
ID do dispositivo, no qual cada dispositivo acessa dados em intervalos relativamente semelhantes.	Bom
ID do dispositivo, no qual, mesmo que haja muitos dispositivos rastreados, um deles é muito mais popular do que todos os outros.	Ruim

Se uma única tabela tiver apenas um número pequeno de valores de chaves de partição, considere distribuir suas operações de gravação entre valores de chaves de partição mais distintos. Em outras palavras, estruture os elementos de chave primária para evitar um valor chave de partição "quente" (intensamente solicitada) que diminua a performance geral.

Por exemplo, considere uma tabela com uma chave primária composta. A chave de partição representa a data de criação do item, arredondada para o próximo dia. A chave de classificação é um identificador de item. Em um determinado dia, digamos 2014-07-09, todos os novos itens são gravados naquele valor de chave de partição único (e na partição física correspondente).

Se a tabela se encaixar inteiramente em uma única partição (considerando o crescimento dos seus dados ao longo do tempo) e se os requisitos de throughput de leitura e gravação do seu aplicativo não excederem os recursos de leitura e gravação de uma única partição, seu aplicativo não deverá se deparar com limitações inesperadas resultantes do particionamento.

Para usar o NoSQL Workbench para DynamoDB a fim de ajudar a visualizar o design da chave de partição, consulte Criar modelos de dados com o NoSQL Workbench.