kvp in attributeList)
{
string attributeName = kvp.Key;
AttributeValue value = kvp.Value;
Console.WriteLine(
attributeName + " " +
(value.S == null ? "" : "S=[" + value.S + "]") +
(value.N == null ? "" : "N=[" + value.N + "]") +
(value.SS == null ? "" : "SS=[" + string.Join(",", value.SS.ToArray()) + "]") +
(value.NS == null ? "" : "NS=[" + string.Join(",", value.NS.ToArray()) + "]") +
(value.B == null ? "" : "B=[" + FromGzipMemoryStream(value.B) + "]")
);
}
Console.WriteLine("************************************************");
}
private static MemoryStream ToGzipMemoryStream(string value)
{
MemoryStream output = new MemoryStream();
using (GZipStream zipStream = new GZipStream(output, CompressionMode.Compress, true))
using (StreamWriter writer = new StreamWriter(zipStream))
{
writer.Write(value);
}
return output;
}
private static string FromGzipMemoryStream(MemoryStream stream)
{
using (GZipStream zipStream = new GZipStream(stream, CompressionMode.Decompress))
using (StreamReader reader = new StreamReader(zipStream))
{
return reader.ReadToEnd();
}
}
}
}
```
# Miglioramento dell’accesso ai dati con gli indici secondari in DynamoDB
Amazon DynamoDB offre l'accesso rapido agli elementi in una tabella specificando i valori della chiave primaria. Tuttavia, molte applicazioni potrebbero trarre vantaggio dalla presenza di una o più chiavi secondarie (o alternative) disponibili, per permettere un accesso ai dati efficiente con altri attributi rispetto alla chiave primaria. A tale scopo, puoi creare uno o più indici secondari in una tabella ed emettere delle richieste `Query` o `Scan` rispetto a tali indici.
Un *indice secondario* è una struttura di dati contente un sottoinsieme di attributi di una tabella, oltre a una chiave alternativa per il supporto delle operazioni `Query`. Puoi recuperare dati dall'indice tramite una `Query`, nello stesso modo in cui utilizzi `Query` con una tabella. Una tabella può presentare più indici secondari, che consentono alle applicazioni di accedere a molti modelli di query diversi.
**Nota**
Puoi inoltre eseguire un'operazione `Scan` su un indice nello stesso modo in cui esegui eseguiresti una `Scan` su una tabella.
L’accesso multi-account per le operazioni di scansione degli indici secondari non è attualmente supportato dalle [policy basate su risorse](access-control-resource-based.md).
Ciascun indice secondario è associato esattamente a una tabella della quale ottiene i dati. Questa è denominata *tabella di base* dell'indice. Quando crei un indice, è necessario definire una chiave alternativa dell'indice (chiave di partizione e chiave di ordinamento). Vengono definiti anche gli attributi che si desidera siano *proiettati*, o copiati, dalla tabella di base nell'indice. DynamoDB copia questi attributi dell'indice insieme agli attributi della chiave primaria dalla tabella di base. Puoi scansionare o eseguire una query sull'indice nello stesso modo in cui lo faresti su una tabella.
Ciascun indice secondario viene gestito automaticamente da DynamoDB. Quando aggiungi, modifichi o elimini item nella tabella di base, verranno aggiornati tutti gli indici della tabella sulla base di tali modifiche.
DynamoDB supporta due tipi di indici secondari:
+ **[Indice secondario globale](GSI.html)**: un indice con una chiave di partizione e una chiave di ordinamento che possono essere differenti da quelle presenti sulla tabella di base. Un indice secondario viene considerato globale perché le query possono riferirsi a tutti i dati di una tabella di base, in tutte le partizioni. Un indice secondario locale è memorizzato nel suo spazio di partizione lontano dalla tabella di base e viene dimensionato separatamente dalla tabella di base.
+ **[Indice secondario locale](LSI.html):** un indice con la stessa chiave di partizione della tabella di base ma con una chiave di ordinamento diversa. Un indice secondario è locale nel senso che l'ambito di ogni partizione di un indice secondario locale è rappresentato da una partizione di tabella di base con lo stesso valore di chiave di partizione.
Per un confronto tra gli indici secondari globali e gli indici secondari locali, guarda questo video.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/BkEu7zBWge8)
**Topics**
+ [Utilizzo degli indici secondari globali in DynamoDB](GSI.md)
+ [Indici secondari locali](LSI.md)
Quando determini il tipo di indice da utilizzare, è consigliabile prendere in considerazione i requisiti della tua applicazione. Nella tabella riportata di seguito sono riportate le differenze principali tra un indice secondario globale e un indice secondario locale.
****
| Caratteristica | Indice secondario globale | Indice secondario locale |
| --- | --- | --- |
| Schema della chiave | La chiave primaria di un indice secondario globale può essere sia semplice (chiave di partizione) che composita (chiave di partizione e chiave di ordinamento). | La chiave primaria di un indice secondario locale deve essere composita (chiave di partizione e chiave di ordinamento). |
| Attributi della chiave | La chiave di partizione e la chiave di ordinamento (se presente) dell'indice possono essere costituite da qualsiasi attributo della tabella di base di tipo stringa, numero o binario. | La chiave di partizione dell'indice è lo stesso attributo della chiave di partizione della tabella di base. La chiave di partizione può essere qualsiasi attributo della tabella di base di tipo stringa, numero o binario. |
| Limitazioni della dimensione per valore di chiave di partizione | Non sono previste limitazioni sulle dimensioni per gli indici secondari globali. | Per ciascun valore della chiave di partizione, la dimensione totale tutti gli elementi indicizzati deve essere minore o uguale a 10 GB. |
| Operazioni di indici online | Gli indici secondari globali possono essere creati al momento della creazione di una tabella. È inoltre possibile aggiungere un nuovo indice secondario globale a una tabella esistente oppure eliminare un indice secondario globale esistente. Per ulteriori informazioni, consulta [Gestione degli indici secondari globali in DynamoDB](GSI.OnlineOps.md). | È possibile creare indici secondari locali al momento della creazione di una tabella. Non è possibile aggiungere un indice secondario locale a una tabella esistente né eliminare gli indici secondari locali presenti correntemente. |
| Query e partizioni | Un indice secondario globale consente di eseguire una query sull'intera tabella, su tutte le partizioni. | Un indice secondario locale consente di eseguire una query su una singola partizione, come specificato dal valore della chiave di partizione nella query. |
| Consistenza di lettura | Tuttavia, le query sugli indici secondari globali supportano solo la consistenza finale. | Quando si esegue una query su un indice secondario locale, è possibile scegliere tra consistenza finale o forte consistenza. |
| Utilizzo del throughput assegnato | Ciascun indice secondario globale ha le proprie impostazioni di velocità effettiva assegnata per l'attività di lettura e scrittura. Le query o le scansioni su un indice secondario globale utilizzano unità di capacità dall'indice, non della tabella di base. Lo stesso vale per gli aggiornamenti dell'indice secondario globale a causa delle scritture nella tabella. Un indice secondario globale associato a tabelle globali consuma unità di capacità di scrittura. | Le query o le scansioni su un indice secondario locale utilizzano unità di capacità di lettura della tabella di base. Quando si scrive su una tabella, vengono aggiornati anche i relativi indici secondari locali; tali aggiornamenti utilizzano unità di capacità di scrittura della tabella di base. Un indice secondario globale associato a tabelle globali consuma unità di capacità di scrittura replicate. |
| Attributi proiettati | Con le query o le scansioni dell'indice secondario globale, è possibile richiedere solo gli attributi proiettati nell'indice. DynamoDB non recupera alcun attributo dalla tabella. | Se si esegue una query o una scansione sull'indice secondario globale, è possibile richiedere gli attributi che non sono proiettati sull'indice. DynamoDB recupera automaticamente tali attributi dalla tabella. |
Se si intende creare una o più tabelle con gli indici secondari, è necessario farlo in sequenza. Ad esempio, sarebbe necessario creare la prima tabella e attendere che il relativo stato divenga `ACTIVE` per poter creare la tabella successiva, dunque attendere che il suo stato divenga `ACTIVE`e così via. Se si prova a creare più tabelle contemporaneamente con un indice secondario, DynamoDB restituisce una `LimitExceededException`.
Ogni indice secondario utilizza la stessa [classe di tabella](HowItWorks.TableClasses.html) e [modalità di capacità](capacity-mode.md) della tabella di base a cui è associato. Per ogni indice secondario, è necessario specificare quanto segue:
+ Tipo di indice da creare, ovvero un indice secondario globale o un indice secondario locale.
+ Un nome dell'indice. Le regole di denominazione per gli indici sono le stesse regole per le tabelle, come elencate in [Quote in Amazon DynamoDB](ServiceQuotas.md). Il nome deve essere univoco per la tabella di base a cui è associato, ma puoi utilizzare lo stesso nome per gli indici associati a tabelle di base diverse.
+ Lo schema delle chiavi dell'indice. Ciascun attributo dello schema della chiave di indicizzazione deve essere un attributo di tipo `String`, `Number` o `Binary`. Non sono consentiti altri tipi di dati, tra cui documenti e set. Altri requisiti della schema della chiave dipendono dal tipo di indice:
+ Per un indice secondario globale, la chiave di partizione può essere qualsiasi attributo scalare della tabella di base. È facoltativa una chiave di ordinamento, che può essere anch'essa qualsiasi attributo scalare della tabella di base.
+ Per un indice secondario locale, la chiave di partizione deve essere uguale alla chiave di partizione della tabella di base; la chiave di ordinamento deve essere un attributo non chiave della tabella di base.
+ Gli attributi aggiuntivi, se presenti, da proiettare dalla tabella di base nell'indice. Questi attributi si aggiungono agli attributi di chiave della tabella, proiettati automaticamente in ciascun indice. Puoi proiettare attributi di qualsiasi tipo di dati, tra cui scalari, documenti e set.
+ Le impostazioni di throughput assegnato dell'indice, se necessario:
+ Per un indice secondario globale, è necessario specificare le impostazioni delle unità di capacità di lettura e scrittura. Queste impostazioni di throughput assegnato sono indipendenti dalle impostazioni della tabella di base.
+ Per un indice secondario locale, non è necessario specificare le impostazioni delle unità di capacità di lettura e scrittura. Tutte le operazioni di lettura e scrittura su un indice secondario locale utilizzano le impostazioni di velocità effettiva assegnata della relativa tabella di base.
Per la massima flessibilità delle query, è possibile creare fino a 20 indici secondari globali (quota predefinita) e fino a 5 indici secondari locali per tabella.
Per ottenere un elenco dettagliato di indici secondari su una tabella, utilizza l'operazione `DescribeTable`. `DescribeTable` restituisce il nome, la dimensione dell'archiviazione e il numero di elementi per ogni indice secondario nella tabella. Questi valori non vengono aggiornati in tempo reale, bensì ogni circa sei ore.
È possibile accedere ai dati in un indice secondario utilizzando l'operazione `Query` o `Scan`. È necessario specificare il nome della tabella di base e il nome dell'indice che si desidera utilizzare, gli attributi da restituire nei risultati e qualsiasi espressione di condizione o filtro da applicare. DynamoDB può restituire i risultati in ordine crescente o decrescente.
Quando elimini una tabella, verranno eliminati anche tutti gli indici associati alla tabella.
Per le best practice, consulta [Best practice per l'uso di indici secondari in DynamoDB.](bp-indexes.md).
# Utilizzo degli indici secondari globali in DynamoDB
Alcune applicazioni devono poter eseguire molti tipi di query, usando un'ampia gamma di attributi diversi come criteri di query. Per supportare questi requisiti, è possibile creare uno o più *indici secondari globali* ed emettere richieste `Query` rispetto a questi indici in Amazon DynamoDB.
**Topics**
+ [Scenario: Utilizzo di un indice secondario globale](#GSI.scenario)
+ [Proiezioni di attributi](#GSI.Projections)
+ [Schema chiave con più attributi](#GSI.MultiAttributeKeys)
+ [Lettura di dati da un indice secondario globale](#GSI.Reading)
+ [Sincronizzazione dei dati tra tabelle e indici secondari globali](#GSI.Writes)
+ [Classi di tabella con indici secondari globali](#GSI.tableclasses)
+ [Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari globali](#GSI.ThroughputConsiderations)
+ [Considerazioni sullo storage per indici secondari globali](#GSI.StorageConsiderations)
+ [Modelli di progettazione](GSI.DesignPatterns.md)
+ [Gestione degli indici secondari globali in DynamoDB](GSI.OnlineOps.md)
+ [Rilevamento e correzione delle violazioni delle chiavi in DynamoDB](GSI.OnlineOps.ViolationDetection.md)
+ [Utilizzo di indici secondari globali: Java](GSIJavaDocumentAPI.md)
+ [Utilizzo di indici secondari globali: .NET](GSILowLevelDotNet.md)
+ [Utilizzo di indici secondari in DynamoDB con la AWS CLI](GCICli.md)
## Scenario: Utilizzo di un indice secondario globale
A titolo illustrativo, considera una tabella denominata `GameScores` che tiene traccia di utenti e punteggi per un'applicazione di gioco per dispositivi mobili. Ogni item in `GameScores` è identificato da una chiave di partizione (`UserId`) e una chiave di ordinamento (`GameTitle`). Il seguente diagramma mostra in che modo verrebbero organizzarti gli elementi nella tabella. Non tutti gli attributi vengono visualizzati.
![\[GameScores tabella contenente un elenco di ID utente, titolo, punteggio, data e vittorie/sconfitte.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/GSI_01.png)
Supponi ora di voler scrivere un'applicazione di tipo classifica per visualizzare i punteggi più alti per ogni gioco. Una query che specifica gli attributi chiave (`UserId` e `GameTitle`) sarebbe molto efficiente. Tuttavia, se l'applicazione deve recuperare i dati da `GameScores` solo in base a `GameTitle`, occorre utilizzare un'operazione `Scan`. Con l'aggiunta di altri item alla tabella, le scansioni di tutti i dati rallenterebbero e diventerebbero meno pratiche, rendendo difficile rispondere a domande come le seguenti:
+ Qual è il punteggio più alto mai registrato per il gioco Meteor Blasters?
+ Quale utente ha il punteggio più alto per Galaxy Invaders?
+ Qual è il rapporto più elevato tra vittorie e sconfitte?
Per accelerare le query su attributi non chiave, è possibile creare un indice secondario globale. Un indice secondario globale contiene una selezione di attributi dalla tabella di base organizzati tramite una chiave primaria diversa da quella della tabella. La chiave dell'indice non deve avere alcuno degli attributi di chiave della tabella, né lo stesso schema della chiave di una tabella.
Ad esempio, è possibile creare un indice secondario globale denominato `GameTitleIndex` con una chiave di partizione `GameTitle` e una chiave di ordinamento `TopScore`. Gli attributi della chiave primaria della tabella di base vengono sempre proiettati in un indice, pertanto è presente anche l'attributo `UserId`. Il diagramma seguente mostra l'aspetto di un indice `GameTitleIndex`.
![\[GameTitleIndex tabella contenente un elenco di titoli, punteggi e ID utente.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/GSI_02.png)
A questo punto, puoi eseguire una query su `GameTitleIndex` e ottenere facilmente i punteggi per Meteor Blasters. I risultati sono ordinati in base ai valori della chiave di ordinamento, ovvero `TopScore`. Se imposti il parametro `ScanIndexForward` su false, i risultati vengono restituiti in ordine decrescente e di conseguenza il punteggio più alto viene restituito per primo.
Ogni indice secondario globale deve avere una chiave di partizione e può avere anche una chiave di ordinamento facoltativa. Lo schema della chiave di indicizzazione può essere diverso dallo schema della tabella di base. È possibile avere una tabella con una chiave primaria semplice (chiave di partizione) e creare un indice secondario globale con una chiave primaria composita (chiave di partizione e chiave di ordinamento) o viceversa. Gli attributi della chiave dell'indice possono essere costituiti da qualsiasi attributo `String`, `Number` o `Binary` di primo livello della tabella di base. Altri tipi scalari, documento e set non sono consentiti.
Se vuoi, puoi proiettare altri attributi della tabella di base nell'indice. Quando si esegue una query sull'indice, DynamoDB può recuperare questi attributi proiettati in modo efficiente. Tuttavia, le query su un indice secondario globale non possono recuperare gli attributi dalla tabella di base. Ad esempio, se esegui una query `GameTitleIndex` come mostrato nel diagramma precedente, la query non è in grado di accedere ad alcun attributo non di chiave diverso da `TopScore` (se vengono automaticamente proiettati gli attributi della chiave `GameTitle` e `UserId`).
In una tabella DynamoDB ogni valore di chiave deve essere univoco. Tuttavia, i valori delle chiavi in un indice secondario globale non devono essere univoci. A titolo illustrativo, supponi che un gioco denominato Comet Quest sia particolarmente difficile, con molti nuovi utenti che provano ma non riescono a ottenere un punteggio maggiore di zero. Di seguito sono illustrati alcuni dati che possono rappresentare questa situazione.
****
| UserId | GameTitle | TopScore |
| --- | --- | --- |
| 123 | Comet Quest | 0 |
| 201 | Comet Quest | 0 |
| 301 | Comet Quest | 0 |
Quando questi dati vengono aggiunti alla tabella `GameScores`, vengono propagati da DynamoDB a `GameTitleIndex`. Se quindi eseguiamo una query sull'indice utilizzando Comet Quest per `GameTitle` e 0 per `TopScore`, vengono restituiti i dati seguenti.
![\[Tabella contenente un elenco di titoli, punteggi più alti e ID utente.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/GSI_05.png)
Nella risposta vengono visualizzati solo gli elementi con i valori di chiave specificati. All'interno di questo set di dati, gli elementi non hanno un ordine specifico.
Un indice secondario globale tiene traccia solo degli elementi di dati in cui esistono effettivamente i suoi attributi di chiave. Ad esempio, supponi di aver aggiunto un nuovo item alla tabella `GameScores`, ma di aver fornito solo gli attributi della chiave primaria obbligatori.
****
| UserId | GameTitle |
| --- | --- |
| 400 | Comet Quest |
Poiché non è stato specificato l'attributo `TopScore`, DynamoDB non propaga questo elemento a `GameTitleIndex`. Di conseguenza, se ha eseguito una query su `GameScores` per tutti gli elementi di Comet Quest, ottieni i quattro item seguenti:
![\[Tabella contenente un elenco di quattro titoli, punteggi più alti e ID utente.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/GSI_04.png)
Una query simile su `GameTitleIndex` continua a restituire tre item anziché quattro. Il motivo è che l'item con `TopScore` inesistente non viene propagato nell'indice.
![\[Tabella contenente un elenco di tre titoli, punteggi più alti e ID utente.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/GSI_05.png)
## Proiezioni di attributi
Una *proiezione* è l'insieme di attributi copiato da una tabella in un indice secondario. La chiave di partizione e la chiave di ordinamento della tabella vengono sempre proiettati nell'indice; è possibile proiettare altri attributi per supportare i requisiti di query dell'applicazione. Quando si esegue una query su un indice, Amazon DynamoDB può accedere a qualsiasi attributo nella proiezione come se tali attributi fossero in una propria tabella.
Quando si crea un indice secondario, è necessario specificare gli attributi che saranno proiettati nell'indice. DynamoDB fornisce tre diverse opzioni per questo:
+ *KEYS\$1ONLY*: ogni elemento dell'indice è costituito solo dalla chiave di partizione della tabella e dai valori della chiave di ordinamento, oltre ai valori della chiave di indice. L'opzione `KEYS_ONLY` si traduce nell'indice secondario più piccolo possibile.
+ *INCLUDE*: oltre agli attributi descritti in `KEYS_ONLY`, l'indice secondario includerà gli altri attributi non chiave che sono stati specificati.
+ *ALL*: l'indice secondario include tutti gli attributi della tabella di origine. Poiché tutti i dati della tabella sono duplicati nell'indice, una proiezione `ALL` restituisce il più grande indice secondario possibile.
Nel diagramma precedente, `GameTitleIndex` dispone di un solo attributo proiettato: `UserId`. Pertanto, sebbene un'applicazione possa determinare in maniera efficiente il valore `UserId` dei punteggi più alti per ogni partita utilizzando `GameTitle` e `TopScore` nelle query, non può determinare in maniera efficiente il rapporto più elevato tra vittorie e sconfitte per i punteggi più alti. A tale scopo, l'applicazione dovrebbe eseguire un'interrogazione aggiuntiva sulla tabella di base per recuperare le vittorie e le sconfitte di ciascuno dei migliori marcatori. Un modo più efficiente per supportare le query su questi dati consiste nel proiettare gli attributi dalla tabella di base nell'indice secondario globale, come mostrato in questo diagramma.
![\[Rappresentazione della proiezione di attributi non chiave in un GSI per supportare l’esecuzione di query efficienti.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/GSI_06.png)
Poiché gli attributi non di chiave `Wins` e `Losses` vengono proiettati nell'indice, un'applicazione può determinare il rapporto tra vittorie e sconfitte per qualsiasi gioco o per qualsiasi combinazione di gioco e ID utente.
Quando si scelgono gli attributi da proiettare in un indice secondario globale, è necessario considerare il compromesso tra i costi correlati alla velocità effettiva assegnata e i costi di archiviazione:
+ Se è necessario accedere a pochi attributi con la latenza più bassa possibile, considerare la possibilità di proiettare solo quegli attributi in un indice secondario globale. Più piccolo è l'indice, minore è il costo per memorizzarlo e minori sono i costi di scrittura.
+ Se l'applicazione accede frequentemente ad alcuni attributi non chiave, è necessario considerare di proiettare quegli attributi in un indice secondario globale. I costi di archiviazione aggiuntivi per l'indice secondario globale compensano il costo di esecuzione di scansioni frequenti delle tabelle.
+ Se è necessario accedere alla maggior parte degli attributi non chiave su base frequente, è possibile proiettare questi attributi, o anche l'intera tabella di base, in un indice secondario globale. Questo offre massima flessibilità. Tuttavia, i costi di storage aumenteranno o addirittura raddoppieranno.
+ Se l'applicazione esegue di rado le query sulla tabella, ma esegue molte scritture o aggiornamenti dei dati nella tabella, considera di proiettare `KEYS_ONLY`. L'indice secondario globale avrebbe dimensioni minime e sarebbe comunque disponibile se necessario per l'attività di query.
## Schema chiave con più attributi
Gli indici secondari globali supportano chiavi con più attributi, che consentono di comporre chiavi di partizione e ordinare le chiavi a partire da più attributi. Con le chiavi multiattributo, è possibile creare una chiave di partizione da un massimo di quattro attributi e una chiave di ordinamento da un massimo di quattro attributi, per un totale di un massimo di otto attributi per schema di chiavi.
Le chiavi multiattributo semplificano il modello di dati eliminando la necessità di concatenare manualmente gli attributi in chiavi sintetiche. Invece di creare stringhe composite, ad esempio`TOURNAMENT#WINTER2024#REGION#NA-EAST`, puoi utilizzare direttamente gli attributi naturali del tuo modello di dominio. DynamoDB gestisce automaticamente la logica delle chiavi composite, eseguendo l'hashing di più attributi chiave di partizione per la distribuzione dei dati e mantenendo l'ordinamento gerarchico tra più attributi delle chiavi di ordinamento.
Ad esempio, prendi in considerazione un sistema di tornei di gioco in cui desideri organizzare le partite per torneo e regione. Con le chiavi multiattributo, è possibile definire la chiave di partizione come due attributi separati: `tournamentId` e. `region` Allo stesso modo, è possibile definire la chiave di ordinamento utilizzando più attributi come `round``bracket`, e `matchId` creare una gerarchia naturale. Questo approccio mantiene i dati digitati e il codice pulito, senza manipolazione o analisi delle stringhe.
Quando si esegue una query su un indice secondario globale con chiavi multiattributo, è necessario specificare tutti gli attributi delle chiavi di partizione utilizzando condizioni di uguaglianza. Per gli attributi chiave di ordinamento, è possibile interrogarli left-to-right nell'ordine in cui sono definiti nello schema chiave. Ciò significa che è possibile interrogare solo il primo attributo chiave di ordinamento, i primi due attributi insieme o tutti gli attributi insieme, ma non è possibile saltare gli attributi intermedi. Condizioni di disuguaglianza come`>`, `<``BETWEEN`, o `begins_with()` devono essere l'ultima condizione della query.
Le chiavi con più attributi funzionano particolarmente bene quando si creano indici secondari globali su tabelle esistenti. È possibile utilizzare gli attributi già presenti nella tabella senza inserire le chiavi sintetiche tra i dati. Ciò semplifica l'aggiunta di nuovi modelli di query all'applicazione creando indici che riorganizzano i dati utilizzando diverse combinazioni di attributi.
Ogni attributo in una chiave con più attributi può avere il proprio tipo di dati: `String` (S), (N) o `Number` (B). `Binary` Quando scegliete i tipi di dati, tenete presente che `Number` gli attributi vengono ordinati numericamente senza richiedere il riempimento zero, mentre gli attributi vengono ordinati lessicograficamente. `String` Ad esempio, se utilizzi un `Number` tipo per un attributo score, i valori 5, 50, 500 e 1000 vengono ordinati in ordine numerico naturale. Gli stessi valori `String` di type verrebbero ordinati come «1000", «5", «50", «500" a meno che non vengano riempiti con zeri iniziali.
Quando progettate chiavi con più attributi, ordinate gli attributi dal più generale al più specifico. Per le chiavi di partizione, combinate gli attributi che vengono sempre interrogati insieme e che garantiscono una buona distribuzione dei dati. Per le chiavi di ordinamento, posiziona gli attributi più richiesti al primo posto nella gerarchia per massimizzare la flessibilità delle query. Questo ordinamento consente di eseguire query a qualsiasi livello di granularità che corrisponda ai modelli di accesso.
Vedi gli esempi di [Chiavi con più attributi](GSI.DesignPattern.MultiAttributeKeys.md) implementazione.
## Lettura di dati da un indice secondario globale
È possibile recuperare gli elementi da un indice secondario globale utilizzando le operazioni `Query` e `Scan`. Le operazioni `GetItem` e `BatchGetItem` non possono essere utilizzate su un indice secondario globale.
### Esecuzione di query su un indice secondario globale
È possibile utilizzare l'operazione `Query` per accedere a uno o più elementi in un indice secondario globale. La query deve specificare il nome della tabella di base e il nome dell'indice che si desidera utilizzare, gli attributi da restituire nei risultati della query e qualsiasi condizione di query da applicare. DynamoDB può restituire i risultati in ordine crescente o decrescente.
Considera i dati seguenti restituiti da un'operazione `Query` che richiede dati di gioco per un'applicazione di tipo classifica.
```
{
"TableName": "GameScores",
"IndexName": "GameTitleIndex",
"KeyConditionExpression": "GameTitle = :v_title",
"ExpressionAttributeValues": {
":v_title": {"S": "Meteor Blasters"}
},
"ProjectionExpression": "UserId, TopScore",
"ScanIndexForward": false
}
```
In questa query:
+ DynamoDB *GameTitleIndex*accede, utilizzando la chiave di partizione per individuare gli elementi *GameTitle*dell'indice per Meteor Blasters. Tutti gli elementi dell'indice con questa chiave sono memorizzati l'uno accanto all'altro per il recupero rapido.
+ All'interno di questo gioco, DynamoDB utilizza l'indice per accedere a tutti gli IDs utenti e ai punteggi più alti di questo gioco.
+ Vengono restituiti i risultati in base all'ordine decrescente, perché il parametro `ScanIndexForward` è impostato su false.
### Scansione di un indice secondario globale
È possibile utilizzare l'operazione `Scan` per recuperare tutti i dati da un indice secondario globale. Devi fornire il nome della tabella di base e il nome dell'indice nella richiesta. Con un'operazione `Scan`, DynamoDB legge tutti i dati nell'indice e li restituisce all'applicazione. Inoltre puoi richiedere che vengano restituiti solo alcuni dati e che quelli rimanenti vengano eliminati. A questo scopo, usa il parametro `FilterExpression` dell'operazione `Scan`. Per ulteriori informazioni, consulta [Espressioni di filtro per la scansione](Scan.md#Scan.FilterExpression).
## Sincronizzazione dei dati tra tabelle e indici secondari globali
DynamoDB sincronizza automaticamente ogni indice secondario globale con la relativa tabella di base. Quando un'applicazione scrive o elimina elementi in una tabella, ogni indice secondario globale nella tabella viene aggiornato in modo asincrono, usando un modello a consistenza finale. Le applicazioni non scrivono mai direttamente in un indice. Tuttavia, è importante comprendere le implicazioni di come DynamoDB mantiene questi indici.
Gli indici secondari globali ereditano la modalità di read/write capacità dalla tabella base. Per ulteriori informazioni, consulta [Considerazioni sul passaggio tra modalità di capacità in DynamoDB](bp-switching-capacity-modes.md).
Quando si crea un indice secondario globale, viene specificato uno o più attributi della chiave di indice e i rispettivi tipi di dati. Questo significa che ogni volta che scrivi un item nella tabella di base, i tipi di dati per questi attributi devono corrispondere ai tipi di dati dello schema della chiave dell'indice. Nel caso di `GameTitleIndex`, la chiave di partizione `GameTitle` nell'indice è definita come un tipo di dati `String`. La chiave di ordinamento `TopScore` nell'indice è di tipo `Number`. Se si prova ad aggiungere un elemento alla tabella `GameScores` e si specifica un tipo di dati diverso per `GameTitle` o `TopScore`, DynamoDB restituisce un `ValidationException` perché il tipo di dati non corrisponde.
Quando inserisci o elimini item in una tabella, ogni indice secondario globale nella tabella viene aggiornato in base a un modello eventualmente consistente. Le modifiche apportate ai dati della tabella vengono propagate in ogni indice secondario globale entro una frazione di secondo in condizioni normali. Tuttavia, in alcuni improbabili scenari di errore, possono verificarsi ritardi di propagazione prolungati. Per questo motivo, le applicazioni devono poter prevedere e gestire le situazioni in cui una query su un indice secondario globale restituisce risultati non aggiornati.
Se si scrive un elemento in una tabella, non è necessario specificare gli attributi per la chiave di ordinamento di alcun indice secondario globale. Utilizzando `GameTitleIndex` come un esempio, non devi specificare un valore per l'attributo `TopScore` per scrivere un nuovo item nella tabella `GameScores`. In questo caso, DynamoDB non scrive alcun dato nell'indice per questo particolare elemento.
Una tabella con molti indici secondari globali comporta costi maggiori per l'attività di scrittura rispetto alle tabelle con meno indici. Per ulteriori informazioni, consulta [Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari globali](#GSI.ThroughputConsiderations).
## Classi di tabella con indici secondari globali
Un indice secondario globale utilizzerà sempre la stessa classe di tabella della tabella di base. Ogni volta che viene aggiunto un nuovo indice secondario globale per una tabella, il nuovo indice utilizzerà la stessa classe di tabella della tabella di base. Quando la classe di tabella di una tabella viene aggiornata, vengono aggiornati anche tutti gli indici secondari globali associati.
## Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari globali
Quando si crea un indice secondario globale su una tabella con modalità assegnata, è necessario specificare le unità di capacità di lettura e scrittura per il carico di lavoro previsto sull'indice. Le impostazioni correlate alla velocità effettiva assegnata di un indice secondario globale sono separate da quelle della relativa tabella di base. Un'operazione `Query` su un indice secondario globale utilizza unità di capacità di lettura dell'indice e non della tabella di base. Quando inserisci, aggiorni o elimini item in una tabella, anche gli indici secondari globali nella tabella vengono aggiornati. Questi aggiornamenti dell'indice utilizzano unità di capacità in scrittura dell'indice, non della tabella.
Ad esempio, se si esegui un'operazione `Query` su un indice secondario globale e se ne supera la capacità di lettura assegnata, la richiesta sarà sottoposta a limitazione. Se si esegue un'attività di scrittura pesante sulla tabella, ma un indice secondario globale su quella tabella ha una capacità di scrittura insufficiente, l'attività di scrittura sulla tabella verrà limitata.
**Importante**
Per evitare il possibile throttling, la capacità in scrittura assegnata per un indice secondario globale deve essere maggiore o uguale alla capacità in scrittura della tabella di base poiché nuovi aggiornamenti scrivono nella tabella di base e nell'indice secondario globale.
Per visualizzare le impostazioni di velocità effettiva assegnata per un indice secondario globale, utilizza l'operazione `DescribeTable`. Vengono restituite informazioni dettagliare relative a tutti gli indici secondari della tabella.
### Unità di capacità in lettura
Gli indici secondari globali supportano letture consistenti finali, ognuna delle quali utilizza metà di un'unità di capacità in lettura. Questo significa che una singola query su un indice secondario globale può recuperare fino a 2 × 4 KB = 8 KB per ogni unità di capacità di lettura.
Per le query su un indice secondario globale, DynamoDB calcola l'attività di lettura assegnata come avviene per le query sulle tabelle. L'unica differenza è che il calcolo si basa sulle dimensioni delle voci dell'indice, piuttosto che sulla dimensione dell'item nella tabella di base. Il numero di unità di capacità in lettura è la somma di tutte le dimensioni degli attributi proiettati di tutti gli elementi restituiti. Il risultato viene arrotondato al limite di 4 KB successivo. Per ulteriori informazioni sul modo in cui DynamoDB calcola l'uso della velocità effettiva assegnata, consulta [Modalità con capacità allocata di DynamoDB](provisioned-capacity-mode.md).
La dimensione massima dei risultati restituiti da un'operazione `Query` è 1 MB. Sono incluse le dimensioni di tutti i nomi e i valori degli attributi in tutti gli elementi restituiti.
Ad esempio, si consideri un indice secondario globale in cui ogni elemento contiene 2.000 byte di dati. Si supponga ora di eseguire un'operazione `Query` su questo indice e che `KeyConditionExpression` della query restituisca otto elementi. La dimensione totale degli elementi corrispondenti è 2.000 byte 8 elementi = 16.000 byte. Questo risultato viene quindi arrotondato al limite da 4 KB più vicino. Poiché le query su un indice secondario globale sono a consistenza finale, il costo totale equivale a 0,5 × (16 KB / 4 KB) o 2 unità di capacità di lettura.
### Unità di capacità in scrittura
Quando un elemento in una tabella viene aggiunto, aggiornato o eliminato e questa operazione interessa un indice secondario globale, l'indice utilizzerà le unità di capacità di scrittura assegnate per l'operazione. Il costo totale del throughput assegnato per una scrittura è la somma delle unità di capacità in scrittura utilizzate dalla scrittura nella tabella di base e quelle utilizzate dall'aggiornamento degli indici secondari globali. Se una scrittura in una tabella non richiede l'aggiornamento di un indice secondario globale, non viene utilizzata capacità di scrittura dell'indice.
Perché la scrittura in una tabella riesca, le impostazioni correlate al throughput assegnato per la tabella e tutti i suoi indici secondari globali devono avere capacità in scrittura sufficiente per la scrittura. In caso contrario, la scrittura nella tabella viene limitata.
**Importante**
Quando si crea un indice secondario globale (GSI), le operazioni di scrittura sulla tabella di base possono essere sottoposte a limitazione (della larghezza di banda della rete) se l’attività dei GSI risultante dalle scritture sulla tabella di base supera la capacità di scrittura allocata del GSI. Questa limitazione (della larghezza di banda della rete) influisce su tutte le operazioni di scrittura, dal processo di indicizzazione alla potenziale interruzione dei carichi di lavoro di produzione. Per ulteriori informazioni, consulta [Risoluzione dei problemi di limitazione (della larghezza di banda della rete) in Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
Il costo della scrittura di un elemento in un indice secondario globale dipende da diversi fattori:
+ Se scrivi un nuovo item nella tabella che definisce un attributo indicizzato o aggiorni un item esistente per definire un attributo indicizzato in precedenza non definito, è necessario eseguire un'operazione di scrittura per inserire l'item nell'indice.
+ Se un aggiornamento della tabella modifica il valore di un attributo chiave indicizzato (da A a B), sono necessarie due scritture, una per eliminare l'item precedente dall'indice e un'altra per inserire il nuovo item nell'indice.
+ Se un item era presente nell'indice, ma una scrittura nella tabella ha causato la cancellazione dell'attributo indicizzato, è necessaria una scrittura per eliminare la proiezione dell'item precedente dall'indice.
+ Se un item non è presente nell'indice prima o dopo l'aggiornamento dell'item, non vi è alcun costo di scrittura aggiuntivo per l'indice.
+ Se un aggiornamento della tabella modifica solo il valore degli attributi proiettati nello schema della chiave dell'indice, ma non modifica il valore di alcun attributo di chiave indicizzato, è necessaria una scrittura per aggiornare i valori degli attributi proiettati nell'indice.
Tutti questi fattori presuppongono che la dimensione di ciascun elemento nell'indice sia minore o uguale alla dimensione dell'elemento di 1 KB per il calcolo delle unità di capacità di scrittura. Le voci di indice più grandi richiedono unità di capacità in scrittura aggiuntive. Puoi contenere al minimo i costi di scrittura considerando gli attributi che le query devono restituire e proiettando solo tali attributi nell'indice.
## Considerazioni sullo storage per indici secondari globali
Quando un'applicazione scrive un elemento in una tabella, DynamoDB copia automaticamente il sottoinsieme di attributi corretto in qualsiasi indice secondario globale in cui devono essere presenti gli attributi. All' AWS account vengono addebitati i costi per la memorizzazione dell'articolo nella tabella di base e anche per la memorizzazione degli attributi in tutti gli indici secondari globali di tale tabella.
La quantità di spazio utilizzata da un item dell'indice è la somma di quanto segue:
+ La dimensione in byte della chiave primaria della tabella di base (chiave di partizione e chiave di ordinamento)
+ La dimensione in byte dell'attributo della chiave di indicizzazione
+ La dimensione in byte degli attributi proiettati (se presenti)
+ 100 byte di sovraccarico per elemento dell'indice
Per stimare i requisiti di archiviazione per un indice secondario globale, è possibile stimare la dimensione media di un elemento nell'indice e quindi moltiplicarla per il numero di elementi nella tabella di base che hanno attributi di chiave dell'indice secondario globale.
Se una tabella contiene un elemento in cui uno o più attributi particolari non sono definiti, ma tale attributo è definito come chiave di partizione dell'indice o chiave di ordinamento, DynamoDB non scrive alcun dato per quell'elemento nell'indice.
# Modelli di progettazione
I modelli di progettazione forniscono soluzioni comprovate alle sfide più comuni quando si lavora con indici secondari globali. Questi modelli consentono di creare applicazioni efficienti e scalabili mostrando come strutturare gli indici per casi d'uso specifici.
Ogni modello include una guida all'implementazione completa con esempi di codice, best practice e casi d'uso reali per aiutarvi ad applicare il pattern alle vostre applicazioni.
**Topics**
+ [Chiavi con più attributi](GSI.DesignPattern.MultiAttributeKeys.md)
# Schema di chiavi multiattributo
## Panoramica
Le chiavi multi-attributo consentono di creare chiavi di partizione e ordinamento del Global Secondary Index (GSI) composte da un massimo di quattro attributi ciascuna. Ciò riduce il codice lato client e semplifica la modellazione iniziale dei dati e l'aggiunta di nuovi modelli di accesso in un secondo momento.
Consideriamo uno scenario comune: per creare un GSI che interroghi gli elementi in base a più attributi gerarchici, tradizionalmente è necessario creare chiavi sintetiche concatenando i valori. Ad esempio, in un'app di gioco, per interrogare le partite dei tornei per torneo, regione e round, potresti creare una chiave di partizione GSI sintetica come TOURNAMENT\$1 WINTER2 024 \$1REGION \$1NA -EAST e una chiave di ordinamento sintetica come ROUND \$1SEMIFINALS \$1BRACKET \$1UPPER. Questo approccio funziona, ma richiede la concatenazione di stringhe durante la scrittura dei dati, l'analisi durante la lettura e il riempimento delle chiavi sintetiche su tutti gli elementi esistenti se si aggiunge il GSI a una tabella esistente. Ciò rende il codice più disordinato e difficile da mantenere la sicurezza dei tipi sui singoli componenti chiave.
Le chiavi multiattributo risolvono questo problema per. GSIs Definisci la tua chiave di partizione GSI utilizzando più attributi esistenti come TournamentID e region. DynamoDB gestisce automaticamente la logica delle chiavi composite, eseguendo l'hashing delle stesse per la distribuzione dei dati. Gli elementi vengono scritti utilizzando gli attributi naturali del modello di dominio e il GSI li indicizza automaticamente. Nessuna concatenazione, nessuna analisi, nessun riempimento. Il codice rimane pulito, i dati rimangono digitati e le query rimangono semplici. Questo approccio è particolarmente utile quando si hanno dati gerarchici con raggruppamenti di attributi naturali (come torneo → regione → round o organizzazione → dipartimento → squadra).
## Esempio di applicazione
Questa guida illustra la creazione di un sistema di tracciamento delle partite di torneo per una piattaforma di eSport. La piattaforma deve interrogare in modo efficiente le partite su più fronti: per torneo e regione per la gestione dei gironi, per giocatore per la cronologia delle partite e per data di programmazione.
## Modello di dati
In questa procedura dettagliata, il sistema di tracciamento delle partite dei tornei supporta tre modelli di accesso principali, ognuno dei quali richiede una struttura chiave diversa:
**Schema di accesso 1:** cerca una partita specifica in base al relativo ID univoco
+ **Soluzione:** tabella di base con `matchId` chiave di partizione
**Schema di accesso 2:** interroga tutte le partite di un torneo e di una regione specifici, filtrandole facoltativamente per round, tabellone o partita
+ **Soluzione:** Indice secondario globale con chiave di partizione multiattributo (`tournamentId`\$1`region`) e chiave di ordinamento multiattributo (\$1) `round` `bracket` `matchId`
+ **Query di esempio:** «Tutte le partite WINTER2 024 nella regione NA-EST» o «Tutte le SEMIFINALI corrispondono nel girone SUPERIORE per 024/NA-EST» WINTER2
**Schema di accesso 3:** interroga la cronologia delle partite di un giocatore, filtrandola facoltativamente per intervallo di date o round del torneo
+ **Soluzione:** Indice secondario globale con chiave di partizione singola (`player1Id`) e chiave di ordinamento multiattributo (\$1) `matchDate` `round`
+ **Domande di esempio:** «Tutte le partite del giocatore 101" o «Le partite del giocatore 101 a gennaio 2024"
La differenza fondamentale tra gli approcci tradizionali e quelli con più attributi diventa evidente quando si esamina la struttura degli elementi:
**Approccio tradizionale all'indice secondario globale (chiavi concatenate):**
```
// Manual concatenation required for GSI keys
const item = {
matchId: 'match-001', // Base table PK
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '101',
// Synthetic keys needed for GSI
GSI_PK: `TOURNAMENT#${tournamentId}#REGION#${region}`, // Must concatenate
GSI_SK: `${round}#${bracket}#${matchId}`, // Must concatenate
// ... other attributes
};
```
**Approccio all'indice secondario globale multiattributo (chiavi native):**
```
// Use existing attributes directly - no concatenation needed
const item = {
matchId: 'match-001', // Base table PK
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '101',
matchDate: '2024-01-18',
// No synthetic keys needed - GSI uses existing attributes directly
// ... other attributes
};
```
Con le chiavi multiattributo, gli elementi vengono scritti una sola volta con attributi di dominio naturali. DynamoDB li indicizza automaticamente su GSIs più pagine senza richiedere chiavi sintetiche concatenate.
**Schema della tabella di base:**
+ Chiave di partizione: `matchId` (1 attributo)
**Schema dell'indice secondario globale (TournamentRegionIndex con chiavi multiattributo):**
+ Chiave di partizione:`tournamentId`, `region` (2 attributi)
+ Chiave di ordinamento: `round``bracket`,, `matchId` (3 attributi)
**Schema dell'indice secondario globale (PlayerMatchHistoryIndex con chiavi multiattributo):**
+ Chiave di partizione: `player1Id` (1 attributo)
+ Chiave di ordinamento:`matchDate`, `round` (2 attributi)
### Tabella base: TournamentMatches
| MatchID (PK) | ID del torneo | region | round | staffa | ID giocatore 1 | ID giocatore 2 | Data della partita | vincitore | punteggio |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| partita-001 | WINTER2024 | NA-EST | FINALE | CAMPIONATO | 101 | 103 | 2024-01-20 | 101 | 3-1 |
| inquadrato-002 | WINTER2024 | NA-EST | SEMIFINALI | UPPER | 101 | 105 | 2024-01-18 | 101 | 3-2 |
| inquadrato-003 | WINTER2024 | NA-EST | SEMIFINALI | UPPER | 103 | 107 | 2024-01-18 | 103 | 3-0 |
| inquadrato-004 | WINTER2024 | NA-EST | QUARTI DI FINALE | UPPER | 101 | 109 | 2024-01-15 | 101 | 3-1 |
| inquadrato-005 | WINTER2024 | NORD-OVEST | FINALE | CAMPIONATO | 102 | 104 | 2024-01-20 | 102 | 3-2 |
| inquadrato-006 | WINTER2024 | NORD-OVEST | SEMIFINALI | UPPER | 102 | 106 | 2024-01-18 | 102 | 3-1 |
| partita-007 | SPRING2024 | NA-EST | QUARTI DI FINALE | UPPER | 101 | 108 | 2024-03-15 | 101 | 3-0 |
| inquadrato-008 | SPRING2024 | NA-EST | QUARTI DI FINALE | LOWER | 103 | 110 | 2024-03-15 | 103 | 3-2 |
### GSI: TournamentRegionIndex (chiavi multiattributo)
| ID torneo (PK) | regione (PK) | rotondo (SK) | staffa (SK) | MatchID (SK) | ID giocatore 1 | ID giocatore 2 | Data della partita | vincitore | punteggio |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| WINTER2024 | NA-EST | FINALE | CAMPIONATO | partita-001 | 101 | 103 | 2024-01-20 | 101 | 3-1 |
| WINTER2024 | NA-EST | QUARTI DI FINALE | UPPER | match-004 | 101 | 109 | 2024-01-15 | 101 | 3-1 |
| WINTER2024 | NA-EST | SEMIFINALI | UPPER | partita-002 | 101 | 105 | 2024-01-18 | 101 | 3-2 |
| WINTER2024 | NA-EST | SEMIFINALI | UPPER | match-003 | 103 | 107 | 2024-01-18 | 103 | 3-0 |
| WINTER2024 | NORD-OVEST | FINALE | CAMPIONATO | partita-005 | 102 | 104 | 2024-01-20 | 102 | 3-2 |
| WINTER2024 | NORD-OVEST | SEMIFINALI | UPPER | partita-006 | 102 | 106 | 2024-01-18 | 102 | 3-1 |
| SPRING2024 | NA-EST | QUARTI DI FINALE | LOWER | partita-008 | 103 | 110 | 2024-03-15 | 103 | 3-2 |
| SPRING2024 | NA-EST | QUARTI DI FINALE | UPPER | match-007 | 101 | 108 | 2024-03-15 | 101 | 3-0 |
### GSI: PlayerMatchHistoryIndex (chiavi multiattributo)
| Player1ID (PK) | MatchDate (SK) | rotondo (SK) | ID del torneo | region | staffa | MatchID | ID giocatore 2 | vincitore | punteggio |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 101 | 2024-01-15 | QUARTI DI FINALE | WINTER2024 | NA-EST | UPPER | partita-004 | 109 | 101 | 3-1 |
| 101 | 2024-01-18 | SEMIFINALI | WINTER2024 | NA-EST | UPPER | partita-002 | 105 | 101 | 3-2 |
| 101 | 2024-01-20 | FINALE | WINTER2024 | NA-EST | CAMPIONATO | partita-001 | 103 | 101 | 3-1 |
| 101 | 2024-03-15 | QUARTI DI FINALE | SPRING2024 | NA-EST | UPPER | partita-007 | 108 | 101 | 3-0 |
| 102 | 2024-01-18 | SEMIFINALI | WINTER2024 | NORD-OVEST | UPPER | incontro 006 | 106 | 102 | 3-1 |
| 102 | 2024-01-20 | FINALE | WINTER2024 | NORD-OVEST | CAMPIONATO | partita-005 | 104 | 102 | 3-2 |
| 103 | 2024-01-18 | SEMIFINALI | WINTER2024 | NA-EST | UPPER | partita-003 | 107 | 103 | 3-0 |
| 103 | 2024-03-15 | QUARTI DI FINALE | SPRING2024 | NA-EST | LOWER | partita-008 | 110 | 103 | 3-2 |
## Prerequisiti
Prima di iniziare, assicurati di disporre dei seguenti elementi:
### Account e autorizzazioni
+ Un AWS account attivo ([creane uno qui](https://aws.amazon.com/free/) se necessario)
+ Autorizzazioni IAM per le operazioni DynamoDB:
+ `dynamodb:CreateTable`
+ `dynamodb:DeleteTable`
+ `dynamodb:DescribeTable`
+ `dynamodb:PutItem`
+ `dynamodb:Query`
+ `dynamodb:BatchWriteItem`
**Nota**
**Nota di sicurezza:** per l'uso in produzione, crea una policy IAM personalizzata con solo le autorizzazioni necessarie. Per questo tutorial, puoi utilizzare la policy AWS `AmazonDynamoDBFullAccessV2` gestita.
### Ambiente di sviluppo
+ Node.js installato sul tuo computer
+ AWS credenziali configurate utilizzando uno di questi metodi:
**Opzione 1: AWS CLI**
```
aws configure
```
**Opzione 2: variabili di ambiente**
```
export AWS_ACCESS_KEY_ID=your_access_key_here
export AWS_SECRET_ACCESS_KEY=your_secret_key_here
export AWS_DEFAULT_REGION=us-east-1
```
### Installazione dei pacchetti richiesti
```
npm install @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb
```
## Implementazione
### Passaggio 1: creare una tabella GSIs utilizzando chiavi multiattributo
Crea una tabella con una struttura chiave di base semplice e GSIs che utilizzi chiavi multiattributo.
#### esempio di codice
```
import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const response = await client.send(new CreateTableCommand({
TableName: 'TournamentMatches',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'matchId', KeyType: 'HASH' } // Simple PK
],
AttributeDefinitions: [
{ AttributeName: 'matchId', AttributeType: 'S' },
{ AttributeName: 'tournamentId', AttributeType: 'S' },
{ AttributeName: 'region', AttributeType: 'S' },
{ AttributeName: 'round', AttributeType: 'S' },
{ AttributeName: 'bracket', AttributeType: 'S' },
{ AttributeName: 'player1Id', AttributeType: 'S' },
{ AttributeName: 'matchDate', AttributeType: 'S' }
],
// GSIs with multi-attribute keys
GlobalSecondaryIndexes: [
{
IndexName: 'TournamentRegionIndex',
KeySchema: [
{ AttributeName: 'tournamentId', KeyType: 'HASH' }, // GSI PK attribute 1
{ AttributeName: 'region', KeyType: 'HASH' }, // GSI PK attribute 2
{ AttributeName: 'round', KeyType: 'RANGE' }, // GSI SK attribute 1
{ AttributeName: 'bracket', KeyType: 'RANGE' }, // GSI SK attribute 2
{ AttributeName: 'matchId', KeyType: 'RANGE' } // GSI SK attribute 3
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'PlayerMatchHistoryIndex',
KeySchema: [
{ AttributeName: 'player1Id', KeyType: 'HASH' }, // GSI PK
{ AttributeName: 'matchDate', KeyType: 'RANGE' }, // GSI SK attribute 1
{ AttributeName: 'round', KeyType: 'RANGE' } // GSI SK attribute 2
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}));
console.log("Table with multi-attribute GSI keys created successfully");
```
**Principali decisioni di progettazione:**
**Tabella base:** la tabella base utilizza una semplice chiave di `matchId` partizione per le ricerche dirette, mantenendo la struttura della tabella di base semplice e GSIs fornendo al contempo modelli di interrogazione complessi.
**TournamentRegionIndex Indice secondario globale: l'indice** secondario `TournamentRegionIndex` globale utilizza `tournamentId` \$1 `region` come chiave di partizione multiattributo, creando un isolamento tra regione e torneo in cui i dati vengono distribuiti combinando l'hash di entrambi gli attributi, permettendo di eseguire query efficienti all'interno di un contesto specifico tra torneo e regione. La chiave di ordinamento multiattributo (`round`\$1 `bracket` \$1`matchId`) fornisce un ordinamento gerarchico che supporta le query a qualsiasi livello della gerarchia con un ordinamento naturale da generale (round) a specifico (match ID).
**PlayerMatchHistoryIndex Indice secondario globale:** il `PlayerMatchHistoryIndex` Global Secondary Index riorganizza i dati per giocatore utilizzandoli `player1Id` come chiave di partizione, abilitando le interrogazioni tra tornei per un giocatore specifico. La chiave di ordinamento multiattributo (`matchDate`\$1`round`) fornisce un ordine cronologico con la possibilità di filtrare per intervalli di date o turni di torneo specifici.
### Fase 2: Inserimento di dati con attributi nativi
Aggiungi i dati delle partite del torneo utilizzando attributi naturali. Il GSI indicizzerà automaticamente questi attributi senza richiedere chiavi sintetiche.
#### esempio di codice
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Tournament match data - no synthetic keys needed for GSIs
const matches = [
// Winter 2024 Tournament, NA-EAST region
{
matchId: 'match-001',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'FINALS',
bracket: 'CHAMPIONSHIP',
player1Id: '101',
player2Id: '103',
matchDate: '2024-01-20',
winner: '101',
score: '3-1'
},
{
matchId: 'match-002',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '101',
player2Id: '105',
matchDate: '2024-01-18',
winner: '101',
score: '3-2'
},
{
matchId: 'match-003',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '103',
player2Id: '107',
matchDate: '2024-01-18',
winner: '103',
score: '3-0'
},
{
matchId: 'match-004',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'QUARTERFINALS',
bracket: 'UPPER',
player1Id: '101',
player2Id: '109',
matchDate: '2024-01-15',
winner: '101',
score: '3-1'
},
// Winter 2024 Tournament, NA-WEST region
{
matchId: 'match-005',
tournamentId: 'WINTER2024',
region: 'NA-WEST',
round: 'FINALS',
bracket: 'CHAMPIONSHIP',
player1Id: '102',
player2Id: '104',
matchDate: '2024-01-20',
winner: '102',
score: '3-2'
},
{
matchId: 'match-006',
tournamentId: 'WINTER2024',
region: 'NA-WEST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '102',
player2Id: '106',
matchDate: '2024-01-18',
winner: '102',
score: '3-1'
},
// Spring 2024 Tournament, NA-EAST region
{
matchId: 'match-007',
tournamentId: 'SPRING2024',
region: 'NA-EAST',
round: 'QUARTERFINALS',
bracket: 'UPPER',
player1Id: '101',
player2Id: '108',
matchDate: '2024-03-15',
winner: '101',
score: '3-0'
},
{
matchId: 'match-008',
tournamentId: 'SPRING2024',
region: 'NA-EAST',
round: 'QUARTERFINALS',
bracket: 'LOWER',
player1Id: '103',
player2Id: '110',
matchDate: '2024-03-15',
winner: '103',
score: '3-2'
}
];
// Insert all matches
for (const match of matches) {
await docClient.send(new PutCommand({
TableName: 'TournamentMatches',
Item: match
}));
console.log(`Added: ${match.matchId} - ${match.tournamentId}/${match.region} - ${match.round} ${match.bracket}`);
}
console.log(`\nInserted ${matches.length} tournament matches`);
console.log("No synthetic keys created - GSIs use native attributes automatically");
```
**Struttura dei dati spiegata:**
**Utilizzo degli attributi naturali:** ogni attributo rappresenta un vero concetto di torneo senza necessità di concatenazione o analisi di stringhe, e fornisce una mappatura diretta al modello di dominio.
Indicizzazione **automatica dell'indice secondario globale: indicizza** GSIs automaticamente gli elementi utilizzando gli attributi esistenti (`tournamentId`,,,, `matchId` for TournamentRegionIndex e `region` `round` `bracket` `player1Id``matchDate`, `round` for PlayerMatchHistoryIndex) senza richiedere chiavi concatenate sintetiche.
**Non è necessario il backfill:** quando aggiungi un nuovo indice secondario globale con chiavi multiattributo a una tabella esistente, DynamoDB indicizza automaticamente tutti gli elementi esistenti utilizzando i loro attributi naturali, senza bisogno di aggiornare gli elementi con chiavi sintetiche.
### Fase 3: Interroga l'indice secondario globale con tutti gli attributi delle chiavi di partizione TournamentRegionIndex
Questo esempio interroga il TournamentRegionIndex Global Secondary Index che ha una chiave di partizione multiattributo (\$1). `tournamentId` `region` Tutti gli attributi delle chiavi di partizione devono essere specificati con condizioni di uguaglianza nelle query: non è possibile eseguire query `tournamentId` solo con o utilizzare operatori di disuguaglianza sugli attributi delle chiavi di partizione.
#### esempio di codice
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query GSI: All matches for WINTER2024 tournament in NA-EAST region
const response = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region',
ExpressionAttributeNames: {
'#region': 'region', // 'region' is a reserved keyword
'#tournament': 'tournament'
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST'
}
}));
console.log(`Found ${response.Items.length} matches for WINTER2024/NA-EAST:\n`);
response.Items.forEach(match => {
console.log(` ${match.round} | ${match.bracket} | ${match.matchId}`);
console.log(` Players: ${match.player1Id} vs ${match.player2Id}`);
console.log(` Winner: ${match.winner}, Score: ${match.score}\n`);
});
```
**Output previsto:**
```
Found 4 matches for WINTER2024/NA-EAST:
FINALS | CHAMPIONSHIP | match-001
Players: 101 vs 103
Winner: 101, Score: 3-1
QUARTERFINALS | UPPER | match-004
Players: 101 vs 109
Winner: 101, Score: 3-1
SEMIFINALS | UPPER | match-002
Players: 101 vs 105
Winner: 101, Score: 3-2
SEMIFINALS | UPPER | match-003
Players: 103 vs 107
Winner: 103, Score: 3-0
```
**Interrogazioni non valide:**
```
// Missing region attribute
KeyConditionExpression: 'tournamentId = :tournament'
// Using inequality on partition key attribute
KeyConditionExpression: 'tournamentId = :tournament AND #region > :region'
```
**Prestazioni: le** chiavi di partizione con più attributi vengono codificate insieme, fornendo le stesse prestazioni di ricerca O (1) delle chiavi ad attributo singolo.
### Fase 4: Interroga le chiavi di ordinamento dell'indice secondario globale left-to-right
Gli attributi delle chiavi di ordinamento devono essere interrogati left-to-right nell'ordine in cui sono definiti nell'indice secondario globale. Questo esempio dimostra l'esecuzione di interrogazioni TournamentRegionIndex a diversi livelli gerarchici: filtraggio per just`round`, per `round` \$1 `bracket` o per tutti e tre gli attributi chiave di ordinamento. Non è possibile saltare gli attributi al centro, ad esempio non è possibile eseguire una query per e mentre si salta. `round` `matchId` `bracket`
#### esempio di codice
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query 1: Filter by first sort key attribute (round)
console.log("Query 1: All SEMIFINALS matches");
const query1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS'
}
}));
console.log(` Found ${query1.Items.length} matches\n`);
// Query 2: Filter by first two sort key attributes (round + bracket)
console.log("Query 2: SEMIFINALS UPPER bracket matches");
const query2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round AND bracket = :bracket',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS',
':bracket': 'UPPER'
}
}));
console.log(` Found ${query2.Items.length} matches\n`);
// Query 3: Filter by all three sort key attributes (round + bracket + matchId)
console.log("Query 3: Specific match in SEMIFINALS UPPER bracket");
const query3 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round AND bracket = :bracket AND matchId = :matchId',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS',
':bracket': 'UPPER',
':matchId': 'match-002'
}
}));
console.log(` Found ${query3.Items.length} matches\n`);
// Query 4: INVALID - skipping round
console.log("Query 4: Attempting to skip first sort key attribute (WILL FAIL)");
try {
const query4 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND bracket = :bracket',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':bracket': 'UPPER'
}
}));
} catch (error) {
console.log(` Error: ${error.message}`);
console.log(` Cannot skip sort key attributes - must query left-to-right\n`);
}
```
**Output previsto:**
```
Query 1: All SEMIFINALS matches
Found 2 matches
Query 2: SEMIFINALS UPPER bracket matches
Found 2 matches
Query 3: Specific match in SEMIFINALS UPPER bracket
Found 1 matches
Query 4: Attempting to skip first sort key attribute (WILL FAIL)
Error: Query key condition not supported
Cannot skip sort key attributes - must query left-to-right
```
**Left-to-right regole di interrogazione:** è necessario interrogare gli attributi in ordine da sinistra a destra, senza saltarne nessuno.
**Modelli validi:**
+ Solo primo attributo: `round = 'SEMIFINALS'`
+ Primi due attributi: `round = 'SEMIFINALS' AND bracket = 'UPPER'`
+ Tutti e tre gli attributi: `round = 'SEMIFINALS' AND bracket = 'UPPER' AND matchId = 'match-002'`
**Schemi non validi:**
+ Il primo attributo viene ignorato: `bracket = 'UPPER'` (salta il giro)
+ Interrogazione non corretta: `matchId = 'match-002' AND round = 'SEMIFINALS'`
+ Lasciare spazi vuoti: `round = 'SEMIFINALS' AND matchId = 'match-002'` (salta la parentesi)
**Nota**
**Suggerimento di progettazione:** ordina gli attributi chiave di ordinamento dal più generale al più specifico per massimizzare la flessibilità delle query.
### Fase 5: Utilizza le condizioni di disuguaglianza nelle chiavi di ordinamento dell'Indice secondario globale
Le condizioni di disuguaglianza devono essere l'ultima condizione della ricerca. Questo esempio dimostra l'utilizzo degli operatori di confronto (`>=`,`BETWEEN`) e del prefisso matching (`begins_with()`) sugli attributi delle chiavi di ordinamento. Una volta utilizzato un operatore di disuguaglianza, non è possibile aggiungere ulteriori condizioni di chiave di ordinamento dopo di esso: la disuguaglianza deve essere l'ultima condizione nell'espressione della condizione chiave.
#### esempio di codice
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query 1: Round comparison (inequality on first sort key attribute)
console.log("Query 1: Matches from QUARTERFINALS onwards");
const query1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round >= :round',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'QUARTERFINALS'
}
}));
console.log(` Found ${query1.Items.length} matches\n`);
// Query 2: Round range with BETWEEN
console.log("Query 2: Matches between QUARTERFINALS and SEMIFINALS");
const query2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round BETWEEN :start AND :end',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':start': 'QUARTERFINALS',
':end': 'SEMIFINALS'
}
}));
console.log(` Found ${query2.Items.length} matches\n`);
// Query 3: Prefix matching with begins_with (treated as inequality)
console.log("Query 3: Matches in brackets starting with 'U'");
const query3 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round AND begins_with(bracket, :prefix)',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS',
':prefix': 'U'
}
}));
console.log(` Found ${query3.Items.length} matches\n`);
// Query 4: INVALID - condition after inequality
console.log("Query 4: Attempting condition after inequality (WILL FAIL)");
try {
const query4 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round > :round AND bracket = :bracket',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'QUARTERFINALS',
':bracket': 'UPPER'
}
}));
} catch (error) {
console.log(` Error: ${error.message}`);
console.log(` Cannot add conditions after inequality - it must be last\n`);
}
```
**Regole degli operatori di disuguaglianza:** è possibile utilizzare gli operatori di confronto (`>`,,,`<=`) `>=``<`, `BETWEEN` per le interrogazioni sugli intervalli e per la corrispondenza dei prefissi. `begins_with()` La disuguaglianza deve essere l'ultima condizione della query.
**Schemi validi:**
+ Condizioni di uguaglianza seguite dalla disuguaglianza: `round = 'SEMIFINALS' AND bracket = 'UPPER' AND matchId > 'match-001'`
+ Disuguaglianza sul primo attributo: `round BETWEEN 'QUARTERFINALS' AND 'SEMIFINALS'`
+ Corrispondenza del prefisso come condizione finale: `round = 'SEMIFINALS' AND begins_with(bracket, 'U')`
**Schemi non validi:**
+ Aggiungere condizioni dopo una disuguaglianza: `round > 'QUARTERFINALS' AND bracket = 'UPPER'`
+ Utilizzo di più disuguaglianze: `round > 'QUARTERFINALS' AND bracket > 'L'`
**Importante**
`begins_with()`viene considerata una condizione di disuguaglianza, quindi non può essere seguita da alcuna condizione di chiave di ordinamento aggiuntiva.
### Fase 6: Interrogazione dell'indice secondario PlayerMatchHistoryIndex globale con una chiave di ordinamento multiattributo
Questo esempio interroga il PlayerMatchHistoryIndex che ha una chiave di partizione singola (`player1Id`) e una chiave di ordinamento con più attributi (\$1). `matchDate` `round` Ciò consente l'analisi tra tornei interrogando tutte le partite di un giocatore specifico senza conoscere il torneo, IDs mentre la tabella base richiederebbe interrogazioni separate per combinazione torneo-regione.
#### esempio di codice
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query 1: All matches for Player 101 across all tournaments
console.log("Query 1: All matches for Player 101");
const query1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player',
ExpressionAttributeValues: {
':player': '101'
}
}));
console.log(` Found ${query1.Items.length} matches for Player 101:`);
query1.Items.forEach(match => {
console.log(` ${match.tournamentId}/${match.region} - ${match.matchDate} - ${match.round}`);
});
console.log();
// Query 2: Player 101 matches on specific date
console.log("Query 2: Player 101 matches on 2024-01-18");
const query2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player AND matchDate = :date',
ExpressionAttributeValues: {
':player': '101',
':date': '2024-01-18'
}
}));
console.log(` Found ${query2.Items.length} matches\n`);
// Query 3: Player 101 SEMIFINALS matches on specific date
console.log("Query 3: Player 101 SEMIFINALS matches on 2024-01-18");
const query3 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player AND matchDate = :date AND round = :round',
ExpressionAttributeValues: {
':player': '101',
':date': '2024-01-18',
':round': 'SEMIFINALS'
}
}));
console.log(` Found ${query3.Items.length} matches\n`);
// Query 4: Player 101 matches in date range
console.log("Query 4: Player 101 matches in January 2024");
const query4 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player AND matchDate BETWEEN :start AND :end',
ExpressionAttributeValues: {
':player': '101',
':start': '2024-01-01',
':end': '2024-01-31'
}
}));
console.log(` Found ${query4.Items.length} matches\n`);
```
## Variazioni del modello
### Dati di serie temporali con chiavi multiattributo
Ottimizzazione per le query su serie temporali con attributi temporali gerarchici
#### esempio di codice
```
{
TableName: 'IoTReadings',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'readingId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'readingId', AttributeType: 'S' },
{ AttributeName: 'deviceId', AttributeType: 'S' },
{ AttributeName: 'locationId', AttributeType: 'S' },
{ AttributeName: 'year', AttributeType: 'S' },
{ AttributeName: 'month', AttributeType: 'S' },
{ AttributeName: 'day', AttributeType: 'S' },
{ AttributeName: 'timestamp', AttributeType: 'S' }
],
// GSI with multi-attribute keys for time-series queries
GlobalSecondaryIndexes: [{
IndexName: 'DeviceLocationTimeIndex',
KeySchema: [
{ AttributeName: 'deviceId', KeyType: 'HASH' },
{ AttributeName: 'locationId', KeyType: 'HASH' },
{ AttributeName: 'year', KeyType: 'RANGE' },
{ AttributeName: 'month', KeyType: 'RANGE' },
{ AttributeName: 'day', KeyType: 'RANGE' },
{ AttributeName: 'timestamp', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}],
BillingMode: 'PAY_PER_REQUEST'
}
// Query patterns enabled via GSI:
// - All readings for device in location
// - Readings for specific year
// - Readings for specific month in year
// - Readings for specific day
// - Readings in time range
```
**Vantaggi:** la gerarchia temporale naturale (anno → mese → giorno → timestamp) consente una granularità delle query efficienti in qualsiasi momento senza analisi o manipolazione della data. L'indice secondario globale indicizza automaticamente tutte le letture utilizzando i loro attributi temporali naturali.
### Ordini di e-commerce con chiavi multiattributo
Tieni traccia degli ordini con più dimensioni
#### esempio di codice
```
{
TableName: 'Orders',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'orderId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'orderId', AttributeType: 'S' },
{ AttributeName: 'sellerId', AttributeType: 'S' },
{ AttributeName: 'region', AttributeType: 'S' },
{ AttributeName: 'orderDate', AttributeType: 'S' },
{ AttributeName: 'category', AttributeType: 'S' },
{ AttributeName: 'customerId', AttributeType: 'S' },
{ AttributeName: 'orderStatus', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'SellerRegionIndex',
KeySchema: [
{ AttributeName: 'sellerId', KeyType: 'HASH' },
{ AttributeName: 'region', KeyType: 'HASH' },
{ AttributeName: 'orderDate', KeyType: 'RANGE' },
{ AttributeName: 'category', KeyType: 'RANGE' },
{ AttributeName: 'orderId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'CustomerOrdersIndex',
KeySchema: [
{ AttributeName: 'customerId', KeyType: 'HASH' },
{ AttributeName: 'orderDate', KeyType: 'RANGE' },
{ AttributeName: 'orderStatus', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// SellerRegionIndex GSI queries:
// - Orders by seller and region
// - Orders by seller, region, and date
// - Orders by seller, region, date, and category
// CustomerOrdersIndex GSI queries:
// - Customer's orders
// - Customer's orders by date
// - Customer's orders by date and status
```
### Dati organizzativi gerarchici
Gerarchie organizzative modello
#### esempio di codice
```
{
TableName: 'Employees',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'employeeId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'employeeId', AttributeType: 'S' },
{ AttributeName: 'companyId', AttributeType: 'S' },
{ AttributeName: 'divisionId', AttributeType: 'S' },
{ AttributeName: 'departmentId', AttributeType: 'S' },
{ AttributeName: 'teamId', AttributeType: 'S' },
{ AttributeName: 'skillCategory', AttributeType: 'S' },
{ AttributeName: 'skillLevel', AttributeType: 'S' },
{ AttributeName: 'yearsExperience', AttributeType: 'N' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'OrganizationIndex',
KeySchema: [
{ AttributeName: 'companyId', KeyType: 'HASH' },
{ AttributeName: 'divisionId', KeyType: 'HASH' },
{ AttributeName: 'departmentId', KeyType: 'RANGE' },
{ AttributeName: 'teamId', KeyType: 'RANGE' },
{ AttributeName: 'employeeId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'SkillsIndex',
KeySchema: [
{ AttributeName: 'skillCategory', KeyType: 'HASH' },
{ AttributeName: 'skillLevel', KeyType: 'RANGE' },
{ AttributeName: 'yearsExperience', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'INCLUDE', NonKeyAttributes: ['employeeId', 'name'] }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// OrganizationIndex GSI query patterns:
// - All employees in company/division
// - Employees in specific department
// - Employees in specific team
// SkillsIndex GSI query patterns:
// - Employees by skill and experience level
```
### Chiavi sparse con più attributi
Combina chiavi multiattributo per creare un GSI sparso
#### esempio di codice
```
{
TableName: 'Products',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'productId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'productId', AttributeType: 'S' },
{ AttributeName: 'categoryId', AttributeType: 'S' },
{ AttributeName: 'subcategoryId', AttributeType: 'S' },
{ AttributeName: 'averageRating', AttributeType: 'N' },
{ AttributeName: 'reviewCount', AttributeType: 'N' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'CategoryIndex',
KeySchema: [
{ AttributeName: 'categoryId', KeyType: 'HASH' },
{ AttributeName: 'subcategoryId', KeyType: 'HASH' },
{ AttributeName: 'productId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'ReviewedProductsIndex',
KeySchema: [
{ AttributeName: 'categoryId', KeyType: 'HASH' },
{ AttributeName: 'averageRating', KeyType: 'RANGE' }, // Optional attribute
{ AttributeName: 'reviewCount', KeyType: 'RANGE' } // Optional attribute
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// Only products with reviews appear in ReviewedProductsIndex GSI
// Automatic filtering without application logic
// Multi-attribute sort key enables rating and count queries
```
### Multi-tenancy SaaS
Piattaforma SaaS multi-tenant con isolamento del cliente
#### esempio di codice
```
// Table design
{
TableName: 'SaasData',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'resourceId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'resourceId', AttributeType: 'S' },
{ AttributeName: 'tenantId', AttributeType: 'S' },
{ AttributeName: 'customerId', AttributeType: 'S' },
{ AttributeName: 'resourceType', AttributeType: 'S' }
],
// GSI with multi-attribute keys for tenant-customer isolation
GlobalSecondaryIndexes: [{
IndexName: 'TenantCustomerIndex',
KeySchema: [
{ AttributeName: 'tenantId', KeyType: 'HASH' },
{ AttributeName: 'customerId', KeyType: 'HASH' },
{ AttributeName: 'resourceType', KeyType: 'RANGE' },
{ AttributeName: 'resourceId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}],
BillingMode: 'PAY_PER_REQUEST'
}
// Query GSI: All resources for tenant T001, customer C001
const resources = await docClient.send(new QueryCommand({
TableName: 'SaasData',
IndexName: 'TenantCustomerIndex',
KeyConditionExpression: 'tenantId = :tenant AND customerId = :customer',
ExpressionAttributeValues: {
':tenant': 'T001',
':customer': 'C001'
}
}));
// Query GSI: Specific resource type for tenant/customer
const documents = await docClient.send(new QueryCommand({
TableName: 'SaasData',
IndexName: 'TenantCustomerIndex',
KeyConditionExpression: 'tenantId = :tenant AND customerId = :customer AND resourceType = :type',
ExpressionAttributeValues: {
':tenant': 'T001',
':customer': 'C001',
':type': 'document'
}
}));
```
**Vantaggi:** interrogazioni efficienti nel contesto tra inquilino e cliente e organizzazione naturale dei dati.
### Transazioni finanziarie
Sistema bancario che monitora le transazioni del conto utilizzando GSIs
#### esempio di codice
```
// Table design
{
TableName: 'BankTransactions',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'transactionId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'transactionId', AttributeType: 'S' },
{ AttributeName: 'accountId', AttributeType: 'S' },
{ AttributeName: 'year', AttributeType: 'S' },
{ AttributeName: 'month', AttributeType: 'S' },
{ AttributeName: 'day', AttributeType: 'S' },
{ AttributeName: 'transactionType', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'AccountTimeIndex',
KeySchema: [
{ AttributeName: 'accountId', KeyType: 'HASH' },
{ AttributeName: 'year', KeyType: 'RANGE' },
{ AttributeName: 'month', KeyType: 'RANGE' },
{ AttributeName: 'day', KeyType: 'RANGE' },
{ AttributeName: 'transactionId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'TransactionTypeIndex',
KeySchema: [
{ AttributeName: 'accountId', KeyType: 'HASH' },
{ AttributeName: 'transactionType', KeyType: 'RANGE' },
{ AttributeName: 'year', KeyType: 'RANGE' },
{ AttributeName: 'month', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// Query AccountTimeIndex GSI: All transactions for account in 2023
const yearTransactions = await docClient.send(new QueryCommand({
TableName: 'BankTransactions',
IndexName: 'AccountTimeIndex',
KeyConditionExpression: 'accountId = :account AND #year = :year',
ExpressionAttributeNames: { '#year': 'year' },
ExpressionAttributeValues: {
':account': 'ACC-12345',
':year': '2023'
}
}));
// Query AccountTimeIndex GSI: Transactions in specific month
const monthTransactions = await docClient.send(new QueryCommand({
TableName: 'BankTransactions',
IndexName: 'AccountTimeIndex',
KeyConditionExpression: 'accountId = :account AND #year = :year AND #month = :month',
ExpressionAttributeNames: { '#year': 'year', '#month': 'month' },
ExpressionAttributeValues: {
':account': 'ACC-12345',
':year': '2023',
':month': '11'
}
}));
// Query TransactionTypeIndex GSI: Deposits in 2023
const deposits = await docClient.send(new QueryCommand({
TableName: 'BankTransactions',
IndexName: 'TransactionTypeIndex',
KeyConditionExpression: 'accountId = :account AND transactionType = :type AND #year = :year',
ExpressionAttributeNames: { '#year': 'year' },
ExpressionAttributeValues: {
':account': 'ACC-12345',
':type': 'deposit',
':year': '2023'
}
}));
```
## Esempio completo
L'esempio seguente illustra le chiavi con più attributi dalla configurazione alla pulizia:
### esempio di codice
```
import {
DynamoDBClient,
CreateTableCommand,
DeleteTableCommand,
waitUntilTableExists
} from "@aws-sdk/client-dynamodb";
import {
DynamoDBDocumentClient,
PutCommand,
QueryCommand
} from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
async function multiAttributeKeysDemo() {
console.log("Starting Multi-Attribute GSI Keys Demo\n");
// Step 1: Create table with GSIs using multi-attribute keys
console.log("1. Creating table with multi-attribute GSI keys...");
await client.send(new CreateTableCommand({
TableName: 'TournamentMatches',
KeySchema: [
{ AttributeName: 'matchId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'matchId', AttributeType: 'S' },
{ AttributeName: 'tournamentId', AttributeType: 'S' },
{ AttributeName: 'region', AttributeType: 'S' },
{ AttributeName: 'round', AttributeType: 'S' },
{ AttributeName: 'bracket', AttributeType: 'S' },
{ AttributeName: 'player1Id', AttributeType: 'S' },
{ AttributeName: 'matchDate', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'TournamentRegionIndex',
KeySchema: [
{ AttributeName: 'tournamentId', KeyType: 'HASH' },
{ AttributeName: 'region', KeyType: 'HASH' },
{ AttributeName: 'round', KeyType: 'RANGE' },
{ AttributeName: 'bracket', KeyType: 'RANGE' },
{ AttributeName: 'matchId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'PlayerMatchHistoryIndex',
KeySchema: [
{ AttributeName: 'player1Id', KeyType: 'HASH' },
{ AttributeName: 'matchDate', KeyType: 'RANGE' },
{ AttributeName: 'round', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}));
await waitUntilTableExists({ client, maxWaitTime: 120 }, { TableName: 'TournamentMatches' });
console.log("Table created\n");
// Step 2: Insert tournament matches
console.log("2. Inserting tournament matches...");
const matches = [
{ matchId: 'match-001', tournamentId: 'WINTER2024', region: 'NA-EAST', round: 'FINALS', bracket: 'CHAMPIONSHIP', player1Id: '101', player2Id: '103', matchDate: '2024-01-20', winner: '101', score: '3-1' },
{ matchId: 'match-002', tournamentId: 'WINTER2024', region: 'NA-EAST', round: 'SEMIFINALS', bracket: 'UPPER', player1Id: '101', player2Id: '105', matchDate: '2024-01-18', winner: '101', score: '3-2' },
{ matchId: 'match-003', tournamentId: 'WINTER2024', region: 'NA-WEST', round: 'FINALS', bracket: 'CHAMPIONSHIP', player1Id: '102', player2Id: '104', matchDate: '2024-01-20', winner: '102', score: '3-2' },
{ matchId: 'match-004', tournamentId: 'SPRING2024', region: 'NA-EAST', round: 'QUARTERFINALS', bracket: 'UPPER', player1Id: '101', player2Id: '108', matchDate: '2024-03-15', winner: '101', score: '3-0' }
];
for (const match of matches) {
await docClient.send(new PutCommand({ TableName: 'TournamentMatches', Item: match }));
}
console.log(`Inserted ${matches.length} tournament matches\n`);
// Step 3: Query GSI with multi-attribute partition key
console.log("3. Query TournamentRegionIndex GSI: WINTER2024/NA-EAST matches");
const gsiQuery1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region',
ExpressionAttributeNames: { '#region': 'region' },
ExpressionAttributeValues: { ':tournament': 'WINTER2024', ':region': 'NA-EAST' }
}));
console.log(` Found ${gsiQuery1.Items.length} matches:`);
gsiQuery1.Items.forEach(match => {
console.log(` ${match.round} - ${match.bracket} - ${match.winner} won`);
});
// Step 4: Query GSI with multi-attribute sort key
console.log("\n4. Query PlayerMatchHistoryIndex GSI: All matches for Player 101");
const gsiQuery2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player',
ExpressionAttributeValues: { ':player': '101' }
}));
console.log(` Found ${gsiQuery2.Items.length} matches for Player 101:`);
gsiQuery2.Items.forEach(match => {
console.log(` ${match.tournamentId}/${match.region} - ${match.matchDate} - ${match.round}`);
});
console.log("\nDemo complete");
console.log("No synthetic keys needed - GSIs use native attributes automatically");
}
async function cleanup() {
console.log("Deleting table...");
await client.send(new DeleteTableCommand({ TableName: 'TournamentMatches' }));
console.log("Table deleted");
}
// Run demo
multiAttributeKeysDemo().catch(console.error);
// Uncomment to cleanup:
// cleanup().catch(console.error);
```
**Scaffold di codice minimo**
### esempio di codice
```
// 1. Create table with GSI using multi-attribute keys
await client.send(new CreateTableCommand({
TableName: 'MyTable',
KeySchema: [
{ AttributeName: 'id', KeyType: 'HASH' } // Simple base table PK
],
AttributeDefinitions: [
{ AttributeName: 'id', AttributeType: 'S' },
{ AttributeName: 'attr1', AttributeType: 'S' },
{ AttributeName: 'attr2', AttributeType: 'S' },
{ AttributeName: 'attr3', AttributeType: 'S' },
{ AttributeName: 'attr4', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [{
IndexName: 'MyGSI',
KeySchema: [
{ AttributeName: 'attr1', KeyType: 'HASH' }, // GSI PK attribute 1
{ AttributeName: 'attr2', KeyType: 'HASH' }, // GSI PK attribute 2
{ AttributeName: 'attr3', KeyType: 'RANGE' }, // GSI SK attribute 1
{ AttributeName: 'attr4', KeyType: 'RANGE' } // GSI SK attribute 2
],
Projection: { ProjectionType: 'ALL' }
}],
BillingMode: 'PAY_PER_REQUEST'
}));
// 2. Insert items with native attributes (no concatenation needed for GSI)
await docClient.send(new PutCommand({
TableName: 'MyTable',
Item: {
id: 'item-001',
attr1: 'value1',
attr2: 'value2',
attr3: 'value3',
attr4: 'value4',
// ... other attributes
}
}));
// 3. Query GSI with all partition key attributes
await docClient.send(new QueryCommand({
TableName: 'MyTable',
IndexName: 'MyGSI',
KeyConditionExpression: 'attr1 = :v1 AND attr2 = :v2',
ExpressionAttributeValues: {
':v1': 'value1',
':v2': 'value2'
}
}));
// 4. Query GSI with sort key attributes (left-to-right)
await docClient.send(new QueryCommand({
TableName: 'MyTable',
IndexName: 'MyGSI',
KeyConditionExpression: 'attr1 = :v1 AND attr2 = :v2 AND attr3 = :v3',
ExpressionAttributeValues: {
':v1': 'value1',
':v2': 'value2',
':v3': 'value3'
}
}));
// Note: If any attribute name is a DynamoDB reserved keyword, use ExpressionAttributeNames:
// KeyConditionExpression: 'attr1 = :v1 AND #attr2 = :v2'
// ExpressionAttributeNames: { '#attr2': 'attr2' }
```
## Risorse aggiuntive
+ [Best practice per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html)
+ [Lavorare con tabelle e dati](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.html)
+ [Indici secondari globali](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html)
+ [Operazioni di interrogazione e scansione](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html)
# Gestione degli indici secondari globali in DynamoDB
In questa sezione viene descritto come creare, modificare ed eliminare indici secondari globali in Amazon DynamoDB.
**Topics**
+ [Creazione di una tabella con indici secondari globali](#GSI.Creating)
+ [Descrizione degli indici secondari globali su una tabella](#GSI.Describing)
+ [Aggiunta di un indice secondario globale a una tabella esistente](#GSI.OnlineOps.Creating)
+ [Eliminazione di un indice secondario globale](#GSI.OnlineOps.Deleting)
+ [Modifica di un indice secondario globale durante la creazione](#GSI.OnlineOps.Creating.Modify)
## Creazione di una tabella con indici secondari globali
Per creare una tabella con uno o più indici secondari globali, utilizza l'operazione `CreateTable` con il parametro `GlobalSecondaryIndexes`. Per una massima flessibilità delle query, è possibile creare fino a 20 indici secondari globali (quota predefinita) per tabella.
Devi specificare un attributo che funga da chiave di partizione dell'indice. Facoltativamente, puoi specificare un altro attributo per la chiave di ordinamento dell'indice. Non è necessario che questi attributi di chiave coincidano con quelli della tabella. Ad esempio, nella *GameScores*tabella (vedi[Utilizzo degli indici secondari globali in DynamoDB](GSI.md)), `TopScore` né lo `TopScoreDateTime` sono gli attributi chiave. È possibile creare un indice secondario globale con una chiave di partizione `TopScore` e una chiave di ordinamento `TopScoreDateTime`. Puoi utilizzare questo indice per determinare se esiste una correlazione tra punteggi elevati e il periodo del giorno in cui si svolge un gioco.
Ogni attributo di chiave dell'indice deve essere uno scalare di tipo `String`, `Number` o `Binary` (non può essere un tipo documento o set). È possibile proiettare gli attributi di qualsiasi tipo di dati in un indice secondario globale. Questo include scalari, documenti e set. Per l'elenco completo dei tipi di dati, consulta [Tipi di dati](HowItWorks.NamingRulesDataTypes.md#HowItWorks.DataTypes).
Se utilizzi la modalità assegnata, devi specificare le impostazioni `ProvisionedThroughput` per l'indice, consistenti di `ReadCapacityUnits` e `WriteCapacityUnits`. Queste impostazioni di throughput assegnato sono distinte da quelle della tabella, ma il funzionamento è analogo. Per ulteriori informazioni, consulta [Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari globali](GSI.md#GSI.ThroughputConsiderations).
Gli indici secondari globali ereditano la modalità di read/write capacità dalla tabella di base. Per ulteriori informazioni, consulta [Considerazioni sul passaggio tra modalità di capacità in DynamoDB](bp-switching-capacity-modes.md).
**Nota**
Quando si crea un nuovo GSI, può essere importante verificare se la chiave di partizione scelta sta producendo una distribuzione irregolare o ristretta di dati o traffico attraverso i valori chiave della partizione del nuovo indice. In questo caso, è possibile che si verifichino operazioni di backfill e scrittura contemporaneamente e limitando le scritture nella tabella di base. Il servizio adotta misure per ridurre al minimo il potenziale di questo scenario, ma non ha alcuna visione della forma dei dati dei clienti in relazione alla chiave di partizione dell'indice, alla proiezione scelta o alla scarsità della chiave primaria dell'indice.
Se si sospetta che il nuovo indice secondario globale possa avere dati limitati o disallineati o distribuzione del traffico tra i valori chiave delle partizioni, considerare quanto segue prima di aggiungere nuovi indici alle tabelle di importanza operativa.
Potrebbe essere più sicuro aggiungere l'indice in un momento in cui l’applicazione guida la quantità minima di traffico.
Valuta la possibilità di abilitare CloudWatch Contributor Insights sulla tabella e sugli indici di base. Questo ti darà informazioni preziose sulla distribuzione del traffico.
Guarda `WriteThrottleEvents` e `OnlineIndexPercentageProgress` CloudWatch metriche `ThrottledRequests` durante tutto il processo. Adatta la capacità di scrittura assegnata in base alle esigenze per completare il backfill in un tempo ragionevole senza effetti di limitazione significativi sulle operazioni in corso. `OnlineIndexConsumedWriteCapacity`e `OnlineThrottleEvents` si prevede che mostrino 0 durante il riempimento dell'indice.
Preparatevi ad annullare la creazione dell'indice se doveste riscontrare un impatto operativo dovuto alla limitazione della scrittura.
## Descrizione degli indici secondari globali su una tabella
Per visualizzare lo stato di tutti gli indici secondari globali su una tabella, utilizza l'operazione `DescribeTable`. La parte `GlobalSecondaryIndexes` della risposta mostra tutti gli indici della tabella insieme allo stato corrente di ciascuno (`IndexStatus`).
`IndexStatus` per un indice secondario globale sarà uno dei seguenti:
+ `CREATING`: l'indice è in fase di creazione e non è ancora disponibile per l'uso.
+ `ACTIVE`: l'indice è pronto per l'uso e le applicazioni possono eseguire operazioni `Query` sull'indice.
+ `UPDATING`: vengono modificate le impostazioni di velocità effettiva assegnata dell'indice.
+ `DELETING`: l'indice è attualmente in fase di eliminazione e non può essere più utilizzato.
Quando DynamoDB ha terminato la creazione di un indice secondario globale, lo stato dell'indice cambia da `CREATING` a `ACTIVE`.
## Aggiunta di un indice secondario globale a una tabella esistente
Per aggiungere un indice secondario globale a una tabella esistente, utilizza l'operazione `UpdateTable` con il parametro `GlobalSecondaryIndexUpdates`. Devi specificare quanto segue:
+ Un nome per l'indice. Il nome deve essere univoco tra tutti gli indici della tabella.
+ Lo schema delle chiavi dell'indice. Devi specificare un attributo per la chiave di partizione dell'indice; opzionalmente, puoi specificare un altro attributo per la chiave di ordinamento dell'indice. Non è necessario che questi attributi di chiave coincidano con quelli della tabella. I tipi di dati per ogni attributo dello schema devono essere scalari: `String`, `Number` o `Binary`.
+ Gli attributi da proiettare dalla tabella all'indice:
+ `KEYS_ONLY`: ogni elemento dell'indice è costituito solo dalla chiave di partizione della tabella e dai valori della chiave di ordinamento, oltre ai valori della chiave di indice.
+ `INCLUDE`: oltre agli attributi descritti in `KEYS_ONLY`, l'indice secondario include gli altri attributi non chiave che sono stati specificati.
+ `ALL`: l'indice include tutti gli attributi della tabella di origine.
+ Le impostazioni di throughput assegnato dell'indice, consistenti di `ReadCapacityUnits` e `WriteCapacityUnits`. Queste impostazioni di throughput assegnato sono distinte da quelle della tabella.
È possibile creare un solo indice secondario globale per operazione `UpdateTable`.
### Fasi della creazione di un indice
Quando si aggiunge un nuovo indice secondario locale a una tabella esistente, mentre l'indice viene creato la tabella continua a essere disponibile. Tuttavia, il nuovo indice non è disponibile per le operazioni Query finché il suo stato non cambia da `CREATING` ad `ACTIVE`.
**Nota**
La creazione di un indice secondario globale non utilizza Application Auto Scaling. L’aumento della capacità di `MIN` Application Auto Scaling non diminuisce il tempo di creazione dell'indice secondario globale.
Dietro le quinte, DynamoDB crea l'indice in due fasi:
**Allocazione delle risorse**
DynamoDB alloca le risorse di calcolo e archiviazione necessarie per la creazione dell'indice.
Durante la fase di allocazione delle risorse, l'attributo `IndexStatus` è `CREATING` e l'attributo `Backfilling` è false. Utilizza l'operazione `DescribeTable` per recuperare lo stato di una tabella e di tutti i suoi indici secondari.
Mentre l'indice si trova nella fase di allocazione delle risorse, non puoi eliminare l'indice o la sua tabella padre. Inoltre, non puoi modificare il throughput assegnato dell'indice o della tabella. Non puoi aggiungere o eliminare altri indici nella tabella. Tuttavia, puoi modificare il throughput assegnato di questi altri indici.
**Compilazione**
Per ogni elemento nella tabella, DynamoDB determina quale set di attributi scrivere sull'indice in base alla relativa proiezione (`KEYS_ONLY`, `INCLUDE` o `ALL`). Procede quindi a scrivere questi attributi nell'indice. Durante la fase di backfill, DynamoDB tiene traccia degli elementi che vengono aggiunti, eliminati o aggiornati nella tabella. Anche gli attributi di questi item vengono aggiunti, eliminati o aggiornati nell'indice secondo il caso.
Durante la fase di compilazione, l'attributo `IndexStatus` è impostato su `CREATING` e l'attributo `Backfilling` è true. Utilizza l'operazione `DescribeTable` per recuperare lo stato di una tabella e di tutti i suoi indici secondari.
Mentre l'indice è in fase di compilazione, non puoi eliminare la tabella padre. Tuttavia, puoi comunque eliminare l'indice o modificare il throughput assegnato della tabella e di qualsiasi suoi indici secondari globali.
Nella fase di compilazione, alcune scritture di item in violazione possono riuscire mentre altre vengono rifiutate. Dopo la compilazione, tutte le scritture negli elementi che violano lo schema delle chiavi del nuovo indice vengono rifiutate. È consigliabile eseguire lo strumento Rilevamento violazioni alla fine della fase di backfill per rilevare e risolvere le eventuali violazioni delle chiavi che possono essersi verificate. Per ulteriori informazioni, consulta [Rilevamento e correzione delle violazioni delle chiavi in DynamoDB](GSI.OnlineOps.ViolationDetection.md).
Mentre le fasi di allocazione delle risorse e compilazione sono in corso, l'indice si trova nello stato `CREATING`. Durante questo periodo, DynamoDB esegue operazioni di lettura sulla tabella. Le operazioni di lettura dalla tabella di base per popolare l'indice secondario globale non vengono addebitate.
Quando la creazione è terminata, lo stato dell'indice diventa `ACTIVE`. Non puoi eseguire operazioni di `Query` o `Scan` dell'indice finché è `ACTIVE`.
**Nota**
In alcuni casi DynamoDB non è in grado di scrivere dati dalla tabella all'indice a causa di violazioni delle chiavi di indice. Ciò può verificarsi se:
Il tipo di dati di un valore di attributo non corrisponde al tipo di dati di un tipo di dati dello schema della chiave dell'indice.
La dimensione di un attributo supera la lunghezza massima di un attributo della chiave dell'indice.
Un attributo della chiave dell'indice ha un valore di attributo String vuoto o Binary vuoto.
Le violazioni delle chiavi dell'indice non interferiscono con la creazione di un indice secondario. Tuttavia, quando l'indice diventa `ACTIVE`, le chiavi in violazione non sono presenti nell'indice.
DynamoDB fornisce uno strumento autonomo per individuare e risolvere questi problemi. Per ulteriori informazioni, consulta [Rilevamento e correzione delle violazioni delle chiavi in DynamoDB](GSI.OnlineOps.ViolationDetection.md).
### Aggiunta di un indice secondario globale a una tabella di grandi dimensioni
Il tempo necessario per creare un indice secondario globale dipende da diversi fattori, tra cui:
+ Le dimensioni della tabella
+ Il numero di item nella tabella idonei per essere inclusi nell'indice
+ Il numero di attributi proiettati nell'indice
+ L'attività di scrittura sulla tabella principale durante la creazione dell'indice
Se si aggiunge un indice secondario globale a una tabella molto grande, il processo di creazione potrebbe richiedere molto tempo. Per monitorare l'avanzamento e determinare se l'indice ha una capacità di scrittura sufficiente, consulta i seguenti CloudWatch parametri di Amazon:
+ `OnlineIndexPercentageProgress`
Per ulteriori informazioni sulle CloudWatch metriche relative a DynamoDB, vedere. [Parametri di DynamoDB](metrics-dimensions.md#dynamodb-metrics)
**Importante**
Potrebbe essere necessario consentire l’inserimento di tabelle molto grandi prima di creare o aggiornare un indice secondario globale. Contatta l' AWS assistenza per inserire i tuoi tavoli nella lista dei preferiti.
Durante il backfill di un indice, DynamoDB utilizza la capacità interna del sistema per leggere dalla tabella. Ciò ha lo scopo di ridurre al minimo l'impatto della creazione dell'indice e di assicurare che la tabella non esaurisca la capacità di lettura.
## Eliminazione di un indice secondario globale
Se l'indice secondario globale non è più necessario, è possibile eliminarlo utilizzando l'operazione `UpdateTable`.
È possibile eliminare un solo indice secondario globale per operazione `UpdateTable`.
Mentre l'indice secondario globale viene eliminato, non vi sono effetti sull'attività di lettura o scrittura nella tabella padre. Durante l'eliminazione è comunque possibile modificare il throughput assegnato di altri indici.
**Nota**
Quando elimini una tabella utilizzando l'operazione `DeleteTable`, vengono eliminati anche tutti gli indici secondari globali della tabella.
L'operazione di eliminazione dell'indice secondario globale non verrà addebitata sul tuo account.
## Modifica di un indice secondario globale durante la creazione
Nel corso della creazione di un indice puoi utilizzare l'operazione `DescribeTable` per determinare in quale fase si trova. La descrizione dell'indice include un attributo booleano, `Backfilling`, che indica se DynamoDB sta attualmente caricando l'indice con elementi della tabella. Se `Backfilling` è true, la fase di allocazione delle risorse è terminata ed è in corso la compilazione dell'indice.
Durante la fase di compilazione, puoi eliminare l'indice in corso di creazione. Durante questa fase, non puoi aggiungere o eliminare altri indici nella tabella.
**Nota**
Per gli indici creati nell'ambito di un'operazione `CreateTable`, l'attributo `Backfilling` non compare nell'output di `DescribeTable`. Per ulteriori informazioni, consulta [Fasi della creazione di un indice](#GSI.OnlineOps.Creating.Phases).
# Rilevamento e correzione delle violazioni delle chiavi in DynamoDB
Durante la fase di backfill della creazione dell'indice secondario globale, Amazon DynamoDB esamina ogni elemento nella tabella per determinare se è idoneo all'inclusione nell'indice. Alcuni elementi potrebbero non essere idonei perché causerebbero violazioni della chiave dell'indice. In questi casi, gli elementi rimangono nella tabella, ma l'indice non ha una voce corrispondente per tale elemento.
Una *violazione della chiave di indice* si verifica nelle seguenti situazioni:
+ È presente una mancata corrispondenza del tipo di dati tra un valore di attributo e il tipo di dati dello schema della chiave dell'indice. Si supponga, ad esempio, che uno degli elementi nella tabella `GameScores` aveva un valore `TopScore` di tipo `String`. Se è stato aggiunto un indice secondario globale con una chiave di partizione di `TopScore`, di tipo `Number`, l'elemento della tabella violerebbe la chiave di indice.
+ Il valore di un attributo supera la lunghezza massima di un attributo della chiave dell'indice. La lunghezza massima di una chiave di partizione è 2048 byte e la lunghezza massima di una chiave di ordinamento è 1024 byte. Se uno qualsiasi dei valori di attributo corrispondenti nella tabella supera questi limiti, l'elemento della tabella violerebbe la chiave di indice.
**Nota**
Se un valore di attributo String o Binary è impostato per un attributo utilizzato come chiave di indice, il valore dell'attributo deve avere una lunghezza maggiore di zero; in caso contrario, l'elemento della tabella violerebbe la chiave di indice.
Questo strumento non contrassegna questa violazione della chiave di indice, al momento.
Se si verifica una violazione della chiave di indice, la fase di backfill continua senza interruzioni. Tuttavia, gli elementi che violano non saranno inclusi nell'indice. Una volta completata la fase di backfill, tutte le scritture sugli elementi che violano lo schema delle chiavi del nuovo indice saranno rifiutate.
Per identificare e correggere i valori degli attributi in una tabella che violano una chiave di indice, utilizza lo strumento Rilevatore di violazioni. Per eseguire Rilevatore di violazioni, è necessario creare un file di configurazione che specifica il nome di una tabella da sottoporre a scansione, i nomi e i tipi di dati della chiave di partizione dell'indice secondario globale e della chiave di ordinamento e quali azioni intraprendere se vengono rilevate violazioni della chiave di indice. Rilevatore di violazioni può essere eseguito in una delle due diverse modalità:
+ **Modalità di rilevamento**: rileva le violazioni della chiave dell'indice. Utilizza la modalità di rilevamento per segnalare gli elementi della tabella che causerebbero violazioni chiave in un indice secondario globale. Facoltativamente, è possibile richiedere che questi elementi di tabella che violano vengano eliminati immediatamente quando vengono rilevati. L'output dalla modalità di rilevamento viene scritto in un file, che è possibile utilizzare per ulteriori analisi.
+ **Modalità di correzione**: correggere le violazioni della chiave di indice. In modalità di correzione, Rilevatore violazioni legge un file di input con lo stesso formato del file di output dalla modalità di rilevamento. La modalità di correzione legge i record dal file di input e, per ogni record, elimina o aggiorna gli elementi corrispondenti nella tabella. Se si sceglie di aggiornare gli elementi, è necessario modificare il file di input e impostare i valori appropriati per questi aggiornamenti.
## Download ed esecuzione di Rilevatore violazioni
Rilevatore violazioni è disponibile come file eseguibile Java Archive (`.jar`) e viene eseguito su computer Windows, macOS o Linux. Rilevatore violazioni richiede Java 1.7 (o versioni successive) e Apache Maven.
+ [Scarica il rilevatore di violazioni da GitHub](https://github.com/awslabs/dynamodb-online-index-violation-detector)
Seguire le istruzioni riportate nel file `README.md` per scaricare e installare Rilevatore violazioni tramite Maven.
Per avviare Rilevatore violazioni, passare alla directory dove è stato creato `ViolationDetector.java` ed immettere il comando seguente.
```
java -jar ViolationDetector.jar [options]
```
La riga di comando di Rilevatore violazioni accetta le seguenti opzioni:
+ `-h | --help`: stampa un riepilogo di utilizzo e le opzioni per Rilevatore violazioni.
+ `-p | --configFilePath` `value`: il nome completo di un file di configurazione di Rilevatore violazioni. Per ulteriori informazioni, consulta [File di configurazione di Rilevatore violazioni](#GSI.OnlineOps.ViolationDetection.ConfigFile).
+ `-t | --detect` `value`: rileva le violazioni della chiave di indice nella tabella e le scrive nel file di output di Rilevatore violazioni. Se il valore di questo parametro è impostato su `keep`, gli elementi con violazioni della chiave non vengono modificati. Se il valore è impostato su `delete`, gli elementi con violazioni della chiave vengono eliminati dalla tabella.
+ `-c | --correct` `value`: legge le violazioni della chiave di indice da un file di input ed esegue azioni correttive sugli elementi della tabella. Se il valore di questo parametro è impostato su `update`, gli elementi con violazioni della chiave vengono aggiornati con valori nuovi e che non violano. Se il valore è impostato su `delete`, gli elementi con violazioni della chiave vengono eliminati dalla tabella.
## File di configurazione di Rilevatore violazioni
Durante il runtime, lo strumento Rilevatore violazioni richiede un file di configurazione. I parametri di questo file determinano a quali risorse DynamoDB può accedere Rilevatore violazioni e la velocità effettiva assegnata che può utilizzare. Nella tabella seguente vengono descritti questi parametri.
****
| Nome del parametro | Description | Obbligatorio? |
| --- | --- | --- |
| `awsCredentialsFile` | Il nome completo di un file contenente le credenziali AWS . Il file delle credenziali deve avere il seguente formato: accessKey = access_key_id_goes_here
secretKey = secret_key_goes_here
| Sì |
| `dynamoDBRegion` | La AWS regione in cui risiede la tabella. Ad esempio: `us-west-2`. | Sì |
| `tableName` | Il nome della tabella DynamoDB da sottoporre a scansione. | Sì |
| `gsiHashKeyName` | Il nome della chiave della partizione dell'indice. | Sì |
| `gsiHashKeyType` | Il tipo di dati della chiave di partizione dell'indice, `String`, `Number` o `Binary`: `S \| N \| B` | Sì |
| `gsiRangeKeyName` | Il nome della chiave di ordinamento dell'indice. Non specificare questo parametro se l'indice dispone solo di una chiave primaria semplice (chiave di partizione). | No |
| `gsiRangeKeyType` | Il tipo di dati della chiave di ordinamento dell'indice, `String`, `Number` o `Binary`: `S \| N \| B` Non specificare questo parametro se l'indice dispone solo di una chiave primaria semplice (chiave di partizione). | No |
| `recordDetails` | Indica se scrivere i dettagli completi delle violazioni della chiave di indice nel file di output. Se impostato su `true` (impostazione predefinita), vengono riportate tutte le informazioni sugli elementi che violano. Se impostato su `false`, viene riportato solo il numero di violazioni. | No |
| `recordGsiValueInViolationRecord` | Indica se scrivere i valori delle chiavi di indice che violano nel file di output. Se impostato su `true` (impostazione predefinita), vengono riportati i valori chiave. Se impostato su `false` (impostazione predefinita), i valori chiave non vengono riportati. | No |
| `detectionOutputPath` | Il percorso completo del file di output di Rilevatore violazioni. Questo parametro supporta la scrittura in una directory locale o in Amazon Simple Storage Service (Amazon S3). Di seguito vengono mostrati gli esempi: `detectionOutputPath = ``//local/path/filename.csv` `detectionOutputPath = ``s3://bucket/filename.csv` Le informazioni nel file di output vengono visualizzate in formato CSV (valori separati da virgola). Se non si imposta `detectionOutputPath`, il file di output è denominato `violation_detection.csv`e viene scritto nella directory di lavoro corrente. | No |
| `numOfSegments` | Il numero di segmenti di scansione parallela da utilizzare quando Rilevatore violazioni esegue la scansione della tabella. Il valore predefinito è 1, che indica che la tabella viene scansionata in modo sequenziale. Se il valore è 2 o superiore, Rilevatore violazioni divide la tabella in tanti segmenti logici e un numero uguale di thread di scansione. L'impostazione massima per `numOfSegments` è 4.096.Per le tabelle più grandi, una scansione parallela è generalmente più veloce di una scansione sequenziale. Inoltre, se la tabella è abbastanza grande da estendersi su più partizioni, una scansione parallela distribuisce l'attività di lettura in modo uniforme su più partizioni.Per ulteriori informazioni sulle scansioni parallele in DynamoDB, consulta [Scansione parallela](Scan.md#Scan.ParallelScan). | No |
| `numOfViolations` | Il limite superiore delle violazioni della chiave di indice da scrivere nel file di output. Se impostato su `-1` (impostazione predefinita), viene scansionata l'intera tabella. Se impostato su un numero intero positivo, Rilevatore violazioni si interrompe dopo il rilevamento di tale numero di violazioni. | No |
| `numOfRecords` | Il numero di elementi nella tabella da sottoporre a scansione. Se impostato su -1 (impostazione predefinita), viene scansionata l'intera tabella. Se impostato su un numero intero positivo, Rilevatore violazioni si interrompe dopo la scansione di molti elementi nella tabella. | No |
| `readWriteIOPSPercent` | Regola la percentuale di unità di capacità di lettura assegnata utilizzate durante la scansione della tabella. I valori validi sono compresi tra `1` e `100`. Il valore predefinito (`25`) significa che Rilevatore violazioni non consumerà più del 25% della velocità effettiva di lettura assegnata della tabella. | No |
| `correctionInputPath` | Il percorso completo del file di output di correzione di Rilevatore violazioni. Se si esegue Rilevatore violazioni in modalità di correzione, il contenuto di questo file viene utilizzato per modificare o eliminare elementi di dati nella tabella che violano l'indice secondario globale. Il formato del file `correctionInputPath` è uguale a quello del file `detectionOutputPath`. Ciò consente di elaborare l'output dalla modalità di rilevamento come input in modalità di correzione. | No |
| `correctionOutputPath` | Il percorso completo del file di output di correzione di Rilevatore violazioni. Questo file viene creato solo se ci sono errori di aggiornamento. Questo parametro supporta la scrittura in una directory locale o su Amazon S3. Di seguito vengono mostrati gli esempi: `correctionOutputPath = ``//local/path/filename.csv` `correctionOutputPath = ``s3://bucket/filename.csv` Le informazioni nel file di output vengono visualizzate in formato CSV. Se non si imposta `correctionOutputPath`, il file di output è denominato `violation_update_errors.csv`e viene scritto nella directory di lavoro corrente. | No |
## Rilevamento
Per rilevare le violazioni della chiave di indice, utilizza Rilevatore violazioni con l'opzione `--detect` della riga di comando. Per mostrare come funziona questa opzione, si consideri la tabella `ProductCatalog`. Di seguito è riportato un elenco di elementi nella tabella. Sono visualizzati solo la chiave primaria (`Id`) e l'attributo `Price`.
****
| ID (chiave primaria) | Prezzo |
| --- | --- |
| 101 | 5 |
| 102 | 20 |
| 103 | 200 |
| 201 | 100 |
| 202 | 200 |
| 203 | 300 |
| 204 | 400 |
| 205 | 500 |
Tutti i valori per `Price` sono di tipo `Number`. Tuttavia, poiché DynamoDB è senza schemi, è possibile aggiungere un elemento con un `Price` non numerico. Ad esempio, si supponga di aggiungere un altro elemento alla tabella `ProductCatalog`.
****
| ID (chiave primaria) | Prezzo |
| --- | --- |
| 999 | "Hello" |
La tabella ha ora un totale di nove elementi.
A questo punto aggiungere un nuovo indice secondario globale alla tabella: `PriceIndex`. La chiave primaria di questo indice è una chiave di partizione, `Price`, che è di tipo `Number`. Dopo che l'indice è stato creato, conterrà otto elementi, ma la tabella `ProductCatalog` ne ha nove. La ragione di questa discrepanza è che il valore `"Hello"` è di tipo `String`, ma `PriceIndex` ha una chiave primaria di tipo `Number`. Il valore `String` viola la chiave dell'indice secondario globale, quindi non è presente nell'indice.
Per utilizzare Rilevatore violazioni in questo scenario, è innanzitutto necessario creare un file di configurazione come il seguente.
```
# Properties file for violation detection tool configuration.
# Parameters that are not specified will use default values.
awsCredentialsFile = /home/alice/credentials.txt
dynamoDBRegion = us-west-2
tableName = ProductCatalog
gsiHashKeyName = Price
gsiHashKeyType = N
recordDetails = true
recordGsiValueInViolationRecord = true
detectionOutputPath = ./gsi_violation_check.csv
correctionInputPath = ./gsi_violation_check.csv
numOfSegments = 1
readWriteIOPSPercent = 40
```
Quindi, è possibile eseguire Rilevatore violazioni come nell'esempio seguente.
```
$ java -jar ViolationDetector.jar --configFilePath config.txt --detect keep
Violation detection started: sequential scan, Table name: ProductCatalog, GSI name: PriceIndex
Progress: Items scanned in total: 9, Items scanned by this thread: 9, Violations found by this thread: 1, Violations deleted by this thread: 0
Violation detection finished: Records scanned: 9, Violations found: 1, Violations deleted: 0, see results at: ./gsi_violation_check.csv
```
Se il parametro di configurazione `recordDetails` è impostato su `true`, Rilevatore violazioni scrive i dettagli di ogni violazione nel file di output, come nell'esempio seguente.
```
Table Hash Key,GSI Hash Key Value,GSI Hash Key Violation Type,GSI Hash Key Violation Description,GSI Hash Key Update Value(FOR USER),Delete Blank Attributes When Updating?(Y/N)
999,"{""S"":""Hello""}",Type Violation,Expected: N Found: S,,
```
Il file di output è in formato CSV. La prima riga del file è un'intestazione, seguita da un record per elemento che viola la chiave di indice. I campi di questi record di violazione sono i seguenti:
+ **Chiave hash tabella**: il valore della chiave di partizione dell'elemento nella tabella.
+ **Chiave di intervallo tabella**: il valore della chiave di ordinamento dell'elemento nella tabella.
+ **Valore chiave hash GSI**: il valore della chiave di partizione dell'indice secondario globale.
+ **Tipo di violazione della chiave hash GSI**: `Type Violation` o `Size Violation`.
+ **Descrizione della violazione della chiave hash GSI**: la causa della violazione.
+ **Valore di aggiornamento della chiave hash GSI (PER UTENTE)**: in modalità di correzione, un nuovo valore fornito dall'utente per l'attributo.
+ **Valore chiave hash GSI**: il valore della chiave di ordinamento dell'indice secondario globale.
+ **Tipo di violazione della chiave di intervallo GSI**: `Type Violation` o `Size Violation`.
+ **Descrizione della violazione della chiave di intervallo GSI**: la causa della violazione.
+ **Valore di aggiornamento della chiave di intervallo GSI (PER UTENTE)**: in modalità di correzione, un nuovo valore fornito dall'utente per l'attributo.
+ **Elimina attributo vuoto durante l'aggiornamento (S/N)**: in modalità di correzione, determina se eliminare (S) o mantenere (N) l'elemento di violazione nella tabella, ma solo se uno dei seguenti campi è vuoto:
+ `GSI Hash Key Update Value(FOR USER)`
+ `GSI Range Key Update Value(FOR USER)`
Se uno di questi campi non è vuoto, allora `Delete Blank Attribute When Updating(Y/N)` non ha effetto.
**Nota**
Il formato dell'output può variare a seconda del file di configurazione e delle opzioni della riga di comando. Ad esempio, se la tabella ha una chiave primaria semplice (senza una chiave di ordinamento), nell'output non saranno presenti campi della chiave di ordinamento.
I record di violazione nel file potrebbero non essere ordinati.
## Correzione
Per correggere le violazioni della chiave di indice, utilizza Rilevatore violazioni con l'opzione `--correct` della riga di comando. In modalità di correzione, Rilevatore violazioni legge il file di input specificato dal parametro `correctionInputPath`. Il file ha lo stesso formato del file `detectionOutputPath`, in modo da poter utilizzare l'output del rilevamento come input per la correzione.
Rilevatore violazioni fornisce due modi diversi per correggere le violazioni della chiave di indice:
+ **Elimina le violazioni**: eliminare gli elementi della tabella che hanno valori di attributi che violano.
+ **Aggiorna violazioni**: aggiornare gli elementi della tabella, sostituendo gli attributi che violano con valori che non violano.
In entrambi i casi, è possibile utilizzare il file di output dalla modalità di rilevamento come input per la modalità di correzione.
Continuando con l'esempio `ProductCatalog`, si supponga di voler eliminare l'elemento che viola dalla tabella. A tale scopo, utilizza la seguente riga di comando.
```
$ java -jar ViolationDetector.jar --configFilePath config.txt --correct delete
```
A questo punto, verrà richiesto di confermare se desideri eliminare gli elementi che violano.
```
Are you sure to delete all violations on the table?y/n
y
Confirmed, will delete violations on the table...
Violation correction from file started: Reading records from file: ./gsi_violation_check.csv, will delete these records from table.
Violation correction from file finished: Violations delete: 1, Violations Update: 0
```
Ora sia `ProductCatalog` che `PriceIndex` hanno lo stesso numero di elementi.
# Utilizzo di indici secondari globali: Java
Puoi utilizzare l'API AWS SDK per Java Document per creare una tabella Amazon DynamoDB con uno o più indici secondari globali, descrivere gli indici sulla tabella ed eseguire query utilizzando gli indici.
Di seguito sono riportate le fasi comuni per le operazioni di tabella.
1. Creare un'istanza della classe `DynamoDB`.
1. Fornisci i parametri obbligatori e facoltativi per l'operazione creando gli oggetti di richiesta corrispondenti.
1. Chiama il metodo appropriato fornito dal client creato nella fase precedente.
**Topics**
+ [Creazione di una tabella con un indice secondario globale](#GSIJavaDocumentAPI.CreateTableWithIndex)
+ [Descrizione di una tabella con un indice secondario globale](#GSIJavaDocumentAPI.DescribeTableWithIndex)
+ [Esecuzione di query su un indice secondario globale](#GSIJavaDocumentAPI.QueryAnIndex)
+ [Esempio: indici secondari globali che utilizzano l'API del documento AWS SDK per Java](GSIJavaDocumentAPI.Example.md)
## Creazione di una tabella con un indice secondario globale
Puoi creare indici secondari globali al momento della creazione di una tabella. A tale scopo, utilizza `CreateTable` e fornisci le specifiche per uno o più indici secondari globali. Il seguente esempio di codice Java crea una tabella per contenere le informazioni sui dati meteo. La chiave di partizione è `Location` e la chiave di ordinamento è `Date`. Un indice secondario globale denominato `PrecipIndex` consente di accedere rapidamente ai dati delle precipitazioni di vari luoghi.
Di seguito sono riportate le fasi per creare una tabella con un indice secondario globale, utilizzando l'API documento di DynamoDB.
1. Creare un'istanza della classe `DynamoDB`.
1. Crea un'istanza della classe `CreateTableRequest` per fornire le informazioni della richiesta.
È necessario fornire il nome della tabella, la sua chiave primaria e i valori del throughput assegnato. Per l'indice secondario globale, è necessario fornire il nome dell'indice, le impostazioni di velocità effettiva assegnata, le definizioni degli attributi per la chiave di ordinamento dell'indice, lo schema della chiave per l'indice e la proiezione degli attributi.
1. Chiama il metodo `createTable` fornendo l'oggetto richiesta come parametro.
Il seguente esempio di codice Java mostra le fasi precedenti. Il codice crea una tabella (`WeatherData`) con un indice secondario globale (`PrecipIndex`). La chiave di partizione dell'indice è `Date` e la sua chiave di ordinamento è `Precipitation`. Tutti gli attributi della tabella vengono proiettati nell'indice. Gli utenti possono eseguire query su questo indice per ottenere dati sul meteo di una data specifica, ordinando facoltativamente i dati per quantità di precipitazioni.
Poiché `Precipitation` non è un attributo chiave per la tabella, non è obbligatorio. Tuttavia, item `WeatherData` senza `Precipitation` non vengono visualizzati in `PrecipIndex`.
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
// Attribute definitions
ArrayList attributeDefinitions = new ArrayList();
attributeDefinitions.add(new AttributeDefinition()
.withAttributeName("Location")
.withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition()
.withAttributeName("Date")
.withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition()
.withAttributeName("Precipitation")
.withAttributeType("N"));
// Table key schema
ArrayList tableKeySchema = new ArrayList();
tableKeySchema.add(new KeySchemaElement()
.withAttributeName("Location")
.withKeyType(KeyType.HASH)); //Partition key
tableKeySchema.add(new KeySchemaElement()
.withAttributeName("Date")
.withKeyType(KeyType.RANGE)); //Sort key
// PrecipIndex
GlobalSecondaryIndex precipIndex = new GlobalSecondaryIndex()
.withIndexName("PrecipIndex")
.withProvisionedThroughput(new ProvisionedThroughput()
.withReadCapacityUnits((long) 10)
.withWriteCapacityUnits((long) 1))
.withProjection(new Projection().withProjectionType(ProjectionType.ALL));
ArrayList indexKeySchema = new ArrayList();
indexKeySchema.add(new KeySchemaElement()
.withAttributeName("Date")
.withKeyType(KeyType.HASH)); //Partition key
indexKeySchema.add(new KeySchemaElement()
.withAttributeName("Precipitation")
.withKeyType(KeyType.RANGE)); //Sort key
precipIndex.setKeySchema(indexKeySchema);
CreateTableRequest createTableRequest = new CreateTableRequest()
.withTableName("WeatherData")
.withProvisionedThroughput(new ProvisionedThroughput()
.withReadCapacityUnits((long) 5)
.withWriteCapacityUnits((long) 1))
.withAttributeDefinitions(attributeDefinitions)
.withKeySchema(tableKeySchema)
.withGlobalSecondaryIndexes(precipIndex);
Table table = dynamoDB.createTable(createTableRequest);
System.out.println(table.getDescription());
```
È necessario attendere fino a quando DynamoDB crea la tabella e imposta lo stato su `ACTIVE`. Dopodiché, puoi iniziare a inserire item di dati nella tabella.
## Descrizione di una tabella con un indice secondario globale
Per ottenere informazioni sugli indici secondari globali in una tabella, utilizza `DescribeTable`. Puoi accedere al nome, allo schema della chiave e agli attributi proiettati di ciascun indice.
Di seguito sono riportate le fasi per accedere alle informazioni dell'indice secondario globale su una tabella.
1. Creare un'istanza della classe `DynamoDB`.
1. Crea un'istanza della classe `Table` per rappresentare l'indice con cui intendi lavorare.
1. Chiama il metodo `describe` per l'oggetto `Table`.
Il seguente esempio di codice Java mostra le fasi precedenti.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
Table table = dynamoDB.getTable("WeatherData");
TableDescription tableDesc = table.describe();
Iterator gsiIter = tableDesc.getGlobalSecondaryIndexes().iterator();
while (gsiIter.hasNext()) {
GlobalSecondaryIndexDescription gsiDesc = gsiIter.next();
System.out.println("Info for index "
+ gsiDesc.getIndexName() + ":");
Iterator kseIter = gsiDesc.getKeySchema().iterator();
while (kseIter.hasNext()) {
KeySchemaElement kse = kseIter.next();
System.out.printf("\t%s: %s\n", kse.getAttributeName(), kse.getKeyType());
}
Projection projection = gsiDesc.getProjection();
System.out.println("\tThe projection type is: "
+ projection.getProjectionType());
if (projection.getProjectionType().toString().equals("INCLUDE")) {
System.out.println("\t\tThe non-key projected attributes are: "
+ projection.getNonKeyAttributes());
}
}
```
## Esecuzione di query su un indice secondario globale
È possibile utilizzare l'operazione `Query` su un indice secondario globale quasi nello stesso modo in cui si esegue una `Query` su una tabella. È necessario specificare il nome dell'indice, i criteri di query per la chiave di partizione e di ordinamento dell'indice (se presente) e gli attributi da restituire. In questo esempio, l'indice è `PrecipIndex`, avente una chiave di partizione `Date` e una chiave di ordinamento `Precipitation`. La query di indice restituisce tutti i dati sul meteo di una data specifica in cui le precipitazioni sono maggiori di zero.
Di seguito sono riportati i passaggi per interrogare un indice secondario globale utilizzando l'API Document. AWS SDK per Java
1. Creare un'istanza della classe `DynamoDB`.
1. Crea un'istanza della classe `Table` per rappresentare l'indice con cui intendi lavorare.
1. Crea un'istanza della classe `Index` per l'indice su cui intendi eseguire una query.
1. Chiama il metodo `query` per l'oggetto `Index`.
Il nome di attributo `Date` è una parola riservata in DynamoDB. Pertanto, devi utilizzare un nome di attributo di espressione come segnaposto in `KeyConditionExpression`.
Il seguente esempio di codice Java mostra le fasi precedenti.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
Table table = dynamoDB.getTable("WeatherData");
Index index = table.getIndex("PrecipIndex");
QuerySpec spec = new QuerySpec()
.withKeyConditionExpression("#d = :v_date and Precipitation = :v_precip")
.withNameMap(new NameMap()
.with("#d", "Date"))
.withValueMap(new ValueMap()
.withString(":v_date","2013-08-10")
.withNumber(":v_precip",0));
ItemCollection items = index.query(spec);
Iterator- iter = items.iterator();
while (iter.hasNext()) {
System.out.println(iter.next().toJSONPretty());
}
```
# Esempio: indici secondari globali che utilizzano l'API del documento AWS SDK per Java
Il seguente esempio di codice Java mostra come utilizzare gli indici secondari globali. L'esempio crea una tabella denominata `Issues`, che può essere utilizzata in un semplice sistema di tracciamento di bug per lo sviluppo di software. La chiave di partizione è `IssueId` e la chiave di ordinamento è `Title`. In questa tabella esistono tre indici secondari globali:
+ `CreateDateIndex`: la chiave di partizione è `CreateDate` e la chiave di ordinamento è `IssueId`. Oltre alle chiavi di tabella, vengono proiettati nell'indice gli attributi `Description` e `Status`.
+ `TitleIndex`: la chiave di partizione è `Title` e la chiave di ordinamento è `IssueId`. Non vengono proiettati nell'indice attributi diversi dalle chiavi di tabella.
+ `DueDateIndex`: la chiave di partizione è `DueDate`; non è presente una chiave di ordinamento. Tutti gli attributi della tabella vengono proiettati nell'indice.
Una volta creata la tabella `Issues`, il programma carica la tabella con i dati che rappresentano i report sui bug del software. Quindi esegue una query sui dati utilizzando gli indici secondari globali. Infine, il programma elimina la tabella `Issues`.
Per step-by-step istruzioni su come testare l'esempio seguente, vedere. [Esempi di codice Java](CodeSamples.Java.md)
**Example**
```
package com.amazonaws.codesamples.document;
import java.util.ArrayList;
import java.util.Iterator;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDB;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClientBuilder;
import com.amazonaws.services.dynamodbv2.document.DynamoDB;
import com.amazonaws.services.dynamodbv2.document.Index;
import com.amazonaws.services.dynamodbv2.document.Item;
import com.amazonaws.services.dynamodbv2.document.ItemCollection;
import com.amazonaws.services.dynamodbv2.document.QueryOutcome;
import com.amazonaws.services.dynamodbv2.document.Table;
import com.amazonaws.services.dynamodbv2.document.spec.QuerySpec;
import com.amazonaws.services.dynamodbv2.document.utils.ValueMap;
import com.amazonaws.services.dynamodbv2.model.AttributeDefinition;
import com.amazonaws.services.dynamodbv2.model.CreateTableRequest;
import com.amazonaws.services.dynamodbv2.model.GlobalSecondaryIndex;
import com.amazonaws.services.dynamodbv2.model.KeySchemaElement;
import com.amazonaws.services.dynamodbv2.model.KeyType;
import com.amazonaws.services.dynamodbv2.model.Projection;
import com.amazonaws.services.dynamodbv2.model.ProvisionedThroughput;
public class DocumentAPIGlobalSecondaryIndexExample {
static AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
static DynamoDB dynamoDB = new DynamoDB(client);
public static String tableName = "Issues";
public static void main(String[] args) throws Exception {
createTable();
loadData();
queryIndex("CreateDateIndex");
queryIndex("TitleIndex");
queryIndex("DueDateIndex");
deleteTable(tableName);
}
public static void createTable() {
// Attribute definitions
ArrayList attributeDefinitions = new ArrayList();
attributeDefinitions.add(new AttributeDefinition().withAttributeName("IssueId").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("Title").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("CreateDate").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("DueDate").withAttributeType("S"));
// Key schema for table
ArrayList tableKeySchema = new ArrayList();
tableKeySchema.add(new KeySchemaElement().withAttributeName("IssueId").withKeyType(KeyType.HASH)); // Partition
// key
tableKeySchema.add(new KeySchemaElement().withAttributeName("Title").withKeyType(KeyType.RANGE)); // Sort
// key
// Initial provisioned throughput settings for the indexes
ProvisionedThroughput ptIndex = new ProvisionedThroughput().withReadCapacityUnits(1L)
.withWriteCapacityUnits(1L);
// CreateDateIndex
GlobalSecondaryIndex createDateIndex = new GlobalSecondaryIndex().withIndexName("CreateDateIndex")
.withProvisionedThroughput(ptIndex)
.withKeySchema(new KeySchemaElement().withAttributeName("CreateDate").withKeyType(KeyType.HASH), // Partition
// key
new KeySchemaElement().withAttributeName("IssueId").withKeyType(KeyType.RANGE)) // Sort
// key
.withProjection(
new Projection().withProjectionType("INCLUDE").withNonKeyAttributes("Description", "Status"));
// TitleIndex
GlobalSecondaryIndex titleIndex = new GlobalSecondaryIndex().withIndexName("TitleIndex")
.withProvisionedThroughput(ptIndex)
.withKeySchema(new KeySchemaElement().withAttributeName("Title").withKeyType(KeyType.HASH), // Partition
// key
new KeySchemaElement().withAttributeName("IssueId").withKeyType(KeyType.RANGE)) // Sort
// key
.withProjection(new Projection().withProjectionType("KEYS_ONLY"));
// DueDateIndex
GlobalSecondaryIndex dueDateIndex = new GlobalSecondaryIndex().withIndexName("DueDateIndex")
.withProvisionedThroughput(ptIndex)
.withKeySchema(new KeySchemaElement().withAttributeName("DueDate").withKeyType(KeyType.HASH)) // Partition
// key
.withProjection(new Projection().withProjectionType("ALL"));
CreateTableRequest createTableRequest = new CreateTableRequest().withTableName(tableName)
.withProvisionedThroughput(
new ProvisionedThroughput().withReadCapacityUnits((long) 1).withWriteCapacityUnits((long) 1))
.withAttributeDefinitions(attributeDefinitions).withKeySchema(tableKeySchema)
.withGlobalSecondaryIndexes(createDateIndex, titleIndex, dueDateIndex);
System.out.println("Creating table " + tableName + "...");
dynamoDB.createTable(createTableRequest);
// Wait for table to become active
System.out.println("Waiting for " + tableName + " to become ACTIVE...");
try {
Table table = dynamoDB.getTable(tableName);
table.waitForActive();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public static void queryIndex(String indexName) {
Table table = dynamoDB.getTable(tableName);
System.out.println("\n***********************************************************\n");
System.out.print("Querying index " + indexName + "...");
Index index = table.getIndex(indexName);
ItemCollection items = null;
QuerySpec querySpec = new QuerySpec();
if (indexName == "CreateDateIndex") {
System.out.println("Issues filed on 2013-11-01");
querySpec.withKeyConditionExpression("CreateDate = :v_date and begins_with(IssueId, :v_issue)")
.withValueMap(new ValueMap().withString(":v_date", "2013-11-01").withString(":v_issue", "A-"));
items = index.query(querySpec);
} else if (indexName == "TitleIndex") {
System.out.println("Compilation errors");
querySpec.withKeyConditionExpression("Title = :v_title and begins_with(IssueId, :v_issue)")
.withValueMap(
new ValueMap().withString(":v_title", "Compilation error").withString(":v_issue", "A-"));
items = index.query(querySpec);
} else if (indexName == "DueDateIndex") {
System.out.println("Items that are due on 2013-11-30");
querySpec.withKeyConditionExpression("DueDate = :v_date")
.withValueMap(new ValueMap().withString(":v_date", "2013-11-30"));
items = index.query(querySpec);
} else {
System.out.println("\nNo valid index name provided");
return;
}
Iterator
- iterator = items.iterator();
System.out.println("Query: printing results...");
while (iterator.hasNext()) {
System.out.println(iterator.next().toJSONPretty());
}
}
public static void deleteTable(String tableName) {
System.out.println("Deleting table " + tableName + "...");
Table table = dynamoDB.getTable(tableName);
table.delete();
// Wait for table to be deleted
System.out.println("Waiting for " + tableName + " to be deleted...");
try {
table.waitForDelete();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public static void loadData() {
System.out.println("Loading data into table " + tableName + "...");
// IssueId, Title,
// Description,
// CreateDate, LastUpdateDate, DueDate,
// Priority, Status
putItem("A-101", "Compilation error", "Can't compile Project X - bad version number. What does this mean?",
"2013-11-01", "2013-11-02", "2013-11-10", 1, "Assigned");
putItem("A-102", "Can't read data file", "The main data file is missing, or the permissions are incorrect",
"2013-11-01", "2013-11-04", "2013-11-30", 2, "In progress");
putItem("A-103", "Test failure", "Functional test of Project X produces errors", "2013-11-01", "2013-11-02",
"2013-11-10", 1, "In progress");
putItem("A-104", "Compilation error", "Variable 'messageCount' was not initialized.", "2013-11-15",
"2013-11-16", "2013-11-30", 3, "Assigned");
putItem("A-105", "Network issue", "Can't ping IP address 127.0.0.1. Please fix this.", "2013-11-15",
"2013-11-16", "2013-11-19", 5, "Assigned");
}
public static void putItem(
String issueId, String title, String description, String createDate, String lastUpdateDate, String dueDate,
Integer priority, String status) {
Table table = dynamoDB.getTable(tableName);
Item item = new Item().withPrimaryKey("IssueId", issueId).withString("Title", title)
.withString("Description", description).withString("CreateDate", createDate)
.withString("LastUpdateDate", lastUpdateDate).withString("DueDate", dueDate)
.withNumber("Priority", priority).withString("Status", status);
table.putItem(item);
}
}
```
# Utilizzo di indici secondari globali: .NET
Puoi utilizzare l'API di AWS SDK per .NET basso livello per creare una tabella Amazon DynamoDB con uno o più indici secondari globali, descrivere gli indici sulla tabella ed eseguire query utilizzando gli indici. Queste operazioni vengono mappate alle operazioni DynamoDB corrispondenti. Per ulteriori informazioni, consulta la [Documentazione di riferimento delle API di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/).
Di seguito sono riportate le operazioni comuni per le operazioni delle tabelle che utilizzano l'API di basso livello .NET.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Fornisci i parametri obbligatori e facoltativi per l'operazione creando gli oggetti di richiesta corrispondenti.
Ad esempio, creare un oggetto `CreateTableRequest` per creare una tabella e un oggetto `QueryRequest` per eseguire una query su una tabella o un indice.
1. Eseguire il metodo appropriato fornito dal client creato nella fase precedente.
**Topics**
+ [Creazione di una tabella con un indice secondario globale](#GSILowLevelDotNet.CreateTableWithIndex)
+ [Descrizione di una tabella con un indice secondario globale](#GSILowLevelDotNet.DescribeTableWithIndex)
+ [Esecuzione di query su un indice secondario globale](#GSILowLevelDotNet.QueryAnIndex)
+ [Esempio AWS SDK per .NET : indici secondari globali che utilizzano l'API di basso livello](GSILowLevelDotNet.Example.md)
## Creazione di una tabella con un indice secondario globale
Puoi creare indici secondari globali al momento della creazione di una tabella. A tale scopo, utilizza `CreateTable` e fornisci le specifiche per uno o più indici secondari globali. Il seguente esempio di codice C\$1 crea una tabella per contenere le informazioni sui dati meteo. La chiave di partizione è `Location` e la chiave di ordinamento è `Date`. Un indice secondario globale denominato `PrecipIndex` consente di accedere rapidamente ai dati delle precipitazioni di vari luoghi.
Di seguito sono riportate le fasi per creare una tabella con un indice secondario globale, utilizzando l'API di basso livello di DynamoDB.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Crea un'istanza della classe `CreateTableRequest` per fornire le informazioni della richiesta.
È necessario fornire il nome della tabella, la sua chiave primaria e i valori del throughput assegnato. Per l'indice secondario globale, è necessario fornire il nome dell'indice, le impostazioni di velocità effettiva assegnata, le definizioni degli attributi per la chiave di ordinamento dell'indice, lo schema della chiave per l'indice e la proiezione degli attributi.
1. Eseguire il metodo `CreateTable` fornendo l'oggetto della richiesta come parametro.
Il seguente esempio di codice C\$1 mostra le fasi precedenti. Il codice crea una tabella (`WeatherData`) con un indice secondario globale (`PrecipIndex`). La chiave di partizione dell'indice è `Date` e la sua chiave di ordinamento è `Precipitation`. Tutti gli attributi della tabella vengono proiettati nell'indice. Gli utenti possono eseguire query su questo indice per ottenere dati sul meteo di una data specifica, ordinando facoltativamente i dati per quantità di precipitazioni.
Poiché `Precipitation` non è un attributo chiave per la tabella, non è obbligatorio. Tuttavia, item `WeatherData` senza `Precipitation` non vengono visualizzati in `PrecipIndex`.
```
client = new AmazonDynamoDBClient();
string tableName = "WeatherData";
// Attribute definitions
var attributeDefinitions = new List()
{
{new AttributeDefinition{
AttributeName = "Location",
AttributeType = "S"}},
{new AttributeDefinition{
AttributeName = "Date",
AttributeType = "S"}},
{new AttributeDefinition(){
AttributeName = "Precipitation",
AttributeType = "N"}
}
};
// Table key schema
var tableKeySchema = new List()
{
{new KeySchemaElement {
AttributeName = "Location",
KeyType = "HASH"}}, //Partition key
{new KeySchemaElement {
AttributeName = "Date",
KeyType = "RANGE"} //Sort key
}
};
// PrecipIndex
var precipIndex = new GlobalSecondaryIndex
{
IndexName = "PrecipIndex",
ProvisionedThroughput = new ProvisionedThroughput
{
ReadCapacityUnits = (long)10,
WriteCapacityUnits = (long)1
},
Projection = new Projection { ProjectionType = "ALL" }
};
var indexKeySchema = new List {
{new KeySchemaElement { AttributeName = "Date", KeyType = "HASH"}}, //Partition key
{new KeySchemaElement{AttributeName = "Precipitation",KeyType = "RANGE"}} //Sort key
};
precipIndex.KeySchema = indexKeySchema;
CreateTableRequest createTableRequest = new CreateTableRequest
{
TableName = tableName,
ProvisionedThroughput = new ProvisionedThroughput
{
ReadCapacityUnits = (long)5,
WriteCapacityUnits = (long)1
},
AttributeDefinitions = attributeDefinitions,
KeySchema = tableKeySchema,
GlobalSecondaryIndexes = { precipIndex }
};
CreateTableResponse response = client.CreateTable(createTableRequest);
Console.WriteLine(response.CreateTableResult.TableDescription.TableName);
Console.WriteLine(response.CreateTableResult.TableDescription.TableStatus);
```
È necessario attendere fino a quando DynamoDB crea la tabella e imposta lo stato su `ACTIVE`. Dopodiché, puoi iniziare a inserire item di dati nella tabella.
## Descrizione di una tabella con un indice secondario globale
Per ottenere informazioni sugli indici secondari globali in una tabella, utilizza `DescribeTable`. Puoi accedere al nome, allo schema della chiave e agli attributi proiettati di ciascun indice.
Di seguito sono riportate le fasi per accedere alle informazioni dell'indice secondario globale per una tabella utilizzando l'API di basso livello .NET.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Eseguire il metodo `describeTable` fornendo l'oggetto della richiesta come parametro.
Crea un'istanza della classe `DescribeTableRequest` per fornire le informazioni della richiesta. Devi specificare il nome della tabella.
Il seguente esempio di codice C\$1 mostra le fasi precedenti.
**Example**
```
client = new AmazonDynamoDBClient();
string tableName = "WeatherData";
DescribeTableResponse response = client.DescribeTable(new DescribeTableRequest { TableName = tableName});
List globalSecondaryIndexes =
response.DescribeTableResult.Table.GlobalSecondaryIndexes;
// This code snippet will work for multiple indexes, even though
// there is only one index in this example.
foreach (GlobalSecondaryIndexDescription gsiDescription in globalSecondaryIndexes) {
Console.WriteLine("Info for index " + gsiDescription.IndexName + ":");
foreach (KeySchemaElement kse in gsiDescription.KeySchema) {
Console.WriteLine("\t" + kse.AttributeName + ": key type is " + kse.KeyType);
}
Projection projection = gsiDescription.Projection;
Console.WriteLine("\tThe projection type is: " + projection.ProjectionType);
if (projection.ProjectionType.ToString().Equals("INCLUDE")) {
Console.WriteLine("\t\tThe non-key projected attributes are: "
+ projection.NonKeyAttributes);
}
}
```
## Esecuzione di query su un indice secondario globale
È possibile utilizzare l'operazione `Query` su un indice secondario globale quasi nello stesso modo in cui si esegue una `Query` su una tabella. È necessario specificare il nome dell'indice, i criteri di query per la chiave di partizione e di ordinamento dell'indice (se presente) e gli attributi da restituire. In questo esempio, l'indice è `PrecipIndex`, avente una chiave di partizione `Date` e una chiave di ordinamento `Precipitation`. La query di indice restituisce tutti i dati sul meteo di una data specifica in cui le precipitazioni sono maggiori di zero.
Di seguito sono riportate le fasi per eseguire una query su un indice secondario globale utilizzando l'API di basso livello .NET.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Crea un'istanza della classe `QueryRequest` per fornire le informazioni della richiesta.
1. Eseguire il metodo `query` fornendo l'oggetto della richiesta come parametro.
Il nome di attributo `Date` è una parola riservata in DynamoDB. Pertanto, devi utilizzare un nome di attributo di espressione come segnaposto in `KeyConditionExpression`.
Il seguente esempio di codice C\$1 mostra le fasi precedenti.
**Example**
```
client = new AmazonDynamoDBClient();
QueryRequest queryRequest = new QueryRequest
{
TableName = "WeatherData",
IndexName = "PrecipIndex",
KeyConditionExpression = "#dt = :v_date and Precipitation > :v_precip",
ExpressionAttributeNames = new Dictionary {
{"#dt", "Date"}
},
ExpressionAttributeValues = new Dictionary {
{":v_date", new AttributeValue { S = "2013-08-01" }},
{":v_precip", new AttributeValue { N = "0" }}
},
ScanIndexForward = true
};
var result = client.Query(queryRequest);
var items = result.Items;
foreach (var currentItem in items)
{
foreach (string attr in currentItem.Keys)
{
Console.Write(attr + "---> ");
if (attr == "Precipitation")
{
Console.WriteLine(currentItem[attr].N);
}
else
{
Console.WriteLine(currentItem[attr].S);
}
}
Console.WriteLine();
}
```
# Esempio AWS SDK per .NET : indici secondari globali che utilizzano l'API di basso livello
Il seguente esempio di codice C\$1 mostra come utilizzare gli indici secondari globali. L'esempio crea una tabella denominata `Issues`, che può essere utilizzata in un semplice sistema di tracciamento di bug per lo sviluppo di software. La chiave di partizione è `IssueId` e la chiave di ordinamento è `Title`. In questa tabella esistono tre indici secondari globali:
+ `CreateDateIndex`: la chiave di partizione è `CreateDate` e la chiave di ordinamento è `IssueId`. Oltre alle chiavi di tabella, vengono proiettati nell'indice gli attributi `Description` e `Status`.
+ `TitleIndex`: la chiave di partizione è `Title` e la chiave di ordinamento è `IssueId`. Non vengono proiettati nell'indice attributi diversi dalle chiavi di tabella.
+ `DueDateIndex`: la chiave di partizione è `DueDate`; non è presente una chiave di ordinamento. Tutti gli attributi della tabella vengono proiettati nell'indice.
Una volta creata la tabella `Issues`, il programma carica la tabella con i dati che rappresentano i report sui bug del software. Quindi esegue una query sui dati utilizzando gli indici secondari globali. Infine, il programma elimina la tabella `Issues`.
Per step-by-step istruzioni su come testare il seguente esempio, vedere. [Esempi di codice .NET](CodeSamples.DotNet.md)
**Example**
```
using System;
using System.Collections.Generic;
using System.Linq;
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.DataModel;
using Amazon.DynamoDBv2.DocumentModel;
using Amazon.DynamoDBv2.Model;
using Amazon.Runtime;
using Amazon.SecurityToken;
namespace com.amazonaws.codesamples
{
class LowLevelGlobalSecondaryIndexExample
{
private static AmazonDynamoDBClient client = new AmazonDynamoDBClient();
public static String tableName = "Issues";
public static void Main(string[] args)
{
CreateTable();
LoadData();
QueryIndex("CreateDateIndex");
QueryIndex("TitleIndex");
QueryIndex("DueDateIndex");
DeleteTable(tableName);
Console.WriteLine("To continue, press enter");
Console.Read();
}
private static void CreateTable()
{
// Attribute definitions
var attributeDefinitions = new List()
{
{new AttributeDefinition {
AttributeName = "IssueId", AttributeType = "S"
}},
{new AttributeDefinition {
AttributeName = "Title", AttributeType = "S"
}},
{new AttributeDefinition {
AttributeName = "CreateDate", AttributeType = "S"
}},
{new AttributeDefinition {
AttributeName = "DueDate", AttributeType = "S"
}}
};
// Key schema for table
var tableKeySchema = new List() {
{
new KeySchemaElement {
AttributeName= "IssueId",
KeyType = "HASH" //Partition key
}
},
{
new KeySchemaElement {
AttributeName = "Title",
KeyType = "RANGE" //Sort key
}
}
};
// Initial provisioned throughput settings for the indexes
var ptIndex = new ProvisionedThroughput
{
ReadCapacityUnits = 1L,
WriteCapacityUnits = 1L
};
// CreateDateIndex
var createDateIndex = new GlobalSecondaryIndex()
{
IndexName = "CreateDateIndex",
ProvisionedThroughput = ptIndex,
KeySchema = {
new KeySchemaElement {
AttributeName = "CreateDate", KeyType = "HASH" //Partition key
},
new KeySchemaElement {
AttributeName = "IssueId", KeyType = "RANGE" //Sort key
}
},
Projection = new Projection
{
ProjectionType = "INCLUDE",
NonKeyAttributes = {
"Description", "Status"
}
}
};
// TitleIndex
var titleIndex = new GlobalSecondaryIndex()
{
IndexName = "TitleIndex",
ProvisionedThroughput = ptIndex,
KeySchema = {
new KeySchemaElement {
AttributeName = "Title", KeyType = "HASH" //Partition key
},
new KeySchemaElement {
AttributeName = "IssueId", KeyType = "RANGE" //Sort key
}
},
Projection = new Projection
{
ProjectionType = "KEYS_ONLY"
}
};
// DueDateIndex
var dueDateIndex = new GlobalSecondaryIndex()
{
IndexName = "DueDateIndex",
ProvisionedThroughput = ptIndex,
KeySchema = {
new KeySchemaElement {
AttributeName = "DueDate",
KeyType = "HASH" //Partition key
}
},
Projection = new Projection
{
ProjectionType = "ALL"
}
};
var createTableRequest = new CreateTableRequest
{
TableName = tableName,
ProvisionedThroughput = new ProvisionedThroughput
{
ReadCapacityUnits = (long)1,
WriteCapacityUnits = (long)1
},
AttributeDefinitions = attributeDefinitions,
KeySchema = tableKeySchema,
GlobalSecondaryIndexes = {
createDateIndex, titleIndex, dueDateIndex
}
};
Console.WriteLine("Creating table " + tableName + "...");
client.CreateTable(createTableRequest);
WaitUntilTableReady(tableName);
}
private static void LoadData()
{
Console.WriteLine("Loading data into table " + tableName + "...");
// IssueId, Title,
// Description,
// CreateDate, LastUpdateDate, DueDate,
// Priority, Status
putItem("A-101", "Compilation error",
"Can't compile Project X - bad version number. What does this mean?",
"2013-11-01", "2013-11-02", "2013-11-10",
1, "Assigned");
putItem("A-102", "Can't read data file",
"The main data file is missing, or the permissions are incorrect",
"2013-11-01", "2013-11-04", "2013-11-30",
2, "In progress");
putItem("A-103", "Test failure",
"Functional test of Project X produces errors",
"2013-11-01", "2013-11-02", "2013-11-10",
1, "In progress");
putItem("A-104", "Compilation error",
"Variable 'messageCount' was not initialized.",
"2013-11-15", "2013-11-16", "2013-11-30",
3, "Assigned");
putItem("A-105", "Network issue",
"Can't ping IP address 127.0.0.1. Please fix this.",
"2013-11-15", "2013-11-16", "2013-11-19",
5, "Assigned");
}
private static void putItem(
String issueId, String title,
String description,
String createDate, String lastUpdateDate, String dueDate,
Int32 priority, String status)
{
Dictionary item = new Dictionary();
item.Add("IssueId", new AttributeValue
{
S = issueId
});
item.Add("Title", new AttributeValue
{
S = title
});
item.Add("Description", new AttributeValue
{
S = description
});
item.Add("CreateDate", new AttributeValue
{
S = createDate
});
item.Add("LastUpdateDate", new AttributeValue
{
S = lastUpdateDate
});
item.Add("DueDate", new AttributeValue
{
S = dueDate
});
item.Add("Priority", new AttributeValue
{
N = priority.ToString()
});
item.Add("Status", new AttributeValue
{
S = status
});
try
{
client.PutItem(new PutItemRequest
{
TableName = tableName,
Item = item
});
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
private static void QueryIndex(string indexName)
{
Console.WriteLine
("\n***********************************************************\n");
Console.WriteLine("Querying index " + indexName + "...");
QueryRequest queryRequest = new QueryRequest
{
TableName = tableName,
IndexName = indexName,
ScanIndexForward = true
};
String keyConditionExpression;
Dictionary expressionAttributeValues = new Dictionary();
if (indexName == "CreateDateIndex")
{
Console.WriteLine("Issues filed on 2013-11-01\n");
keyConditionExpression = "CreateDate = :v_date and begins_with(IssueId, :v_issue)";
expressionAttributeValues.Add(":v_date", new AttributeValue
{
S = "2013-11-01"
});
expressionAttributeValues.Add(":v_issue", new AttributeValue
{
S = "A-"
});
}
else if (indexName == "TitleIndex")
{
Console.WriteLine("Compilation errors\n");
keyConditionExpression = "Title = :v_title and begins_with(IssueId, :v_issue)";
expressionAttributeValues.Add(":v_title", new AttributeValue
{
S = "Compilation error"
});
expressionAttributeValues.Add(":v_issue", new AttributeValue
{
S = "A-"
});
// Select
queryRequest.Select = "ALL_PROJECTED_ATTRIBUTES";
}
else if (indexName == "DueDateIndex")
{
Console.WriteLine("Items that are due on 2013-11-30\n");
keyConditionExpression = "DueDate = :v_date";
expressionAttributeValues.Add(":v_date", new AttributeValue
{
S = "2013-11-30"
});
// Select
queryRequest.Select = "ALL_PROJECTED_ATTRIBUTES";
}
else
{
Console.WriteLine("\nNo valid index name provided");
return;
}
queryRequest.KeyConditionExpression = keyConditionExpression;
queryRequest.ExpressionAttributeValues = expressionAttributeValues;
var result = client.Query(queryRequest);
var items = result.Items;
foreach (var currentItem in items)
{
foreach (string attr in currentItem.Keys)
{
if (attr == "Priority")
{
Console.WriteLine(attr + "---> " + currentItem[attr].N);
}
else
{
Console.WriteLine(attr + "---> " + currentItem[attr].S);
}
}
Console.WriteLine();
}
}
private static void DeleteTable(string tableName)
{
Console.WriteLine("Deleting table " + tableName + "...");
client.DeleteTable(new DeleteTableRequest
{
TableName = tableName
});
WaitForTableToBeDeleted(tableName);
}
private static void WaitUntilTableReady(string tableName)
{
string status = null;
// Let us wait until table is created. Call DescribeTable.
do
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
status = res.Table.TableStatus;
}
catch (ResourceNotFoundException)
{
// DescribeTable is eventually consistent. So you might
// get resource not found. So we handle the potential exception.
}
} while (status != "ACTIVE");
}
private static void WaitForTableToBeDeleted(string tableName)
{
bool tablePresent = true;
while (tablePresent)
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
}
catch (ResourceNotFoundException)
{
tablePresent = false;
}
}
}
}
}
```
# Utilizzo di indici secondari in DynamoDB con la AWS CLI
È possibile utilizzare la AWS CLI per creare una tabella Amazon DynamoDB con uno o più indici secondari globali, descrivere gli indici sulla tabella ed eseguire query utilizzando gli indici.
**Topics**
+ [Creazione di una tabella con un indice secondario globale](#GCICli.CreateTableWithIndex)
+ [Aggiunta di un indice secondario globale a una tabella esistente](#GCICli.CreateIndexAfterTable)
+ [Descrizione di una tabella con un indice secondario globale](#GCICli.DescribeTableWithIndex)
+ [Esecuzione di query su un indice secondario globale](#GCICli.QueryAnIndex)
## Creazione di una tabella con un indice secondario globale
Gli indici secondari globali possono essere creati al momento della creazione di una tabella. A tale scopo, utilizza il parametro `create-table` e fornire le specifiche per uno o più indici secondari globali. Nell'esempio seguente viene creata una tabella denominata `GameScores` con un indice secondario globale denominato `GameTitleIndex`. La tabella di base ha una chiave di partizione di `UserId` e una chiave di ordinamento di `GameTitle`, permettendo di trovare il miglior punteggio di un singolo utente per un gioco specifico in modo efficiente, mentre il GSI ha una chiave di partizione di `GameTitle` e una chiave di ordinamento di `TopScore`, permettendo di trovare rapidamente il punteggio più alto complessivo per un determinato gioco.
```
aws dynamodb create-table \
--table-name GameScores \
--attribute-definitions AttributeName=UserId,AttributeType=S \
AttributeName=GameTitle,AttributeType=S \
AttributeName=TopScore,AttributeType=N \
--key-schema AttributeName=UserId,KeyType=HASH \
AttributeName=GameTitle,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=10,WriteCapacityUnits=5 \
--global-secondary-indexes \
"[
{
\"IndexName\": \"GameTitleIndex\",
\"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
\"Projection\":{
\"ProjectionType\":\"INCLUDE\",
\"NonKeyAttributes\":[\"UserId\"]
},
\"ProvisionedThroughput\": {
\"ReadCapacityUnits\": 10,
\"WriteCapacityUnits\": 5
}
}
]"
```
È necessario attendere fino a quando DynamoDB crea la tabella e imposta lo stato su `ACTIVE`. Dopodiché, puoi iniziare a inserire item di dati nella tabella. È possibile utilizzare [describe-table](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/describe-table.html) per determinare lo stato di avanzamento della creazione della tabella.
## Aggiunta di un indice secondario globale a una tabella esistente
Gli indici secondari globali possono essere aggiunti o modificati anche dopo la creazione della tabella. A tale scopo, utilizza il parametro `update-table` e fornire le specifiche per uno o più indici secondari globali. Nell'esempio seguente viene utilizzato lo stesso schema dell'esempio precedente, ma si presuppone che la tabella sia già stata creata e che la GSI verrà aggiunta in seguito.
```
aws dynamodb update-table \
--table-name GameScores \
--attribute-definitions AttributeName=TopScore,AttributeType=N \
--global-secondary-index-updates \
"[
{
\"Create\": {
\"IndexName\": \"GameTitleIndex\",
\"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
\"Projection\":{
\"ProjectionType\":\"INCLUDE\",
\"NonKeyAttributes\":[\"UserId\"]
}
}
}
]"
```
## Descrizione di una tabella con un indice secondario globale
Per ottenere informazioni sugli indici secondari globali in una tabella, utilizza il parametro `describe-table`. Puoi accedere al nome, allo schema della chiave e agli attributi proiettati di ciascun indice.
```
aws dynamodb describe-table --table-name GameScores
```
## Esecuzione di query su un indice secondario globale
È possibile utilizzare l'operazione `query` su un indice secondario globale nello stesso modo in cui si esegue una `query` su una tabella. È necessario specificare il nome dell'indice, i criteri della query per la chiave di ordinamento dell'indice e gli attributi da restituire. In questo esempio, l'indice è `GameTitleIndex` e la chiave di ordinamento dell'indice è `GameTitle`.
Gli unici attributi restituiti sono quelli proiettati nell'indice. È possibile modificare questa query per selezionare anche attributi non chiave, ma ciò richiederebbe un'attività di recupero della tabella relativamente costosa. Per ulteriori informazioni sul recupero delle tabelle, consulta [Proiezioni di attributi](GSI.md#GSI.Projections).
```
aws dynamodb query --table-name GameScores\
--index-name GameTitleIndex \
--key-condition-expression "GameTitle = :v_game" \
--expression-attribute-values '{":v_game":{"S":"Alien Adventure"} }'
```
# Indici secondari locali
Alcune applicazioni devono eseguire query sui dati soltanto utilizzando la chiave primaria della tabella di base. Tuttavia, potrebbero esserci situazioni in cui una chiave di ordinamento alternativa sarebbe utile. Per dare all'applicazione una scelta di chiavi di ordinamento, è possibile creare uno o più indici secondari locali su una tabella Amazon DynamoDB ed emettere le richieste `Query` o `Scan` rispetto a questi indici.
**Topics**
+ [Scenario: Utilizzo di un indice secondario locale](#LSI.Scenario)
+ [Proiezioni di attributi](#LSI.Projections)
+ [Creazione di un indice secondario locale](#LSI.Creating)
+ [Lettura di dati da un indice secondario locale](#LSI.Reading)
+ [Scritture di elementi e indici secondari locali](#LSI.Writes)
+ [Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari locali](#LSI.ThroughputConsiderations)
+ [Considerazioni sull'archiviazione per indici secondari locali](#LSI.StorageConsiderations)
+ [Raccolte di elementi negli indici secondari locali](#LSI.ItemCollections)
+ [Utilizzo di indici secondari locali: Java](LSIJavaDocumentAPI.md)
+ [Utilizzo di indici secondari locali: .NET](LSILowLevelDotNet.md)
+ [Utilizzo di indici secondari locali nella AWS CLI di DynamoDB](LCICli.md)
## Scenario: Utilizzo di un indice secondario locale
Ad esempio, si consideri la tabella `Thread`. Questa tabella è utile per un'applicazione come [Forum di discussione AWS](https://forums.aws.amazon.com/). Il seguente diagramma mostra in che modo verrebbero organizzarti gli elementi nella tabella. Non tutti gli attributi vengono visualizzati.
![\[Tabella dei thread contenente un elenco di nomi dei forum, argomenti, ora dell'ultimo post e numero di risposte.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/LSI_01.png)
DynamoDB archivia tutti gli elementi con lo stesso valore della chiave di partizione in modo continuo. In questo esempio, dato un particolare `ForumName`, un'operazione `Query` potrebbe individuare immediatamente tutti i thread per quel forum. All'interno di un gruppo di elementi con lo stesso valore della chiave di partizione, gli elementi vengono ordinati in base al valore della chiave di ordinamento. Se la chiave di ordinamento (`Subject`) viene fornita anche nella query, DynamoDB può restringere i risultati restituiti, ad esempio restituendo tutti i thread nel forum "S3" che hanno un `Subject` che inizia con la lettera "a".
Alcune richieste potrebbero richiedere modelli di accesso ai dati più complessi. Ad esempio:
+ Quali thread del forum ottengono il maggior numero di visualizzazioni e risposte?
+ Quale thread in un particolare forum ha il maggior numero di messaggi?
+ Quanti thread sono stati pubblicati in un particolare forum in un determinato periodo di tempo?
Per rispondere a queste domande, l'operazione `Query` non sarebbe sufficiente. Con questa procedura, sarà necessario eseguire una `Scan` di tutta la tabella. Per una tabella con milioni di elementi, questa operazione consumerebbe una grande quantità di velocità effettiva di lettura assegnata e richiederebbe molto tempo per il completamento.
Tuttavia, è possibile specificare uno o più indici secondari locali su attributi non chiave, ad esempio `Replies` o `LastPostDateTime`.
Un *indice secondario locale* gestisce una chiave di ordinamento alternativa per un determinato valore della chiave di partizione. Un indice secondario locale contiene anche una copia di alcuni o tutti gli attributi della relativa tabella di base. È possibile specificare gli attributi proiettati nell'indice secondario locale quando si crea la tabella. I dati in un indice secondario locale sono organizzati in base alla stessa chiave di partizione della tabella di base ma con una chiave di ordinamento diversa. Ciò consente di accedere in modo efficiente agli elementi di dati in questa diversa dimensione. Per una maggiore flessibilità di query o scansione, è possibile creare un massimo di cinque indici secondari locali per tabella.
Supponiamo che un'applicazione debba trovare tutti i thread che sono stati pubblicati negli ultimi tre mesi in un particolare forum. Senza un indice secondario locale, l'applicazione dovrebbe eseguire la `Scan` dell'intera tabella `Thread` ed eliminare tutti i post che non erano nel periodo di tempo specificato. Con un indice secondario locale, un'operazione `Query`potrebbe usare `LastPostDateTime` come chiave di ordinamento e trovare rapidamente i dati.
Il seguente diagramma mostra un indice secondario locale denominato `LastPostIndex`. Si noti che la chiave di partizione è la stessa di quella della tabella `Thread`, ma la chiave di ordinamento è`LastPostDateTime`.
![\[LastPostIndex tabella contenente un elenco di nomi del forum, argomenti e ora dell'ultimo post.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/LSI_02.png)
Ciascun indice secondario locale deve soddisfare le seguenti condizioni:
+ La chiave di partizione deve essere la stessa della tabella di base.
+ La chiave di ordinamento deve essere costituita esattamente da un attributo scalare.
+ La chiave di ordinamento della tabella di base deve essere proiettata nell'indice, dove funzionerà da attributo non chiave.
In questo esempio, la chiave di partizione è `ForumName` e la chiave di ordinamento dell'indice secondario locale è `LastPostDateTime`. Inoltre, il valore della chiave di ordinamento dalla tabella di base (in questo esempio, `Subject`) viene proiettato nell'indice ma non fa parte della chiave di indice. Se un'applicazione ha bisogno di un elenco basato su `ForumName` e `LastPostDateTime`, può emettere una richiesta `Query` rispetto a `LastPostIndex`. I risultati della query sono ordinati per `LastPostDateTime` e possono essere restituiti in ordine crescente o decrescente. La query può applicare anche condizioni chiave, ad esempio restituendo solo gli elementi che dispongono di un `LastPostDateTime` entro un determinato lasso di tempo.
Ogni indice secondario locale contiene automaticamente le chiavi di partizione e ordinamento dalla relativa tabella di base; facoltativamente, è possibile proiettare gli attributi non chiave nell'indice. Quando si esegue una query sull'indice, DynamoDB può recuperare questi attributi proiettati in modo efficiente. Se si esegue una query sull'indice secondario locale, è possibile richiamare gli attributi che *non* sono proiettati sull'indice. DynamoDB recupera automaticamente questi attributi dalla tabella di base, ma a una latenza maggiore e con costi di velocità effettiva assegnata più elevati.
Per qualsiasi indice secondario locale, è possibile memorizzare fino a 10 GB di dati per ogni valore di chiave di partizione distinto. Questa figura include tutti gli elementi della tabella di base più tutti gli elementi degli indici, che hanno lo stesso valore della chiave di partizione. Per ulteriori informazioni, consulta [Raccolte di elementi negli indici secondari locali](#LSI.ItemCollections).
## Proiezioni di attributi
Con `LastPostIndex`, un'applicazione potrebbe usare `ForumName` e `LastPostDateTime` come criteri di query. Tuttavia, per richiamare eventuali altri attributi, DynamoDB deve eseguire ulteriori operazioni di lettura rispetto alla tabella `Thread`. Queste letture extra sono conosciute come *recuperi* e possono aumentare la quantità totale di velocità effettiva assegnata necessaria per una query.
Supponiamo di voler compilare una pagina web con un elenco di tutte le discussioni in «S3" e il numero di risposte per ogni thread, ordinate in base all'ultima risposta che inizia con la risposta più recente. date/time Per popolare questo elenco, sono necessari i seguenti attributi:
+ `Subject`
+ `Replies`
+ `LastPostDateTime`
Il modo più efficiente per interrogare questi dati e per evitare operazioni di recupero sarebbe quello di proiettare l'attributo `Replies` dalla tabella nell'indice secondario locale, come mostrato in questo diagramma.
![\[LastPostIndex tabella contenente un elenco di nomi del forum, orari degli ultimi post, argomenti e risposte.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/LSI_03.png)
Una *proiezione* è l'insieme di attributi copiato da una tabella in un indice secondario. La chiave di partizione e la chiave di ordinamento della tabella vengono sempre proiettati nell'indice; è possibile proiettare altri attributi per supportare i requisiti di query dell'applicazione. Quando si esegue una query su un indice, Amazon DynamoDB può accedere a qualsiasi attributo nella proiezione come se tali attributi fossero in una propria tabella.
Quando si crea un indice secondario, è necessario specificare gli attributi che saranno proiettati nell'indice. DynamoDB fornisce tre diverse opzioni per questo:
+ *KEYS\$1ONLY*: ogni elemento dell'indice è costituito solo dalla chiave di partizione della tabella e dai valori della chiave di ordinamento, oltre ai valori della chiave di indice. L'opzione `KEYS_ONLY` si traduce nell'indice secondario più piccolo possibile.
+ *INCLUDE*: oltre agli attributi descritti in `KEYS_ONLY`, l'indice secondario includerà gli altri attributi non chiave che sono stati specificati.
+ *ALL*: l'indice secondario include tutti gli attributi della tabella di origine. Poiché tutti i dati della tabella sono duplicati nell'indice, una proiezione `ALL` restituisce il più grande indice secondario possibile.
Nel diagramma precedente, l'attributo non chiave `Replies` è proiettato in `LastPostIndex`. Un'applicazione può interrogare `LastPostIndex` al posto della tabella `Thread` completa per popolare una pagina Web con`Subject`, `Replies` e `LastPostDateTime`. Se vengono richiesti altri attributi non chiave, DynamoDB dovrebbe recuperare tali attributi dalla tabella `Thread`.
Dal punto di vista di un'applicazione, il recupero di attributi aggiuntivi dalla tabella di base è automatico e trasparente, quindi non è necessario riscrivere alcuna logica dell'applicazione. Tuttavia, tale recupero può ridurre notevolmente il vantaggio in termini di prestazioni dell'utilizzo di un indice secondario locale.
Quando si scelgono gli attributi da proiettare in un indice secondario locale, è necessario considerare il compromesso tra i costi correlati alla velocità effettiva assegnata e costi di archiviazione:
+ Se è necessario accedere a pochi attributi con la latenza più bassa possibile, considerare la possibilità di proiettare solo quegli attributi in un indice secondario locale. Più piccolo è l'indice, minore è il costo per memorizzarlo e minori sono i costi di scrittura. Se sono presenti attributi che occasionalmente è necessario recuperare, il costo per la velocità effettiva assegnata potrebbe superare il costo a lungo termine della memorizzazione di tali attributi.
+ Se l'applicazione accede frequentemente ad alcuni attributi non chiave, è necessario considerare di proiettare quegli attributi in un indice secondario locale. I costi di archiviazione aggiuntivi per l'indice secondario locale compensano il costo di esecuzione di scansioni frequenti delle tabelle.
+ Se è necessario accedere alla maggior parte degli attributi non chiave su base frequente, è possibile proiettare questi attributi, o anche l'intera tabella di base, in un indice secondario locale. Ciò offre la massima flessibilità e il minor consumo di velocità effettiva assegnata, in quanto non sarebbe necessario eseguire alcun recupero. Tuttavia, i costi di archiviazione aumenteranno o addirittura raddoppieranno se verranno proiettati tutti gli attributi.
+ Se l'applicazione esegue di rado le query sulla tabella ma esegue molte scritture o aggiornamenti dei dati, considerare la possibilità di proiettare *KEYS\$1ONLY*. L'indice secondario locale avrebbe dimensioni minime e sarebbe comunque disponibile, se necessario, per l'attività di query.
## Creazione di un indice secondario locale
Per creare una tabella con uno o più indici secondari locali su una tabella, utilizza il parametro `LocalSecondaryIndexes` con l'operazione `CreateTable`. Gli indici secondari locali in una tabella vengono creati al momento della creazione della tabella. Quando si elimina una tabella, vengono eliminati anche tutti gli indici secondari locali della tabella.
È necessario specificare un attributo non chiave che funzioni da chiave di ordinamento dell'indice secondario locale. L'attributo scelto deve essere uno `String`, `Number` oppure `Binary` scalare. Altri tipi scalari, documento e set non sono consentiti. Per l'elenco completo dei tipi di dati, consulta [Tipi di dati](HowItWorks.NamingRulesDataTypes.md#HowItWorks.DataTypes).
**Importante**
Per le tabelle con gli indici secondari locali, esiste un limite di 10 GB per valore di chiave di partizione. Una tabella con indici secondari locali può memorizzare qualsiasi numero di elementi, a condizione che la dimensione totale per qualsiasi valore di una chiave di partizione non superi 10 GB. Per ulteriori informazioni, consulta [Limite delle dimensioni delle raccolte di elementi](#LSI.ItemCollections.SizeLimit).
È possibile proiettare gli attributi di qualsiasi tipo di dati in un indice secondario locale. Questo include scalari, documenti e set. Per l'elenco completo dei tipi di dati, consulta [Tipi di dati](HowItWorks.NamingRulesDataTypes.md#HowItWorks.DataTypes).
## Lettura di dati da un indice secondario locale
È possibile richiamare gli elementi da un indice secondario locale utilizzando le operazioni `Query` e `Scan`. Le operazioni `GetItem` e `BatchGetItem` non possono essere utilizzate su un indice secondario locale.
### Esecuzione di una query su un indice secondario locale
In una tabella DynamoDB, il valore combinato della chiave di partizione e della chiave di ordinamento per ogni elemento deve essere univoco. Tuttavia, in un indice secondario locale, il valore della chiave di ordinamento non deve essere univoco per un determinato valore di chiave di partizione. Se nell'indice secondario locale sono presenti più elementi con lo stesso valore della chiave di ordinamento, un'operazione `Query` restituisce tutti gli elementi che hanno lo stesso valore della chiave di partizione. Nella risposta, gli articoli corrispondenti non vengono restituiti in un ordine particolare.
È possibile eseguire una query su un indice secondario locale utilizzando letture a consistenza finale o fortemente coerenti. Per specificare il tipo di coerenza desiderato, utilizza il parametro `ConsistentRead` dell'operazione `Query`. Una lettura fortemente consistente da un indice secondario locale restituisce sempre gli ultimi valori aggiornati. Se la query deve recuperare attributi aggiuntivi dalla tabella di base, tali attributi saranno coerenti rispetto all'indice.
**Example**
Valuta i seguenti dati restituiti da una `Query` che richiede dati dai thread di discussione in un particolare forum.
```
{
"TableName": "Thread",
"IndexName": "LastPostIndex",
"ConsistentRead": false,
"ProjectionExpression": "Subject, LastPostDateTime, Replies, Tags",
"KeyConditionExpression":
"ForumName = :v_forum and LastPostDateTime between :v_start and :v_end",
"ExpressionAttributeValues": {
":v_start": {"S": "2015-08-31T00:00:00.000Z"},
":v_end": {"S": "2015-11-31T00:00:00.000Z"},
":v_forum": {"S": "EC2"}
}
}
```
In questa query:
+ DynamoDB accede a `LastPostIndex` utilizzando la chiave di partizione `ForumName` per individuare gli elementi dell'indice per "EC2". Tutti gli elementi dell'indice con questa chiave sono memorizzati l'uno accanto all'altro per il recupero rapido.
+ All'interno di questo forum, DynamoDB utilizza l'indice per cercare le chiavi che corrispondono alla condizione `LastPostDateTime` specificata.
+ Poiché l'attributo `Replies` viene proiettato nell'indice, DynamoDB è in grado di recuperare questo attributo senza utilizzare alcuna velocità effettiva assegnata aggiuntiva.
+ L'attributo `Tags` non viene proiettato nell'indice, quindi DynamoDB deve accedere alla tabella `Thread` e recuperare questo attributo.
+ I risultati vengono restituiti, ordinati per `LastPostDateTime`. Le voci dell'indice vengono ordinate in base al valore della chiave di partizione e quindi in base al valore della chiave di ordinamento e `Query` li restituisce nell'ordine in cui sono memorizzati. È possibile utilizzare il parametro `ScanIndexForward` per restituire i risultati in ordine decrescente.
Poiché l'attributo `Tags` non viene proiettato nell'indice secondario locale, DynamoDB deve consumare unità di capacità di lettura aggiuntive per recuperare questo attributo dalla tabella di base. Se è necessario eseguire spesso questa query, è necessario proiettare `Tags` in `LastPostIndex` per evitare il recupero dalla tabella di base. Tuttavia, se è necessario accedere a `Tags` solo occasionalmente, il costo di archiviazione aggiuntivo per la proiezione `Tags` nell'indice potrebbe non valere la pena.
### Scansione di un indice secondario locale
È possibile utilizzare l'operazione `Scan` per recuperare tutti i dati da un indice secondario globale. Devi fornire il nome della tabella di base e il nome dell'indice nella richiesta. Con un'operazione `Scan`, DynamoDB legge tutti i dati nell'indice e li restituisce all'applicazione. Inoltre puoi richiedere che vengano restituiti solo alcuni dati e che quelli rimanenti vengano eliminati. A questo scopo, utilizza il parametro `FilterExpression` dell'API `Scan`. Per ulteriori informazioni, consulta [Espressioni di filtro per la scansione](Scan.md#Scan.FilterExpression).
## Scritture di elementi e indici secondari locali
DynamoDB conserva automaticamente tutti gli indici secondari locali sincronizzati con le rispettive tabelle di base. Le applicazioni non scrivono mai direttamente in un indice. Tuttavia, è importante comprendere le implicazioni di come DynamoDB mantiene questi indici.
Quando si crea un indice secondario locale, viene specificato un attributo da utilizzare come chiave di ordinamento per l'indice. È inoltre possibile specificare un tipo di dati per tale attributo. Questo significa che ogni volta che si scrive un elemento nella tabella di base, se l'elemento definisce un attributo della chiave di indice, il relativo tipo deve corrispondere al tipo di dati dello schema della chiave di indice. Nel caso di `LastPostIndex`, la chiave di ordinamento `LastPostDateTime` nell'indice è definita come un tipo di dati `String`. Se si prova ad aggiungere un elemento alla tabella `Thread` e si specifica un tipo di dati diverso per `LastPostDateTime` (come `Number`), DynamoDB restituisce un `ValidationException` perché il tipo di dati non corrisponde.
Non è richiesta una one-to-one relazione tra gli elementi di una tabella di base e gli elementi di un indice secondario locale. In effetti, questo comportamento può essere vantaggioso per molte applicazioni.
Una tabella con molti indici secondari globali comporta costi maggiori per l'attività di scrittura rispetto alle tabelle con meno indici. Per ulteriori informazioni, consulta [Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari locali](#LSI.ThroughputConsiderations).
**Importante**
Per le tabelle con gli indici secondari locali, esiste un limite di 10 GB per valore di chiave di partizione. Una tabella con indici secondari locali può memorizzare qualsiasi numero di elementi, a condizione che la dimensione totale per qualsiasi valore di una chiave di partizione non superi 10 GB. Per ulteriori informazioni, consulta [Limite delle dimensioni delle raccolte di elementi](#LSI.ItemCollections.SizeLimit).
## Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari locali
Quando si crea una tabella in DynamoDB, vengono assegnate le unità di capacità di lettura e scrittura per il carico di lavoro previsto della tabella. Tale carico di lavoro include attività di lettura e scrittura sugli indici secondari locali della tabella.
Per visualizzare le tariffe correnti per la capacità di throughput assegnata, consulta [Prezzi di Amazon DynamoDB](https://aws.amazon.com/dynamodb/pricing).
### Unità di capacità in lettura
Quando si esegue una query su un indice secondario locale, il numero di unità di capacità di lettura utilizzate dipende dal modo in cui si accede ai dati.
Come per le query su una tabella, una query su un indice può utilizzare letture a consistenza finale o fortemente consistenti a seconda del valore di `ConsistentRead`. Una lettura fortemente consistente utilizza una unità di capacità di lettura mentre una lettura a consistenza finale ne consuma solo la metà. Pertanto, scegliendo letture a consistenza finale, è possibile ridurre i costi delle unità di capacità di lettura.
Per le query su un indice che richiedono solo chiavi di indice e attributi proiettati, DynamoDB calcola l'attività di lettura assegnata come avviene per le query sulle tabelle. L'unica differenza è che il calcolo si basa sulle dimensioni delle voci dell'indice, piuttosto che sulla dimensione dell'item nella tabella di base. Il numero di unità di capacità in lettura è la somma di tutte le dimensioni degli attributi proiettati di tutti gli elementi restituiti; il risultato viene quindi arrotondato al successivo limite di 4 KB. Per ulteriori informazioni sul modo in cui DynamoDB calcola l'uso della velocità effettiva assegnata, consulta [Modalità con capacità allocata di DynamoDB](provisioned-capacity-mode.md).
Per le query sugli indici che leggono gli attributi non proiettati sull'indice secondario locale, oltre a leggere gli attributi proiettati dall'indice DynamoDB deve recuperare tali attributi dalla tabella di base. Questi recuperi si verificano quando si includono attributi non proiettati nei parametri `Select` o `ProjectionExpression` dell'operazione `Query`. Il recupero causa una latenza aggiuntiva nelle risposte alle query e comporta anche un costo della velocità effettiva assegnata più elevato: oltre alle letture dall'indice secondario locale descritto in precedenza, vengono addebitate le unità di capacità di lettura per ogni elemento della tabella di base recuperato. Questo addebito è per la lettura di ogni elemento intero dalla tabella, non solo degli attributi richiesti.
La dimensione massima dei risultati restituiti da un'operazione `Query` è 1 MB. Sono incluse le dimensioni di tutti i nomi e i valori degli attributi in tutti gli elementi restituiti. Tuttavia, se una query su un indice secondario locale fa sì che DynamoDB recuperi gli attributi dell'elemento dalla tabella di base, la dimensione massima dei dati nei risultati potrebbe essere inferiore. In questo caso, la dimensione del risultato è la somma di:
+ La dimensione degli elementi corrispondenti nell'indice, arrotondata per eccesso ai 4 KB successivi.
+ La dimensione di ogni elemento corrispondente nella tabella di base, con ogni elemento arrotondato singolarmente ai 4 KB successivi.
Utilizzando questa formula, la dimensione massima dei risultati restituiti da un'operazione Query è comunque 1 MB.
Ad esempio, si consideri una tabella in cui la dimensione di ogni elemento è 300 byte. Su quella tabella è presente un indice secondario locale, ma solo 200 byte di ogni elemento vengono proiettati sull'indice. Si supponga adesso che venga eseguita una `Query` su questo indice, che la query richieda recuperi di tabella per ogni elemento e che la query restituisca 4 elementi. DynamoDB riassume quanto segue:
+ Dimensione degli elementi corrispondenti nell'indice: 200 byte × 4 elementi = 800 byte; questo valore viene quindi arrotondato a 4 KB.
+ Dimensione di ogni elemento corrispondente nella tabella di base: (300 byte, arrotondato a 4 KB) × 4 elementi = 16 KB.
La dimensione totale dei dati nel risultato è pertanto 20 KB.
### Unità di capacità in scrittura
Quando un elemento viene aggiunto, aggiornato o eliminato in una tabella, l'aggiornamento degli indici secondari locali utilizza le unità di capacità di scrittura assegnate per la tabella. Il costo totale della velocità effettiva assegnata per una scrittura è la somma delle unità di capacità di scrittura utilizzate scrivendo sulla tabella e di quelle utilizzate dall'aggiornamento degli indici secondari locali.
Il costo della scrittura di un elemento in un indice secondario locale dipende da diversi fattori:
+ Se scrivi un nuovo item nella tabella che definisce un attributo indicizzato o aggiorni un item esistente per definire un attributo indicizzato in precedenza non definito, è necessario eseguire un'operazione di scrittura per inserire l'item nell'indice.
+ Se un aggiornamento alla tabella modifica il valore di un attributo chiave indicizzato (da A a B), sono necessarie due scritture, una per eliminare l'elemento precedente dall'indice e un'altra per inserire il nuovo elemento nell'indice.
+ Se un item era presente nell'indice, ma una scrittura nella tabella ha causato la cancellazione dell'attributo indicizzato, è necessaria una scrittura per eliminare la proiezione dell'item precedente dall'indice.
+ Se un item non è presente nell'indice prima o dopo l'aggiornamento dell'item, non vi è alcun costo di scrittura aggiuntivo per l'indice.
Tutti questi fattori presuppongono che la dimensione di ciascun elemento nell'indice sia minore o uguale alla dimensione dell'elemento di 1 KB per il calcolo delle unità di capacità di scrittura. Le voci di indice più grandi richiedono unità di capacità in scrittura aggiuntive. È possibile ridurre al minimo i costi di scrittura considerando gli attributi che le query devono restituire e proiettando solo tali attributi nell'indice.
## Considerazioni sull'archiviazione per indici secondari locali
Quando un'applicazione scrive un elemento in una tabella, DynamoDB copia automaticamente il sottoinsieme di attributi corretto in qualsiasi indice secondario locale in cui devono essere presenti gli attributi. All' AWS account vengono addebitati i costi per la memorizzazione dell'elemento nella tabella di base e anche per l'archiviazione degli attributi in qualsiasi indice secondario locale di tale tabella.
La quantità di spazio utilizzata da un item dell'indice è la somma di quanto segue:
+ La dimensione in byte della chiave primaria della tabella di base (chiave di partizione e chiave di ordinamento)
+ La dimensione in byte dell'attributo della chiave di indicizzazione
+ La dimensione in byte degli attributi proiettati (se presenti)
+ 100 byte di sovraccarico per elemento dell'indice
Per stimare i requisiti di archiviazione per un indice secondario locale, è possibile stimare la dimensione media di un elemento nell'indice e quindi moltiplicarla per il numero di elementi nella tabella di base.
Se una tabella contiene un elemento in cui non è definito un attributo specifico, ma l'attributo è definito come una chiave di ordinamento dell'indice, DynamoDB non scrive alcun dato per tale elemento nell'indice.
## Raccolte di elementi negli indici secondari locali
**Nota**
In questa sezione vengono trattate solo le tabelle con indici secondari locali.
In DynamoDB, una *raccolta di elementi* è un gruppo di elementi in che hanno lo stesso valore della chiave di partizione in una tabella e in tutti gli indici secondari locali. Negli esempi utilizzati in tutta questa sezione, la chiave di partizione per la tabella `Thread` è `ForumName` e la chiave di partizione per `LastPostIndex` è anch'essa `ForumName`. Tutti gli elementi della tabella e dell'indice con lo stesso `ForumName` fanno parte della stessa raccolta di elementi. Ad esempio, nella tabella `Thread` e nell'indice secondario locale `LastPostIndex` esiste una raccolta di elementi per il forum `EC2` e una raccolta di elementi diversa per il forum `RDS`.
Il seguente diagramma mostra la raccolta di elementi per il forum `S3`.
![\[Una raccolta di elementi DynamoDB ed elementi di indici secondari locali che hanno lo stesso valore di chiave di partizione di S3.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/LSI_04.png)
In questo diagramma, la raccolta di elementi è costituita da tutti gli elementi in `Thread` e `LastPostIndex` dove il valore della chiave di partizione `ForumName` è "S3". Se nella tabella sono presenti altri indici secondari locali, tutti gli elementi in tali indici con `ForumName` uguale a "S3" fanno parte della raccolta di elementi.
È possibile utilizzare una delle seguenti operazioni in DynamoDB per restituire informazioni sulle raccolte di elementi:
+ `BatchWriteItem`
+ `DeleteItem`
+ `PutItem`
+ `UpdateItem`
+ `TransactWriteItems`
Ognuna di queste operazioni supporta il parametro `ReturnItemCollectionMetrics`. Quando si .imposta questo parametro su `SIZE`, è possibile visualizzare informazioni sulle dimensioni di ogni raccolta di elementi nell'indice.
**Example**
Di seguito è riportato un esempio dall'output di una operazione `UpdateItem` sulla tabella `Thread`, con `ReturnItemCollectionMetrics` impostato su `SIZE`. L'elemento che è stato aggiornato aveva un valore di `ForumName` pari a "EC2", quindi l'output include informazioni su tale raccolta di elementi.
```
{
ItemCollectionMetrics: {
ItemCollectionKey: {
ForumName: "EC2"
},
SizeEstimateRangeGB: [0.0, 1.0]
}
}
```
L'oggetto `SizeEstimateRangeGB` indica che la dimensione di questa raccolta di elementi è compresa tra 0 e 1 GB. DynamoDB aggiorna periodicamente questa stima delle dimensioni, quindi i numeri potrebbero essere diversi la volta successiva che l'elemento viene modificato.
### Limite delle dimensioni delle raccolte di elementi
La dimensione massima di qualsiasi raccolta di elementi per una tabella con uno o più indici secondari locali è di 10 GB. Ciò non si applica alle raccolte di elementi nelle tabelle senza indici secondari locali e non si applica alle raccolte di elementi negli indici secondari globali. Sono interessate solo le tabelle con uno o più indici secondari locali.
Se una raccolta di elementi supera il limite di 10 GB, DynamoDB potrebbe restituire `ItemCollectionSizeLimitExceededException` un elemento e l'utente potrebbe non essere in grado di aggiungere altri elementi alla raccolta di elementi o aumentare le dimensioni degli elementi presenti nella raccolta di elementi. Le operazioni di lettura e scrittura che riducono le dimensioni della raccolta di elementi sono ancora consentite. Gli elementi possono comunque essere aggiunti ad altre raccolte di elementi.
Per ridurre le dimensioni di una raccolta di elementi, è possibile procedere in uno dei seguenti modi:
+ Eliminare eventuali elementi non necessari con il valore della chiave di partizione in questione. Quando si eliminano questi elementi dalla tabella di base, DynamoDB rimuove anche tutte le voci di indice che hanno lo stesso valore della chiave di partizione.
+ Aggiorna gli elementi rimuovendo gli attributi o riducendo le dimensioni degli attributi. Se questi attributi sono proiettati su qualsiasi indice secondario locale, DynamoDB riduce anche la dimensione delle voci di indice corrispondenti.
+ Crea una nuova tabella con la stessa chiave di partizione e la stessa chiave di ordinamento, quindi sposta gli elementi dalla tabella precedente alla nuova tabella. Questo potrebbe essere un buon approccio se una tabella dispone di dati cronologici a cui si accede raramente. È possibile anche considerare l'archiviazione di questi dati della cronologia in Amazon Simple Storage Service (Amazon S3).
Quando la dimensione totale della raccolta di elementi scende al di sotto di 10 GB, è possibile aggiungere nuovamente elementi con lo stesso valore della chiave di partizione.
Come best practice, consigliamo di strumentalizzare l'applicazione in modo da monitorare le dimensioni delle raccolte di elementi. Un modo per farlo è impostare il parametro `ReturnItemCollectionMetrics` su `SIZE`ogni volta che si utilizza `BatchWriteItem`, `DeleteItem`, `PutItem` o `UpdateItem`. L'applicazione dovrebbe esaminare l'oggetto `ReturnItemCollectionMetrics` nell'output e registrare un messaggio di errore ogni volta che una raccolta di elementi supera un limite definito dall'utente (ad esempio, 8 GB). L'impostazione di un limite inferiore a 10 GB fornirebbe un sistema di avviso anticipato in modo da sapere che una raccolta di elementi si sta avvicinando al limite in tempo per intervenire.
### Raccolte di elementi e partizioni
In una tabella con uno o più indici secondari locali, ogni raccolta di elementi viene archiviata in una partizione. La dimensione totale di tale raccolta di elementi è limitata alla capacità di quella partizione: 10 GB. Per un'applicazione in cui il modello di dati include raccolte di elementi con dimensioni illimitate o in cui si potrebbe ragionevolmente aspettarsi che alcune raccolte di elementi crescano oltre i 10 GB in futuro, è consigliabile prendere in considerazione l'utilizzo di un indice secondario globale.
Progettare le applicazioni in modo che i dati della tabella siano distribuiti uniformemente tra valori distinti della chiave di partizione. Per le tabelle con indici secondari locali, le applicazioni non devono creare "hot spot" di attività di lettura e scrittura all'interno di una singola raccolta di elementi su una singola partizione.
# Utilizzo di indici secondari locali: Java
Puoi utilizzare l'API AWS SDK per Java Document per creare una tabella Amazon DynamoDB con uno o più indici secondari locali, descrivere gli indici sulla tabella ed eseguire query utilizzando gli indici.
Di seguito sono riportati i passaggi più comuni per le operazioni sulle tabelle utilizzando l'API Document. AWS SDK per Java
1. Creare un'istanza della classe `DynamoDB`.
1. Fornisci i parametri obbligatori e facoltativi per l'operazione creando gli oggetti di richiesta corrispondenti.
1. Chiama il metodo appropriato fornito dal client creato nella fase precedente.
**Topics**
+ [Creazione di una tabella con un indice secondario locale](#LSIJavaDocumentAPI.CreateTableWithIndex)
+ [Descrizione di una tabella con un indice secondario locale](#LSIJavaDocumentAPI.DescribeTableWithIndex)
+ [Esecuzione di query su un indice secondario locale](#LSIJavaDocumentAPI.QueryAnIndex)
+ [Esempio: indici secondari locali che utilizzano l'API del documento Java](LSIJavaDocumentAPI.Example.md)
## Creazione di una tabella con un indice secondario locale
Gli indici secondari locali devono essere creati al momento della creazione di una tabella. A tale scopo, utilizza il metodo `createTable` e fornire le specifiche per uno o più indici secondari locali. Il seguente esempio di codice Java crea una tabella per contenere le informazioni sui brani in una raccolta musicale. La chiave di partizione è `Artist` e la chiave di ordinamento è `SongTitle`. Un indice secondario, `AlbumTitleIndex`, facilita le query in base al titolo dell'album.
Di seguito sono riportate le operazioni necessarie per creare una tabella con un indice secondario locale, utilizzando l'API documento di DynamoDB.
1. Creare un'istanza della classe `DynamoDB`.
1. Crea un'istanza della classe `CreateTableRequest` per fornire le informazioni della richiesta.
È necessario fornire il nome della tabella, la sua chiave primaria e i valori del throughput assegnato. Per l'indice secondario locale, è necessario fornire il nome dell'indice, il nome e il tipo di dati della chiave di ordinamento dell'indice, lo schema della chiave per l'indice e la proiezione degli attributi.
1. Chiama il metodo `createTable` fornendo l'oggetto richiesta come parametro.
Il seguente esempio di codice Java mostra le fasi precedenti. Il codice crea una tabella (`Music`) con un indice secondario sull'attributo `AlbumTitle`. La chiave di partizione e la chiave di ordinamento della tabella, più la chiave di ordinamento dell'indice, sono gli unici attributi proiettati sull'indice.
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
String tableName = "Music";
CreateTableRequest createTableRequest = new CreateTableRequest().withTableName(tableName);
//ProvisionedThroughput
createTableRequest.setProvisionedThroughput(new ProvisionedThroughput().withReadCapacityUnits((long)5).withWriteCapacityUnits((long)5));
//AttributeDefinitions
ArrayList attributeDefinitions= new ArrayList();
attributeDefinitions.add(new AttributeDefinition().withAttributeName("Artist").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("SongTitle").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("AlbumTitle").withAttributeType("S"));
createTableRequest.setAttributeDefinitions(attributeDefinitions);
//KeySchema
ArrayList tableKeySchema = new ArrayList();
tableKeySchema.add(new KeySchemaElement().withAttributeName("Artist").withKeyType(KeyType.HASH)); //Partition key
tableKeySchema.add(new KeySchemaElement().withAttributeName("SongTitle").withKeyType(KeyType.RANGE)); //Sort key
createTableRequest.setKeySchema(tableKeySchema);
ArrayList indexKeySchema = new ArrayList();
indexKeySchema.add(new KeySchemaElement().withAttributeName("Artist").withKeyType(KeyType.HASH)); //Partition key
indexKeySchema.add(new KeySchemaElement().withAttributeName("AlbumTitle").withKeyType(KeyType.RANGE)); //Sort key
Projection projection = new Projection().withProjectionType(ProjectionType.INCLUDE);
ArrayList nonKeyAttributes = new ArrayList();
nonKeyAttributes.add("Genre");
nonKeyAttributes.add("Year");
projection.setNonKeyAttributes(nonKeyAttributes);
LocalSecondaryIndex localSecondaryIndex = new LocalSecondaryIndex()
.withIndexName("AlbumTitleIndex").withKeySchema(indexKeySchema).withProjection(projection);
ArrayList localSecondaryIndexes = new ArrayList();
localSecondaryIndexes.add(localSecondaryIndex);
createTableRequest.setLocalSecondaryIndexes(localSecondaryIndexes);
Table table = dynamoDB.createTable(createTableRequest);
System.out.println(table.getDescription());
```
È necessario attendere fino a quando DynamoDB crea la tabella e imposta lo stato su `ACTIVE`. Dopodiché, puoi iniziare a inserire item di dati nella tabella.
## Descrizione di una tabella con un indice secondario locale
Per ottenere informazioni sugli indici secondari locali in una tabella, utilizza il metodo `describeTable`. Puoi accedere al nome, allo schema della chiave e agli attributi proiettati di ciascun indice.
Di seguito sono riportate le fasi per accedere alle informazioni sull'indice secondario locale di una tabella utilizzando l'API documento AWS SDK per Java .
1. Creare un'istanza della classe `DynamoDB`.
1. Creare un'istanza della classe `Table`. Devi specificare il nome della tabella.
1. Chiama il metodo `describeTable` per l'oggetto `Table`.
Il seguente esempio di codice Java mostra le fasi precedenti.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
String tableName = "Music";
Table table = dynamoDB.getTable(tableName);
TableDescription tableDescription = table.describe();
List localSecondaryIndexes
= tableDescription.getLocalSecondaryIndexes();
// This code snippet will work for multiple indexes, even though
// there is only one index in this example.
Iterator lsiIter = localSecondaryIndexes.iterator();
while (lsiIter.hasNext()) {
LocalSecondaryIndexDescription lsiDescription = lsiIter.next();
System.out.println("Info for index " + lsiDescription.getIndexName() + ":");
Iterator kseIter = lsiDescription.getKeySchema().iterator();
while (kseIter.hasNext()) {
KeySchemaElement kse = kseIter.next();
System.out.printf("\t%s: %s\n", kse.getAttributeName(), kse.getKeyType());
}
Projection projection = lsiDescription.getProjection();
System.out.println("\tThe projection type is: " + projection.getProjectionType());
if (projection.getProjectionType().toString().equals("INCLUDE")) {
System.out.println("\t\tThe non-key projected attributes are: " + projection.getNonKeyAttributes());
}
}
```
## Esecuzione di query su un indice secondario locale
È possibile utilizzare l'operazione `Query` su un indice secondario locale nello stesso modo in cui si esegue una `Query` su una tabella. È necessario specificare il nome dell'indice, i criteri della query per la chiave di ordinamento dell'indice e gli attributi da restituire. In questo esempio, l'indice è `AlbumTitleIndex` e la chiave di ordinamento dell'indice è `AlbumTitle`.
Gli unici attributi restituiti sono quelli proiettati nell'indice. È possibile modificare questa query per selezionare anche attributi non chiave, ma ciò richiederebbe un'attività di recupero della tabella relativamente costosa. Per ulteriori informazioni sul recupero delle tabelle, consulta [Proiezioni di attributi](LSI.md#LSI.Projections).
Di seguito sono riportati i passaggi per interrogare un indice secondario locale utilizzando l'API AWS SDK per Java Document.
1. Creare un'istanza della classe `DynamoDB`.
1. Creare un'istanza della classe `Table`. Devi specificare il nome della tabella.
1. Creare un'istanza della classe `Index`. È necessario specificare il nome dell'indice.
1. Chiamare il metodo `query` della classe `Index`.
Il seguente esempio di codice Java mostra le fasi precedenti.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
String tableName = "Music";
Table table = dynamoDB.getTable(tableName);
Index index = table.getIndex("AlbumTitleIndex");
QuerySpec spec = new QuerySpec()
.withKeyConditionExpression("Artist = :v_artist and AlbumTitle = :v_title")
.withValueMap(new ValueMap()
.withString(":v_artist", "Acme Band")
.withString(":v_title", "Songs About Life"));
ItemCollection items = index.query(spec);
Iterator
- itemsIter = items.iterator();
while (itemsIter.hasNext()) {
Item item = itemsIter.next();
System.out.println(item.toJSONPretty());
}
```
### Letture coerenti su un indice secondario locale
A differenza degli indici secondari globali, che supportano solo letture alla fine coerenti, un indice secondario locale supporta sia letture sostanzialmente coerenti che fortemente coerenti. Una lettura fortemente consistente da un indice secondario locale restituisce sempre gli ultimi valori aggiornati. Se la query deve recuperare attributi aggiuntivi dalla tabella di base, tali attributi recuperati sono coerenti anche rispetto all'indice.
Per impostazione predefinita, `Query` utilizza alla fine letture coerenti. Per richiedere una lettura fortemente coerente, imposta `ConsistentRead` su `true` in. `QuerySpec` Il seguente esempio esegue una query `AlbumTitleIndex` utilizzando una lettura fortemente coerente:
**Example**
```
QuerySpec spec = new QuerySpec()
.withKeyConditionExpression("Artist = :v_artist and AlbumTitle = :v_title")
.withValueMap(new ValueMap()
.withString(":v_artist", "Acme Band")
.withString(":v_title", "Songs About Life"))
.withConsistentRead(true);
```
**Nota**
Una lettura altamente coerente consuma un'unità di capacità di lettura per 4 KB di dati restituiti (arrotondati per eccesso), mentre una lettura sostanzialmente coerente ne consuma la metà. Ad esempio, una lettura altamente coerente che restituisce 9 KB di dati consuma 3 unità di capacità di lettura (9 KB/ 4 KB = 2,25, arrotondato a 3), mentre la stessa query che utilizza una lettura sostanzialmente coerente consuma 1,5 unità di capacità di lettura. Se l'applicazione è in grado di tollerare la lettura di dati che potrebbero essere leggermente obsoleti, utilizzate eventuali letture coerenti per ridurre l'utilizzo della capacità di lettura. Per ulteriori informazioni, consulta [Unità di capacità in lettura](LSI.md#LSI.ThroughputConsiderations.Reads).
# Esempio: indici secondari locali che utilizzano l'API del documento Java
Il seguente esempio di codice Java mostra come utilizzare gli indici secondari globali in Amazon DynamoDB. Nell'esempio viene creata una tabella denominata `CustomerOrders` con una chiave di partizione `CustomerId` e una chiave di ordinamento `OrderId`. In questa tabella esistono due indici secondari locali:
+ `OrderCreationDateIndex`: la chiave di ordinamento è `OrderCreationDate` e i seguenti attributi sono proiettati sull'indice.
+ `ProductCategory`
+ `ProductName`
+ `OrderStatus`
+ `ShipmentTrackingId`
+ `IsOpenIndex`: la chiave di ordinamento è `IsOpen` e tutti gli attributi della tabella vengono proiettati nell'indice.
Una volta creata la tabella `CustomerOrders`, il programma carica la tabella con i dati che rappresentano gli ordini dei clienti. Quindi esegue una query sui dati utilizzando gli indici secondari locali. Infine, il programma elimina la tabella `CustomerOrders`.
Per step-by-step istruzioni su come testare il seguente esempio, vedere. [Esempi di codice Java](CodeSamples.Java.md)
**Example**
```
package com.example.dynamodb;
import software.amazon.awssdk.core.waiters.WaiterResponse;
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.*;
import software.amazon.awssdk.services.dynamodb.waiters.DynamoDbWaiter;
import java.util.HashMap;
import java.util.Map;
public class DocumentAPILocalSecondaryIndexExample {
static DynamoDbClient client = DynamoDbClient.create();
public static String tableName = "CustomerOrders";
public static void main(String[] args) {
createTable();
loadData();
query(null);
query("IsOpenIndex");
query("OrderCreationDateIndex");
deleteTable(tableName);
}
public static void createTable() {
CreateTableRequest request = CreateTableRequest.builder()
.tableName(tableName)
.provisionedThroughput(ProvisionedThroughput.builder()
.readCapacityUnits(1L)
.writeCapacityUnits(1L)
.build())
.attributeDefinitions(
AttributeDefinition.builder().attributeName("CustomerId").attributeType(ScalarAttributeType.S).build(),
AttributeDefinition.builder().attributeName("OrderId").attributeType(ScalarAttributeType.N).build(),
AttributeDefinition.builder().attributeName("OrderCreationDate").attributeType(ScalarAttributeType.N).build(),
AttributeDefinition.builder().attributeName("IsOpen").attributeType(ScalarAttributeType.N).build())
.keySchema(
KeySchemaElement.builder().attributeName("CustomerId").keyType(KeyType.HASH).build(),
KeySchemaElement.builder().attributeName("OrderId").keyType(KeyType.RANGE).build())
.localSecondaryIndexes(
LocalSecondaryIndex.builder()
.indexName("OrderCreationDateIndex")
.keySchema(
KeySchemaElement.builder().attributeName("CustomerId").keyType(KeyType.HASH).build(),
KeySchemaElement.builder().attributeName("OrderCreationDate").keyType(KeyType.RANGE).build())
.projection(Projection.builder()
.projectionType(ProjectionType.INCLUDE)
.nonKeyAttributes("ProductCategory", "ProductName")
.build())
.build(),
LocalSecondaryIndex.builder()
.indexName("IsOpenIndex")
.keySchema(
KeySchemaElement.builder().attributeName("CustomerId").keyType(KeyType.HASH).build(),
KeySchemaElement.builder().attributeName("IsOpen").keyType(KeyType.RANGE).build())
.projection(Projection.builder()
.projectionType(ProjectionType.ALL)
.build())
.build())
.build();
System.out.println("Creating table " + tableName + "...");
client.createTable(request);
try (DynamoDbWaiter waiter = client.waiter()) {
WaiterResponse response = waiter.waitUntilTableExists(r -> r.tableName(tableName));
response.matched().response().ifPresent(System.out::println);
}
}
public static void query(String indexName) {
System.out.println("\n***********************************************************\n");
System.out.println("Querying table " + tableName + "...");
if ("IsOpenIndex".equals(indexName)) {
System.out.println("\nUsing index: '" + indexName + "': Bob's orders that are open.");
System.out.println("Only a user-specified list of attributes are returned\n");
Map values = new HashMap<>();
values.put(":v_custid", AttributeValue.builder().s("bob@example.com").build());
values.put(":v_isopen", AttributeValue.builder().n("1").build());
QueryRequest request = QueryRequest.builder()
.tableName(tableName)
.indexName(indexName)
.keyConditionExpression("CustomerId = :v_custid and IsOpen = :v_isopen")
.expressionAttributeValues(values)
.projectionExpression("OrderCreationDate, ProductCategory, ProductName, OrderStatus")
.build();
System.out.println("Query: printing results...");
client.query(request).items().forEach(System.out::println);
} else if ("OrderCreationDateIndex".equals(indexName)) {
System.out.println("\nUsing index: '" + indexName + "': Bob's orders that were placed after 01/31/2015.");
System.out.println("Only the projected attributes are returned\n");
Map values = new HashMap<>();
values.put(":v_custid", AttributeValue.builder().s("bob@example.com").build());
values.put(":v_orddate", AttributeValue.builder().n("20150131").build());
QueryRequest request = QueryRequest.builder()
.tableName(tableName)
.indexName(indexName)
.keyConditionExpression("CustomerId = :v_custid and OrderCreationDate >= :v_orddate")
.expressionAttributeValues(values)
.select(Select.ALL_PROJECTED_ATTRIBUTES)
.build();
System.out.println("Query: printing results...");
client.query(request).items().forEach(System.out::println);
} else {
System.out.println("\nNo index: All of Bob's orders, by OrderId:\n");
Map values = new HashMap<>();
values.put(":v_custid", AttributeValue.builder().s("bob@example.com").build());
QueryRequest request = QueryRequest.builder()
.tableName(tableName)
.keyConditionExpression("CustomerId = :v_custid")
.expressionAttributeValues(values)
.build();
System.out.println("Query: printing results...");
client.query(request).items().forEach(System.out::println);
}
}
public static void deleteTable(String tableName) {
System.out.println("Deleting table " + tableName + "...");
client.deleteTable(DeleteTableRequest.builder().tableName(tableName).build());
try (DynamoDbWaiter waiter = client.waiter()) {
waiter.waitUntilTableNotExists(r -> r.tableName(tableName));
}
}
public static void loadData() {
System.out.println("Loading data into table " + tableName + "...");
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("alice@example.com").build(),
"OrderId", AttributeValue.builder().n("1").build(),
"IsOpen", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150101").build(),
"ProductCategory", AttributeValue.builder().s("Book").build(),
"ProductName", AttributeValue.builder().s("The Great Outdoors").build(),
"OrderStatus", AttributeValue.builder().s("PACKING ITEMS").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("alice@example.com").build(),
"OrderId", AttributeValue.builder().n("2").build(),
"IsOpen", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150221").build(),
"ProductCategory", AttributeValue.builder().s("Bike").build(),
"ProductName", AttributeValue.builder().s("Super Mountain").build(),
"OrderStatus", AttributeValue.builder().s("ORDER RECEIVED").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("alice@example.com").build(),
"OrderId", AttributeValue.builder().n("3").build(),
"OrderCreationDate", AttributeValue.builder().n("20150304").build(),
"ProductCategory", AttributeValue.builder().s("Music").build(),
"ProductName", AttributeValue.builder().s("A Quiet Interlude").build(),
"OrderStatus", AttributeValue.builder().s("IN TRANSIT").build(),
"ShipmentTrackingId", AttributeValue.builder().s("176493").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150111").build(),
"ProductCategory", AttributeValue.builder().s("Movie").build(),
"ProductName", AttributeValue.builder().s("Calm Before The Storm").build(),
"OrderStatus", AttributeValue.builder().s("SHIPPING DELAY").build(),
"ShipmentTrackingId", AttributeValue.builder().s("859323").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("2").build(),
"OrderCreationDate", AttributeValue.builder().n("20150124").build(),
"ProductCategory", AttributeValue.builder().s("Music").build(),
"ProductName", AttributeValue.builder().s("E-Z Listening").build(),
"OrderStatus", AttributeValue.builder().s("DELIVERED").build(),
"ShipmentTrackingId", AttributeValue.builder().s("756943").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("3").build(),
"OrderCreationDate", AttributeValue.builder().n("20150221").build(),
"ProductCategory", AttributeValue.builder().s("Music").build(),
"ProductName", AttributeValue.builder().s("Symphony 9").build(),
"OrderStatus", AttributeValue.builder().s("DELIVERED").build(),
"ShipmentTrackingId", AttributeValue.builder().s("645193").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("4").build(),
"IsOpen", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150222").build(),
"ProductCategory", AttributeValue.builder().s("Hardware").build(),
"ProductName", AttributeValue.builder().s("Extra Heavy Hammer").build(),
"OrderStatus", AttributeValue.builder().s("PACKING ITEMS").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("5").build(),
"OrderCreationDate", AttributeValue.builder().n("20150309").build(),
"ProductCategory", AttributeValue.builder().s("Book").build(),
"ProductName", AttributeValue.builder().s("How To Cook").build(),
"OrderStatus", AttributeValue.builder().s("IN TRANSIT").build(),
"ShipmentTrackingId", AttributeValue.builder().s("440185").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("6").build(),
"OrderCreationDate", AttributeValue.builder().n("20150318").build(),
"ProductCategory", AttributeValue.builder().s("Luggage").build(),
"ProductName", AttributeValue.builder().s("Really Big Suitcase").build(),
"OrderStatus", AttributeValue.builder().s("DELIVERED").build(),
"ShipmentTrackingId", AttributeValue.builder().s("893927").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("7").build(),
"OrderCreationDate", AttributeValue.builder().n("20150324").build(),
"ProductCategory", AttributeValue.builder().s("Golf").build(),
"ProductName", AttributeValue.builder().s("PGA Pro II").build(),
"OrderStatus", AttributeValue.builder().s("OUT FOR DELIVERY").build(),
"ShipmentTrackingId", AttributeValue.builder().s("383283").build()));
}
private static void putItem(Map item) {
client.putItem(PutItemRequest.builder().tableName(tableName).item(item).build());
}
}
```
# Utilizzo di indici secondari locali: .NET
**Topics**
+ [Creazione di una tabella con un indice secondario locale](#LSILowLevelDotNet.CreateTableWithIndex)
+ [Descrizione di una tabella con un indice secondario locale](#LSILowLevelDotNet.DescribeTableWithIndex)
+ [Esecuzione di query su un indice secondario locale](#LSILowLevelDotNet.QueryAnIndex)
+ [Esempio AWS SDK per .NET : indici secondari locali che utilizzano l'API di basso livello](LSILowLevelDotNet.Example.md)
Puoi utilizzare l'API di AWS SDK per .NET basso livello per creare una tabella Amazon DynamoDB con uno o più indici secondari locali, descrivere gli indici sulla tabella ed eseguire query utilizzando gli indici. Queste operazioni vengono mappate alle corrispondenti azioni dell'API DynamoDB di basso livello. Per ulteriori informazioni, consulta [Esempi di codice .NET](CodeSamples.DotNet.md).
Di seguito sono riportate le operazioni comuni per le operazioni delle tabelle che utilizzano l'API di basso livello .NET.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Fornisci i parametri obbligatori e facoltativi per l'operazione creando gli oggetti di richiesta corrispondenti.
Ad esempio, creare un oggetto `CreateTableRequest` per creare una tabella e un oggetto `QueryRequest` per eseguire una query su una tabella o un indice.
1. Eseguire il metodo appropriato fornito dal client creato nella fase precedente.
## Creazione di una tabella con un indice secondario locale
Gli indici secondari locali possono essere creati al momento della creazione di una tabella. A tale scopo, utilizza `CreateTable` e fornire le specifiche per uno o più indici secondari locali. Il seguente esempio di codice C\$1 crea una tabella per contenere le informazioni sui brani in una raccolta musicale. La chiave di partizione è `Artist` e la chiave di ordinamento è `SongTitle`. Un indice secondario, `AlbumTitleIndex`, facilita le query in base al titolo dell'album.
Di seguito sono riportate le operazioni per creare una tabella con un indice secondario locale, utilizzando l'API di basso livello di DynamoDB.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Crea un'istanza della classe `CreateTableRequest` per fornire le informazioni della richiesta.
È necessario fornire il nome della tabella, la sua chiave primaria e i valori del throughput assegnato. Per l'indice secondario locale, è necessario fornire il nome dell'indice, il nome e il tipo di dati della chiave di ordinamento dell'indice, lo schema della chiave per l'indice e la proiezione degli attributi.
1. Eseguire il metodo `CreateTable` fornendo l'oggetto della richiesta come parametro.
Il seguente esempio di codice C\$1 mostra le fasi precedenti. Il codice crea una tabella (`Music`) con un indice secondario sull'attributo `AlbumTitle`. La chiave di partizione e la chiave di ordinamento della tabella, più la chiave di ordinamento dell'indice, sono gli unici attributi proiettati sull'indice.
```
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
string tableName = "Music";
CreateTableRequest createTableRequest = new CreateTableRequest()
{
TableName = tableName
};
//ProvisionedThroughput
createTableRequest.ProvisionedThroughput = new ProvisionedThroughput()
{
ReadCapacityUnits = (long)5,
WriteCapacityUnits = (long)5
};
//AttributeDefinitions
List attributeDefinitions = new List();
attributeDefinitions.Add(new AttributeDefinition()
{
AttributeName = "Artist",
AttributeType = "S"
});
attributeDefinitions.Add(new AttributeDefinition()
{
AttributeName = "SongTitle",
AttributeType = "S"
});
attributeDefinitions.Add(new AttributeDefinition()
{
AttributeName = "AlbumTitle",
AttributeType = "S"
});
createTableRequest.AttributeDefinitions = attributeDefinitions;
//KeySchema
List tableKeySchema = new List();
tableKeySchema.Add(new KeySchemaElement() { AttributeName = "Artist", KeyType = "HASH" }); //Partition key
tableKeySchema.Add(new KeySchemaElement() { AttributeName = "SongTitle", KeyType = "RANGE" }); //Sort key
createTableRequest.KeySchema = tableKeySchema;
List indexKeySchema = new List();
indexKeySchema.Add(new KeySchemaElement() { AttributeName = "Artist", KeyType = "HASH" }); //Partition key
indexKeySchema.Add(new KeySchemaElement() { AttributeName = "AlbumTitle", KeyType = "RANGE" }); //Sort key
Projection projection = new Projection() { ProjectionType = "INCLUDE" };
List nonKeyAttributes = new List();
nonKeyAttributes.Add("Genre");
nonKeyAttributes.Add("Year");
projection.NonKeyAttributes = nonKeyAttributes;
LocalSecondaryIndex localSecondaryIndex = new LocalSecondaryIndex()
{
IndexName = "AlbumTitleIndex",
KeySchema = indexKeySchema,
Projection = projection
};
List localSecondaryIndexes = new List();
localSecondaryIndexes.Add(localSecondaryIndex);
createTableRequest.LocalSecondaryIndexes = localSecondaryIndexes;
CreateTableResponse result = client.CreateTable(createTableRequest);
Console.WriteLine(result.CreateTableResult.TableDescription.TableName);
Console.WriteLine(result.CreateTableResult.TableDescription.TableStatus);
```
È necessario attendere fino a quando DynamoDB crea la tabella e imposta lo stato su `ACTIVE`. Dopodiché, puoi iniziare a inserire item di dati nella tabella.
## Descrizione di una tabella con un indice secondario locale
Per ottenere informazioni sugli indici secondari locali in una tabella, utilizza l'API `DescribeTable`. Puoi accedere al nome, allo schema della chiave e agli attributi proiettati di ciascun indice.
Di seguito sono riportate le operazioni per accedere alle informazioni sull'indice secondario locale su una tabella utilizzando l'API di basso livello .NET.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Crea un'istanza della classe `DescribeTableRequest` per fornire le informazioni della richiesta. Devi specificare il nome della tabella.
1. Eseguire il metodo `describeTable` fornendo l'oggetto della richiesta come parametro.
Il seguente esempio di codice C\$1 mostra le fasi precedenti.
**Example**
```
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
string tableName = "Music";
DescribeTableResponse response = client.DescribeTable(new DescribeTableRequest() { TableName = tableName });
List localSecondaryIndexes =
response.DescribeTableResult.Table.LocalSecondaryIndexes;
// This code snippet will work for multiple indexes, even though
// there is only one index in this example.
foreach (LocalSecondaryIndexDescription lsiDescription in localSecondaryIndexes)
{
Console.WriteLine("Info for index " + lsiDescription.IndexName + ":");
foreach (KeySchemaElement kse in lsiDescription.KeySchema)
{
Console.WriteLine("\t" + kse.AttributeName + ": key type is " + kse.KeyType);
}
Projection projection = lsiDescription.Projection;
Console.WriteLine("\tThe projection type is: " + projection.ProjectionType);
if (projection.ProjectionType.ToString().Equals("INCLUDE"))
{
Console.WriteLine("\t\tThe non-key projected attributes are:");
foreach (String s in projection.NonKeyAttributes)
{
Console.WriteLine("\t\t" + s);
}
}
}
```
## Esecuzione di query su un indice secondario locale
È possibile utilizzare l'operazione `Query` su un indice secondario locale nello stesso modo in cui si esegue una `Query` su una tabella. È necessario specificare il nome dell'indice, i criteri della query per la chiave di ordinamento dell'indice e gli attributi da restituire. In questo esempio, l'indice è `AlbumTitleIndex` e la chiave di ordinamento dell'indice è `AlbumTitle`.
Gli unici attributi restituiti sono quelli proiettati nell'indice. È possibile modificare questa query per selezionare anche attributi non chiave, ma ciò richiederebbe un'attività di recupero della tabella relativamente costosa. Per ulteriori informazioni sul recupero delle tabelle, consulta [Proiezioni di attributi](LSI.md#LSI.Projections)
Di seguito sono riportate le operazioni per eseguire una query su un indice secondario locale utilizzando l'API di basso livello .NET.
1. Creare un'istanza della classe `AmazonDynamoDBClient`.
1. Crea un'istanza della classe `QueryRequest` per fornire le informazioni della richiesta.
1. Eseguire il metodo `query` fornendo l'oggetto della richiesta come parametro.
Il seguente esempio di codice C\$1 mostra le fasi precedenti.
**Example**
```
QueryRequest queryRequest = new QueryRequest
{
TableName = "Music",
IndexName = "AlbumTitleIndex",
Select = "ALL_ATTRIBUTES",
ScanIndexForward = true,
KeyConditionExpression = "Artist = :v_artist and AlbumTitle = :v_title",
ExpressionAttributeValues = new Dictionary()
{
{":v_artist",new AttributeValue {S = "Acme Band"}},
{":v_title",new AttributeValue {S = "Songs About Life"}}
},
};
QueryResponse response = client.Query(queryRequest);
foreach (var attribs in response.Items)
{
foreach (var attrib in attribs)
{
Console.WriteLine(attrib.Key + " ---> " + attrib.Value.S);
}
Console.WriteLine();
}
```
# Esempio AWS SDK per .NET : indici secondari locali che utilizzano l'API di basso livello
Il seguente esempio di codice C\$1 mostra come utilizzare gli indici secondari locali in Amazon DynamoDB. Nell'esempio viene creata una tabella denominata `CustomerOrders` con una chiave di partizione `CustomerId` e una chiave di ordinamento `OrderId`. In questa tabella esistono due indici secondari locali:
+ `OrderCreationDateIndex`: la chiave di ordinamento è `OrderCreationDate` e i seguenti attributi sono proiettati sull'indice.
+ `ProductCategory`
+ `ProductName`
+ `OrderStatus`
+ `ShipmentTrackingId`
+ `IsOpenIndex`: la chiave di ordinamento è `IsOpen` e tutti gli attributi della tabella vengono proiettati nell'indice.
Una volta creata la tabella `CustomerOrders`, il programma carica la tabella con i dati che rappresentano gli ordini dei clienti. Quindi esegue una query sui dati utilizzando gli indici secondari locali. Infine, il programma elimina la tabella `CustomerOrders`.
Per step-by-step istruzioni su come testare l'esempio seguente, consulta. [Esempi di codice .NET](CodeSamples.DotNet.md)
**Example**
```
using System;
using System.Collections.Generic;
using System.Linq;
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.DataModel;
using Amazon.DynamoDBv2.DocumentModel;
using Amazon.DynamoDBv2.Model;
using Amazon.Runtime;
using Amazon.SecurityToken;
namespace com.amazonaws.codesamples
{
class LowLevelLocalSecondaryIndexExample
{
private static AmazonDynamoDBClient client = new AmazonDynamoDBClient();
private static string tableName = "CustomerOrders";
static void Main(string[] args)
{
try
{
CreateTable();
LoadData();
Query(null);
Query("IsOpenIndex");
Query("OrderCreationDateIndex");
DeleteTable(tableName);
Console.WriteLine("To continue, press Enter");
Console.ReadLine();
}
catch (AmazonDynamoDBException e) { Console.WriteLine(e.Message); }
catch (AmazonServiceException e) { Console.WriteLine(e.Message); }
catch (Exception e) { Console.WriteLine(e.Message); }
}
private static void CreateTable()
{
var createTableRequest =
new CreateTableRequest()
{
TableName = tableName,
ProvisionedThroughput =
new ProvisionedThroughput()
{
ReadCapacityUnits = (long)1,
WriteCapacityUnits = (long)1
}
};
var attributeDefinitions = new List()
{
// Attribute definitions for table primary key
{ new AttributeDefinition() {
AttributeName = "CustomerId", AttributeType = "S"
} },
{ new AttributeDefinition() {
AttributeName = "OrderId", AttributeType = "N"
} },
// Attribute definitions for index primary key
{ new AttributeDefinition() {
AttributeName = "OrderCreationDate", AttributeType = "N"
} },
{ new AttributeDefinition() {
AttributeName = "IsOpen", AttributeType = "N"
}}
};
createTableRequest.AttributeDefinitions = attributeDefinitions;
// Key schema for table
var tableKeySchema = new List()
{
{ new KeySchemaElement() {
AttributeName = "CustomerId", KeyType = "HASH"
} }, //Partition key
{ new KeySchemaElement() {
AttributeName = "OrderId", KeyType = "RANGE"
} } //Sort key
};
createTableRequest.KeySchema = tableKeySchema;
var localSecondaryIndexes = new List();
// OrderCreationDateIndex
LocalSecondaryIndex orderCreationDateIndex = new LocalSecondaryIndex()
{
IndexName = "OrderCreationDateIndex"
};
// Key schema for OrderCreationDateIndex
var indexKeySchema = new List()
{
{ new KeySchemaElement() {
AttributeName = "CustomerId", KeyType = "HASH"
} }, //Partition key
{ new KeySchemaElement() {
AttributeName = "OrderCreationDate", KeyType = "RANGE"
} } //Sort key
};
orderCreationDateIndex.KeySchema = indexKeySchema;
// Projection (with list of projected attributes) for
// OrderCreationDateIndex
var projection = new Projection()
{
ProjectionType = "INCLUDE"
};
var nonKeyAttributes = new List()
{
"ProductCategory",
"ProductName"
};
projection.NonKeyAttributes = nonKeyAttributes;
orderCreationDateIndex.Projection = projection;
localSecondaryIndexes.Add(orderCreationDateIndex);
// IsOpenIndex
LocalSecondaryIndex isOpenIndex
= new LocalSecondaryIndex()
{
IndexName = "IsOpenIndex"
};
// Key schema for IsOpenIndex
indexKeySchema = new List()
{
{ new KeySchemaElement() {
AttributeName = "CustomerId", KeyType = "HASH"
}}, //Partition key
{ new KeySchemaElement() {
AttributeName = "IsOpen", KeyType = "RANGE"
}} //Sort key
};
// Projection (all attributes) for IsOpenIndex
projection = new Projection()
{
ProjectionType = "ALL"
};
isOpenIndex.KeySchema = indexKeySchema;
isOpenIndex.Projection = projection;
localSecondaryIndexes.Add(isOpenIndex);
// Add index definitions to CreateTable request
createTableRequest.LocalSecondaryIndexes = localSecondaryIndexes;
Console.WriteLine("Creating table " + tableName + "...");
client.CreateTable(createTableRequest);
WaitUntilTableReady(tableName);
}
public static void Query(string indexName)
{
Console.WriteLine("\n***********************************************************\n");
Console.WriteLine("Querying table " + tableName + "...");
QueryRequest queryRequest = new QueryRequest()
{
TableName = tableName,
ConsistentRead = true,
ScanIndexForward = true,
ReturnConsumedCapacity = "TOTAL"
};
String keyConditionExpression = "CustomerId = :v_customerId";
Dictionary expressionAttributeValues = new Dictionary {
{":v_customerId", new AttributeValue {
S = "bob@example.com"
}}
};
if (indexName == "IsOpenIndex")
{
Console.WriteLine("\nUsing index: '" + indexName
+ "': Bob's orders that are open.");
Console.WriteLine("Only a user-specified list of attributes are returned\n");
queryRequest.IndexName = indexName;
keyConditionExpression += " and IsOpen = :v_isOpen";
expressionAttributeValues.Add(":v_isOpen", new AttributeValue
{
N = "1"
});
// ProjectionExpression
queryRequest.ProjectionExpression = "OrderCreationDate, ProductCategory, ProductName, OrderStatus";
}
else if (indexName == "OrderCreationDateIndex")
{
Console.WriteLine("\nUsing index: '" + indexName
+ "': Bob's orders that were placed after 01/31/2013.");
Console.WriteLine("Only the projected attributes are returned\n");
queryRequest.IndexName = indexName;
keyConditionExpression += " and OrderCreationDate > :v_Date";
expressionAttributeValues.Add(":v_Date", new AttributeValue
{
N = "20130131"
});
// Select
queryRequest.Select = "ALL_PROJECTED_ATTRIBUTES";
}
else
{
Console.WriteLine("\nNo index: All of Bob's orders, by OrderId:\n");
}
queryRequest.KeyConditionExpression = keyConditionExpression;
queryRequest.ExpressionAttributeValues = expressionAttributeValues;
var result = client.Query(queryRequest);
var items = result.Items;
foreach (var currentItem in items)
{
foreach (string attr in currentItem.Keys)
{
if (attr == "OrderId" || attr == "IsOpen"
|| attr == "OrderCreationDate")
{
Console.WriteLine(attr + "---> " + currentItem[attr].N);
}
else
{
Console.WriteLine(attr + "---> " + currentItem[attr].S);
}
}
Console.WriteLine();
}
Console.WriteLine("\nConsumed capacity: " + result.ConsumedCapacity.CapacityUnits + "\n");
}
private static void DeleteTable(string tableName)
{
Console.WriteLine("Deleting table " + tableName + "...");
client.DeleteTable(new DeleteTableRequest()
{
TableName = tableName
});
WaitForTableToBeDeleted(tableName);
}
public static void LoadData()
{
Console.WriteLine("Loading data into table " + tableName + "...");
Dictionary item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "alice@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "1"
};
item["IsOpen"] = new AttributeValue
{
N = "1"
};
item["OrderCreationDate"] = new AttributeValue
{
N = "20130101"
};
item["ProductCategory"] = new AttributeValue
{
S = "Book"
};
item["ProductName"] = new AttributeValue
{
S = "The Great Outdoors"
};
item["OrderStatus"] = new AttributeValue
{
S = "PACKING ITEMS"
};
/* no ShipmentTrackingId attribute */
PutItemRequest putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "alice@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "2"
};
item["IsOpen"] = new AttributeValue
{
N = "1"
};
item["OrderCreationDate"] = new AttributeValue
{
N = "20130221"
};
item["ProductCategory"] = new AttributeValue
{
S = "Bike"
};
item["ProductName"] = new AttributeValue
{
S = "Super Mountain"
};
item["OrderStatus"] = new AttributeValue
{
S = "ORDER RECEIVED"
};
/* no ShipmentTrackingId attribute */
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "alice@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "3"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130304"
};
item["ProductCategory"] = new AttributeValue
{
S = "Music"
};
item["ProductName"] = new AttributeValue
{
S = "A Quiet Interlude"
};
item["OrderStatus"] = new AttributeValue
{
S = "IN TRANSIT"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "176493"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "1"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130111"
};
item["ProductCategory"] = new AttributeValue
{
S = "Movie"
};
item["ProductName"] = new AttributeValue
{
S = "Calm Before The Storm"
};
item["OrderStatus"] = new AttributeValue
{
S = "SHIPPING DELAY"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "859323"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "2"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130124"
};
item["ProductCategory"] = new AttributeValue
{
S = "Music"
};
item["ProductName"] = new AttributeValue
{
S = "E-Z Listening"
};
item["OrderStatus"] = new AttributeValue
{
S = "DELIVERED"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "756943"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "3"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130221"
};
item["ProductCategory"] = new AttributeValue
{
S = "Music"
};
item["ProductName"] = new AttributeValue
{
S = "Symphony 9"
};
item["OrderStatus"] = new AttributeValue
{
S = "DELIVERED"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "645193"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "4"
};
item["IsOpen"] = new AttributeValue
{
N = "1"
};
item["OrderCreationDate"] = new AttributeValue
{
N = "20130222"
};
item["ProductCategory"] = new AttributeValue
{
S = "Hardware"
};
item["ProductName"] = new AttributeValue
{
S = "Extra Heavy Hammer"
};
item["OrderStatus"] = new AttributeValue
{
S = "PACKING ITEMS"
};
/* no ShipmentTrackingId attribute */
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "5"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130309"
};
item["ProductCategory"] = new AttributeValue
{
S = "Book"
};
item["ProductName"] = new AttributeValue
{
S = "How To Cook"
};
item["OrderStatus"] = new AttributeValue
{
S = "IN TRANSIT"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "440185"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "6"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130318"
};
item["ProductCategory"] = new AttributeValue
{
S = "Luggage"
};
item["ProductName"] = new AttributeValue
{
S = "Really Big Suitcase"
};
item["OrderStatus"] = new AttributeValue
{
S = "DELIVERED"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "893927"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "7"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130324"
};
item["ProductCategory"] = new AttributeValue
{
S = "Golf"
};
item["ProductName"] = new AttributeValue
{
S = "PGA Pro II"
};
item["OrderStatus"] = new AttributeValue
{
S = "OUT FOR DELIVERY"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "383283"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
}
private static void WaitUntilTableReady(string tableName)
{
string status = null;
// Let us wait until table is created. Call DescribeTable.
do
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
status = res.Table.TableStatus;
}
catch (ResourceNotFoundException)
{
// DescribeTable is eventually consistent. So you might
// get resource not found. So we handle the potential exception.
}
} while (status != "ACTIVE");
}
private static void WaitForTableToBeDeleted(string tableName)
{
bool tablePresent = true;
while (tablePresent)
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
}
catch (ResourceNotFoundException)
{
tablePresent = false;
}
}
}
}
}
```
# Utilizzo di indici secondari locali nella AWS CLI di DynamoDB
Puoi utilizzare la AWS CLI per creare una tabella Amazon DynamoDB con uno o più indici secondari locali, descrivere gli indici nella tabella ed eseguire query utilizzando gli indici.
**Topics**
+ [Creazione di una tabella con un indice secondario locale](#LCICli.CreateTableWithIndex)
+ [Descrizione di una tabella con un indice secondario locale](#LCICli.DescribeTableWithIndex)
+ [Esecuzione di query su un indice secondario locale](#LCICli.QueryAnIndex)
## Creazione di una tabella con un indice secondario locale
Gli indici secondari locali devono essere creati al momento della creazione di una tabella. A tale scopo, utilizza il parametro `create-table` e fornisci le specifiche per uno o più indici secondari locali. Nel seguente esempio viene creata una tabella (`Music`) per contenere le informazioni sui brani in una raccolta musicale. La chiave di partizione è `Artist` e la chiave di ordinamento è `SongTitle`. Un indice secondario, `AlbumTitleIndex` sull'attributo `AlbumTitle`, facilita le query in base al titolo dell'album.
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions AttributeName=Artist,AttributeType=S AttributeName=SongTitle,AttributeType=S \
AttributeName=AlbumTitle,AttributeType=S \
--key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--local-secondary-indexes \
"[{\"IndexName\": \"AlbumTitleIndex\",
\"KeySchema\":[{\"AttributeName\":\"Artist\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"AlbumTitle\",\"KeyType\":\"RANGE\"}],
\"Projection\":{\"ProjectionType\":\"INCLUDE\", \"NonKeyAttributes\":[\"Genre\", \"Year\"]}}]"
```
È necessario attendere fino a quando DynamoDB crea la tabella e imposta lo stato su `ACTIVE`. Dopodiché, puoi iniziare a inserire item di dati nella tabella. È possibile utilizzare [describe-table](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/describe-table.html) per determinare lo stato di avanzamento della creazione della tabella.
## Descrizione di una tabella con un indice secondario locale
Per ottenere informazioni sugli indici secondari locali in una tabella, utilizza il parametro `describe-table`. Puoi accedere al nome, allo schema della chiave e agli attributi proiettati di ciascun indice.
```
aws dynamodb describe-table --table-name Music
```
## Esecuzione di query su un indice secondario locale
Puoi utilizzare l'operazione `query` su un indice secondario locale nello stesso modo in cui esegui una `query` su una tabella. È necessario specificare il nome dell'indice, i criteri della query per la chiave di ordinamento dell'indice e gli attributi da restituire. In questo esempio, l'indice è `AlbumTitleIndex` e la chiave di ordinamento dell'indice è `AlbumTitle`.
Gli unici attributi restituiti sono quelli proiettati nell'indice. È possibile modificare questa query per selezionare anche attributi non chiave, ma ciò richiederebbe un'attività di recupero della tabella relativamente costosa. Per ulteriori informazioni sul recupero delle tabelle, consulta [Proiezioni di attributi](LSI.md#LSI.Projections).
```
aws dynamodb query \
--table-name Music \
--index-name AlbumTitleIndex \
--key-condition-expression "Artist = :v_artist and AlbumTitle = :v_title" \
--expression-attribute-values '{":v_artist":{"S":"Acme Band"},":v_title":{"S":"Songs About Life"} }'
```
# Gestione di flussi di lavoro complessi con transazioni DynamoDB
Le transazioni Amazon DynamoDB semplificano l'esperienza degli sviluppatori di apportare modifiche coordinate all-or-nothing a più elementi sia all'interno che tra tabelle. La transazioni forniscono atomicità, coerenza, isolamento e durabilità (ACID) in DynamoDB, consentendo di conservare più facilmente dati corretti nelle applicazioni.
Puoi utilizzare la lettura e la APIs scrittura transazionale di DynamoDB per gestire flussi di lavoro aziendali complessi che richiedono l'aggiunta, l'aggiornamento o l'eliminazione di più elementi in un'unica operazione. all-or-nothing Ad esempio, uno sviluppatore di videogiochi può garantire che i profili dei giocatori siano aggiornati correttamente quando si scambiano le voci in un videogioco o effettuano acquisti all'interno del gioco.
Con l'API di scrittura di transazione, è possibile raggruppare diverse operazioni `Put`, `Update`, `Delete` e `ConditionCheck`. Puoi quindi inviare le operazioni come un'operazione `TransactWriteItems` singola con esito positivo o negativo a livello di unità. Lo stesso vale per diverse azioni `Get`, che possono essere raggruppate e inviate come un'operazione `TransactGetItems` singola.
Non è previsto alcun costo aggiuntivo per abilitare le transazioni per le tabelle DynamoDB. Si paga solo per le letture o le scritture che fanno parte della transazione. DynamoDB esegue due letture o scritture sottostanti per ciascun elemento nella transazione: uno per preparare la transazione uno per eseguire il commit della transazione. Queste due read/write operazioni sottostanti sono visibili nelle CloudWatch metriche di Amazon.
Per iniziare a utilizzare le transazioni DynamoDB, scarica l'SDK AWS più recente o (). AWS Command Line Interface AWS CLI Quindi segui la procedura [Esempio di transazioni di DynamoDB](transaction-example.md).
Le seguenti sezioni forniscono una panoramica dettagliata della transazione APIs e di come utilizzarla in DynamoDB.
**Topics**
+ [Come funziona](transaction-apis.md)
+ [Utilizzo di IAM con le transazioni](transaction-apis-iam.md)
+ [Codice di esempio](transaction-example.md)
# Transazioni Amazon DynamoDB: come funzionano
Con le transazioni Amazon DynamoDB, puoi raggruppare più azioni e inviarle come singola all-or-nothing `TransactWriteItems` operazione. `TransactGetItems` Le seguenti sezioni descrivono le operazioni delle API, la gestione della capacità, le best practice e altri dettagli sulle operazioni transazionali in DynamoDB.
**Topics**
+ [TransactWriteItems API](#transaction-apis-txwriteitems)
+ [TransactGetItems API](#transaction-apis-txgetitems)
+ [Livelli di isolamento per le transazioni DynamoDB](#transaction-isolation)
+ [Gestione dei conflitti nelle transazioni in DynamoDB](#transaction-conflict-handling)
+ [Utilizzo delle transazioni in APIs DynamoDB Accelerator (DAX)](#transaction-apis-dax)
+ [Gestione della capacità per le transazioni](#transaction-capacity-handling)
+ [Best practice per le transazioni](#transaction-best-practices)
+ [Utilizzo di tabelle transazionali con tabelle globali APIs](#transaction-integration)
+ [DynamoDB Transactions e la libreria client delle transazioni AWSLabs](#transaction-vs-library)
## TransactWriteItems API
`TransactWriteItems`è un'operazione di scrittura sincrona e idempotente che raggruppa fino a 100 azioni di scrittura in un'unica operazione. all-or-nothing Queste azioni possono indirizzare fino a 100 elementi distinti in una o più tabelle DynamoDB all'interno dello AWS stesso account e nella stessa regione. La dimensione aggregata degli elementi nella transazione non può superare i 4 MB. Le operazioni vengono completate in modo atomico, in maniera tale che abbiano tutte esito positivo oppure abbiano tutte esito negativo.
**Nota**
Un'operazione `TransactWriteItems` differisce da un'operazione `BatchWriteItem` nel fatto che tutte le operazioni che contiene devono essere completate con successo, altrimenti non viene apportata alcuna modifica. Con un'operazione `BatchWriteItem`, è possibile che solo alcune azioni nel batch abbiano esito positivo, contrariamente alle altre.
Le transazioni non possono essere eseguite utilizzando gli indici.
Non è possibile fare riferimento allo stesso item con diverse operazioni all'interno della stessa transazione. Ad esempio, non è possibile eseguire un'operazione `ConditionCheck` e `Update` per lo stesso item nella stessa transazione.
È possibile aggiungere uno dei seguenti tipi di operazioni a una transazione:
+ `Put`: avvia un'operazione `PutItem` per creare un nuovo elemento o sostituire un vecchio elemento con uno nuovo, in base a condizioni o senza specificare alcuna condizione.
+ `Update`: avvia un'operazione `UpdateItem` per modificare gli attributi di un elemento esistente o aggiungere un nuovo elemento alla tabella se non è già presente. Utilizza questa operazione per aggiungere, eliminare o aggiornare attributi su un item esistente in base a condizioni o senza una condizione.
+ `Delete`: avvia un'operazione `DeleteItem` per eliminare un singolo elemento in una tabella identificata dalla chiave primaria.
+ `ConditionCheck`: verifica che un elemento esista o controlla la condizione di attributi specifici dell'elemento.
Quando una transazione viene completata in DynamoDB, le sue modifiche iniziano a propagarsi agli indici secondari globali (), ai flussi e ai backupGSIs. Questa propagazione avviene gradualmente: i record dei flussi della stessa transazione potrebbero apparire in momenti diversi e potrebbero risultare interleaved con i record di altre transazioni. I consumer dei flussi non dovrebbero presumere l’atomicità delle transazioni o garanzie d’ordine.
Per garantire un'istantanea atomica degli elementi modificati in una transazione, utilizza l'operazione per leggere tutti gli elementi pertinenti insieme. TransactGetItems Questa operazione fornisce una visione coerente dei dati, garantendo la visualizzazione di tutte le modifiche rispetto a una transazione completata o di nessuna.
Poiché la propagazione non è immediata, se una tabella viene ripristinata da backup ([RestoreTableFromBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableFromBackup.html)) o esportata in un punto temporale ([ExportTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html)) durante la propagazione, può contenere solo alcune delle modifiche apportate durante una transazione recente.
### Idempotenza
È possibile includere un token client quando si effettua una chiamata `TransactWriteItems` per garantire che la richiesta sia *idempotente*. Rendere le transazioni idempotenti impedisce errori nelle applicazioni se la stessa operazione viene inviata più volte a causa di un timeout della connessione o altri problemi di connettività.
Se la chiamata `TransactWriteItems` originale è andata a buon fine, allora le successive chiamate `TransactWriteItems` con lo stesso token client hanno esito positivo senza apportare alcuna modifica. Se viene impostato il parametro `ReturnConsumedCapacity`, la chiamata `TransactWriteItems` iniziale restituisce il numero di unità di capacità in scrittura consumate mentre venivano apportate le modifiche. Le successive chiamate `TransactWriteItems` con lo stesso token client restituiscono il numero di unità di capacità in lettura consumate durante la lettura dell'item.
**Considerazioni importanti sull'idempotenza**
+ Un token client è valido per 10 minuti dopo il termine della richiesta che lo utilizza. Dopo 10 minuti, qualsiasi richiesta che utilizza lo stesso token client viene trattata come una nuova richiesta. Lo stesso token client non deve essere riutilizzato per la stessa richiesta dopo 10 minuti.
+ Se si ripete la richiesta con lo stesso token client all'interno della finestra di idempotenza di 10 minuti, ma vengono modificati altri parametri, DynamoDB restituisce un'eccezione `IdempotentParameterMismatch`.
### Gestione degli errori per scrittura
Le transazioni di scrittura non hanno esito positivo nelle seguenti circostanze:
+ Quando una condizione in una delle espressioni di condizione non viene soddisfatta.
+ Quando un errore di convalida della transazione si verifica in quanto un'operazione all'interno della stessa operazione `TransactWriteItems` mira allo stesso item.
+ Quando una richiesta `TransactWriteItems` è in conflitto con un'operazione `TransactWriteItems` in corso su uno o più item nella richiesta `TransactWriteItems`. In questo caso, la richiesta ha esito negativo con una `TransactionCanceledException`.
+ Quando la capacità assegnata è insufficiente per il completamento della transazione.
+ Quando la dimensione di un item diventa eccessiva (superiore a 400 KB), un indice secondario locale (LSI) diventa eccessivo o si verifica un errore di convalida simile a causa delle modifiche apportate dalla transazione.
+ Quando è presente un errore utente, come un formato di dati invalido.
Per ulteriori informazioni sulla gestione dei conflitti con le operazioni `TransactWriteItems`, consulta [Gestione dei conflitti nelle transazioni in DynamoDB](#transaction-conflict-handling).
## TransactGetItems API
`TransactGetItems` è un'operazione di lettura sincrona che raggruppa fino a 100 operazioni `Get`. Queste azioni possono indirizzare fino a 100 elementi distinti in una o più tabelle DynamoDB all'interno dello stesso account e della AWS stessa regione. La dimensione aggregata degli elementi nella transazione non può superare i 4 MB.
Le operazioni `Get` vengono eseguite in modo atomico, in maniera tale che abbiano tutte esito positivo oppure abbiano tutte esito negativo.
+ `Get`: avvia un'operazione `GetItem` per recuperare un set di attributi dell'elemento con la chiave primaria specificata. Se non viene trovato un item corrispondente, `Get` non restituisce dati.
### Gestione degli errori per lettura
Le transazioni di lettura non hanno esito positivo nelle seguenti circostanze:
+ Quando una richiesta `TransactGetItems` è in conflitto con un'operazione `TransactWriteItems` in corso su uno o più item nella richiesta `TransactGetItems`. In questo caso, la richiesta ha esito negativo con una `TransactionCanceledException`.
+ Quando la capacità assegnata è insufficiente per il completamento della transazione.
+ Quando è presente un errore utente, come un formato di dati invalido.
Per ulteriori informazioni sulla gestione dei conflitti con le operazioni `TransactGetItems`, consulta [Gestione dei conflitti nelle transazioni in DynamoDB](#transaction-conflict-handling).
## Livelli di isolamento per le transazioni DynamoDB
I livelli di isolamento delle operazioni transazionali (`TransactWriteItems` o `TransactGetItems`) e di altre operazioni sono:
### SERIALIZZABILI
L'isolamento *serializzabile* garantisce che i risultati di diverse operazioni simultanee siano le stesse, come se nessuna operazione avesse inizio prima che l'ultima fosse finita.
L'isolamento serializzabile è presente tra i seguenti tipi di operazione:
+ Tra una qualsiasi operazione transazionale e una qualsiasi operazione di scrittura standard (`PutItem`, `UpdateItem` o `DeleteItem`).
+ Tra una qualsiasi operazione transazionale e una qualsiasi operazione di lettura standard (`GetItem`).
+ Tra un'operazione `TransactWriteItems` e un'operazione `TransactGetItems`.
Nonostante l’isolamento serializzabile sia presente tra le operazioni transazionali e ogni singola scrittura standard in un’operazione `BatchWriteItem`, l’isolamento serializzabile non è presente tra la transazione e l’operazione `BatchWriteItem` come un’unità.
Allo stesso modo, il livello di isolamento tra un'operazione transazionale e un `GetItems` individuale in un'operazione `BatchGetItem` è serializzabile. Tuttavia, il livello di isolamento tra la transazione e l'operazione `BatchGetItem`come unità è *read-committed*.
Una singola richiesta `GetItem` è serializzabile rispetto a una richiesta `TransactWriteItems` in uno dei due modi seguenti, prima o dopo la richiesta `TransactWriteItems`. Più richieste `GetItem`, rispetto alle chiavi in una richiesta `TransactWriteItems`simultanea, possono essere eseguite in qualsiasi ordine, e quindi i risultati sono *letti–commessi*.
Ad esempio, se le richieste `GetItem` per l'elemento A e l'elemento B vengono eseguite contemporaneamente a una richiesta `TransactWriteItems` che modifica sia l'elemento A che l'elemento B, esistono quattro possibilità:
+ Entrambe le richieste `GetItem` vengono eseguite prima della richiesta `TransactWriteItems`.
+ Entrambe le richieste `GetItem` vengono eseguite dopo la richiesta `TransactWriteItems`.
+ La richiesta `GetItem` per l'elemento A viene eseguita prima della richiesta `TransactWriteItems`. Per l'elemento B, `GetItem` viene eseguito dopo `TransactWriteItems`.
+ La richiesta `GetItem` per l'elemento B viene eseguita prima della richiesta `TransactWriteItems`. Per l'elemento A, `GetItem` viene eseguito dopo `TransactWriteItems`.
Sarebbe opportuno utilizzare `TransactGetItems` se si preferisce un livello di isolamento serializzabile per più richieste `GetItem`.
Se viene effettuata una lettura non transazionale su più elementi che facevano parte della stessa richiesta di scrittura della transazione in corso, è possibile che si sia in grado di leggere il nuovo stato di alcuni elementi e il vecchio stato degli altri elementi. Sarà possibile leggere il nuovo stato di tutti gli elementi che facevano parte della richiesta di scrittura della transazione solo quando si riceverà una risposta positiva per la scrittura transazionale, a indicare che la transazione è stata completata.
Una volta completata con successo la transazione e ricevuta una risposta, le successive operazioni di lettura *a coerenza finale* possono comunque restituire il vecchio stato per un breve periodo a causa di un modello di consistenza finale di DynamoDB. Per garantire la lettura della maggior parte up-to-date dei dati subito dopo una transazione, è necessario utilizzare letture [*fortemente coerenti*](HowItWorks.ReadConsistency.md#HowItWorks.ReadConsistency.Strongly) `ConsistentRead` impostando su true.
### READ-COMMITTED
L'isolamento *Read-committed* garantisce che le operazioni di lettura restituiscano sempre valori sottoposti a commit per un elemento: la lettura non presenterà mai una vista dell'elemento che rappresenta uno stato di una scrittura transazionale terminata con un errore. L'isolamento read-committed non impedisce le modifiche dell'item immediatamente dopo l'operazione di lettura.
Il livello di isolamento è read-committed tra una qualsiasi operazione transazionale e una qualsiasi operazione di lettura che coinvolga diverse letture standard (`BatchGetItem`, `Query` o `Scan`). Se una scrittura transazionale aggiorna un elemento durante un'operazione `BatchGetItem`, `Query` o `Scan`, la fase successiva dell'operazione di lettura restituisce il nuovo valore sottoposto a commit, con `ConsistentRead)` o eventualmente un valore sottoposto a commit precedente (letture a consistenza finale).
### Riepilogo dell'operazione
Per riassumere, la seguente tabella mostra i livelli di isolamento tra un'operazione transazionale (`TransactWriteItems` o `TransactGetItems`) e altre operazioni.
| Operation | Livello di isolamento |
| --- | --- |
| `DeleteItem` | *Serializzabile* |
| `PutItem` | *Serializzabile* |
| `UpdateItem` | *Serializzabile* |
| `GetItem` | *Serializzabile* |
| `BatchGetItem` | *Read-committed*\$1 |
| `BatchWriteItem` | *NON serializzabile*\$1 |
| `Query` | *Read-committed* |
| `Scan` | *Read-committed* |
| Altra operazione transazionale | *Serializzabile* |
I livelli contrassegnati da un asterisco (\$1) si applicano all'operazione come un'unità. Tuttavia, le singole operazioni all'interno di tali operazioni hanno un livello di isolamento *serializzabile*.
## Gestione dei conflitti nelle transazioni in DynamoDB
Un conflitto transazionale si può verificare durante richieste simultanee a livello di voci su una singola voce all'interno di una transazione. I conflitti tra transazioni possono verificarsi nei seguenti scenari:
+ Una richiesta `PutItem`,`UpdateItem` e `DeleteItem` per una voce è in conflitto con una richiesta `TransactWriteItems` continua che include la stessa voce.
+ Una voce all'interno di una richiesta `TransactWriteItems` è parte di un'altra richiesta `TransactWriteItems` continua.
+ Una voce all'interno di una richiesta `TransactGetItems` è parte di una richiesta continua `TransactWriteItems`, `BatchWriteItem`, `PutItem`, `UpdateItem` o `DeleteItem`.
**Nota**
Quando una richiesta `PutItem`, `UpdateItem` o `DeleteItem` viene rifiutata, la richiesta dà esito negativo con un `TransactionConflictException`.
Se una richiesta a livello di voce all'interno di `TransactWriteItems` o `TransactGetItems` viene rifiutata, la richiesta dà esito negativo con `TransactionCanceledException`. Se la richiesta fallisce, AWS SDKs non riprovarla.
Se si utilizza il AWS SDK per Java, l'eccezione contiene l'elenco di [CancellationReasons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CancellationReason.html), ordinato in base all'elenco di elementi nel parametro di `TransactItems` richiesta. Per altre lingue, una rappresentazione della stringa dell'elenco è inclusa nel messaggio di errore dell'eccezione.
Quando un'operazione `TransactWriteItems` o `TransactGetItems` in corso è in conflitto con una richiesta `GetItem` simultanea, entrambe le operazione possono avere esito positivo.
La [TransactionConflict CloudWatch metrica](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) viene incrementata per ogni richiesta a livello di elemento non riuscita.
## Utilizzo delle transazioni in APIs DynamoDB Accelerator (DAX)
`TransactWriteItems` e `TransactGetItems` sono entrambi supportati in DynamoDB Accelerator (DAX) con gli stessi livelli di isolamento di DynamoDB.
`TransactWriteItems` scrive tramite DAX. DAX passa una chiamata `TransactWriteItems` a DynamoDB e restituisce la risposta. Per popolare la cache dopo la scrittura, DAX chiama `TransactGetItems` in background per ogni elemento nell'operazione `TransactWriteItems`che consuma unità di capacità di lettura aggiuntive. Per ulteriori informazioni, consulta [Gestione della capacità per le transazioni](#transaction-capacity-handling). Questa funzionalità consente di mantenere la logica dell'applicazione semplice e di utilizzare DAX per operazioni sia transazionali che non transazionali.
Le chiamate `TransactGetItems` vengono passate tramite DAX senza che gli elementi vengano memorizzati nella cache in locale. Si tratta dello stesso comportamento utilizzato per una lettura fortemente coerente in DAX. APIs
## Gestione della capacità per le transazioni
Non è previsto alcun costo aggiuntivo per abilitare le transazioni per le tabelle DynamoDB. Si paga solo per le letture o le scritture che fanno parte della transazione. DynamoDB esegue due letture o scritture sottostanti per ciascun elemento nella transazione: uno per preparare la transazione uno per eseguire il commit della transazione. Le due read/write operazioni sottostanti sono visibili nelle CloudWatch metriche di Amazon.
Pianifica le letture e le scritture aggiuntive richieste da Transactional APIs per fornire capacità alle tabelle. Ad esempio, si supponga che l'applicazione esegua una transazione al secondo e che ciascuna transazione scriva nella tabella tre elementi da 500 byte. Ogni articolo richiede due unità di capacità di scrittura (WCUs): una per preparare la transazione e l'altra per confermare la transazione. Pertanto, è necessario assegnarne sei WCUs alla tabella.
Se nell'esempio precedente si utilizzava DynamoDB Accelerator (DAX), si utilizzerebbero anche due unità di capacità di lettura RCUs () per ogni elemento della chiamata. `TransactWriteItems` Quindi è necessario aggiungere altre RCUs sei unità alla tabella.
Analogamente, se l'applicazione esegue una transazione di lettura al secondo e ogni transazione legge tre elementi da 500 byte della tabella, è necessario fornire sei unità di capacità di lettura (RCUs) alla tabella. La lettura di ogni elemento richiede due elementi RCUs: uno per preparare la transazione e uno per confermare la transazione.
Inoltre, il comportamento dell'SDK predefinito prevede di ritentare le transazioni in caso di un'eccezione `TransactionInProgressException`. Pianifica le unità di capacità di lettura aggiuntive (RCUs) utilizzate da questi nuovi tentativi. Lo stesso vale qualora si ritentino le transazioni nel proprio codice utilizzandone uno `ClientRequestToken`.
## Best practice per le transazioni
Durante l'utilizzo delle transazioni DynamoDB, considerare le seguenti best practice suggerite.
+ Abilita il dimensionamento automatico o assicurati di aver effettuato il provisioning di una capacità di throughput sufficiente da eseguire le due operazioni di lettura o scrittura per ogni item della transazione.
+ Se non utilizzi un SDK AWS fornito, includi un `ClientRequestToken` attributo quando effettui una `TransactWriteItems` chiamata per assicurarti che la richiesta sia idempotente.
+ Non raggruppare le operazioni in una transazione qualora non sia necessario. Ad esempio, se una singola transazione con 10 operazioni può essere suddivisa in diverse transazioni senza compromettere la correttezza dell'applicazione, si raccomanda di frazionare la transazione. Le transazioni più semplici migliorano il throughput e hanno maggiori probabilità di successo.
+ Diverse transazioni che aggiornano gli stessi item simultaneamente possono causare conflitti che annullano le transazioni. Per minimizzare tali conflitti, si consiglia di utilizzare le seguenti best practice DynamoDB per la modellazione dei dati.
+ Se un set di attributi viene spesso aggiornato tra più item come parte di una transazione singola, considera di raggruppare gli attributi in un singolo item per ridurre l'ambito della transazione.
+ Evita l'uso di transazioni per l'inserimento di dati in blocco. Per le scritture in blocco, è consigliabile utilizzare `BatchWriteItem`.
## Utilizzo di tabelle transazionali con tabelle globali APIs
Le operazioni transazionali forniscono garanzie di atomicità, coerenza, isolamento e durabilità (ACID) solo all'interno della AWS regione in cui è stata richiamata l'API di scrittura. Le transazioni non sono supportate tra le Regioni nelle tabelle globali. Ad esempio, supponi di avere una tabella globale con repliche nelle Regioni Stati Uniti orientali (Ohio) e Stati Uniti occidentali (Oregon) e di eseguire un'operazione `TransactWriteItems` nella Regione Stati Uniti orientali (Virginia settentrionale). In questo caso, è possibile osservare transazioni parzialmente completate nella Regione degli Stati Uniti occidentali (Oregon) mentre le modifiche vengono replicate. Le modifiche vengono replicate in altre Regioni solo dopo essere state confermate nella Regione di origine.
## DynamoDB Transactions e la libreria client delle transazioni AWSLabs
Le transazioni DynamoDB forniscono un sostituto più economico, robusto e performante della libreria client delle transazioni. [AWSLabs](https://github.com/awslabs) Ti suggeriamo di aggiornare le tue applicazioni per utilizzare la transazione nativa lato server. APIs
# Utilizzo di IAM con transazioni DynamoDB
Puoi usare AWS Identity and Access Management (IAM) per limitare le azioni che le operazioni transazionali possono eseguire in Amazon DynamoDB. Per ulteriori informazioni sull'uso di policy IAM in DynamoDB, consulta [Policy basate su identità per DynamoDB](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies).
Le autorizzazioni per le operazioni `Put`, `Update`, `Delete` e `Get` sono regolate dalle autorizzazioni utilizzate per le operazioni `PutItem`, `UpdateItem`, `DeleteItem` e `GetItem` sottostanti. Per l'operazione `ConditionCheck`, è possibile utilizzare l'autorizzazione `dynamodb:ConditionCheckItem` nelle policy IAM.
Di seguito sono riportati degli esempi di policy IAM che è possibile utilizzare per configurare le transazioni DynamoDB.
## Esempio 1: consentire le operazioni transazionali
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
]
}
]
}
```
------
## Esempio 2: consentire solo le operazioni transazionali
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
],
"Condition": {
"ForAnyValue:StringEquals": {
"dynamodb:EnclosingOperation": [
"TransactWriteItems",
"TransactGetItems"
]
}
}
}
]
}
```
------
## Esempio 3: consentire le letture e le scritture non transazionali e bloccare le letture e le scritture transazionali
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
],
"Condition": {
"ForAnyValue:StringEquals": {
"dynamodb:EnclosingOperation": [
"TransactWriteItems",
"TransactGetItems"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:UpdateItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
]
}
]
}
```
------
## Esempio 4: impedire che le informazioni vengano restituite in caso di errore ConditionCheck
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/table01",
"Condition": {
"StringEqualsIfExists": {
"dynamodb:ReturnValues": "NONE"
}
}
}
]
}
```
------
# Esempio di transazioni di DynamoDB
Come esempio di una situazione in cui le transazioni Amazon DynamoDB possono essere utili, si consideri questa applicazione Java di esempio per un marketplace online.
L'applicazione ha tre tabelle DynamoDB nel backend:
+ `Customers`: questa tabella archivia i dettagli sui clienti del marketplace. La sua chiave primaria è un identificatore univoco `CustomerId`.
+ `ProductCatalog`: questa tabella archivia dettagli quali prezzo e disponibilità dei prodotti in vendita nel marketplace. La sua chiave primaria è un identificatore univoco `ProductId`.
+ `Orders`: questa tabella archivia i dettagli sugli ordini del marketplace. La sua chiave primaria è un identificatore univoco `OrderId`.
## Come effettuare un ordine
I seguenti frammenti di codice illustrano come utilizzare le transazioni DynamoDB per coordinare i vari passaggi necessari per creare ed elaborare un ordine. L'utilizzo di una singola all-or-nothing operazione garantisce che, se una parte della transazione fallisce, non vengano eseguite azioni nella transazione e non vengano apportate modifiche.
In questo esempio, si configura un ordine da un cliente il cui `customerId` è `09e8e9c8-ec48`. Si esegue quindi come una singola transazione utilizzando il seguente flusso di lavoro semplice di elaborazione degli ordini:
1. Determinare che l'ID cliente sia valido.
1. Assicurati che il prodotto sia `IN_STOCK` e aggiornare lo stato del prodotto in `SOLD`.
1. Assicurati che l'ordine non esista già e creare l'ordine.
### Convalida del cliente
Per prima cosa, definire un'azione per verificare che un cliente con `customerId` uguale a `09e8e9c8-ec48` esista nella tabella dei clienti.
```
final String CUSTOMER_TABLE_NAME = "Customers";
final String CUSTOMER_PARTITION_KEY = "CustomerId";
final String customerId = "09e8e9c8-ec48";
final HashMap customerItemKey = new HashMap<>();
customerItemKey.put(CUSTOMER_PARTITION_KEY, new AttributeValue(customerId));
ConditionCheck checkCustomerValid = new ConditionCheck()
.withTableName(CUSTOMER_TABLE_NAME)
.withKey(customerItemKey)
.withConditionExpression("attribute_exists(" + CUSTOMER_PARTITION_KEY + ")");
```
### Aggiornamento dello stato dei prodotti
Quindi, definire un'operazione per aggiornare lo stato del prodotto in `SOLD` se la condizione in cui lo stato del prodotto è attualmente impostato su `IN_STOCK` è `true`. La configurazione del parametro `ReturnValuesOnConditionCheckFailure` restituisce l'elemento se l'attributo dello stato del prodotto dell'elemento non era uguale a `IN_STOCK`.
```
final String PRODUCT_TABLE_NAME = "ProductCatalog";
final String PRODUCT_PARTITION_KEY = "ProductId";
HashMap productItemKey = new HashMap<>();
productItemKey.put(PRODUCT_PARTITION_KEY, new AttributeValue(productKey));
Map expressionAttributeValues = new HashMap<>();
expressionAttributeValues.put(":new_status", new AttributeValue("SOLD"));
expressionAttributeValues.put(":expected_status", new AttributeValue("IN_STOCK"));
Update markItemSold = new Update()
.withTableName(PRODUCT_TABLE_NAME)
.withKey(productItemKey)
.withUpdateExpression("SET ProductStatus = :new_status")
.withExpressionAttributeValues(expressionAttributeValues)
.withConditionExpression("ProductStatus = :expected_status")
.withReturnValuesOnConditionCheckFailure(ReturnValuesOnConditionCheckFailure.ALL_OLD);
```
### Creazione dell'ordine
Infine, creare l'ordine se un ordine con quell'`OrderId` non esiste già.
```
final String ORDER_PARTITION_KEY = "OrderId";
final String ORDER_TABLE_NAME = "Orders";
HashMap orderItem = new HashMap<>();
orderItem.put(ORDER_PARTITION_KEY, new AttributeValue(orderId));
orderItem.put(PRODUCT_PARTITION_KEY, new AttributeValue(productKey));
orderItem.put(CUSTOMER_PARTITION_KEY, new AttributeValue(customerId));
orderItem.put("OrderStatus", new AttributeValue("CONFIRMED"));
orderItem.put("OrderTotal", new AttributeValue("100"));
Put createOrder = new Put()
.withTableName(ORDER_TABLE_NAME)
.withItem(orderItem)
.withReturnValuesOnConditionCheckFailure(ReturnValuesOnConditionCheckFailure.ALL_OLD)
.withConditionExpression("attribute_not_exists(" + ORDER_PARTITION_KEY + ")");
```
### Esecuzione della transazione
L'esempio seguente illustra come eseguire le azioni definite in precedenza come singola all-or-nothing operazione.
```
Collection actions = Arrays.asList(
new TransactWriteItem().withConditionCheck(checkCustomerValid),
new TransactWriteItem().withUpdate(markItemSold),
new TransactWriteItem().withPut(createOrder));
TransactWriteItemsRequest placeOrderTransaction = new TransactWriteItemsRequest()
.withTransactItems(actions)
.withReturnConsumedCapacity(ReturnConsumedCapacity.TOTAL);
// Run the transaction and process the result.
try {
client.transactWriteItems(placeOrderTransaction);
System.out.println("Transaction Successful");
} catch (ResourceNotFoundException rnf) {
System.err.println("One of the table involved in the transaction is not found" + rnf.getMessage());
} catch (InternalServerErrorException ise) {
System.err.println("Internal Server Error" + ise.getMessage());
} catch (TransactionCanceledException tce) {
System.out.println("Transaction Canceled " + tce.getMessage());
}
```
## Lettura dei dettagli dell'ordine
L'esempio seguente mostra come leggere l'ordine completato in modo transazionale attraverso le tabelle `Orders` e `ProductCatalog`.
```
HashMap productItemKey = new HashMap<>();
productItemKey.put(PRODUCT_PARTITION_KEY, new AttributeValue(productKey));
HashMap orderKey = new HashMap<>();
orderKey.put(ORDER_PARTITION_KEY, new AttributeValue(orderId));
Get readProductSold = new Get()
.withTableName(PRODUCT_TABLE_NAME)
.withKey(productItemKey);
Get readCreatedOrder = new Get()
.withTableName(ORDER_TABLE_NAME)
.withKey(orderKey);
Collection getActions = Arrays.asList(
new TransactGetItem().withGet(readProductSold),
new TransactGetItem().withGet(readCreatedOrder));
TransactGetItemsRequest readCompletedOrder = new TransactGetItemsRequest()
.withTransactItems(getActions)
.withReturnConsumedCapacity(ReturnConsumedCapacity.TOTAL);
// Run the transaction and process the result.
try {
TransactGetItemsResult result = client.transactGetItems(readCompletedOrder);
System.out.println(result.getResponses());
} catch (ResourceNotFoundException rnf) {
System.err.println("One of the table involved in the transaction is not found" + rnf.getMessage());
} catch (InternalServerErrorException ise) {
System.err.println("Internal Server Error" + ise.getMessage());
} catch (TransactionCanceledException tce) {
System.err.println("Transaction Canceled" + tce.getMessage());
}
```
# Change Data Capture con Amazon DynamoDB
Molte applicazioni traggono vantaggio dalla possibilità di acquisire le modifiche apportate a elementi archiviati in una tabella DynamoDB, nel momento in cui si verificano tali modifiche. Di seguito sono riportati alcuni esempi di casi d'uso:
+ Un'applicazione per dispositivi mobili popolare modifica i dati in una tabella DynamoDB alla velocità di migliaia di aggiornamenti al secondo. Un'altra applicazione acquisisce e archivia i dati relativi a questi aggiornamenti, fornendo metriche di near-real-time utilizzo per l'app mobile.
+ Un'applicazione finanziaria modifica i dati del mercato azionario in una tabella DynamoDB. Diverse applicazioni eseguite in parallelo tracciano questi cambiamenti in tempo reale, calcolano e value-at-risk ribilanciano automaticamente i portafogli in base ai movimenti dei prezzi delle azioni.
+ I sensori nei veicoli di trasporto e nelle attrezzature industriali inviano dati a una tabella DynamoDB. Diverse applicazioni monitorano le prestazioni e inviano avvisi di messaggistica quando viene rilevato un problema, prevedono eventuali difetti applicando algoritmi di machine learning e comprimono e archiviano i dati in Amazon Simple Storage Service (Amazon S3).
+ Un'applicazione invia automaticamente notifiche ai dispositivi mobili di tutti gli amici inclusi in un gruppo non appena un amico carica una nuova immagine.
+ Un nuovo cliente aggiunge dati a una tabella DynamoDB. Questo evento richiama un'altra applicazione che invia un'e-mail di benvenuto al nuovo cliente.
DynamoDB supporta lo streaming dei record di acquisizione dei dati delle modifiche a livello di elemento in tempo quasi reale. È possibile creare applicazioni che utilizzano questi flussi e agiscono in base al contenuto.
**Nota**
L’aggiunta di tag ai flussi DynamoDB e l’utilizzo del [controllo degli accessi basato su attributi (ABAC)](access-control-resource-based.md) con i flussi DynamoDB non sono supportati.
Il seguente video ti fornirà un'introduzione sul concetto di acquisizione dei dati di modifica.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/VVv_-mZ5Ge8)
**Topics**
+ [Opzioni di streaming per Change Data Capture](#streamsmain.choose)
+ [Utilizzo di Kinesis Data Streams per acquisire le modifiche apportate a Dynamo DB.](kds.md)
+ [Acquisizione dei dati di modifica per DynamoDB Streams](Streams.md)
## Opzioni di streaming per Change Data Capture
DynamoDB offre due modelli di streaming per l'acquisizione dei dati delle modifiche: Kinesis Data Streams per DynamoDB e DynamoDB Streams.
Per scegliere la soluzione più adatta per l'applicazione, la tabella seguente riassume le caratteristiche di ciascun modello di streaming.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/streamsmain.html)
È possibile abilitare entrambi i modelli di streaming sulla stessa tabella DynamoDB.
Il video seguente analizza ulteriormente le differenze tra le due opzioni.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/UgG17Wh2y0g)
# Utilizzo di Kinesis Data Streams per acquisire le modifiche apportate a Dynamo DB.
Utilizzare Amazon Kinesis Data Streams per acquisire le modifiche apportate a Amazon DynamoDB.
Kinesis Data Streams acquisisce le modifiche a livello di elemento in qualsiasi tabella DynamoDB e le replica in un [flusso dei dati Kinesis](https://docs.aws.amazon.com/streams/latest/dev/introduction.html). Le applicazioni possono accedere a questo flusso e visualizzare le modifiche a livello di elemento quasi in tempo reale. Puoi acquisire e archiviare in modo continuo terabyte di dati ogni ora. Puoi sfruttare tempi di conservazione dei dati più lunghi e, grazie alla funzionalità di fan-out migliorata, puoi raggiungere contemporaneamente due o più applicazioni downstream. Altri vantaggi includono controlli aggiuntivi e trasparenza della sicurezza.
Il flusso di dati Kinesis consente inoltre di accedere ad [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) e al [Servizio gestito da Amazon per Apache Flink](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/what-is.html). Questi servizi consentono di creare applicazioni per utilizzare pannelli di controllo in tempo reale, generare avvisi, implementare prezzi e inserzioni dinamici ed eseguire analisi dei dati e algoritmi di machine learning sofisticati.
**Nota**
[L'utilizzo di Kinesis Data Streams per DynamoDB è soggetto sia ai prezzi di Kinesis Data Streams per il flusso di dati che ai [prezzi di DynamoDB per](https://aws.amazon.com/kinesis/data-streams/pricing/) la tabella di origine.](https://aws.amazon.com/dynamodb/pricing/)
Per abilitare lo streaming Kinesis su una tabella DynamoDB utilizzando la console o Java SDK AWS CLI, consulta. [Nozioni di base su Kinesis Data Streams per Amazon DynamoDB](kds_gettingstarted.md)
**Topics**
+ [Funzionamento di Kinesis Data Streams con DynamoDB](#kds_howitworks)
+ [Nozioni di base su Kinesis Data Streams per Amazon DynamoDB](kds_gettingstarted.md)
+ [Utilizzo di shard e metriche con i flussi DynamoDB e il flusso di dati Kinesis](kds_using-shards-and-metrics.md)
+ [Utilizzo di policy IAM per il flusso di dati Amazon Kinesis e Amazon DynamoDB](kds_iam.md)
## Funzionamento di Kinesis Data Streams con DynamoDB
Quando un flusso dei dati Kinesis è abilitato per una tabella DynamoDB, quest'ultima invia un record di dati che acquisisce eventuali modifiche ai dati della tabella. Questo record di dati include:
+ L'ora specifica in cui qualsiasi elemento è stato creato, aggiornato o eliminato di recente
+ La chiave primaria di quell'elemento
+ Uno snapshot del record prima della modifica
+ Uno snapshot del record dopo la modifica
Questi record di dati vengono acquisiti e pubblicati quasi in tempo reale. Dopo essere stati scritti sul flusso dei dati Kinesis, possono essere letti come qualsiasi altro record. È possibile utilizzare la Kinesis Client Library, utilizzare AWS Lambda, chiamare l'API Kinesis Data Streams e utilizzare altri servizi connessi. Per ulteriori informazioni, consulta [Lettura di dati da Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/building-consumers.html) nella Guida per gli sviluppatori di Amazon Kinesis Data Streams.
Queste modifiche dei dati vengono acquisite anche in modo asincrono. Kinesis non ha alcun impatto sulle prestazioni di una tabella da cui esegue lo streaming. I record del flusso archiviati nel flusso dei dati Kinesis sono crittografati anche a riposo. Per ulteriori informazioni, consulta [Protezione dei dati in Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html).
I record del flusso di dati Kinesis potrebbero essere visualizzati in un ordine diverso rispetto alle modifiche apportate all’elemento. Le notifiche dello stesso elemento potrebbero apparire anche più di una volta nel flusso. È possibile controllare l’attributo `ApproximateCreationDateTime` per identificare l’ordine in cui sono state apportate le modifiche all’elemento e i record duplicati.
Abilitando un flusso di dati Kinesis come destinazione di streaming di una tabella DynamoDB, è possibile configurare la precisione dei valori `ApproximateCreationDateTime` in millisecondi o microsecondi. Per impostazione predefinita, `ApproximateCreationDateTime` indica l’ora della modifica in millisecondi. Inoltre, è possibile modificare questo valore su una destinazione di streaming attiva. Dopo tale aggiornamento, i record di flussi scritti su Kinesis avranno i valori `ApproximateCreationDateTime` della precisione desiderata.
I valori binari scritti in DynamoDB devono essere codificati in [formato con codifica base64](HowItWorks.NamingRulesDataTypes.md). Tuttavia, quando i record di dati vengono scritti su un flusso di dati Kinesis, questi valori binari codificati vengono codificati una seconda volta con la codifica base64. Quando leggono questi record da un flusso di dati Kinesis, per recuperare i valori binari non elaborati, le applicazioni devono decodificare questi valori due volte.
DynamoDB addebita l’utilizzo di Kinesis Data Streams nelle unità di acquisizione dei dati di modifica. 1 KB di modifica per singolo elemento conta come un'unità di acquisizione dei dati di modifica. I KB di modifica in ogni elemento sono calcolati in base alla più grande delle immagini "prima" e "dopo" dell'elemento scritto nello stream, utilizzando la stessa logica di [consumo di unità di capacità per operazioni di scrittura](read-write-operations.md#write-operation-consumption). In modo analogo al funzionamento della modalità [on demand](capacity-mode.md#capacity-mode-on-demand) di DynamoDB, non è necessario effettuare il provisioning del throughput della capacità per le unità di acquisizione dei dati di modifica.
### Attivazione di un flusso di dati Kinesis per la tabella DynamoDB
Puoi abilitare o disabilitare lo streaming su Kinesis dalla tabella DynamoDB esistente utilizzando l' Console di gestione AWS, l' AWS SDK o il (). AWS Command Line Interface AWS CLI
+ Puoi trasmettere dati da DynamoDB a Kinesis Data Streams solo nello stesso account e nella stessa regione AWS della tabella. AWS
+ Puoi eseguire lo streaming dei dati solo da una tabella DynamoDB a un flusso dei dati Kinesis.
### Applicazione di modifiche a una destinazione di un flusso di dati Kinesis su una tabella DynamoDB
Per impostazione predefinita, tutti i record del flusso di dati Kinesis includono un attributo `ApproximateCreationDateTime`. Questo attributo rappresenta un timestamp in millisecondi dell’ora approssimativa in cui ogni record è stato creato. È possibile modificare la precisione di questi valori utilizzando [https://console.aws.amazon.com/kinesis, l'SDK](https://console.aws.amazon.com/kinesis) o il AWS CLI
# Nozioni di base su Kinesis Data Streams per Amazon DynamoDB
Questa sezione descrive come utilizzare Kinesis Data Streams per le tabelle Amazon DynamoDB con la console Amazon DynamoDB, il () e l'API AWS Command Line Interface .AWS CLI
## Creazione di un flusso di dati Amazon Kinesis attivo
Tutti questi esempi utilizzano la tabella DynamoDB `Music` che è stata creata come parte del tutorial [Nozioni di base su DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html).
Per ulteriori informazioni su come creare consumatori e connettere il flusso di dati Kinesis ad altri servizi AWS , consulta [Leggere i dati dal flusso di dati Amazon Kinesis](https://docs.aws.amazon.com/streams/latest/dev/building-consumers.html), nella *Guida per gli sviluppatori del flusso di dati Amazon Kinesis*.
**Nota**
Quando utilizzi per la prima volta le partizioni KDS, consigliamo di impostarle in modo che aumentino o diminuiscano in base ai modelli di utilizzo. Dopo aver accumulato ulteriori dati sui modelli di utilizzo, è possibile adattare le partizioni nel flusso di conseguenza.
------
#### [ Console ]
1. Accedi Console di gestione AWS e apri la console Kinesis all'indirizzo. [https://console.aws.amazon.com/kinesis/](https://console.aws.amazon.com/kinesis/)
1. Scegli **Crea flusso di dati** e segui le istruzioni per creare un flusso denominato `samplestream`.
1. Apri la console DynamoDB all'indirizzo. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Nel riquadro di navigazione sul lato sinistro della console scegli **Tables (Tabelle)**.
1. Seleziona la tabella **Music**.
1. Scegli la scheda **Exports and streams (Esportazioni e flussi)**.
1. (Facoltativo) Nella sezione **Dettagli del flusso di dati Amazon Kinesis**, è possibile modificare la precisione del timestamp del record da microsecondi (impostazione predefinita) a millisecondi.
1. Scegli **samplestream** dall'elenco a discesa.
1. Seleziona il pulsante **Attiva**.
------
#### [ AWS CLI ]
1. Crea un flusso di dati Kinesis denominato `samplestream` utilizzando il comando [create-stream](https://docs.aws.amazon.com/cli/latest/reference/kinesis/create-stream.html).
```
aws kinesis create-stream --stream-name samplestream --shard-count 3
```
Prima di configurare il numero di partizioni per il flusso di dati Kinesis, consulta [Considerazioni sulla gestione delle partizioni per Kinesis Data Streams](kds_using-shards-and-metrics.md#kds_using-shards-and-metrics.shardmanagment).
1. Verificare che il flusso Kinesis sia attivo e pronto per l'uso utilizzando il comando [describe-stream](https://docs.aws.amazon.com/cli/latest/reference/kinesis/describe-stream.html).
```
aws kinesis describe-stream --stream-name samplestream
```
1. Abilitare lo streaming di Kinesis sulla tabella DynamoDB utilizzando il comando DynamoDB `enable-kinesis-streaming-destination`. Sostituisci il valore `stream-arn` con quello restituito da `describe-stream` nella fase precedente. Facoltativamente, abilita lo streaming con una precisione più granulare (microsecondi) dei valori di timestamp restituiti su ogni record.
Abilita lo streaming con la precisione del timestamp in microsecondi:
```
aws dynamodb enable-kinesis-streaming-destination \
--table-name Music \
--stream-arn arn:aws:kinesis:us-west-2:12345678901:stream/samplestream
--enable-kinesis-streaming-configuration ApproximateCreationDateTimePrecision=MICROSECOND
```
Oppure abilita lo streaming con la precisione del timestamp predefinita (millisecondi):
```
aws dynamodb enable-kinesis-streaming-destination \
--table-name Music \
--stream-arn arn:aws:kinesis:us-west-2:12345678901:stream/samplestream
```
1. Abilitare lo streaming di Kinesis sulla tabella DynamoDB utilizzando il comando `describe-kinesis-streaming-destination` DynamoDB.
```
aws dynamodb describe-kinesis-streaming-destination --table-name Music
```
1. Scrivere i dati nella tabella DynamoDB utilizzando il comando `put-item`, come descritto nella [Guida per gli sviluppatori di DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-2.html).
```
aws dynamodb put-item \
--table-name Music \
--item \
'{"Artist": {"S": "No One You Know"}, "SongTitle": {"S": "Call Me Today"}, "AlbumTitle": {"S": "Somewhat Famous"}, "Awards": {"N": "1"}}'
aws dynamodb put-item \
--table-name Music \
--item \
'{"Artist": {"S": "Acme Band"}, "SongTitle": {"S": "Happy Day"}, "AlbumTitle": {"S": "Songs About Life"}, "Awards": {"N": "10"} }'
```
1. Utilizza il comando [get-record](https://docs.aws.amazon.com/cli/latest/reference/kinesis/get-records.html) della CLI di Kinesis per recuperare il contenuto del flusso Kinesis. Quindi utilizzare il seguente frammento di codice per deserializzare il contenuto del flusso.
```
/**
* Takes as input a Record fetched from Kinesis and does arbitrary processing as an example.
*/
public void processRecord(Record kinesisRecord) throws IOException {
ByteBuffer kdsRecordByteBuffer = kinesisRecord.getData();
JsonNode rootNode = OBJECT_MAPPER.readTree(kdsRecordByteBuffer.array());
JsonNode dynamoDBRecord = rootNode.get("dynamodb");
JsonNode oldItemImage = dynamoDBRecord.get("OldImage");
JsonNode newItemImage = dynamoDBRecord.get("NewImage");
Instant recordTimestamp = fetchTimestamp(dynamoDBRecord);
/**
* Say for example our record contains a String attribute named "stringName" and we want to fetch the value
* of this attribute from the new item image. The following code fetches this value.
*/
JsonNode attributeNode = newItemImage.get("stringName");
JsonNode attributeValueNode = attributeNode.get("S"); // Using DynamoDB "S" type attribute
String attributeValue = attributeValueNode.textValue();
System.out.println(attributeValue);
}
private Instant fetchTimestamp(JsonNode dynamoDBRecord) {
JsonNode timestampJson = dynamoDBRecord.get("ApproximateCreationDateTime");
JsonNode timestampPrecisionJson = dynamoDBRecord.get("ApproximateCreationDateTimePrecision");
if (timestampPrecisionJson != null && timestampPrecisionJson.equals("MICROSECOND")) {
return Instant.EPOCH.plus(timestampJson.longValue(), ChronoUnit.MICROS);
}
return Instant.ofEpochMilli(timestampJson.longValue());
}
```
------
#### [ Java ]
1. Seguire le istruzioni contenute nella guida per gli sviluppatori di Kinesis Data Streams per [creare](https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-create-stream.html) un flusso di dati Kinesis denominato `samplestream` tramite Java.
Prima di configurare il numero di partizioni per il flusso di dati Kinesis, consulta [Considerazioni sulla gestione delle partizioni per Kinesis Data Streams](kds_using-shards-and-metrics.md#kds_using-shards-and-metrics.shardmanagment).
1. Utilizzo il seguente frammento di codice per abilitare lo streamingKinesis sulla tabella DynamoDB. Facoltativamente, abilita lo streaming con una precisione più granulare (microsecondi) dei valori di timestamp restituiti su ogni record.
Abilita lo streaming con la precisione del timestamp in microsecondi:
```
EnableKinesisStreamingConfiguration enableKdsConfig = EnableKinesisStreamingConfiguration.builder()
.approximateCreationDateTimePrecision(ApproximateCreationDateTimePrecision.MICROSECOND)
.build();
EnableKinesisStreamingDestinationRequest enableKdsRequest = EnableKinesisStreamingDestinationRequest.builder()
.tableName(tableName)
.streamArn(kdsArn)
.enableKinesisStreamingConfiguration(enableKdsConfig)
.build();
EnableKinesisStreamingDestinationResponse enableKdsResponse = ddbClient.enableKinesisStreamingDestination(enableKdsRequest);
```
Oppure abilita lo streaming con la precisione del timestamp predefinita (millisecondi):
```
EnableKinesisStreamingDestinationRequest enableKdsRequest = EnableKinesisStreamingDestinationRequest.builder()
.tableName(tableName)
.streamArn(kdsArn)
.build();
EnableKinesisStreamingDestinationResponse enableKdsResponse = ddbClient.enableKinesisStreamingDestination(enableKdsRequest);
```
1. Segui le istruzioni contenute nella guida per gli sviluppatori di *Kinesis Data Streams* per [leggere](https://docs.aws.amazon.com/streams/latest/dev/building-consumers.html) dal flusso di dati creato.
1. Utilizza il seguente frammento di codice per deserializzare il contenuto del flusso.
```
/**
* Takes as input a Record fetched from Kinesis and does arbitrary processing as an example.
*/
public void processRecord(Record kinesisRecord) throws IOException {
ByteBuffer kdsRecordByteBuffer = kinesisRecord.getData();
JsonNode rootNode = OBJECT_MAPPER.readTree(kdsRecordByteBuffer.array());
JsonNode dynamoDBRecord = rootNode.get("dynamodb");
JsonNode oldItemImage = dynamoDBRecord.get("OldImage");
JsonNode newItemImage = dynamoDBRecord.get("NewImage");
Instant recordTimestamp = fetchTimestamp(dynamoDBRecord);
/**
* Say for example our record contains a String attribute named "stringName" and we wanted to fetch the value
* of this attribute from the new item image, the below code would fetch this.
*/
JsonNode attributeNode = newItemImage.get("stringName");
JsonNode attributeValueNode = attributeNode.get("S"); // Using DynamoDB "S" type attribute
String attributeValue = attributeValueNode.textValue();
System.out.println(attributeValue);
}
private Instant fetchTimestamp(JsonNode dynamoDBRecord) {
JsonNode timestampJson = dynamoDBRecord.get("ApproximateCreationDateTime");
JsonNode timestampPrecisionJson = dynamoDBRecord.get("ApproximateCreationDateTimePrecision");
if (timestampPrecisionJson != null && timestampPrecisionJson.equals("MICROSECOND")) {
return Instant.EPOCH.plus(timestampJson.longValue(), ChronoUnit.MICROS);
}
return Instant.ofEpochMilli(timestampJson.longValue());
}
```
------
## Applicazione di modifiche a un flusso di dati Amazon Kinesis attivo
Questa sezione descrive come apportare modifiche a una configurazione attiva di Kinesis Data Streams for DynamoDB utilizzando la console e l'API. AWS CLI
**Console di gestione AWS**
1. Apri la console DynamoDB all'indirizzo [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Vai alla tabella.
1. Seleziona la scheda **Esportazioni e flussi**.
**AWS CLI**
1. Chiama `describe-kinesis-streaming-destination` per confermare che il flusso sia `ACTIVE`.
1. Chiama `UpdateKinesisStreamingDestination`, come in questo esempio:
```
aws dynamodb update-kinesis-streaming-destination --table-name enable_test_table --stream-arn arn:aws:kinesis:us-east-1:12345678901:stream/enable_test_stream --update-kinesis-streaming-configuration ApproximateCreationDateTimePrecision=MICROSECOND
```
1. Chiama `describe-kinesis-streaming-destination` per confermare che il flusso sia `UPDATING`.
1. Chiama `describe-kinesis-streaming-destination` periodicamente fino a quando lo stato dello streaming non è nuovamente `ACTIVE`. In genere sono necessari fino a 5 minuti perché gli aggiornamenti alla precisione del timestamp entrino in vigore. Una volta che lo stato è aggiornato, significa che l’aggiornamento è completo e il nuovo valore di precisione verrà applicato ai record futuri.
1. Scrivi nella tabella usando `putItem`.
1. Utilizza il comando `get-records` di Kinesis per recuperare il contenuto del flusso.
1. Verifica che `ApproximateCreationDateTime` delle scritture presenti la precisione desiderata.
**API Java**
1. Fornisci un frammento di codice che costruisce una richiesta `UpdateKinesisStreamingDestination` e una risposta `UpdateKinesisStreamingDestination`.
1. Fornisci un frammento di codice che costruisce una richiesta `DescribeKinesisStreamingDestination` e una `DescribeKinesisStreamingDestination response`.
1. Chiama `describe-kinesis-streaming-destination` periodicamente fino a quando lo stato dello streaming non è nuovamente `ACTIVE`, a indicare che l’aggiornamento è completo e il nuovo valore di precisione verrà applicato ai record futuri.
1. Effettua le scritture sulla tabella.
1. Effettua la lettura dal flusso e deserializza il contenuto del flusso.
1. Verifica che `ApproximateCreationDateTime` delle scritture presenti la precisione desiderata.
# Utilizzo di shard e metriche con i flussi DynamoDB e il flusso di dati Kinesis
## Considerazioni sulla gestione delle partizioni per Kinesis Data Streams
Un flusso dei dati Kinesis calcola il proprio throughput in [partizioni](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html). Nel flusso di dati Amazon Kinesis è possibile scegliere tra la modalità con capacità on demand**** e la modalità **con provisioning** per i flussi di dati.
Si consiglia di utilizzare la modalità on demand per il flusso di dati Kinesis se il carico di lavoro di scrittura di DynamoDB è altamente variabile e imprevedibile. Con la modalità on demand, non è richiesta pianificazione della capacità in quanto il flusso di dati Kinesis gestisce automaticamente gli shard per fornire il throughput necessario.
Per carichi di lavoro prevedibili è possibile utilizzare la modalità con provisioning per il flusso di dati Kinesis. Con la modalità con provisioning, è necessario specificare il numero di shard per il flusso di dati per ricevere i record di Change Data Capture da DynamoDB. Per determinare il numero di shard di cui il flusso di dati Kinesis avrà bisogno per supportare la tabella DynamoDB sono necessari i seguenti valori di input:
+ La dimensione media del record della tabella DynamoDB in byte (`average_record_size_in_bytes`).
+ Il numero massimo di operazioni di scrittura che la tabella DynamoDB eseguirà al secondo. Questo include le operazioni di creazione, eliminazione e aggiornamento eseguite dalle applicazioni, nonché le operazioni generate automaticamente come le eliminazioni generate dal Time to Live (TTL) (`write_throughput`).
+ La percentuale di operazioni di aggiornamento e sovrascrittura eseguite sulla tabella, rispetto alle operazioni di creazione o eliminazione (`percentage_of_updates`). Tieni a mente che le operazioni di aggiornamento e sovrascrittura replicano nel flusso sia le vecchie che le nuove immagini dell'elemento modificato al flusso. Questo genera il doppio della dimensione dell'elemento DynamoDB.
È possibile calcolare il numero di shard (`number_of_shards`) di cui il flusso di dati Kinesis ha bisogno utilizzando i valori di input nella formula seguente:
```
number_of_shards = ceiling( max( ((write_throughput * (4+percentage_of_updates) * average_record_size_in_bytes) / 1024 / 1024), (write_throughput/1000)), 1)
```
Ad esempio, si potrebbe avere un throughput massimo di 1040 operazioni di scrittura al secondo (`write_throughput`) con una dimensione media dei record di 800 byte (`average_record_size_in_bytes)`. Se il 25% di queste operazioni di scrittura sono operazioni di aggiornamento (`percentage_of_updates`) allora saranno necessari due shard (`number_of_shards`) per supportare il throughput di streaming DynamoDB:
```
ceiling( max( ((1040 * (4+25/100) * 800)/ 1024 / 1024), (1040/1000)), 1).
```
Considera quanto segue prima di utilizzare la formula per calcolare il numero di shard necessari con la modalità con provisioning per il flusso di dati Kinesis:
+ Questa formula aiuta a stimare il numero di shard necessari per ospitare i record di dati di modifica di DynamoDB. Non rappresenta il numero totale di shard necessari nel flusso di dati Kinesis, ad esempio gli shard necessari per supportare consumer del flusso di dati Kinesis aggiuntivi.
+ Nella modalità assegnata è possibile che si verifichino comunque eccezioni di velocità di trasmissione effettiva di lettura e scrittura se non si configura il flusso di dati per gestire i picchi di velocità di trasmissione effettiva. In questo caso, è necessario dimensionare manualmente il flusso di dati in modo da adattarlo al traffico di dati.
+ Questa formula prende in considerazione il bloat aggiuntivo generato da DynamoDB prima di trasmettere i record di dati dei log delle modifiche ai flussi di dati Kinesis.
Per ulteriori informazioni sulle modalità di capacità sul flusso di dati Kinesis, consulta [Scelta della modalità di capacità del flusso di dati](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html). Per ulteriori informazioni sulla differenza di prezzo tra le diverse modalità di capacità, consulta [Prezzi del flusso di dati Amazon Kinesis](https://aws.amazon.com/kinesis/data-streams/pricing/).
## Monitoraggio di Change Data Capture con Kinesis Data Streams
DynamoDB fornisce diversi parametri CloudWatch Amazon per aiutarti a monitorare la replica dell'acquisizione dei dati di modifica su Kinesis. Per un elenco completo delle metriche, consulta. CloudWatch [Parametri e dimensioni di DynamoDB](metrics-dimensions.md)
Per determinare se il flusso dispone di capacità sufficiente, si consiglia di monitorare i seguenti elementi sia durante l'abilitazione del flusso che in produzione:
+ `ThrottledPutRecordCount`: il numero di record che sono stati limitati dal flusso dei dati Kinesis a causa della capacità insufficiente del flusso di dati Kinesis. Potrebbe verificarsi una limitazione della larghezza di banda della rete durante i picchi di utilizzo eccezionali, ma il `ThrottledPutRecordCount` dovrebbe rimanere il più basso possibile. DynamoDB prova a inviare i record con limitazione sul flusso di dati Kinesis, ma ciò potrebbe comportare una maggiore latenza di replica.
Se si verifica una limitazione eccessiva e regolare, potrebbe essere necessario aumentare il numero di partizioni del flusso Kinesis proporzionalmente alla velocità di scrittura osservata della tabella. Per ulteriori informazioni su come determinare le dimensioni di un flusso di dati Kinesis, consulta [Determinazione delle dimensioni iniziali di un flusso di dati Kinesis](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-streams.html#how-do-i-size-a-stream).
+ `AgeOfOldestUnreplicatedRecord`: il tempo trascorso dalla modifica a livello di elemento meno recente da replicare nel flusso di dati Kinesis è apparso nella tabella DynamoDB. In condizioni di funzionamento normale, `AgeOfOldestUnreplicatedRecord` dovrebbe essere nell'ordine dei millisecondi. Questo numero aumenta in base ai tentativi di replica non riusciti quando questi sono causati da scelte di configurazione controllate dal cliente.
Se la metrica `AgeOfOldestUnreplicatedRecord` supera le 168 ore, la replica delle modifiche a livello di elemento dalla tabella DynamoDB al flusso di dati Kinesis verrà automaticamente disabilitata.
Gli esempi di configurazioni controllate dal cliente che portano a tentativi di replica non riusciti sono una capacità del flusso dei dati Kinesis con provisioning insufficiente, che comporta una limitazione eccessiva o un aggiornamento manuale delle policy di accesso del flusso dei dati Kinesis, che impedisce a DynamoDB di aggiungere dati al flusso dei dati. Per mantenere questo parametro il più basso possibile, potrebbe essere necessario garantire il corretto provisioning della capacità del flusso di dati Kinesis e assicurarsi che le autorizzazioni di DynamoDB siano invariate.
+ `FailedToReplicateRecordCount`: il numero di record che DynamoDB non è riuscito a replicare nel flusso dei dati Kinesis. Alcuni elementi di dimensioni superiori a 34 KB potrebbero espandersi per modificare i record di dati superiori al limite di dimensioni di 1 MB degli elementi di Kinesis Data Streams. Questo aumento delle dimensioni si verifica quando gli elementi più grandi di 34 KB includono un numero elevato di valori booleani o vuoti degli attributi. I valori booleani e vuoti degli attributi vengono archiviati come 1 byte in DynamoDB, ma si espandono fino a 5 byte quando vengono serializzati utilizzando JSON standard per la replica di Kinesis Data Streams. DynamoDB non può replicare tali record di modifica nel flusso dei dati Kinesis. DynamoDB ignora questi record di dati di modifica e continua automaticamente a replicare i record successivi.
Puoi creare CloudWatch allarmi Amazon che inviano un messaggio Amazon Simple Notification Service (Amazon SNS) per la notifica quando una delle metriche precedenti supera una soglia specifica.
# Utilizzo di policy IAM per il flusso di dati Amazon Kinesis e Amazon DynamoDB
La prima volta che abiliti Amazon Kinesis Data Streams per Amazon DynamoDB, DynamoDB crea automaticamente un ruolo collegato al servizio (IAM) per te. AWS Identity and Access Management Questo ruolo, `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication`, consente a DynamoDB di gestire la replica delle modifiche a livello di elemento ai Kinesis Data Streams per conto dell'utente. Non eliminare questo ruolo collegato al servizio.
Per ulteriori informazioni sui ruoli collegati al servizio, consulta [Utilizzo dei ruoli collegati al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) nella *Guida per l'utente IAM*.
**Nota**
DynamoDB non supporta le condizioni basate sui tag per le policy IAM.
Per abilitare il flusso di dati Amazon Kinesis per Amazon DynamoDB, è necessario disporre delle seguenti autorizzazioni sulla tabella:
+ `dynamodb:EnableKinesisStreamingDestination`
+ `kinesis:ListStreams`
+ `kinesis:PutRecords`
+ `kinesis:DescribeStream`
Per descrivere il flusso di dati Amazon Kinesis per Amazon DynamoDB per una determinata tabella DynamoDB, è necessario disporre delle seguenti autorizzazioni sulla tabella.
+ `dynamodb:DescribeKinesisStreamingDestination`
+ `kinesis:DescribeStreamSummary`
+ `kinesis:DescribeStream`
Per disabilitare il flusso di dati Amazon Kinesis per Amazon DynamoDB, è necessario disporre delle seguenti autorizzazioni sulla tabella.
+ `dynamodb:DisableKinesisStreamingDestination`
Per aggiornare un flusso di dati Amazon Kinesis per Amazon DynamoDB, è necessario disporre delle seguenti autorizzazioni sulla tabella.
+ `dynamodb:UpdateKinesisStreamingDestination`
Gli esempi seguenti mostrano come utilizzare le policy IAM per concedere autorizzazioni per Amazon Kinesis Data Streams per Amazon DynamoDB.
## Esempio: abilitazione di Amazon Kinesis Data Streams per Amazon DynamoDB
La seguente policy IAM concede le autorizzazioni per abilitare un flusso di dati Amazon Kinesis per Amazon DynamoDB per la tabella `Music`. Non concede le autorizzazioni per disabilitare, aggiornare o descrivere un flusso di dati Kinesis per DynamoDB per la tabella `Music`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kinesisreplication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBKinesisDataStreamsReplication",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kinesisreplication.dynamodb.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"dynamodb:EnableKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
}
]
}
```
------
## Esempio: abilitazione di un flusso di dati Amazon Kinesis per Amazon DynamoDB
La seguente policy IAM concede le autorizzazioni per aggiornare un flusso di dati Amazon Kinesis per Amazon DynamoDB per la tabella `Music`. Non concede le autorizzazioni per abilitare, disabilitare o descrivere un flusso di dati Amazon Kinesis per Amazon DynamoDB per la tabella `Music`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:UpdateKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
}
]
}
```
------
## Esempio: disabilitazione di Amazon Kinesis Data Streams per Amazon DynamoDB
La seguente policy IAM concede le autorizzazioni per aggiornare un flusso di dati Amazon Kinesis per Amazon DynamoDB per la tabella `Music`. Non concede le autorizzazioni per abilitare, aggiornare o descrivere un flusso di dati Amazon Kinesis per Amazon DynamoDB per la tabella `Music`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:DisableKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
}
]
}
```
------
## Esempio: applicazione selettiva delle autorizzazioni per il flusso di dati Amazon Kinesis per Amazon DynamoDB in base alla risorsa
La seguente policy IAM concede le autorizzazioni per abilitare e descrivere il flusso di dati Amazon Kinesis per Amazon DynamoDB per la tabella `Music` e non concede le autorizzazioni per disabilitare il flusso di dati Amazon Kinesis per Amazon DynamoDB per la tabella `Orders`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:EnableKinesisStreamingDestination",
"dynamodb:DescribeKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
},
{
"Effect": "Deny",
"Action": [
"dynamodb:DisableKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Orders"
}
]
}
```
------
## Utilizzo di ruoli collegati ai servizi per Kinesis Data Streams per DynamoDB
[Amazon Kinesis Data Streams per Amazon DynamoDB utilizza ruoli collegati ai servizi (IAM). AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un ruolo collegato al servizio è un tipo univoco di ruolo IAM collegato direttamente a Kinesis Data Streams per DynamoDB. I ruoli collegati ai servizi sono predefiniti da Kinesis Data Streams for DynamoDB e includono tutte le autorizzazioni richieste dal servizio per chiamare altri servizi per tuo conto. AWS
Un ruolo collegato al servizio semplifica la configurazione di Kinesis Data Streams per DynamoDB perché non è necessario aggiungere manualmente le autorizzazioni necessarie. Kinesis Data Streams per DynamoDB definisce le autorizzazioni dei relativi ruoli associati ai servizi e, salvo diversamente definito, solo Kinesis Data Streams potrà assumere i propri ruoli. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere collegata a nessun'altra entità IAM.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consulta la sezione [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cerca i servizi che riportano **Sì** nella colonna **Ruolo associato ai servizi**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
### Autorizzazioni dei ruoli collegati ai servizi per Kinesis Data Streams per DynamoDB
Kinesis Data Streams for DynamoDB utilizza il ruolo collegato al servizio denominato. **AWSServiceRoleForDynamoDBKinesisDataStreamsReplication** Lo scopo di questo ruolo collegato al servizio è di consentire ad Amazon DynamoDB di gestire la replica delle modifiche a livello di elemento al flusso di dati Kinesis per conto dell'utente.
Ai fini dell’assunzione del ruolo, il ruolo collegato al servizio `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication` considera attendibili i seguenti servizi:
+ `kinesisreplication.dynamodb.amazonaws.com`
La policy delle autorizzazioni del ruolo consente a Kinesis Data Streams per DynamoDB per completare le seguenti operazioni sulle risorse specificate:
+ Operazione: `Put records and describe` su `Kinesis stream`
+ Azione: `Generate data keys` attiva per inserire dati `AWS KMS` negli stream Kinesis crittografati utilizzando chiavi generate dall'utente. AWS KMS
[Per i contenuti esatti del documento informativo, consulta Dynamo. DBKinesis ReplicationServiceRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBKinesisReplicationServiceRolePolicy)
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato al servizio è necessario configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/contributorinsights-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
### Creazione di un ruolo collegato ai servizi per Kinesis Data Streams per DynamoDB
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando abiliti Kinesis Data Streams for DynamoDB nella, o nell' AWS CLI AWS API, Kinesis Data Streams for Console di gestione AWS DynamoDB crea automaticamente il ruolo collegato al servizio.
Se elimini questo ruolo collegato al servizio, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell’account. Quando si abilita Kinesis Data Streams per DynamoDB, questo crea automaticamente il ruolo collegato ai servizi.
### Modifica di un ruolo collegato ai servizi per Kinesis Data Streams per DynamoDB
Kinesis Data Streams per DynamoDB non consente di modificare il ruolo collegato ai servizi `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication`. Dopo avere creato un ruolo collegato al servizio, non sarà possibile modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta la sezione [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/contributorinsights-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
### Eliminazione di un ruolo collegato ai servizi per Kinesis Data Streams per DynamoDB
Puoi anche utilizzare la console IAM, the o l'API per eliminare manualmente il ruolo collegato al servizio AWS CLI . AWS Per farlo, sarà necessario prima eseguire manualmente la pulizia delle risorse associate al ruolo collegato ai servizi e poi eliminarlo manualmente.
**Nota**
Se il servizio Kinesis Data Streams per DynamoDB utilizza tale ruolo quando si prova a eliminare le risorse, è possibile che l'eliminazione non abbia esito positivo. In questo caso, attendi alcuni minuti e quindi ripeti l’operazione.
**Per eliminare manualmente il ruolo collegato ai servizi mediante IAM**
Utilizza la console IAM AWS CLI, o l' AWS API per eliminare il ruolo collegato al `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication` servizio. Per ulteriori informazioni, consulta [Eliminazione del ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) nella *Guida per l’utente di IAM*.
# Acquisizione dei dati di modifica per DynamoDB Streams
DynamoDB Streams acquisisce una sequenza cronologica di modifiche a livello di elemento in una tabella DynamoDB qualsiasi e le archivia in un log per un massimo di 24 ore. Le applicazioni possono accedere a questo log e visualizzare gli elementi di dati nel rispettivo stato prima e dopo la modifica, praticamente in tempo reale.
La crittografia a riposo crittografa i dati in DynamoDB Streams. Per ulteriori informazioni, consulta [Crittografia a riposo per DynamoDB](EncryptionAtRest.md).
Un *flusso DynamoDB* è un flusso ordinato di informazioni sulle modifiche apportate agli elementi in una tabella DynamoDB. Quando si abilita un flusso in una tabella, DynamoDB acquisisce informazioni su ogni modifica apportata agli elementi di dati nella tabella.
Ogni volta che un'applicazione crea, aggiorna o elimina elementi nella tabella, DynamoDB Streams scrive un record di flusso con gli attributi della chiave primaria degli elementi che sono stati modificati. Un *record di flusso* contiene informazioni su una modifica di dati apportata a un singolo elemento in una tabella DynamoDB. Puoi configurare il flusso in modo che i record di flusso acquisiscano informazioni aggiuntive, come le immagini "prima" e "dopo" degli elementi modificati.
DynamoDB Streams garantisce quanto segue:
+ Ogni record di flusso viene visualizzato esattamente una volta nel flusso.
+ Per ogni elemento modificato in una tabella DynamoDB, i record di flusso vengono visualizzati nella stessa sequenza delle modifiche effettive apportate all'elemento.
DynamoDB Streams scrive i record di flusso praticamente in tempo reale per permettere di creare applicazioni che utilizzano questi flussi e agiscono in base al contenuto.
**Topics**
+ [Endpoint per DynamoDB Streams](#Streams.Endpoints)
+ [Abilitazione di un flusso](#Streams.Enabling)
+ [Lettura ed elaborazione di un flusso](#Streams.Processing)
+ [DynamoDB Streams e Time to Live](time-to-live-ttl-streams.md)
+ [Utilizzo dell'adattatore DynamoDB Streams Kinesis per elaborare i record di flusso](Streams.KCLAdapter.md)
+ [API di basso livello DynamoDB Streams: esempio Java](Streams.LowLevel.Walkthrough.md)
+ [Streams e trigger DynamoDB AWS Lambda](Streams.Lambda.md)
+ [Flussi DynamoDB e Apache Flink](StreamsApacheFlink.xml.md)
## Endpoint per DynamoDB Streams
AWS mantiene endpoint separati per DynamoDB e DynamoDB Streams. Per usare tabelle e indici di database, l'applicazione deve accedere a un endpoint DynamoDB. Per leggere ed elaborare i record di DynamoDB Streams, l'applicazione deve accedere a un endpoint DynamoDB Streams nella stessa regione.
DynamoDB Streams offre due set di endpoint. Questi sono:
+ **IPv4-only endpoint: endpoint** con la convenzione di denominazione. `streams.dynamodb..amazonaws.com`
+ Endpoint **dual-stack: nuovi endpoint** compatibili con entrambi e che seguono la convenzione di denominazione. IPv4 IPv6 `streams-dynamodb..api.aws`
**Nota**
Per l'elenco completo delle regioni e degli endpoint di DynamoDB e DynamoDB Streams, consulta [Regioni ed endpoint](https://docs.aws.amazon.com/general/latest/gr/rande.html) in *Riferimenti generali di AWS*.
AWS SDKs Forniscono client separati per DynamoDB e DynamoDB Streams. A seconda dei requisiti, l'applicazione può accedere a un endpoint DynamoDB, a un endpoint DynamoDB Streams o a entrambi contemporaneamente. Per connettersi a entrambi gli endpoint, l'applicazione deve creare un'istanza di due client, uno per DynamoDB e uno per DynamoDB Streams.
## Abilitazione di un flusso
È possibile abilitare uno stream su una nuova tabella quando lo si crea utilizzando o uno dei AWS CLI . AWS SDKs È inoltre possibile abilitare o disabilitare un flusso in una tabella esistente oppure modificare le impostazioni di un flusso. DynamoDB Streams opera in modo asincrono, pertanto non vi è alcun impatto sulle prestazioni di una tabella se si abilita un flusso.
Il modo più semplice per gestire DynamoDB Streams consiste nell'usare la Console di gestione AWS.
1. Accedi Console di gestione AWS e apri la console DynamoDB all'indirizzo. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Nel pannello di controllo della console DynamoDB, scegli **Tabelle** e seleziona una tabella esistente.
1. Scegli la scheda **Exports and streams (Esportazioni e flussi)**.
1. Nella sezione **Dettagli del flusso DynamoDB**, seleziona **Attiva.**
1. Nella pagina **Attiva il flusso DynamoDB**, seleziona le informazioni che verranno scritte nel flusso a ogni modifica dei dati nella tabella:
+ **Key attributes only (Solo attributi chiave)**: solo gli attributi chiave dell'elemento modificato.
+ **Nuova immagine**: l'intero elemento, così come visualizzato dopo che è stato modificato.
+ **Vecchia immagine**: l'intero elemento, così come visualizzato prima della modifica.
+ **Immagini nuove e vecchie**: le immagini dell'elemento nuove e vecchie.
Dopo aver configurato le impostazioni, seleziona **Attiva il flusso**.
1. (Facoltativo) Per disabilitare un flusso esistente, seleziona **Disattiva**in **Dettagli del flusso DynamoDB**.
Per abilitare o modificare un flusso, puoi anche usare le operazioni API `CreateTable` o `UpdateTable`. Il parametro `StreamSpecification` determina la configurazione del flusso:
+ `StreamEnabled`: specifica se un flusso è abilitato (`true`) o disabilitato (`false`) per la tabella.
+ `StreamViewType`: specifica le informazioni che verranno scritte nel flusso a ogni modifica dei dati nella tabella:
+ `KEYS_ONLY`: solo gli attributi chiave dell'elemento modificato.
+ `NEW_IMAGE`: l'intero elemento, così come visualizzato dopo che è stato modificato.
+ `OLD_IMAGE`: l'intero elemento, così come visualizzato prima della modifica.
+ `NEW_AND_OLD_IMAGES`: le immagini dell'elemento nuove e vecchie.
Puoi abilitare o disabilitare un flusso in qualsiasi momento. Tuttavia, se provi ad abilitare un flusso in una tabella che include già un flusso riceverai un'eccezione `ValidationException`. Inoltre, se si tenta di disabilitare un flusso in una tabella che non include alcun flusso, verrà mostrata un’eccezione `ValidationException`.
Quando `StreamEnabled` viene impostato su `true`, DynamoDB crea un nuovo flusso con un descrittore di flusso univoco assegnato. Se disabiliti e quindi riabiliti un flusso nella tabella, viene creato un nuovo flusso con un descrittore di flusso diverso.
Ogni flusso è identificato in modo univoco da un Amazon Resource Name (ARN). Di seguito è riportato un ARN di esempio per un flusso in una tabella DynamoDB denominata `TestTable`.
```
arn:aws:dynamodb:us-west-2:111122223333:table/TestTable/stream/2015-05-11T21:21:33.291
```
Per determinare l'ultimo descrittore di flusso per una tabella, inviare una richiesta `DescribeTable` DynamoDB e cercare l'elemento `LatestStreamArn` nella risposta.
**Nota**
Non è possibile modificare un `StreamViewType` una volta configurato un flusso. Se è necessario apportare modifiche a un flusso dopo che è stato configurato, è necessario disabilitare il flusso corrente e crearne uno nuovo.
## Lettura ed elaborazione di un flusso
Per leggere ed elaborare un flusso, l'applicazione deve connettersi a un endpoint DynamoDB Streams ed emettere le richieste API.
Un flusso è costituito da *record di flusso*. Ogni record di flusso rappresenta una singola modifica dei dati nella tabella DynamoDB cui appartiene il flusso. A ogni record di flusso è assegnato un numero in sequenza, corrispondente all'ordine in cui il record è stato pubblicato nel flusso.
I record di flusso sono organizzati in gruppi o *shard*. Ogni shard funge da container per più record di flusso e contiene le informazioni necessarie per l'accesso e l'iterazione attraverso i record. I record di flusso all'interno di uno shard vengono automaticamente rimossi dopo 24 ore.
Gli shard sono effimeri, ovvero vengono creati ed eliminati automaticamente in base alle necessità. Qualsiasi shard può anche essere suddiviso in più nuovi shard e anche questa operazione viene eseguita automaticamente. È anche possibile che per uno shard padre esista un solo shard figlio. Uno shard può essere suddiviso in risposta a livelli elevati di attività di scrittura nella tabella padre corrispondente, in modo che le applicazioni possano elaborare record da più shard in parallelo.
Se disabiliti un flusso, tutti gli shard aperti verranno chiusi. I dati nel flusso continueranno a essere leggibili per 24 ore.
Poiché gli shard hanno una derivazione (padre e figlio), un'applicazione deve sempre elaborare uno shard padre prima dello shard figlio. In questo modo, anche l'elaborazione dei record di flusso avviene sicuramente in base all'ordine corretto. Se si utilizza DynamoDB Streams Kinesis Adapter, questa operazione viene gestita automaticamente. L'applicazione elabora le partizioni e i record di flusso nell'ordine corretto e gestisce automaticamente partizioni nuove o scadute, nonché le partizioni che vengono suddivise durante l'esecuzione dell'applicazione. Per ulteriori informazioni, consultare[Utilizzo dell'adattatore DynamoDB Streams Kinesis per elaborare i record di flusso](Streams.KCLAdapter.md).
Il diagramma seguente mostra la relazione tra un flusso, gli shard nel flusso e i record di flusso negli shard.
![\[Struttura dei flussi DynamoDB. I record dei flussi che rappresentano le modifiche dei dati sono organizzati in shard.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/streams-terminology.png)
**Nota**
Se si esegue un'operazione `PutItem` o `UpdateItem` che non modifica alcun dato in un elemento, DynamoDB Streams *non* scrive un record di flusso per tale operazione.
Per accedere a un flusso ed elaborare i record di flusso al suo interno, devi eseguire queste operazioni:
+ Determinare l'ARN univoco del flusso a cui vuoi accedere.
+ Determinare quali shard nel flusso contengono i record di flusso che ti interessano.
+ Accedi alle partizioni e recupera i record di flusso desiderati.
**Nota**
Non più di due processi devono leggere dalla stessa partizione di flussi contemporaneamente. La presenza di più di due lettori per shard può causare il throttling.
L'API DynamoDB Streams fornisce le operazioni seguenti, che possono essere usate dai programmi applicativi:
+ `[ListStreams](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_ListStreams.html)`: restituisce un elenco dei descrittori di flusso per il conto corrente e l'endpoint. Puoi facoltativamente richiedere solo i descrittori di flusso per un nome di tabella specifico.
+ `[DescribeStream](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_DescribeStream.html)`: restituisce informazioni su un flusso, inclusi lo stato attuale del flusso, il suo nome della risorsa Amazon (ARN), la composizione dei suoi shard e la corrispondente tabella su DynamoDB. Facoltativamente, è possibile utilizzare il campo `ShardFilter` per recuperare lo shard secondario esistente associato allo shard principale.
+ `[GetShardIterator](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetShardIterator.html)`: restituisce un *iteratore di partizioni*, che descrive una posizione all'interno di una partizione. Puoi richiedere che l'iterazione fornisca accesso al punto meno recente, al punto più recente o a un punto particolare nel flusso.
+ `[GetRecords](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetRecords.html)`: restituisce i record di flusso in una determinata partizione. Devi specificare l'iterazione shard restituita da una richiesta `GetShardIterator`.
Per la descrizione completa di queste operazioni API, incluse le richieste e le risposte di esempio, consulta la [Documentazione di riferimento delle API di Amazon DynamoDB Streams](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations_Amazon_DynamoDB_Streams.html).
### Individuazione di shard
Come individuare nuovi shard in un flusso DynamoDB con due potenti metodi. Gli utenti dei flussi Amazon DynamoDB hanno a disposizione due modi efficaci per tracciare e identificare nuovi shard:
**Polling della topologia dell’intero flusso**
Utilizzo dell’API `DescribeStream` per eseguire regolarmente il polling del flusso. Questa operazione restituisce tutti gli shard del flusso, inclusi tutti i nuovi shard creati. Confrontando i risultati nel tempo è possibile rilevare i nuovi shard aggiunti.
**Individuazione di shard secondari**
Usa l’API `DescribeStream`con il parametro `ShardFilter` per trovare un sottoinsieme di shard. Specificando uno shard principale nella richiesta, i flussi DynamoDB restituiranno i relativi shard secondari immediati. Questo approccio è utile quando è necessario solo tracciare la derivazione degli shard senza scansionare l’intero flusso.
Le applicazioni che utilizzano dati dai flussi DynamoDB possono passare in modo efficiente dalla lettura di uno shard chiuso al relativo shard secondario utilizzando questo parametro `ShardFilter`, evitando chiamate ripetute all’API `DescribeStream` per recuperare e attraversare la mappa degli shard per tutti gli shard chiusi e aperti. Questo aiuta a individuare rapidamente gli shard secondari dopo la chiusura di uno shard principale, rendendo le applicazioni di elaborazione dei flussi più reattive e convenienti.
Entrambi i metodi consentono di rimanere aggiornati sulla struttura in evoluzione dei propri flussi DynamoDB, assicurandosi di non perdere mai aggiornamenti cruciali dei dati o modifiche agli shard.
### Limite di conservazione dei dati per DynamoDB Streams
Tutti i dati in DynamoDB Streams hanno una durata di 24 ore. Puoi recuperare e analizzare le ultime 24 ore di attività per qualsiasi tabella specifica. Tuttavia, i dati più vecchi di 24 ore sono soggetti a taglio (rimozione) in qualsiasi momento.
Se disabiliti un flusso in una tabella, i dati nel flusso restano leggibili per 24 ore. Dopo questo intervallo di tempo, i dati scadono e i record di flusso vengono automaticamente eliminati. Non esiste un meccanismo per eliminare manualmente un flusso esistente. Devi attendere fino allo scadere del limite di conservazione (24 ore) perché tutti i record di flusso vengano eliminati.
# DynamoDB Streams e Time to Live
È possibile eseguire il backup o elaborare gli elementi che sono stati eliminati da [Time to Live](TTL.md) (TTL, Time to Live) abilitando Amazon DynamoDB Streams sulla tabella ed elaborando i record di flusso degli elementi scaduti. Per ulteriori informazioni, consulta [Lettura ed elaborazione di un flusso](Streams.md#Streams.Processing).
Il record Streams contiene un campo di identità utente `Records[].userIdentity`.
Gli elementi eliminati dal processo Time to Live (TTL, Time to Live) dopo la scadenza hanno i seguenti campi:
+ `Records[].userIdentity.type`
`"Service"`
+ `Records[