DynamoDB Espressioni di proiezione

Una espressione di proiezione è SELECT col1, col2 di DynamoDB: a elenco separato da virgole diattributonomi che indicano GetItem, Query o Scan per restituire solo quegli attributi anziché l'intero articolo.

Le espressioni di proiezione DynamoDB riducono i costi di lettura?

No. Un ProjectionExpression riduce il payload della risposta, non la capacità di lettura che ti viene fatturata. DynamoDB legge l'intero articolo dal magazzino, misura ilRCUsulla sua dimensione su disco, quindi rilascia gli attributi che non hai nominato all'uscita. Per ridurre effettivamente i costi di lettura, utilizzare una coperturaGSIInvece.

• Riduce il carico utile, non il costo di lettura. DynamoDB legge (e fattura) il articolo completo dallo spazio di archiviazione, quindi elimina gli attributi che non hai nominato lungo il percorso fuori. ProjectionExpression è un'ottimizzazione della rete, non della capacità.
• È il modo in cui recuperi un sottoinsieme pubblico. Nomina i pochi attributi di un chiamante permesso di vedere; il resto non si alza mai dal tabella.
• Utilizza i segnaposto #name per tutto ciò che potrebbe essere riservato. Semplice i nomi degli attributi nell'espressione entrano in conflitto con le ~570 parole riservate di DynamoDB e fallire la richiesta.
• Per un reale risparmio di lettura, utilizza invece un indice di copertura. AGSIche proietta solo le colonne necessarie vengono lette con la propria dimensione (più piccola).

Cosa salva effettivamente

Provenendo da SQL, presumi che SELECT a, b scansiona meno di SELECT *. Dentro DynamoDB quell'intuizione è sbagliata. Il unità di capacità per una lettura viene calcolata da la dimensione dell'elemento su disco, arrotondata ai successivi 4 KB, prima del viene applicata la proiezione AWS è esplicito: un ProjectionExpression non cambia la capacità di lettura consumata da una richiesta.¹

Quindi una proiezione ti fa risparmiare due cose, entrambe reali ma entrambe a valle della lettura:

• Byte in rete. Un elemento da 6 KB restituito come due piccoli attributi è minuscolo risposta. Su un Query che restituisce centinaia di elementi, i risultati si sommano rapidamente.
• Lavoro lato client. Meno cose da deserializzare, meno da conservare in memoria, meno perdite in un log o in una risposta API per sbaglio.

Ciò che non salva è il RCU. Questa è la pistola: la gente prende una pistola proiezione di tagliare il conto, non vedere alcun cambiamento e concludere che DynamoDB è rotto. Esso non lo è: hai misurato la leva sbagliata.

Proietta un profilo utente pubblico

Supponiamo che tu gestisca una directory utente. Ogni profilo è un elemento, codificato in modo da poter recuperare un file persona per handle:

PK = "PROFILE#ada"      (partition key)
SK = "PROFILE#ada"      (sort key — single-item collection)

L'oggetto è grasso. Porta il volto pubblico del conto più una pila di attributi privati e operativi:

{
  "PK": "PROFILE#ada",
  "SK": "PROFILE#ada",
  "displayName": "Ada L.",
  "avatarUrl": "https://cdn.example.com/u/ada.png",
  "bio": "Builds things.",
  "emailAddress": "ada@example.com",
  "passwordResetToken": "…",
  "billingCustomerId": "cus_…",
  "lastLoginIp": "…",
  "internalRiskScore": 0.02
}

Una scheda del profilo pubblico richiede tre campi. Recuperare l'intero articolo significa "emailAddress", "lastLoginIp" e "internalRiskScore" viaggiano in un contesto che non dovresti mai vederli. Nomina solo il sottoinsieme pubblico:

GetItem  PK = "PROFILE#ada"  SK = "PROFILE#ada"
ProjectionExpression: displayName, avatarUrl, bio

La risposta ha tre attributi. Quelli privati restano alla tabella, no filtrato dalla tua app dopo l'arrivo, ma mai serializzato nella risposta affatto. Questa è la vittoria in termini di sicurezza, ed è quella difficile da annullare una volta alla volta il segreto ha già varcato un confine.

Puoi assemblare e copiare esattamente questa richiesta: nomi, segnaposto e SDK chiamare - nel DynamoDB Expression Builder, che emette la mappa ProjectionExpression e ExpressionAttributeNames per te.

Aggiungi o rimuovi campi nella preimpostazione di seguito per guardare ProjectionExpression change - ritornano solo gli attributi elencati:

