Como funcionam as chaves de partição DynamoDB
Seu é um endereço. DynamoDB faz hash dessa chave e o hash decide qual máquina física armazena o item. Escolha bem a chave e spreads de carga; escolha mal e um servidor aguenta a pressão.
Como funcionam as chaves de partição DynamoDB?
O DynamoDB executa seu por meio de uma função hash interna, e esse hash decide qual partição física armazena o item. O hash decide o posicionamento; a chave não é classificada ou indexada como uma coluna SQL. Escolha uma chave de alta cardinalidade e carregue spreads em muitas partições; escolha uma de baixa cardinalidade e uma única partição receberá todo o calor.
- A chave é hash, não classificada. DynamoDB executa sua chave de partição por meio de um hash interno para escolher uma partição. Dois valores adjacentes não chegam nem perto um do outro outro no disco.
- Uma partição é uma unidade de armazenamento real. Cada uma tem cerca de 10 GB, 3.000 unidades de leitura/sec e 1.000 unidades de gravação/sec. Seu tráfego é dividido por quantos particiona suas chaves espalhadas.
- As teclas de atalho são a arma de fogo. Funil a maioria das solicitações em um valor de chave de partição e você acelera nessa partição enquanto o resto da tabela fica ocioso.
- Chaves de alta cardinalidade vencem. Os valores-chave mais distintos e atingidos de maneira uniforme você tem, mais partições absorvem a carga.
Comece com o que a chave realmente faz
Vindo do SQL, uma chave primária é uma coluna classificada e indexada que você JOIN e ORDER POR ativado. No DynamoDB a chave de partição (às vezes chamada de chave hash)
algo diferente: decide colocação.
DynamoDB alimenta a chave de partição em uma função hash interna. Os mapas de saída para um keyspace, e o keyspace é dividido em intervalos - cada intervalo pertencente a um partição física. Essa partição é um armazenamento real em um nó real.
Portanto, a chave de partição responde a uma pergunta: qual máquina contém este item? , se você tiver uma, somente encomenda itens dentro dessa máquina. Ele joga nenhuma parte na colocação.
Siga uma escrita através do hash
Digamos que você execute um SaaS que ingere leituras de dispositivos. Sua mesa SensorReadings usa
uma chave de partição deviceId e uma chave de classificação readingTs. Você escreve uma leitura para
deviceId = "vac-7741".
Caminho que a gravação percorre - da sua chave até o disco em que ela chega:
A gravação para vac-7741 é hash até um ponto no keyspace, esse ponto cai em
Alcance do P2, e o item chega ao P2 – encomendado lá pelo readingTs.
O que deve ser internalizado: "vac-7741" e "vac-7742" são um personagem à parte,
mas seus hashes não estão relacionados. É quase certo que eles vivam em locais diferentes
partições. Não há "próximo" no keyspace da partição.
Esta é a ideia de hashing consistente que o DynamoDB herdou do design original – o artigo do Amazon Dynamo de 2007 ("Dynamo: Amazon's Highly Available Key-value Store") espalham chaves entre nós fazendo hash exatamente para que nenhum nó se torne um gargalo.
Cole uma lista de valores de chave de partição abaixo para ver como um hash os espalha baldes. Um conjunto de alta cardinalidade se espalha uniformemente; reutilizar um valor e tudo se acumula em um único balde - o sobre o qual trata a próxima seção.
Este é um hash de ensino para intuição, não o verdadeiro hash interno do DynamoDB - o a função real, o keyspace e os limites da partição são internos do AWS. Use-o para criar uma noção de propagação versus inclinação, não para prever qual partição física é uma chave pousa.
Respeite os limites rígidos da partição
Uma partição física é finita. De acordo com o Guia do desenvolvedor AWS DynamoDB, cada um aguenta cerca de:
| Limite | Por partição |
|---|---|
| Armazenamento | ~10 GB |
| Taxa de transferência de leitura | 3.000 unidades de leitura/s |
| Taxa de transferência de gravação | 1.000 unidades de gravação/s |
Quando uma partição ultrapassa os 10 GB ou a taxa de transferência provisionada precisa de mais espaço, DynamoDB divide – o intervalo do keyspace é dividido e os itens são redistribuídos em mais partições. Isso é automático; você não o aciona.
Uma divisão pode esculpir a coleção de itens de uma chave de partição em uma chave de classificação limite, para que a carga de uma chave ocupada possa se espalhar por mais partições. Que divisão não posso resgatar é um único item ativo, uma chave de classificação cada vez maior ou uma tabela com um LSI – fixa a coleção em uma partição.
Nomeie a armadilha: a partição quente
Uma partição quente é a arma clássica. Acontece quando uma chave de partição valor (ou um pequeno conjunto deles) absorve uma parcela desproporcional do tráfego.
Falha concreta: você muda SensorReadings para uma chave de partição region com
valores como "us-east", "eu-west". Três regiões significam três valores-chave significam -
no máximo – três partições fazendo trabalho real. Slam "us-east" com leituras e isso
limita em 3.000 RCU enquanto a capacidade total provisionada da tabela permanece sem uso.
A capacidade adaptativa do DynamoDB suaviza isso – ele pode alterar a taxa de transferência não utilizada em direção a uma partição ocupada e isolar uma única tecla muito quente em sua própria partição. AWS detalhou isso no re:Invent "Advanced Design Patterns for Sessões de aprofundamento do DynamoDB". Mas a capacidade adaptativa ganha tempo, não imunidade: uma único item ativo, uma chave de classificação cada vez maior ou um LSI ainda limita uma chave por vez partição única. Design para propagação; não se apoie na rede de segurança.
Escolha uma chave de alta cardinalidade
A solução é cardinalidade — o número de valores-chave distintos e quão uniformemente o tráfego os atinge.
- Baixa cardinalidade (
region,status,true/false): poucas partições, o tráfego se concentra, você acelera cedo. - Alta cardinalidade (
deviceId,userId, um ID de pedido): hash de muitos valores em muitas partições, a carga se espalha e o espaço aumenta.
Vindo do SQL, você indexaria uma coluna status e a filtraria. Como um
Chave de partição DynamoDB ** que é uma armadilha - ela não pode se espalhar. Mantenha baixa cardinalidade
atributos como filtros ou como chave de classificação de índice secundário,
nunca como aquilo que decide a colocação.
Quando uma chave naturalmente boa ainda distorce – um punhado de inquilinos de baleias ultrapassando a
rest — adicione um sufixo para espalhar um valor lógico em N partições, por exemplo.
tenantId#3 para um caminho de gravação fragmentado. Você reagrega na leitura.
Para direcionar itens dentro de uma partição depois que sua chave for espalhada, você escreverá um
KeyConditionExpression na chave de classificação. Você pode montar um contra o seu
esquema no construtor de expressão DynamoDB
antes de conectá-lo ao código:
deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"Isso lê a janela de junho de um dispositivo a partir de uma única partição – um Query, não um
Varredura. A chave de partição fixa a máquina; a chave de classificação
condição restringe as linhas.
Armadilhas e próximos passos
- Não escolha uma chave pelo que lê bem no SQL. Escolha pelo que se espalha. Cardinalidade primeiro, consulta conveniência depois.
- Não presuma que a capacidade total da tabela é sua por chave. A taxa de transferência é por partição; um valor quente pode ser acelerado enquanto a tabela parece ociosa.
- Não lute contra uma divisão. É automático e baseado em hash - seu trabalho é fornecer chaves distintas suficientes para se espalhar.
Depois que sua chave for espalhada de forma limpa, as próximas decisões serão como organizar os itens dentro uma partição - consulte design de tabela única - e quando um índice secundário é a ferramenta certa para um segundo acesso padrão.
Baixe DynoTable e execute um GROUP BY sobre sua chave de partição no
SQL Workbench para ver quais chaves acumulam itens antes que uma delas se transforme em uma partição ativa.