Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Linee guida generali per gli indici secondari in DynamoDB
Amazon DynamoDB supporta due tipi di indici secondari:
-
Indice secondario globale (GSI): un indice con una chiave di partizione e una chiave di ordinamento che può essere diverso da quelli della 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 globale non ha limiti di dimensioni e ha le proprie impostazioni di throughput assegnate per le attività di lettura e scrittura che sono separate da quelle della tabella.
-
Indice secondario locale (LSI): un indice che ha la stessa chiave di partizione della tabella di base, ma 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. Quindi, la dimensione totale degli elementi indicizzati per ogni valore di chiave di partizione non può eccedere 10 GB. Inoltre, un indice secondario locale condivide le impostazioni di throughput assegnate per le attività di lettura e scrittura con la tabella che sta indicizzando.
Ogni tabella in DynamoDB può avere fino a 20 indici secondari globali (quota predefinita) e 5 indici secondari locali.
Gli indici secondari globali sono spesso più utili degli indici secondari locali. La determinazione del tipo di indice da utilizzare dipenderà anche dai requisiti dell'applicazione. Per un confronto tra indici secondari globali e indici secondari locali e ulteriori informazioni su come scegliere tra di essi, vedere. Miglioramento dell'accesso ai dati con indici secondari in DynamoDB
Di seguito sono riportati alcuni principi e modelli di progettazione generici da tenere in considerazione quando si creano gli indici in DynamoDB:
Argomenti
Uso degli indici in modo efficiente
Limita il numero di indici al minimo necessario. Non creare indici secondari su attributi per i quali non esegui spesso query. Gli indici utilizzati raramente contribuiscono a maggior storage e costi di I/O, senza migliorare le prestazioni dell'applicazione.
Scelta accurata delle proiezioni
In quanto gli indici secondari consumano storage e throughput assegnato, mantieni le dimensioni dell'indice al minimo possibile. Inoltre, più piccolo è l'indice, maggiore è il vantaggio in termini di prestazioni rispetto all'esecuzione di query sull'intera tabella. Se le tue query restituiscono generalmente solo un piccolo sottoinsieme di attributi e la dimensione totale di tali attributi è considerevolmente più piccola dell'intera voce, progetta solo gli attributi che richiedi regolarmente.
Se prevedi molte attività di scrittura in una tabella, rispetto a quelle di lettura, segui queste best practice:
-
Considera la proiezione di un numero minore di attributi per ridurre la dimensione delle voci scritte nell'indice. Tuttavia, ciò si applica se le dimensioni degli attributi proiettati sono di dimensioni più grandi rispetto a una singola unità di capacità di scrittura (1 KB). Ad esempio, se la dimensione di una voce dell'indice è solo di 200 byte, DynamoDB la arrotonda a 1 KB. In altre parole, nella misura in cui gli elementi degli indici sono di piccole dimensioni, puoi progettare più attributi senza costi aggiuntivi;
-
Evita di proiettare attributi che sai saranno necessari raramente nelle query. Ogni volta che aggiorni un attributo che è assegnato in un indice, devi sostenere anche il costo aggiuntivo di aggiornamento dell'indice. Puoi comunque recuperare gli attributi non assegnati in una
Querya un costo di throughput assegnato più elevato, ma il costo della query può essere molto più basso rispetto al costo di aggiornare l'indice frequentemente. -
Specifica
ALLsolo se desideri che le tue query restituiscano tutte le voci della tabella, ordinata da una chiave di ordinamento differente. La proiezione di tutti gli attributi elimina l'esigenza di recuperare le tabelle, ma nella maggior parte dei casi raddoppia i costi di storage e delle attività di scrittura.
Mantieni un equilibrio tra la necessità di mantenere piccoli gli indici e i recuperi al minimo, come illustrato nella prossima sezione.
Ottimizzazione delle query frequenti per evitare recuperi
Per ottenere le prestazioni più veloci in termini di query con la latenza più bassa possibile, proietta tutti gli attributi che prevedi vengano restituiti da tali query. In particolare, se si esegue una query su un indice secondario locale per gli attributi che non sono proiettati, DynamoDB recupera automaticamente quegli attributi dalla tabella, il che richiede la lettura di un elemento intero dalla tabella. Ciò introduce latenza e operazioni I/O addizionali che puoi evitare.
Tieni a mente che le query occasionali possono spesso tramutarsi in query essenziali. Se ci sono attributi che non intendi proiettare perché pensi di eseguire query solo occasionalmente, considera se le circostanze possono cambiare e potresti pentirti di non aver proiettato quegli attributi.
Per ulteriori informazioni sul recupero delle tabelle, consulta Considerazioni sulla velocità di trasmissione effettiva assegnata per indici secondari locali.
Fai attenzione ai limiti delle dimensioni della raccolta di elementi quando crei indici secondari locali
Una raccolta di voci è un gruppo di voci in una tabella e i suoi indici locali secondari, che hanno la stessa chiave di partizione. Nessuna raccolta di elementi può superare i 10 GB pertanto è possibile che lo spazio per un determinato valore della chiave di partizione venga esaurito.
Quando si aggiunge o si aggiorna un elemento di una tabella, DynamoDB aggiornerà ogni indice secondario locale interessato. Se gli attributi indicizzati sono definiti nella tabella, anche gli indici secondari locali crescono.
Quando crei un indice secondario locale, pensa alla quantità di dati che dovrà contenere e quante di quelle voci di quei dati avranno lo stesso valore della chiave di partizione. Se si ritiene che la somma della tabella e degli elementi dell'indice per un determinato valore della chiave di partizione possa superare 10 GB, considerare se evitare la creazione dell'indice.
Se non puoi evitare la creazione dell'indice secondario locale, devi capire il limite delle dimensioni della raccolta delle voci e agire a riguardo prima di eccederlo. È consigliabile utilizzare il ReturnItemCollectionMetricsparametro durante la scrittura degli articoli per monitorare e avvisare sulle dimensioni delle raccolte di articoli che si avvicinano al limite di 10 GB. Il superamento della dimensione massima di raccolta degli elementi comporterà tentativi di scrittura non riusciti. È possibile mitigare i problemi relativi alle dimensioni della raccolta degli articoli monitorando e inviando avvisi sulle dimensioni della raccolta degli articoli prima che influiscano sull'applicazione.
Nota
Una volta creato, non è possibile eliminare un indice secondario locale.
Per le strategie da attuare, al fine di non eccedere il limite e per eseguire delle operazioni correttive, consulta Limite delle dimensioni delle raccolte di elementi.