new QueryCommand({
  "TableName": "AuditLog",
  "KeyConditionExpression": "#hashKey = :hashKeyValue AND begins_with(#rangeKey, :rangeKeyValue)",
  "ProjectionExpression": "#proj0, #proj1, #proj2",
  "ExpressionAttributeNames": {
    "#hashKey": "pk",
    "#rangeKey": "sk",
    "#proj0": "action",
    "#proj1": "actor",
    "#proj2": "createdAt"
  },
  "ExpressionAttributeValues": {
    ":hashKeyValue": {
      "S": "TENANT#acme"
    },
    ":rangeKeyValue": {
      "S": "EVENT#"
    }
  }
})

Evita le parole riservate con i segnaposto #

Una proiezione pulita esplode sulle parole riservate. DynamoDB riserva un lungo elenco di parole: name, status, comment, size, timestamp e centinaia di altre.² Se un attributo che stai proiettando è uno di questi, il nome non elaborato nell'espressione viene rifiutato.

Supponiamo che il profilo abbia anche un attributo status ("attivo", "sospeso"`). Questo fallisce:

ProjectionExpression   displayName, status

lo "stato" è riservato. La correzione è un nome di attributo di espressione, un prefisso # segnaposto mappato al nome reale:

ProjectionExpression       displayName, #s
ExpressionAttributeNames   { "#s": "status" }

Lo stesso meccanismo si estende agli attributi nidificati. Per estrarre un singolo campo da una mappa o un elemento di un elenco, utilizza la sintassi del percorso del documento e il segnaposto ogni segmento, poiché ognuno di essi potrebbe essere riservato:

ProjectionExpression       #addr.#city, tags[0]
ExpressionAttributeNames   { "#addr": "address", "#city": "city" }

Una regola pratica: segnaposto tutto. Non devi mai ricordare quale dei ~570 parole riservate su cui ti trovi e anche l'espressione si legge allo stesso modo modo. E se preferisci sapere quali nomi sono effettivamente il problema, incollali nel controllo parole riservate — segnala le collisioni ed emette la mappa alias ExpressionAttributeNames.

Quando un indice di copertura batte una proiezione

Se hai davvero bisogno di ridurre i costi di lettura, non solo il carico utile, la leva è a Indice secondario globale che proietta solo gli attributi che leggi. A GSI è a copia separata dei dati; scegli KEYS_ONLY, INCLUDE o ALL per proiezione.³ Un indice KEYS_ONLY o stretto INCLUDE è fisicamente più piccolo per articolo, quindi un Query contro di esso viene misurato a quella dimensione più piccola.

Questo è un indice di copertura: alla domanda viene data risposta interamente dall'indice, no viaggio di nuovo alla tabella base. Usalo quando un modello di lettura a caldo ne richiede solo pochi attributi da elementi di grandi dimensioni.

L'indice costa spazio di archiviazione e capacità di scrittura da salvare capacità di lettura. Ne vale la pena per una lettura frequente di una fetta sottile di un oggetto pesante; non vale la pena perdere un GetItem una tantum. Vedi GSI vs LSI per scegliere il tipo di indice e quando una lettura GSI può essere obsoleta prima ne metti uno sul sentiero caldo.

Insidie e passaggi successivi

• Non aspettarti una fattura più piccola. Una proiezione da sola non cambia mai RCU. Se il il numero non si è spostato, questo è il comportamento documentato, non un bug.
• Parole riservate segnaposto. Un semplice nome o stato nell'espressione fallisce la richiesta — #-mappala.
• Includi sempre gli attributi chiave: aggiungono un carico utile trascurabile e consentono pagine o recuperi l'elemento.
• Raggiungi un indice di copertura solo quando un modello attivo legge alcuni campi da oggetti di grandi dimensioni; valutare prima il costo di scrittura/archiviazione.

Costruisci ProjectionExpression e la tua mappa dei nomi degli attributi nel file Expression Builder e prova DynoTable per eseguire queste proiezioni rispetto ai tuoi tabelle e guarda la risposta ridursi.

1. AWS DynamoDB Guida per gli sviluppatori, Utilizzo delle espressioni di proiezione in DynamoDB: la capacità di lettura si basa sulla dimensione dell'elemento prima che venga applicato qualsiasi ProjectionExpression. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ProjectionExpressions.html ↩
2. Guida per sviluppatori AWS DynamoDB, Parole riservate in DynamoDB. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ReservedWords.html ↩
3. Guida per sviluppatori AWS DynamoDB, Proiezioni degli attributi (KEYS_ONLY / INCLUDE / ALL). https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html ↩