DynamoDB Projeções de índice

Quando você cria um índice secundário, DynamoDB não copia automaticamente o item inteiro nisso. Você escolhe o que será copiado — a projeção do índice. Escolha muito pouco e suas consultas pagam uma segunda leitura para buscar o resto; escolha tudo e você paga extra armazenamento e custo de gravação em cada atualização. É uma compensação que você define uma vez na criação do índice e conviver com.

(Não confunda isso com uma expressão de projeção, que corta os atributos a retornos de leitura única. Esta página é sobre o que um índice armazena fisicamente — consulte expressões de projeção para o outro.)

O que é uma projeção de índice DynamoDB?

Uma projeção é o conjunto de atributos DynamoDB copiados da tabela base para um índice secundário. Você escolhe um dos três tipos: KEYS_ONLY (apenas as chaves), INCLUDE (chaves mais uma lista nomeada de atributos) ou ALL (o item inteiro). Mais projeção significa menos buscas na tabela base, mas maior custo de armazenamento e gravação.

• Uma projeção é o conjunto de atributos copiados em um índice secundário.
• KEYS_ONLY — apenas as chaves da tabela e do índice. Menor, mais barato.
• INCLUDE — as chaves mais uma lista nomeada de atributos extras que você escolhe.
• ALL — todos os atributos do item. Maior; consultas nunca precisam da tabela base.
• Um atributo que não é projetado simplesmente não está disponível em um GSI — seu aplicativo deve emitir suas próprias leituras de tabela base. (Apenas um LSI busca atributos não projetados para você, com custo extra de leitura.)
• Mais projeção = mais armazenamento + mais custo de gravação, já que cada gravação na tabela base propaga para o índice.

O problema: o índice que faz você ler duas vezes

Digamos que você administre uma central de suporte com um GSI que permite listar tickets abertos por prioridade. Você projeta KEYS_ONLY para mantê-lo enxuto. A consulta retorna rapidamente — mas só fornece IDs de tickets e sua tela de fila precisa do assunto, responsável e idade de cada ticket.

Então agora seu código faz uma segunda rodada de leituras na tabela base para hidratar cada resultado. A "única consulta" que você projetou é na verdade uma consulta mais N obtém, e o a latência e o custo que você estava tentando economizar voltaram imediatamente. A projeção era muito fina para o padrão de acesso.

O que cada tipo de projeção copia

• KEYS_ONLY armazena apenas a chave da tabela base e a chave do índice. Use-o quando o a consulta só precisa saber quais itens correspondem e você buscará detalhes em outro lugar - ou de jeito nenhum.
• INCLUDE armazena as chaves mais uma lista fixa de atributos que você nomeia. O doce spot: projete exatamente os campos que sua consulta precisa renderizar e nada mais.
• ALL copia o item inteiro. As consultas são totalmente autoatendidas a partir do índice, em o custo de duplicar o armazenamento de todo o item e a taxa de transferência de gravação nele.

Para a fila do suporte técnico, INCLUDE com subject, assignee e age é o chamada certa - a fila é renderizada apenas a partir do índice, sem segunda busca e sem duplicando o grande corpo do ticket no índice.

O custo que você está negociando

Cada atributo que você projeta é armazenado pela segunda vez e reescrito no índice sempre que o item base muda. Então, um generoso ALL a projeção em uma tabela atualizada com frequência multiplica a capacidade de armazenamento e gravação. Projete o que a consulta lê, não "tudo, só para garantir".

Uma sutileza que vale a pena conhecer: com um índice esparso, a projeção ainda mantém apenas o itens que carregam a chave de índice - então INCLUDE/ALL em um índice esparso permanece pequeno porque o próprio índice é pequeno. Pese o armazenamento e escreva o multiplicador para sua projeção com o DynamoDB calculadora de preços e monte o o índice consulta a si mesmo com o DynamoDB construtor de expressão.

Vendo uma projeção em DynoTable

DynoTable lista cada um dos índices secundários de uma tabela e permite consultar diretamente um. Execute o mesmo padrão de acesso na tabela base e em GSI e compare os resultados — os atributos que faltam no resultado do índice são exatamente aqueles não projeta, então o efeito de uma projeção é visível sem reler a tabela definição.

Armadilhas + próximos passos

• Um atributo não projetado em um GSI significa uma busca na tabela base — projete o projeção em torno do que a consulta renderiza.
• ALL raramente é gratuito — duplica o armazenamento e o custo de gravação; padrão para INCLUDE a menos que o índice realmente precise de todos os campos.
• As projeções são em sua maioria fixas. Você não pode editar livremente a projeção de um GSI posteriormente sem recriar o índice – escolha deliberadamente antecipadamente.
• Relacionado: GSI vs LSI e índices esparsos determinam quanto uma projeção na verdade armazena.

Quer ver o que cada um dos seus índices realmente retorna antes de redesenhá-los? Baixe DynoTable e consulte suas tabelas diretamente.

Custo de hidratação: KEYS_ONLY + N recebe

Retorne ao exemplo da fila do suporte técnico: 50 tickets abertos exibidos com sujeito, responsável e idade.

Os números exatos dependem dos tamanhos dos atributos projetados — cole um ticket de amostra em a calculadora de tamanho de item e multiplique pela profundidade da fila. INCLUDE que lista apenas os campos da UI geralmente supera ALL quando o O atributo body é grande e raramente mostrado na visualização de lista.

LSI comportamento de busca de projeção

Somente LSIs pode opcionalmente buscar atributos não projetados da tabela base durante uma consulta (com custo adicional de leitura). GSIs nunca fazem isso — faltando atributos exigem que seu aplicativo chame GetItem na tabela base. Isso a diferença empurra muitos designs GSI para projeções INCLUDE um pouco mais amplas na frente.

Alterando as projeções posteriormente

As projeções GSI são fixadas no momento da criação. Ampliando KEYS_ONLY para INCLUDE requer a criação de um novo índice, preenchimento, corte de tráfego e exclusão o índice antigo - planeje os campos antes do lançamento. LSIs compartilham a mesma limitação.

Ao avaliar um novo padrão de acesso, consulte o índice candidato em DynoTable e lista quais atributos aparecem - as lacunas são mapeadas 1:1 para entradas de projeção ausentes.

Parear com índices esparsos

Um GSI esparso que indexa apenas tickets status = open armazena projeções para somente linhas abertas. INCLUDE nesse índice permanece barato mesmo quando a tabela base contém milhões de tickets fechados — o índice nunca os copiou.

Combine com padrões de índice esparso quando o o subconjunto filtrado é pequeno em relação à tabela.

Construa o padrão de acesso primeiro

Use o query builder para criar o protótipo do GSI consulta – condição chave, expressão de projeção e filtro – antes de alterar Formação em nuvem. Troque os tipos de projeção na discussão do projeto perguntando quais colunas que a IU renderiza; todo o resto fica na mesa base.