D: Cos'è Amazon DynamoDB?

Amazon DynamoDB è un servizio di database NoSQL interamente gestito che combina prestazioni elevate e prevedibili con una scalabilità ottimale. Amazon DynamoDB solleva i clienti dagli oneri amministrativi connessi alla gestione e al dimensionamento dei database distribuiti su AWS; non dovranno dunque occuparsi di provisioning di hardware, installazioni e configurazioni, pianificazione della capacità di throughput, repliche, applicazioni di patch o dimensionamento di cluster.

D: Quali attività sono gestite da Amazon DynamoDB per mio conto?

Amazon DynamoDB elimina la principale difficoltà del dimensionamento di database: la gestione del software di database e il provisioning dell'hardware necessario al suo funzionamento. Il clienti possono così distribuire un database non relazionale in pochi minuti. DynamoDB dimensiona automaticamente la capacità di throughput per soddisfare le richieste dei carichi di lavoro e partiziona e ripartiziona i dati man mano che crescono le dimensioni della tabella. Inoltre, Amazon DynamoDB replica simultaneamente i dati su tre strutture in una Regione AWS, garantendo così disponibilità e durabilità dei dati elevate.

D: Cosa significa consistenza di lettura? Perché è importante?

Amazon DynamoDB custodisce tre repliche distribuite geograficamente di ogni tabella per consentire disponibilità e durabilità dei dati elevata. La consistenza di lettura rappresenta il modo e il tempo in cui la scrittura o l'aggiornamento riuscito di una voce di dati si riflette in un'operazione successiva di lettura della stessa voce. La logica impiegata da Amazon DynamoDB consente di specificare le caratteristiche di consistenza desiderate per ogni richiesta di lettura in un'applicazione.

D: Cos'è il modello di consistenza di Amazon DynamoDB?

Quando leggono i dati provenienti da Amazon DynamoDB, gli utenti possono specificare se vogliono che la lettura sia a consistenza finale o forte:

Operazioni di lettura a consistenza finale (impostazione predefinita): l'opzione di consistenza finale massimizza il throughput di lettura. Tuttavia, una lettura a consistenza finale può non riflettere i risultati di una scrittura completata recentemente. La consistenza su tutte le copie dei dati di solito viene raggiunta in un secondo. Una lettura ripetuta qualche minuto dopo dovrebbe fornire i dati aggiornati.

Operazioni di lettura fortemente consistenti – oltre alla consistenza finale, Amazon DynamoDB fornisce ulteriore flessibilità e controllo dando la possibilità di richiedere una lettura fortemente consistente se l'applicazione, o un elemento dell'applicazione, lo richiede. Una lettura fortemente consistente fornisce un risultato che riflette tutte le scritture che hanno ricevuto una risposta positiva prima della lettura.

D: DynamoDB supporta aggiornamenti atomici sul posto?

Amazon DynamoDB supporta aggiornamenti atomici rapidi sul posto. Puoi incrementare o decrementare un attributo numerico in una riga utilizzando una singola chiamata API. In modo simile puoi fare aggiunte o rimozioni atomiche a gruppi, liste o mappe. Consulta la documentazione per ulteriori informazioni sugli aggiornamenti atomici.

D: Perché Amazon DynamoDB è costruito su unità a stato solido?

Amazon DynamoDB funziona esclusivamente su unità a stato solido (SSD). Le unità SSD ci consentono di realizzare i nostri obiettivi di tempi di risposta a bassa latenza per memorizzare e accedere ai dati su qualsiasi scala. Inoltre le elevate prestazioni I/O delle unità SSD ci permettono di rispondere a volumi di domanda su larga scala in modo efficiente e di riflettere questa efficienza in prezzi bassi.

D: Il costo di storage di DynamoDB è piuttosto alto. Nel mio caso d'uso è un costo vantaggioso?

Come per ogni prodotto, invitiamo i clienti potenziali di Amazon DynamoDB a prendere in considerazione il costo globale di una soluzione, non solo un'unica dimensione di prezzo. Il costo globale della gestione del carico di lavoro di un database è in funzione dei requisiti di traffico e della quantità di dati memorizzati. La maggior parte dei carichi di lavoro dei database è caratterizzata da requisiti di I/O elevati (tasso elevato di letture e scritture al secondo) per GB memorizzato. Amazon DynamoDB è costruito su unità SSD, cosa che aumenta il costo per GB memorizzato rispetto alle unità disco rotanti, ma ci consente anche di offrire costi di richiesta molto bassi. Da quello che vediamo nei carichi di lavoro di database tipici, riteniamo che il costo globale dell'utilizzo del servizio DynamoDB basato su unità SSD sia generalmente più basso di quello di un servizio di database relazionali o non relazionali basato su unità disco rotanti. Se hai un caso d'uso che implica la memorizzazione di grandi quantità di dati ai quali accedi raramente, probabilmente DynamoDB non è adatto a te. Per questi casi d'uso consigliamo di usare S3.

Bisogna anche notare che il costo di storage include la memorizzazione di varie copie di ogni voce dei dati su varie sedi in una Regione AWS.

D: DynamoDB è solo per applicazioni su larga scala?

No. DynamoDB offre un dimensionamento lineare per consentirti di dimensionare automaticamente man mano che i requisiti delle tue applicazioni aumentano. Se hai bisogno di prestazioni rapide e prevedibili su qualunque scala, DynamoDB è probabilmente la soluzione giusta per te.

D: Come posso iniziare a usare Amazon DynamoDB?

Fai clic su "Registrazione" per cominciare a usare subito Amazon DynamoDB. Da questo momento puoi interagire usando sia la Console di gestione AWS sia le API di Amazon DynamoDB. Se usi la Console di gestione AWS, puoi creare una tabella con Amazon DynamoDB e cominciare a esplorare in pochi passaggi.

D: Che tipo di funzionalità di query supporta DynamoDB

Amazon DynamoDB supporta operazioni GET/PUT utilizzando una chiave principale definita dall'utente. La chiave principale è l'unico attributo obbligatorio per le voci di una tabella e identifica ogni voce in modo univoco. Deve essere specificata quando si crea una tabella. Inoltre DynamoDB fornisce flessibilità nella creazione delle query, permettendone l'esecuzione su attributi di chiave non principale tramite indici secondari globali e indici secondari locali.

Una chiave principale può essere una chiave di partizione ad attributo singolo o una chiave di partizione-ordinamento composta. Una chiave di partizione principale ad attributo singolo può essere, ad esempio, "UserID". Questo permette di leggere e scrivere rapidamente i dati di una voce associata a un determinato ID utente.

Una chiave di partizione-ordinamento composta viene indicizzata come un elemento chiave di partizione e un elemento chiave di ordinamento. Questa chiave a più sezioni mantiene una gerarchia fra i valori del primo e del secondo elemento. Per esempio, una chiave di partizione-ordinamento composta può essere una combinazione di "UserID" (partizione) e "Timestamp" (ordinamento). Mantenere uno stesso elemento chiave di partizione consente di effettuare ricerche nell'elemento chiave di ordinamento. Questo permette per esempio di utilizzare l'API Query per recuperare tutte le voci di un singolo ID Utente su una serie di timestamp.

Per ulteriori informazioni sull'indicizzazione secondaria globale e le sue capacità di query, consulta la sezione Indici secondari nelle Domande frequenti.

 

D: Come si aggiornano e si interrogano le voci dei dati con Amazon DynamoDB?

Dopo avere creato una tabella con la Console di gestione AWS o l'API CreateTable, puoi utilizzare un'API come PutItem o BatchWriteItem per inserire le voci. Potrai quindi impiegare GetItem, BatchGetItem o, se nella tabella sono abilitate e in uso le chiavi principali composte, l'API Query per recuperare le voci aggiunte alla tabella.

D: Amazon DynamoDB supporta le operazioni condizionali?

Sì, è possibile specificare una condizione che deve essere soddisfatta per un'operazione PUT, UPDATE o DELETE da compiere su una voce. Per eseguire un'operazione condizionale, puoi definire una ConditionExpression costruita come segue:

  • Funzioni booleane: ATTRIBUTE_EXIST, CONTAINS e BEGINS_WITH
  • Operatori di confronto: =, <>, <, >, <=, >=, BETWEEN e IN
  • Operatori logici: NOT, AND e OR. 

Puoi costruire un'espressione condizionale in formato libero che combina clausole condizionali multiple, comprese le clausole condizionali nidificate. Le operazioni condizionali consentono agli utenti di implementare sistemi di controllo a concorrenza ottimistica su DynamoDB. Per ulteriori informazioni sulle operazioni condizionali, consulta la documentazione.

D: Le espressioni sono supportate per le condizioni di chiave?

Sì, puoi specificare un'espressione come parte della chiamata API Query per filtrare i risultati sulla base di valori di chiavi principali su una tabella utilizzando il parametro KeyConditionExpression.

D: Sono supportate le espressioni per le chiavi di partizione e le chiavi di partizione-ordinamento?

Sì, puoi usare espressioni sia per le chiavi di partizione sia per le chiavi partizione-ordinamento. Consulta la pagina della documentazione per ulteriori informazioni su quali espressioni puoi usare con le chiavi di partizione e le chiavi di partizione-ordinamento.

D: Amazon DynamoDB supporta le operazioni di incremento e decremento?

Sì, Amazon DynamoDB permette le operazioni di incremento e decremento atomico su valori scalari.

D: In quali casi è meglio utilizzare Amazon DynamoDB piuttosto che un motore di database relazionale su Amazon RDS o Amazon EC2?

Oggigiorno le applicazioni basate sul Web generano e utilizzano quantità immense di dati. Ad esempio, un gioco online può cominciare con qualche migliaio di utenti e un carico di lavoro di database leggero da 10 scritture e 50 letture al secondo. Tuttavia, se il gioco ha successo, può raggiungere rapidamente alcuni milioni di utenti e generare decine o anche centinaia di migliaia di scritture e letture al secondo. Può anche creare più di un terabyte di dati al giorno. Sviluppare le applicazioni con Amazon DynamoDB consente di cominciare su piccola scala e di aumentare la capacità di richiesta per una tabella man mano che aumentano le necessità, senza subire tempi morti. Paghi tariffe vantaggiose per il volume di richieste impiegato e Amazon DynamoDB esegue il lavoro di partizione dei dati e del traffico su una capacità di server sufficiente a soddisfare le tue necessità. Amazon DynamoDB si occupa della gestione e dell'amministrazione di database e tu non fai altro che memorizzare e richiedere i tuoi dati. La replica e il failover automatici forniscono una tolleranza ai guasti, un'elevata disponibilità e durabilità dei dati predefinite. Amazon DynamoDB ti permette di rilassarti sapendo che il tuo database è interamente gestito e può crescere con la tua applicazione.

Se Amazon DynamoDB affronta i problemi centrali di scalabilità, gestione, prestazioni e affidabilità dei database, non possiede tutte le funzionalità di un database relazionale. Non supporta query relazionali complesse (per es. join) o transazioni complesse. Se il carico di lavoro necessita questa funzionalità o se si cerca una compatibilità con un motore relazionale, è preferibile eseguire un motore relazionale su Amazon RDS o Amazon EC2. Se i motori di database relazionali offrono caratteristiche e funzionalità robuste, dimensionare un carico di lavoro al di là di una singola istanza di database relazionale è estremamente complesso e richiede tempo e competenze notevoli. In questo caso, se prevedi requisiti di dimensionamento per una nuova applicazione e non hai bisogno di caratteristiche relazionali, Amazon DynamoDB è probabilmente la scelta migliore per te.

D: Qual è la differenza fra Amazon DynamoDB e Amazon SimpleDB?

Quale devo usare? Entrambi i servizi sono database non relazionali che eliminano il lavoro di amministrazione di database. Amazon DynamoDB fondamentalmente fornisce una scalabilità ottimale e prestazioni rapide e prevedibili. Funziona su unità a stato solido (SSD), che consentono tempi di risposta a bassa latenza, e non ci sono limiti ai volumi di richieste o di storage per una tabella. Ciò è possibile perché Amazon DynamoDB partiziona automaticamente i dati e il carico di lavoro su un numero di server sufficiente a soddisfare i requisiti di dimensionamento forniti. Invece una tabella in Amazon SimpleDB ha un limite preciso di storage di 10 GB e ha capacità limitate di richiesta (di solito al di sotto di 25 scritture al secondo) e il cliente deve gestire la partizione e ripartizione dei dati su tabelle SimpleDB supplementari se gli occorrono maggiori volumi. Se SimpleDB ha limiti di dimensionamento, può rappresentare una buona soluzione per carichi di lavoro minori che richiedono flessibilità di query. Amazon SimpleDB indicizza automaticamente tutti gli attributi delle voci e perciò offre flessibilità di query piuttosto che prestazioni e volumi.

Il post del blog DynamoDB del CTO di Amazon Werner Vogels offre informazioni supplementari sull'evoluzione della tecnologia di database non relazionale in Amazon.

D: In quali casi è preferibile usare Amazon DynamoDB anziché Amazon S3?

Amazon DynamoDB memorizza dati strutturati, indicizzati da una chiave principale, e permette un accesso in scrittura e lettura a latenza bassa a voci che vanno da 1 byte a 400 KB. Amazon S3 memorizza blob non strutturati ed è adatto allo storage di oggetti di grandi dimensioni fino a 5 TB. Per ottimizzare i costi sulle offerte AWS, gli oggetti di grandi dimensioni o gruppi di dati di accesso non frequente andrebbero memorizzati in Amazon S3, mentre è preferire memorizzare gli elementi di dati più piccoli o i puntatori a file (se possibile su oggetti Amazon S3) in Amazon DynamoDB.

D: DynamoDB può essere usato da applicazioni funzionanti su qualunque sistema operativo?

Sì. DynamoDB è un servizio cloud interamente gestito a cui si accede attraverso API. DynamoDB può essere usato da applicazioni funzionanti su qualunque sistema operativo (per es. Linux, Windows, iOS, Android, Solaris, AIX, HP-UX, ecc.). Consigliamo di utilizzare gli SDK di AWS per cominciare con DynamoDB. Puoi trovare una lista di SDK di AWS sulla pagina Developer Resources. In caso di difficoltà di installazione o utilizzo di uno dei nostri SDK, informaci sul Forum AWS pertinente.


D: Cos'è il modello di dati?

Il modello di dati per Amazon DynamoDB è il seguente:

Tabella: una tabella è una raccolta di voci di dati, proprio come una tabella in un database relazionale è una raccolta di righe. Ogni tabella può avere un numero infinito di voci di dati. Amazon DynamoDB è senza schema, nel senso che le voci dei dati in una tabella non hanno bisogno degli stessi attributi e neanche dello stesso numero di attributi. Ogni tabella deve avere una chiave principale. La chiave principale può essere una chiave ad attributo singolo o una chiave ad attributo "composta" che combina due attributi. L'attributo o attributi designati come chiave principale devono esistere per ogni voce poiché le chiavi principali identificano ogni voce della tabella.

Voce: una voce è formata da una chiave principale o composta e da un numero variabile di attributi. Non sono esplicitamente previste limitazioni al numero di attributi associati a una singola voce, ma le dimensioni aggregate di una voce, inclusi tutti i nomi e i valori degli attributi, non possono superare i 400 KB.

Attributo: ogni attributo associato a una voce di dati è composto da un nome di attributo (per es. "Colore") e un valore o gruppo di valori (per es. "Rosso" o "Rosso, Giallo, Verde"). Gli attributi individuali non hanno limiti espliciti di dimensioni ma il valore totale di una voce (compresi tutti i nomi e valori di attributi) non può superare 400 KB.

D: C'è un limite alle dimensioni di una voce?

Le dimensioni totali di una voce, compresi nomi e valori di attributi, non possono superare 400 KB.

D: C'è un limite al numero di attributi che può avere una voce?

Non c'è un limite al numero di attributi che può avere una voce. Tuttavia le dimensioni totali di una voce, compresi nomi e valori di attributi, non possono superare 400 KB.

D: Che cosa sono le API?

  • CreateTable: crea una tabella e specifica l'indice principale utilizzato per accedere ai dati.
  • UpdateTable: aggiorna i valori di throughput assegnato per una tabella.
  • DeleteTable: elimina una tabella.
  • DescribeTable: restituisce le informazioni sulle dimensioni, lo stato e l'indice della tabella.
  • ListTables: restituisce la lista di tutte le tabelle associate all'account e endpoint attuali.
  • PutItem: crea una nuova voce o sostituisce una vecchia voce con una nuova (compresi tutti gli attributi). Se una voce esiste già in una tabella specificata con la stessa chiave principale, la nuova voce sostituisce completamente quella esistente. Si possono usare gli operatori condizionali per sostituire una voce solo se i suoi valori di attributo corrispondono a certe condizioni o per inserire una nuova voce solo se quella voce non esiste già.
  • BatchWriteItem: inserisce, sostituisce ed elimina voci multiple su tabelle multiple in una singola richiesta, ma non come transazione singola. Supporta batch fino a 25 voci per operazioni di aggiunta o eliminazione fino a 16 MB di richiesta totale massima.
  • UpdateItem: modifica gli attributi di una voce esistente. Si possono usare gli operatori per eseguire un aggiornamento solo se i suoi valori di attributo corrispondono a certe condizioni.
  • DeleteItem: elimina una singola voce in una tabella mediante la chiave principale. Si possono anche usare gli operatori condizionali per eliminare una voce solo se i suoi valori di attributo corrispondono a certe condizioni.
  • GetItem: l'operazione GetItem restituisce un gruppo di attributi per una voce che corrisponde alla chiave principale. L'operazione GetItem fornisce una lettura consistente finale predefinita. Se le letture consistenti finali non sono accettabili per un'applicazione, bisogna usare ConsistentRead.
  • BatchGetItem: l'operazione BatchGetItem restituisce gli attributi di più voci da più tabelle utilizzandone le chiavi principali. Una risposta singola è limitata a 16 MB e restituisce un massimo di 100 voci. Supporta la consistenza forte e finale.
  • Query: ottiene una o più voci utilizzando la chiave principale della tabella o da un indice secondario utilizzando la chiave indice. Si può ridurre l'ambito della query sulla tabella utilizzando operatori o espressioni di confronto. Si possono anche filtrare i risultati della query utilizzando filtri o attributi non chiave. Supporta la consistenza forte e finale. Una risposta singola è limitata a 1 MB.
  • Scan: ottiene tutte le voci e tutti gli attributi con una scansione completa della tabella o dell'indice secondario. Si può limitare il set di dati restituiti filtrando uno o più attributi.

D: Qual è il modello di consistenza di un'operazione di scansione?

L'operazione di scansione supporta letture consistenti finali e consistenti. L'impostazione predefinita dell'operazione di scansione è la lettura consistente finale. Tuttavia si può modificare il modello di consistenza utilizzando il parametro opzionale ConsistentRead nella chiamata API Scan. Impostare il parametro di ConsistentRead a "vero" permette di eseguire letture consistenti dall'operazione di scansione. Per ulteriori informazioni, consultare la documentazione delle operazioni di scansione.

D: Come funziona l'operazione di scansione?

Possiamo immaginare l'operazione di scansione come un iteratore. Quando le dimensioni aggregate delle voci analizzate in una richiesta API Scan superano 1 MB, la richiesta viene terminata e i risultati raccolti sono restituiti con una LastEvaluatedKey (per poter continuare la scansione in un'operazione successiva).

D: Ci sono limiti per un'operazione di scansione?

Un'operazione di scansione su una tabella o un indice secondario possiede un limite di 1 MB di dati per operazione. Oltrepassato il limite di 1 MB, arresta l'operazione e restituisce i valori corrispondenti a quel punto e una LastEvaluatedKey da utilizzare in un'operazione successiva, per poter riprendere dal punto dove si è fermata.

D: Quante unità di capacità in lettura utilizza un'operazione di scansione?

Le unità di lettura richieste sono il numero di byte raccolti dall'operazione di scansione, arrotondato al gruppo di 4 KB più vicino e poi diviso per 4 KB. La scansione di una tabella con letture consistenti utilizza il doppio della capacità in lettura rispetto a una scansione con letture consistenti finali.

D: Quale tipo di dati supporta DynamoDB?

DynamoDB supporta quattro tipi di dati scalari: Numero, Stringa, Binario e Booleano. Inoltre DynamoDB supporta i tipi di dati di raccolta Valore Impostato, Stringa Impostata, Binario Impostato, Lista eterogenea e Mappa eterogenea. DynamoDB supporta inoltre i valori NULL.

D: Che tipo di strutture di dati supporta DynamoDB?

DynamoDB supporta strutture di dati valore chiave e di dati documento.

D: Cos'è uno store di valori chiave?

Uno store di valori chiave è un servizio di database che offre supporto per storage, query e aggiornamento di raccolte di oggetti che sono identificati utilizzando una chiave e valori che contengono il contenuto reale memorizzato.

D: Cos'è uno store di documenti?

Uno store di documenti offre supporto per storage, query e aggiornamento di voci in un formato di documento quale JSON, XML e HTML.

D: DynamoDB possiede un tipo di dati JSON?

No, ma si può usare il Document SDK per trasferire i dati JSON direttamente su DynamoDB. I tipi di dati di DynamoDB sono un soprainsieme dei tipi di dati supportati da JSON. Il Document SDK converte automaticamente i documenti JSON nei tipi di dati DynamoDB.

D: Posso usare la Console di gestione AWS per visualizzare e modificare dei documenti JSON?

Sì. La Console di gestione AWS offre un'interfaccia utente semplice per esplorare e modificare i dati memorizzati nelle tabelle DynamoDB, compresi i documenti JSON. Per visualizzare o modificare i dati nella tabella, si deve accedere alla Console di gestione AWS, scegliere DynamoDB, selezionare la tabella che si vuole visualizzare e fare clic sul pulsante "Explore Table".

D: La query sui dati JSON è diversa dalle altre?

No. Si può creare un indice secondario globale o un indice secondario locale su qualunque elemento JSON di primo livello. Per esempio, supponiamo di aver memorizzato un documento JSON contenente le informazioni seguenti su una persona: Nome, Cognome, Codice Postale e una lista di tutti i suoi amici. Nome, Cognome e Codice Postale sono gli elementi JSON di primo livello. Si può creare un indice per eseguire una query sulla base di Nome, Cognome e Codice Postale. La lista di amici non è un elemento di primo livello, perciò non può essere indicizzata. Per ulteriori informazioni sull'indicizzazione secondaria globale e le sue capacità di query, consultare la sezione Secondary Indexes nelle Domande frequenti.

D: Se ho annidato dei dati JSON in DynamoDB, posso recuperare solo un elemento specifico di quei dati?

Sì. Quando si utilizzano le API GetItem, BatchGetItem, Query o Scan, si può definire una ProjectionExpression per determinare quali attributi devono essere recuperati dalla tabella. Questi attributi includono scalari, gruppi o elementi di un documento JSON.

D: Se ho annidato dei dati JSON in DynamoDB, posso aggiornare solo un elemento specifico di quei dati?

Sì. Quando si aggiorna una voce di DynamoDB, si può specificare il sottoelemento del documento JSON che si vuole aggiornare.

D: Cos'è l'SDK Document?

L'SDK Document è un wrapper di tipi di dati per JavaScript che agevola l'interoperabilità tra i tipi di dati JS e DynamoDB. Con questo SDK, le richieste saranno "impacchettate" automaticamente e nello stesso modo i tipi di dati saranno "spacchettati" per le risposte. Per ulteriori informazioni e scaricare l'SDK, consultare il repository GitHub su questa pagina.

 


D: C'è un limite alla quantità di dati che posso memorizzare in Amazon DynamoDB?

No. Non è prevista alcuna limitazione alla quantità di dati che è possibile memorizzare in una tabella Amazon DynamoDB. Man mano che le dimensioni del gruppo di dati aumentano, Amazon DynamoDB distribuisce automaticamente i dati su risorse di hardware sufficienti a garantire lo storage necessario.

D: C'è un limite al throughput che posso ottenere da una singola tabella?

No, puoi aumentare l'impostazione di limitazione della capacità massima per Auto Scaling o aumentare il throughput assegnato manualmente per una tabella con l'API o con la Console di gestione AWS. DynamoDB può funzionare su vasta scala e non ci sono limiti teorici sul throughput massimo che si può raggiungere. DynamoDB divide automaticamente la tabella su più partizioni e ogni partizione è un'unità di calcolo parallela indipendente. Con l'aggiunta di nuove partizioni DynamoDB può raggiungere tassi di throughput sempre più elevati.

Se vuoi superare i tassi di throughput di 10.000 scritture al secondo o di 10.000 letture al secondo, devi prima contattare Amazon tramite questo formulario online.

D: Amazon DynamoDB resta disponibile nel caso in cui Auto Scaling attivi il dimensionamento o in caso di incremento o riduzione del throughput assegnato?

Sì. Amazon DynamoDB è concepito per aumentare o ridurre il throughput assegnato restando disponibile, indipendentemente dal fatto che sia gestito da Auto Scaling o manualmente.

D: Oltre ad Amazon DynamoDB devo gestire la partizione lato client?

No. Amazon DynamoDB elimina la necessità di partizionare sulle tabelle di database per la scalabilità del throughput.

D: Quanto è elevata la disponibilità di Amazon DynamoDB?

Il servizio funziona su data center di Amazon sicuri e di elevata disponibilità. Il servizio replica i dati su tre strutture in una Regione AWS per offrire tolleranza ai guasti in caso di errore del server o di interruzione di corrente nella zona di disponibilità.

D: In che modo Amazon DynamoDB ottiene un tempo di attività e una durabilità ottimali?

Per ottenere un tempo di attività e una durabilità ottimali, Amazon DynamoDB replica i dati simultaneamente su tre strutture nella Regione AWS.


D: Cos'è la funzione Auto Scaling di DynamoDB?

Auto Scaling di DynamoDB è una funzione completamente gestita che aumenta o riduce automaticamente la capacità di lettura e di scrittura assegnata di una tabella DynamoDB o di un indice secondario globale man mano che le richieste dell'applicazione aumentano o diminuiscono.

D: Perché è utile la funzionalità Auto Scaling?

Auto Scaling elimina i dubbi nell'assegnare una capacità adeguata quando si creano nuove tabelle e riduce il carico operativo del throughput consumato per il monitoraggio continuo e per adeguare manualmente la capacità assegnata. Auto Scaling aiuta ad assicurare la disponibilità dell'applicazione e riduce i costi della capacità assegnata non utilizzata.

D: Quali modelli di richieste dell'applicazione e quale carico di lavoro sono adatti per Auto Scaling?

Auto Scaling è ideale per i modelli di richieste che sono uniformi, prevedibili, con un utilizzo del throughput alto e basso che dura da diversi minuti a ore.

D: Come posso abilitare Auto Scaling per una tabella DynamoDB o un indice secondario globale?

Dalla console di DynamoDB, quando crei una nuova tabella, lascia selezionata l'opzione "Use default settings" per abilitare Auto Scaling e applicare le stesse impostazioni per gli indici secondari globali per la tabella. Se deselezioni l'opzione "Use default settings", puoi impostare la capacità assegnata manualmente o abilitare Auto Scaling con valori personalizzati per l'utilizzo di destinazione e la capacità massima e minima. Per le tabelle esistenti, puoi abilitare Auto Scaling o modificare le impostazioni Auto Scaling esistenti accedendo alla scheda "Capacity" e per gli indici puoi abilitare Auto Scaling dalla scheda "Indexes". Auto Scaling può anche essere gestito a livello di programmazione tramite CLI o SDK AWS. Per ulteriori informazioni, consulta la DynamoDB Developer Guide.

D: Quali impostazioni posso configurare per Auto Scaling?

È possibile configurare tre impostazioni per Auto Scaling: Utilizzo di destinazione, la percentuale del throughput effettivamente consumato rispetto a quello totale assegnato, in un determinato momento, la Capacità minima rispetto alla quale è possibile ridurre Auto Scaling e la Capacità massima rispetto alla quale è possibile aumentare Auto Scaling. Il valore predefinito per l'Utilizzo di destinazione è 70% (l'intervallo consentito è 20% – 80% con incrementi dell'1%), la capacità minima è 1 unità e la capacità massima è il limite della tabella per il tuo account nella regione. Per informazioni sui limiti predefiniti della tabella a livello di regione, consulta la pagina Limiti in DynamoDB.

D: Posso modificare le impostazioni di una policy Auto Scaling esistente?

Sì, in qualsiasi momento puoi modificare le impostazioni di una policy Auto Scaling esistente dalla scheda "Capacity" nella console di gestione o a livello di programmazione dalla CLI o dall'SDK tramite le API Auto Scaling.

D: Come funziona Auto Scaling?

Quando crei una nuova policy Auto Scaling per la tua tabella DynamoDB, vengono creati allarmi di Amazon CloudWatch con soglie per l'utilizzo di destinazione che hai specificato, calcolato in base ai parametri della capacità consumata e assegnata pubblicati su CloudWatch. Se l'utilizzo effettivo della tabella si discosta dall'obiettivo per un intervallo di tempo specifico, gli allarmi di CloudWatch attivano Auto Scaling che valuta la tua policy e invia una richiesta API UpdateTable a DynamoDB per aumentare (o ridurre) in maniera dinamica la capacità di throughput assegnata della tabella per allineare l'utilizzo effettivo all'obiettivo.

D: Posso abilitare un'unica policy Auto Scaling tra più tabelle in più regioni?

No, una policy Auto Scaling può essere impostata solo su un'unica tabella o su indici secondari globali all'interno di una singola regione.

D: È possibile aumentare fino alla capacità massima o ridurre alla capacità minima una policy Auto Scaling istantaneamente?


No, l'incremento alla capacità massima o la riduzione alla capacità minima in maniera istantanea non è supportato. Tuttavia puoi disabilitare momentaneamente Auto Scaling, impostare la capacità desiderata che ti serve manualmente per la durata necessarie e riabilitare successivamente Auto Scaling.

D: Dove è possibile controllare le azioni di dimensionamento attivate da Auto Scaling?

Puoi controllare lo stato delle azioni di dimensionamento attivate da Auto Scaling dalla scheda "Capacity" nella console di gestione e dai grafici CloudWatch nella scheda "Metrics"

D: Come si stabilisce se una tabella ha una policy Auto Scaling attiva o meno?

Dalla console di DynamoDB, fare clic su Tables nel menu di sinistra per visualizzare l'elenco di tutte le tabelle DynamoDB nel tuo account. Per le tabelle che hanno una policy Auto Scaling attiva, nella colonna "Auto Scaling" è indicato READ_CAPACITY, WRITE_CAPACITY o READ_AND_WRITE, a seconda del fatto che la funzione Auto Scaling sia abilitata per la lettura, la scrittura o entrambi. Inoltre, nella sezione "Table details" della scheda "Overview" di una tabella, l'etichetta della capacità assegnata indica se la funzione Auto Scaling è abilitata per la lettura, la scrittura o entrambi.

D: Che cosa succede alla policy Auto Scaling quando si elimina una tabella o un indice secondario globale con una policy attiva?

Quando elimini una tabella o un indice secondario globale dalla console, vengono eliminati anche la relativa policy Auto Scaling e gli allarmi di CloudWatch supportati.

D: Sono previsti altri costi aggiuntivi per l'uso di Auto Scaling?

No, non sono previsti ulteriori costi aggiuntivi per l'uso di Auto Scaling oltre a quello che già paghi per DynamoDB e gli allarmi di CloudWatch. Per ulteriori informazioni sui prezzi di DynamoDB, consultare la pagina dei prezzi di DynamoDB.

D: Come funziona la capacità di throughput gestita da Auto Scaling con la mia capacità riservata?

Auto Scaling funziona con la capacità riservata allo stesso modo in cui funziona oggi la capacità di throughput assegnata manualmente. La capacità riservata viene applicata alla capacità assegnata totale per la regione nella quale l'hai acquistata. La capacità assegnata da Auto Scaling consumerà prima la capacità riservata, fatturata a un prezzo scontato, mentre la capacità in eccesso verrà addebitata alle tariffe standard. Per limitare il consumo totale della capacità riservata che hai acquistato, distribuisci il limite della capacità massima tra tutte le tabelle con la funzione Auto Scaling abilitata in modo che sia cumulativamente inferiore alla quantità della capacità riservata totale che hai acquistato.


D: Cosa sono gli indici secondari globali?

Gli indici secondari globali sono indici che contengono chiavi di partizione o chiavi di partizione-ordinamento differenti dalle chiavi principali della tabella.

Per consentire un accesso efficiente ai dati di una tabella, Amazon DynamoDB crea e mantiene gli indici per gli attributi della chiave principale. Ciò permette alle applicazioni di recuperare i dati rapidamente specificando i valori della chiave principale. Tuttavia molte applicazioni possono trarre vantaggio dal disporre di una o più chiavi secondarie (o alternative) per consentire un accesso efficiente ai dati con attributi diversi da quelli della chiave principale. Per ottenere questo, si possono creare uno o più indici secondari su una tabella ed emettere richieste di query su questi indici.

Amazon DynamoDB supporta due tipi di indici secondari:

  • Indice secondario locale: indice con la stessa chiave di partizione della tabella ma una chiave di ordinamento diversa. Un indice secondario locale è tale in quanto ogni sua partizione è configurata su una partizione di tabella con la stessa chiave di partizione.
  • Indice secondario globale: indice con una chiave di partizione o di partizione-ordinamento che può essere diversa da quelle nella tabella. Un indice secondario globale è considerato "globale" in quanto le query sull'indice possono comprendere tutte le voci in una tabella, su tutte le partizioni. 

Gli indici secondari sono mantenuti in modo automatico da Amazon DynamoDB come oggetti non frequenti. Le voci appaiono in un indice solo se esistono nella tabella nella quale è definito l'indice. Questo rende le query sull'indice molto efficienti, perché il numero di voci nell'indice è spesso considerevolmente minore del numero di voci in una tabella.

Gli indici secondari globali supportano attributi non unici, che aumentano la flessibilità della query consentendo di eseguire query su qualunque attributo non chiave della tabella.

Immaginiamo un gioco che memorizza le informazioni sui giocatori in una tabella DynamoDB la cui chiave principale consiste in UserId (partizione) e GameTitle (ordinamento). Le voci possiedono attributi chiamati TopScore, Timestamp, ZipCode e altri. Al momento della creazione della tabella, DynamoDB fornisce un indice implicito (indice principale) sulla chiave principale che può supportare query efficienti che restituiscono i punteggi massimi di un utente specifico per tutti i giochi.

Tuttavia, se l'applicazione richiede i punteggi massimi di utenti per un gioco in particolare, utilizzare questo indice principale non sarebbe efficace e richiederebbe la scansione di tutta la tabella. Invece un indice secondario globale con GameTitle come elemento chiave di partizione e TopScore come elemento chiave di ordinamento permetterebbe all'applicazione di recuperare rapidamente i punteggi massimi.

Un indice secondario globale o GSI (Global Secondary Index) non necessita di un elemento chiave di ordinamento. Per esempio, si può avere un GSI con una chiave provvista del solo elemento di partizione GameTitle. Nell'esempio sotto, i GSI non hanno attributi proiettati perciò restituiranno solo le voci (identificate dalla chiave principale) che hanno un attributo corrispondente a GameTitle sul quale è eseguita la query.

D: In quali casi devo usare gli indici secondari globali?

Gli indici secondari globali sono particolarmente utili per tener traccia delle relazioni fra attributi che possiedono molti valori diversi. Per esempio, è possibile creare una tabella DynamoDB con CustomerID come chiave di partizione principale per la tabella e ZipCode come chiave di partizione per un indice secondario globale, poiché esistono molti codici postali e, con ogni probabilità, l'elenco di clienti è lungo. Utilizzando la chiave principale è possibile ottenere rapidamente il record per ogni cliente. Utilizzando l'indice secondario globale si può eseguire efficacemente una query su tutti i clienti contrassegnati da un determinato codice postale.

Per assicurarsi di ottenere il massimo dalla capacità dell'indice secondario globale, consultare la documentazione best practices sui carichi di lavoro uniformi.

D: Come posso creare un indice secondario globale per una tabella DynamoDB?

I GSI associati a una tabella possono essere specificati in qualunque momento. Per le fasi dettagliate della creazione di una tabella e dei suoi indici, consultare questa pagina. Si può creare un massimo di 5 indici secondari globali per tabella.

D: La versione locale di DynamoDB supporta gli indici secondari globali?

Sì. La versione locale di DynamoDB è utile per sviluppare e testare applicazioni basate su DynamoDB. La versione locale di DynamoDB può essere scaricata qui

D: Cosa sono gli attributi proiettati?

I dati in un indice secondario consistono in attributi che sono proiettati, ovvero copiati, dalla tabella nell'indice. Quando si crea un indice secondario, si definisce la chiave alternativa per l'indice insieme a qualunque altro attributo che si vuole proiettare nell'indice. Amazon DynamoDB copia questi attributi nell'indice insieme agli attributi della chiave principale della tabella. A questo punto si possono eseguire query sull'indice nello stesso modo in cui si eseguono query su una tabella.

D: Una chiave di indice secondario globale può essere definita su attributi non unici?

Sì. Diversamente dalla chiave principale in una tabella, un indice GSI non esige che gli attributi indicizzati siano unici. Per esempio, un GSI su GameTitle può indicizzare tutte le voci che tengono traccia degli utenti per ogni gioco. In questo esempio su questo GSI può essere eseguita una query per restituire tutti gli utenti che hanno giocato al gioco "TicTacToe".

D: Qual è la differenza fra gli indici secondari globali e gli indici secondari locali?

Sia gli indici globali sia i secondari aumentano la flessibilità di query. Un indice secondario locale o LSI (Local Secondary Index) è collegato a un valore chiave di partizione specifico, mentre un GSI comprende tutti i valori della chiave principale. Poiché le voci che hanno lo stesso valore della chiave di partizione condividono la stessa partizione in DynamoDB, l'indice secondario "locale" comprende solo le voci che sono memorizzate insieme (sulla stessa partizione). Perciò lo scopo dell'LSI è di eseguire query sulle voci che possiedono lo stesso valore della chiave di partizione ma una chiave di ordinamento differente. Per esempio, immaginiamo una tabella DynamoDB che tiene traccia degli ordini per i clienti, in cui la chiave di partizione è CustomerId.

Un LSI su OrderTime consente di inoltrare query più efficienti per recuperare gli ordini recenti di un determinato cliente.

D'altra parte un GSI non è ristretto alle voci con un valore della chiave di partizione comune. Un GSI spazia su tutte le voci della tabella come una chiave principale. Per la tabella sopra, un GSI su ProductId può essere utilizzato per trovare in modo efficace tutti gli ordini di un particolare prodotto. In questo caso non è stata specificata alcuna chiave di ordinamento per il GSI, e anche se possono esistere molti ordini con lo stesso ProductId, saranno memorizzati come voci separate nel GSI.

Per assicurarti che i dati nella tabella e nell'indice abbiano un percorso condiviso nella stessa partizione, gli LSI limitano le dimensioni totali di tutti gli elementi (tabelle e indici) a 10 GB per valore di chiave di partizione. I GSI non obbligano a un percorso condiviso e non hanno nessuna restrizione simile.

Quando si scrive su una tabella, DynamoDB esegue aggiornamenti atomici di tutti gli LSI interessati. D'altra parte, gli aggiornamenti di qualunque GSI definito nella tabella sono a consistenza finale.

Gli LSI permettono all'API Query di recuperare gli attributi che non fanno parte della lista di proiezione. Questo non è un comportamento supportato per i GSI.

D: Come funzionano gli indici secondari globali?

Per molti versi, il comportamento dei GSI è simile a quello di una tabella DynamoDB. Si può eseguire una query su un GSI utilizzando un elemento chiave di partizione, con filtri condizionali sull'elemento chiave di ordinamento del GSI. Tuttavia, diversamente dalla chiave principale di una tabella DynamoDB, che deve essere unica, una chiave di GSI può essere la stessa per più voci. Se esistono più voci con la stessa chiave di GSI, sono tracciate come voci di GSI separate e una query di GSI le recupererà tutte come voci individuali. Internamente DynamoDB assicurerà che il contenuto del GSI sia aggiornato in modo appropriato quando le voci vengono aggiunte, eliminate o aggiornate.

DynamoDB memorizza gli attributi proiettati di un GSI nella struttura di dati del GSI insieme alla chiave del GSI e le chiavi principali delle voci corrispondenti. I GSI utilizzano storage per le voci proiettate che esistono nella tabella di origine. Questo consente di eseguire query sul GSI piuttosto che sulla tabella, aumentando la flessibilità della query e migliorando la distribuzione del carico di lavoro. Gli attributi che fanno parte di una voce in una tabella, ma non fanno parte della chiave del GSI, della chiave principale della tabella o degli attributi proiettati, non sono perciò restituiti quando si esegue una query sull'indice del GSI. Le applicazioni che necessitano di dati supplementari dalla tabella dopo aver eseguito una query sul GSI, possono recuperare la chiave principale dal GSI e poi usare sia l'API GetItem o BatchGetItem per recuperare gli attributi desiderati dalla tabella. Poiché i GSI sono a consistenza finale, le applicazioni che usano questo modello devono provvedere all'eliminazione della voce (dalla tabella) fra la chiamata al GSI e la chiamata a GetItem/BatchItem. 

DynamoDB tratta automaticamente le aggiunte, gli aggiornamenti e le eliminazioni in un GSI quando vengono eseguite le modifiche corrispondenti alla tabella. Quando una voce (con attributi chiave del GSI) viene aggiunta alla tabella, DynamoDB aggiorna il GSI in modo asincrono per aggiungere la nuova voce. In modo simile, quando una voce è eliminata dalla tabella, DynamoDB elimina la voce dal GSI interessato.

D: È possibile creare indici secondari globali per tabelle basate su partizione e tabelle con schema partizione-ordinamento?

Sì, è possibile creare un indice secondario globale indipendentemente dal tipo di chiave principale della tabella DynamoDB. La chiave principale della tabella può includere una chiave di partizione oppure sia una chiave di partizione sia una chiave di ordinamento.

D: Qual è il modello di consistenza per gli indici secondari globali?

I GSI supportano la consistenza finale. Quando delle voci sono inserite o aggiornate in una tabella, i GSI non sono aggiornati simultaneamente. In normali condizioni di funzionamento, una scrittura su un indice secondario globale si propagherà in una frazione di secondo. Nell'ipotesi poco probabile di un errore, i tempi saranno più lunghi. Per questo motivo la logica dell'applicazione deve essere capace di trattare i risultati della query sul GSI che sono potenzialmente obsoleti. Si noti che questo è lo stesso comportamento mostrato da altre API DynamoDB che supportano letture consistenti finali.

Immaginiamo una tabella che tenga traccia dei punteggi massimi nella quale ogni voce possiede gli attributi UserId, GameTitle e TopScore. La chiave di partizione principale è UserId, mentre la chiave di ordinamento principale è GameTitle. Se l'applicazione aggiunge una voce che indica un nuovo punteggio massimo per GameTitle "TicTacToe" e UserId "GAMER123" e poi esegue una query sul GSI, è possibile che il nuovo punteggio non sia nel risultato della query. Tuttavia, appena la propagazione del GSI è terminata, la nuova voce comincerà ad apparire in query di questo tipo nel GSI.

D: Posso effettuare il provisioning del throughput separatamente per la tabella e per ogni indice secondario globale?

Sì. I GSI gestiscono il throughput indipendentemente dalla tabella su cui sono basati. Quando abiliti Auto Scaling per una tabella nuova o esistente dalla console, puoi facoltativamente scegliere di applicare le stesse impostazioni ai GSI. Puoi inoltre assegnare manualmente differenti throughput per le tabelle e gli indici secondari globali.

A seconda dell'applicazione, il carico di lavoro della richiesta su un GSI può variare in modo significativo da quella della tabella o da altri GSI. Qui sotto sono proposti alcuni scenari che mostrano questo:

  • Un GSI che contiene una piccola frazione delle voci della tabella ha bisogno di un throughput di scrittura molto minore rispetto alla tabella intera.
  • Un GSI utilizzato per ricerche di voci poco frequenti ha bisogno di un throughput di lettura molto minore rispetto alla tabella intera.
  • Un GSI utilizzato da un'attività in background che comporta molte letture può necessitare di un throughput di lettura elevato per alcune ore al giorno.

Con l'evolvere delle necessità, si può modificare il throughput assegnato del GSI, indipendentemente dal throughput della tabella.

Immaginiamo una tabella DynamoDB con un GSI che proietta tutti gli attributi e ha la chiave di GSI presente nel 50% delle voci. In questo caso le unità di capacità in scrittura assegnate del GSI devono essere impostate a 50% delle unità di capacità in scrittura assegnate. Usando un approccio simile, si può stimare il throughput di lettura del GSI. Per ulteriori dettagli, consultare la documentazione del GSI di DynamoDB.

D: In che modo aggiungere un indice secondario globale può influenzare il throughput assegnato e lo storage di una tabella?

Similmente a una tabella DynamoDB, un GSI utilizza il throughput assegnato quando vengono eseguite su di esso delle letture o delle scritture. Una scrittura che aggiunge o aggiorna una voce di GSI utilizza unità di capacità in scrittura basate sulle dimensioni dell'aggiornamento. La capacità utilizzata dalla scrittura del GSI è aggiunta a quella necessaria per aggiornare la voce nella tabella.

Si noti che se si aggiunge, elimina o aggiorna una voce in una tabella DynamoDB e questo non risulta in una modifica del GSI, il GSI non utilizza nessuna unità di capacità in scrittura. Questo succede quando una voce senza attributi di chiave del GSI viene aggiunta alla tabella DynamoDB o quando una voce viene aggiornata senza modifiche delle chiavi del GSI o degli attributi proiettati.

Una query su un GSI utilizza unità di capacità in lettura, sulla base delle dimensioni delle voci esaminate dalla query.

I costi di storage per un GSI si basano sul numero totale di byte memorizzati in quel GSI. Questo comprende la chiave di GSI e gli attributi e i valori proiettati e un supplemento di 100 byte per l'indicizzazione.

D: DynamoDB può limitare le scritture della mia applicazione a causa del throughput assegnato di un GSI?

Poiché alcune o tutte le scritture su una tabella DynamoDB risultano in scritture sui GSI associati, è possibile che il throughput assegnato di un GSI si esaurisca. In una simile ipotesi le scritture successive sulla tabella saranno limitate. Questo può accadere anche la tabella possiede unità di capacità in scrittura.

D: Con quale frequenza posso modificare il throughput assegnato a livello dell'indice?

Le tabelle con GSI hanno gli stessi limiti giornalieri di numero delle operazioni di modifica del throughput delle tabelle normali.

D: Come mi viene addebitato l'indice secondario globale di DynamoDB?

Al cliente viene addebitato il throughput assegnato aggregato per una tabella e il suo GSI su base oraria. Quando l'assegnazione viene eseguita manualmente, quando non richiesto, al cliente viene addebitato il throughput assegnato aggregato per una tabella e il suo GSI su base oraria. Oltre a questo, gli vengono addebitati lo storage dei dati usato dal GSI e le spese standard di trasferimento (esterno) dei dati. Se si vuole modificare la capacità di throughput assegnata del GSI, si può utilizzare la Console di DynamoDB o l'API UpdateTable o l'API PutScalingPolicy per aggiornare le impostazioni della policy di Auto Scaling.

D: Posso specificare quale indice secondario globale deve essere usato per una query?

Sì. Oltre ai parametri di query abituali, un Query command del GSI comprende esplicitamente il nome del GSI su cui operare. Si noti che una query può utilizzare un solo GSI.

D: Quali chiamate API sono supportate dall'indice secondario globale?

Le chiamate API supportate da un GSI sono Query e Scan. Un'operazione di query cerca solo i valori degli attributi della chiave dell'indice e supporta un sottoinsieme di operatori di confronto. Poiché i GSI vengono aggiornati in modo asincrono, non si può usare il parametro ConsistentRead con la query. Consultare questa pagina per i dettagli sull'utilizzo dei GSI con query e scansioni.

D: Qual è l'ordine dei risultati di una scansione dell'indice secondario globale?

Per un indice secondario globale, con uno schema provvisto solo di chiave di partizione i risultati non vengono visualizzati in alcun ordine. Per un indice secondario globale con uno schema provvisto di chiave di partizione-ordinamento, l'ordine dei risultati è basato sull'attributo della chiave di ordinamento.

D: Posso modificare gli indici secondari globali dopo che una tabella è stata creata?

Sì, gli indici secondari globali possono essere modificati in qualunque momento, anche dopo che la tabella è stata creata.

D: Come posso aggiungere un indice secondario globale a una tabella esistente?

Un indice secondario globale può essere aggiunto mediante la console o una chiamata API. Sulla console DynamoDB, selezionare la tabella alla quale si vuole aggiungere un indice secondario globale e fare clic sul pulsante "Create Index" per aggiungere un nuovo indice. Seguire le istruzioni della procedura guidata di creazione dell'indice e, quando è terminata, selezionare "Create". Si può anche aggiungere o eliminare un indice secondario globale utilizzando la chiamata API UpdateTable con il parametro GlobalSecondaryIndexes. Per ulteriori informazioni consultare la pagina della documentazione.

D: come posso eliminare un indice secondario globale?

Si può eliminare un indice secondario globale dalla console o mediante una chiamata API. Sulla console DynamoDB, selezionare la tabella per la quale si vuole eliminare l'indice secondario globale. Poi selezionare la scheda "Indexes" sotto "Table Items" e fare clic sul pulsante "Delete" per eliminare l'indice. Si può eliminare un indice secondario globale anche utilizzando la chiamata API UpdateTable. Per ulteriori informazioni consultare la pagina della documentazione.

D: Posso aggiungere o eliminare più di un indice in una singola chiamata API sulla stessa tabella?

Si può aggiungere o eliminare solo un indice per chiamata API.

D: Cosa succede se invio richieste multiple per aggiungere lo stesso indice?

Solo la prima richiesta di aggiunta viene accettata e tutte le richieste successive risulteranno in errore finché la prima richiesta non è terminata.

D: Posso aggiungere o eliminare simultaneamente più indici sulla stessa tabella?

No, in qualunque momento ci può essere solo un'operazione di indicizzazione di aggiunta o eliminazione attiva su una tabella.

D: Devo effettuare un provisioning di throughput supplementare per aggiungere un indice secondario globale?

Con Auto Scaling, è consigliabile applicare le stesse impostazioni della tabella all'indice secondario globale. Quando l'assegnazione viene eseguita manualmente, quando non richiesto, si consiglia vivamente di effettuare un provisioning di throughput di scrittura supplementare separato dal throughput per l'indice. Se non si effettua un provisioning di throughput di scrittura supplementare, il throughput di scrittura dell'indice verrà utilizzato per aggiungere il nuovo indice. Questo influenzerà le prestazioni di scrittura dell'indice mentre l'indice viene creato e aumenterà il tempo di creazione del nuovo indice.

D: Devo ridurre il throughput supplementare sull'indice secondario globale quando l'indice è stato creato?

Sì, bisognerà diminuire il throughput di scrittura assegnato per aggiungere un indice, quando il processo è terminato.

D: Posso modificare il throughput di scrittura assegnato per aggiungere un indice secondario globale?

Sì, si può diminuire o aumentare il throughput di scrittura assegnato per la creazione di un indice in qualunque momento durante il processo di creazione.

D: Quando un indice secondario globale viene aggiunto, la tabella è ancora disponibile?

Sì, la tabella è disponibile quando un indice secondario globale viene aggiornato.

D: Quando un indice globale secondario viene aggiunto o eliminato, gli altri indici esistenti sono ancora disponibili?

Sì, gli indici esistenti sono disponibili quando l'indice secondario globale è in aggiornamento.

D: Quando un indice secondario globale viene creato o aggiunto, il nuovo indice è disponibile?

No, il nuovo indice diventa disponibile solo dopo che il processo di creazione è terminato.

D: Quanto tempo ci vuole per aggiungere un indice secondario globale?

La durata dell'operazione dipende dalle dimensioni della tabella e dal volume di throughput di scrittura supplementari allocato per la creazione dell'indice secondario globale. Il processo di aggiunta o eliminazione di un indice può variare da alcuni minuti ad alcune ore. Per esempio, immaginiamo che tu abbia una tabella di 1 GB che ha 500 unità di capacità in scrittura assegnate e che tu abbia fatto il provisioning di 1000 unità di capacità in scrittura supplementari per l'indice e la creazione del nuovo indice. Se il nuovo indice include tutti gli attributi nella tabella e la tabella usa tutte le unità di capacità in scrittura, si può supporre che la creazione dell'indice duri all'incirca 30 minuti.

D: Quanto tempo ci vuole per eliminare un indice secondario globale?

L'eliminazione di un indice di solito viene completata in pochi minuti. Per esempio, eliminare un indice con 1 GB di dati di solito prende meno di un minuto.

D: Come posso tener traccia del progresso delle operazioni di aggiunta o eliminazione di un indice secondario globale?

Si può usare la console DynamoDB o l'API DescribeTable per verificare lo stato di tutti gli indici associati alla tabella. Per un'operazione di aggiunta di indice, durante la creazione lo stato dell'indice sarà “CREATING”. Quando la creazione dell'indice sarà terminata, lo stato dell'indice cambierà da “CREATING” ad “ACTIVE”. Per un'operazione di eliminazione di indice, quando la richiesta sarà completata, l'indice eliminato non esisterà più.

D: Posso ricevere una notifica quando il processo di creazione per aggiungere un indice secondario globale è stato completato?

Puoi richiedere che una notifica sia inviata al tuo indirizzo email per confermare che l'indice è stato completato. Quando si aggiunge un indice mediante la console, si può richiedere una notifica durante l'ultima fase prima di creare l'indice. Quando la creazione dell'indice è terminata, DynamoDB invia una notifica SNS per email.

D: Cosa succede se provo ad aggiungere altri indici secondari globali, se ne ho già 5?

Attualmente sei limitato a 5 GSI. L'operazione "Add" non sarà completata e riceverai un errore.

D: Posso riutilizzare per un indice secondario globale un nome che è già stato utilizzato per un indice eliminato?

Sì, quando l'indice secondario globale è stato eliminato, quel nome d'indice può essere riutilizzato quando viene aggiunto un nuovo indice.

D: Posso eliminare un indice mentre si sta creando?

No, quando la creazione dell'indice è cominciata, il processo di creazione dell'indice non può essere annullato.

D: Gli attributi di chiave del GSI sono richiesti in tutte le voci di una tabella DynamoDB?

No. I GSI sono indici poco frequenti. Contrariamente al requisito di una chiave principale, una voce in una tabella DynamoDB non deve contenere nessuna delle chiavi del GSI. Se una chiave di GSI dispone di elementi sia di partizione sia di ordinamento e una voce della tabella non contiene uno dei due, tale voce non sarà indicizzata dal GSI corrispondente. In tali casi un GSI può essere molto utile per individuare in modo efficace le voci che possiedono un attributo poco comune.

D: Posso recuperare tutti gli attributi di una tabella DynamoDB da un indice secondario globale?

Una query su un GSI può solo restituire gli attributi che sono stati specificati per essere inclusi nel GSI al momento della creazione. Gli attributi compresi nel GSI sono quelli che sono proiettati in modo predefinito, come gli attributi di chiave di GSI e gli attributi di chiave principale di una tabella, e quelli specificati dall'utente perché siano proiettati. Per questo motivo, una query di GSI non restituirà gli attributi delle voci che fanno parte della tabella ma non sono inclusi nel GSI. Un GSI che specifica tutti gli attributi come proiettati può essere utilizzato per recuperare qualunque attributo di tabella. Consultare qui la documentazione su come usare i GSI per le query.

D: Come posso elencare i GSI associati con una tabella?

La API DescribeTable restituisce informazioni dettagliate sugli indici secondari globali di una tabella.

D: Quali tipi di dati possono essere indicizzati?

Tutti i tipi di dati scalari (numero, stringa, binario e booleano) possono essere usati per l'elemento chiave di ordinamento della chiave dell'indice secondario locale. I tipi gruppo, elenco e mappa non possono essere indicizzati.

D: È possibile impiegare indici di attributo composti?

No. Ma si possono concatenare degli attributi in una stringa e utilizzarla come chiave.

D: Quali tipi di dati possono far parte degli attributi proiettati per un GSI?

Si possono specificare attributi per qualunque tipo di dati (inclusi i tipi gruppo) per proiettarli in un GSI.

D: Quali sono le considerazioni di scalabilità dei GSI?

Le considerazioni di prestazione della chiave principale di una tabella DynamoDB sono valide anche per le chiavi del GSI. Un GSI presuppone uno schema di accesso relativamente casuale su tutte le sue chiavi. Per ottenere il massimo dal throughput allocato agli indici secondari, occorre selezionare un attributo della chiave di partizione del GSI che dispone di molti valori differenti e un attributo della chiave di ordinamento del GSI richiesto in modo sufficientemente uniforme, nel modo più casuale possibile.

D: Quali parametri saranno disponibili mediante CloudWatch per gli indici secondari globali?

Le tabelle con GSI forniranno parametri aggregati per la tabella e i GSI, nonché parametri particolari per la tabella e ogni GSI.

I report dei GSI individuali supporteranno un sottoinsieme dei parametri CloudWatch che sono supportate da una tabella. Queste includono:

  • capacità in lettura (capacità in lettura assegnata, capacità in lettura utilizzata)
  • capacità in scrittura (capacità in scrittura assegnata, capacità in scrittura utilizzata)
  • Eventi di lettura limitati
  • Eventi di scrittura limitati

Per ulteriori dettagli sui parametri supportati dalle tabelle e gli indici DynamoDB consultare questa pagina.

D: Come si esegue la scansione di un indice secondario globale?

Si può eseguire una scansione degli indici secondari globali tramite la console o l'API Scan.

Per eseguire la scansione di un indice secondario globale, bisogna fare un riferimento specifico all'indice oltre che al nome della tabella sulla quale verrà effettuata la scansione. È necessario specificare il nome e il valore dell'attributo di partizione dell'indice. È anche possibile specificare una condizione relativa all'attributo di ordinamento della chiave dell'indice.

D: Una scansione dell'indice secondario globale mi consentirà di specificare attributi non proiettati da restituire nel gruppo dei risultati?

Una scansione degli indici secondari globali non supporta il recupero di attributi non proiettati.

D: Ci sarà un supporto di scansione parallelo per gli indici?

Sì, la scansione parallela sarà supportata per gli indici e la semantica sarà la stessa che per la tabella principale.


D: Cosa sono gli indici secondari locali?

Gli indici secondari locali consentono di eseguire alcune query comuni in modo più rapido e meno costoso invece di recuperare un grande numero di voci e poi filtrare i risultati. Significa che la tua applicazione può contare su query più flessibili basate su un intervallo più ampio di attributi.

Prima del lancio degli indici secondari locali, per trovare voci specifiche all'interno di una partizione (voci che condividono la stessa chiave di partizione), DynamoDB avrebbe dovuto recuperare tutti gli oggetti che condividono la stessa chiave di partizione e filtrare di conseguenza i risultati. Per esempio, immaginiamo un'applicazione di e-commerce che memorizza i dati relativi agli ordini dei clienti in una tabella DynamoDB con uno schema partizione-ordinamento con il time stamp degli ID degli ordini dei clienti. Senza LSI, per trovare la risposta alla domanda "Visualizza tutti gli ordini fatti dal Cliente X con data di spedizione negli ultimi 30 giorni, ordinati per data di spedizione", dovevi utilizzare l'API Query per individuare tutti gli oggetti sotto la chiave di partizione "X", ordinare i risultati per data di spedizione ed escludere i record più vecchi.

Con gli indici secondari locali si semplifica la procedura. Adesso si può creare un indice con l'attributo "shipping date" ed eseguire questa query in modo efficace recuperando solo le voci necessarie. Questo riduce in modo significativo la latenza e il costo delle query poiché si recuperano soltanto le voci che rispondono a criteri specifici. Inoltre semplifica il modello di programmazione per la tua applicazione poiché non c'è più bisogno di definire la logica del cliente per filtrare i risultati. Questo nuovo indice secondario viene chiamato indice secondario "locale" perché è utilizzato con la chiave di partizione e quindi consente di eseguire ricerche a livello locale in un bucket di chiave di partizione. Mentre prima era possibile eseguire ricerche usando solo la chiave di partizione e la chiave di ordinamento, ora è possibile impiegare un indice secondario che sostituisce la chiave di ordinamento, aumentando il numero degli attributi che possono essere usati per query e migliorandone di conseguenza l'efficienza.

Le copie ridondanti degli attributi di dati sono copiate negli indici secondari locali che vengono definiti. Questi attributi includono la chiave di partizione e di ordinamento della tabella, oltre alla chiave di ordinamento alternativa personalizzata. Si possono anche memorizzare in modo ridondante altri attributi di dati nell'indice secondario locale per poter accedere agli altri attributi senza dover accedere alla tabella stessa.

Gli indici secondari locali sono adatti per tutte le applicazioni. Introducono alcune limitazioni sul volume dei dati che può essere memorizzato in un singolo valore di chiave di partizione. Per ulteriori informazioni, consultare le Domande frequenti qui sotto sulle raccolte di voci.

D: Cosa sono le proiezioni?

Il gruppo di attributi che viene copiato nell'indice secondario locale è chiamato proiezione. La proiezione determina gli attributi che si potranno recuperare con la massima efficienza. Quando si esegue una query su un indice secondario locale, Amazon DynamoDB può accedere a qualunque attributo proiettato, con le stesse caratteristiche di prestazioni che avrebbe se gli attributi fossero in una tabella a parte. Se hai bisogno di ritrovare degli attributi non proiettati, Amazon DynamoDB li recupera automaticamente dalla tabella.

Quando si definisce un indice secondario locale, si devono specificare gli attributi che saranno proiettati nell'indice. Gli elementi essenziali di un indice sono: (1) il valore della chiave di partizione della tabella; (2) un attributo da usare come chiave di ordinamento dell'indice; (3) il valore della chiave di ordinamento della tabella.

Oltre a questi elementi di base, è possibile scegliere un elenco personalizzato di altri attributi non chiave da proiettare nell'indice. È anche possibile proiettare tutti gli attributi nell'indice; in questo caso, l'indice replica gli stessi dati della tabella, ma ordinati secondo la chiave di ordinamento alternativa.

D: Come posso creare un LSI?

L'LSI va creato al momento in cui si crea la tabella. Non può essere aggiunto dopo. Per creare un LSI, si devono specificare i due parametri seguenti:

Chiave di ordinamento indicizzata: l'attributo che verrà indicizzato e su cui verranno eseguite le query.

Attributi proiettati: la lista degli attributi provenienti dalla tabella che saranno copiati direttamente nell'indice secondario locale, in modo che vengano restituiti più rapidamente senza raccogliere dati dall'indice principale, che contiene tutte le voci della tabella. Senza attributi proiettati, l'indice secondario locale contiene solo le chiavi dell'indice principale e secondario.

D: Qual è il modello di consistenza per l'LSI?

Gli indici secondari locali vengono aggiornati automaticamente quando viene aggiornato l'indice principale. Come le letture da un indice principale, l'LSI supporta le opzioni di lettura consistente forte e finale.

D: Gli indici secondari locali contengono riferimenti a tutte le voci nella tabella?

No, non necessariamente. Gli indici secondari locali fanno riferimento esclusivamente alle voci che contengono la chiave di ordinamento indicizzata specificata per quell'LSI. Lo schema flessibile di DynamoDB significa che non tutte le voci conterranno necessariamente tutti gli attributi.

Questo significa che l'indice secondario locale può essere scarsamente popolato, in confronto all'indice principale. Poiché gli indici secondari locali sono poco frequenti, sono efficaci per supportare query su attributi poco comuni.

Nell'esempio degli ordini descritto sopra, un cliente può avere alcuni attributi supplementari in una voce che sono inclusi solo se l'ordine viene annullato (come CanceledDateTime, CanceledReason). Per le query riguardanti le voci cancellate, un indice secondario locale su entrambi questi attributi sarebbe efficace poiché le sole voci referenziate nell'indice sarebbero quelle che possiedono questi attributi.

D: Come si eseguono le query sugli indici secondari locali?

Si possono eseguire query sugli indici secondari locali solamente tramite l'API Query.

Per eseguire una query su un indice secondario locale, bisogna referenziare in modo esplicito l'indice oltre al nome della tabella sulla quale si vuole eseguire la query. È necessario specificare il nome e il valore dell'attributo di partizione dell'indice. È anche possibile specificare una condizione relativa all'attributo di ordinamento della chiave dell'indice.

La query può recuperare attributi non proiettati memorizzati nell'indice principale eseguendo un'operazione di recupero di tabella, con un costo di unità di capacità in lettura supplementari.

Utilizzando l'indice secondario locale, entrambe le letture a consistenza forte e finale sono supportate per le query.

D: Come si creano gli indici secondari locali?

Gli indici secondari locali devono essere definiti al momento della creazione della tabella. L'indice principale della tabella deve usare una chiave composta partizione-ordinamento.

D: Posso aggiungere gli indici secondari locali alla tabella esistente?

No, non è possibile aggiungere gli indici secondari locali alla tabella esistente al momento attuale. Progettiamo di aggiungere questa funzionalità in una versione futura. Quando viene creata una tabella con indice secondario locale, è possibile scegliere di creare un indice secondario locale da usare in un secondo momento definendo un elemento chiave di ordinamento non utilizzato. Poiché gli indici secondari locali sono poco frequenti, questo indice non costa nulla finché non si decide di utilizzarlo.

D: Quanti indici secondari locali posso creare su una tabella?

Ogni tabella può avere fino a cinque indici secondari locali.

D: Quanti attributi non chiave proiettati possono creare su una tabella?

Ogni tabella può avere fino a 20 attributi non chiave proiettati in totale su tutti gli indici secondari locali della tabella. Ogni indice può anche specificare che tutti gli attributi non chiave dell'indice principale sono proiettati.

D: Posso modificare l'indice dopo che è stato creato?

No, un indice non può essere modificato dopo la creazione. Progettiamo di aggiungere questa funzionalità in futuro.

D: Posso eliminare gli indici secondari locali?

No, al momento attuale gli indici secondari locali non possono essere eliminati da una tabella dopo essere stati creati. Ovviamente vengono eliminati se si decide di eliminare l'intera tabella. Progettiamo di aggiungere questa funzionalità in una versione futura.

D: In che modo gli indici secondari locali utilizzano la capacità assegnata?

Non è necessario effettuare esplicitamente il provisioning di capacità per un indice secondario locale. Esso utilizza capacità assegnata come parte della tabella alla quale è associato.

Le letture dall'LSI e le scritture sulle tabelle con LSI utilizzano capacità secondo la formula standard di 1 unità per 1 KB di dati, con le differenze seguenti:

Quando le scritture contengono dati che sono pertinenti per uno o più indici secondari locali, le scritture sono replicate negli indici secondari locali appropriati. In questi casi, la capacità in scrittura sarà utilizzata per la tabella e la capacità in scrittura supplementare sarà utilizzata per ogni LSI appropriato.

Gli aggiornamenti che sovrascrivono una voce esistente possono risultare in due operazioni, elimina e inserisci, e perciò utilizzano unità supplementari di capacità in scrittura per 1 KB di dati.

Quando una query di lettura richiede attributi che non sono proiettati nell'LSI, DynamoDB recupera questi attributi nell'indice principale. Questa richiesta implicita GetItem utilizza un'unità di capacità in lettura per 4 KB di dati di voci raccolti.

D: Quanto storage utilizzano gli indici secondari locali?

Gli indici secondari locali utilizzano storage per il nome e il valore dell'attributo della chiave principale e dell'indice di ogni LSI per tutti gli attributi non chiave proiettati, più 100 byte per le voci riflesse nell'LSI.

D: Quali tipi di dati possono essere indicizzati?

Tutti i tipi di dati scalari (numero, stringa, binario) possono essere usati per l'elemento chiave di ordinamento della chiave di indice secondario locale. I tipi gruppo non possono essere usati.

D: Quali tipi di dati possono essere proiettati in un indice secondario locale?

Tutti i tipi di dati (compresi i tipi set) possono essere proiettati in un indice secondario locale.

D: Cosa sono le raccolte di voci e che relazione hanno con l'LSI?

In Amazon DynamoDB, una raccolta di voci è un qualsiasi gruppo di voci che dispongono della stessa chiave di partizione, su una tabella e su tutti gli indici secondari locali. Nei comuni sistemi di database relazionali partizionati (o suddivisi in shard), vengono definiti shard o partizioni, in riferimento a tutte le voci o righe del database memorizzate in una chiave di partizione.

Le raccolte di voci vengono create automaticamente e mantenute per ogni tabella che include indici secondari locali. DynamoDB memorizza ogni raccolta di voci in una singola partizione del disco.

D: Ci sono limiti nelle dimensioni di una raccolta di voci?

Ogni raccolta di voci in Amazon DynamoDB non può superare il limite di 10 gigabyte. Per qualsiasi valore distinto della chiave di partizione, la somma delle dimensioni della voce nella tabella, aggiunta alla somma delle dimensioni delle voci su tutti gli indici secondari locali di quella tabella, non deve superare i 10 GB.

Il limite di 10 GB per le raccolte di voci non è valido per le tabelle senza indici secondari locali, ma ha effetto solo sulle tabelle che possiedono uno o più indici secondari locali.

Anche se le raccolte di voci individuali sono limitate nelle dimensioni, le dimensioni di storage in una tabella con indici secondari locali nel suo insieme non hanno limiti. Le dimensioni totali di una tabella indicizzata in Amazon DynamoDB sono infatti illimitate, purché le dimensioni totali di storage (tabella e indici) per ogni valore della chiave di partizione non superino la soglia dei 10 GB.

D: Come si tiene traccia delle dimensioni di una raccolta di voci?

Le API di scrittura di DynamoDB (PutItem, UpdateItem, DeleteItem e BatchWriteItem) includono un'opzione che permette alla risposta dell'API di includere un calcolo approssimativo delle dimensioni della raccolta di voci in questione. Questo calcolo include la stima delle dimensioni minori e maggiori per i dati in una raccolta di voci particolare, espressa in gigabyte.

Ti raccomandiamo di instrumentare la tua applicazione per controllare le dimensioni delle tue raccolte di voci. Le applicazioni devono esaminare le risposte delle API riguardo alle dimensioni delle raccolte di voci e registrare un messaggio di errore ogni qualvolta una raccolta di voci supera i limiti definiti dall'utente (per esempio, 8 GB). Questo fornirà un sistema di avviso che avvertirà che le dimensioni di una raccolta di voci stanno aumentando, consentendoti di prendere le misure appropriate.

D: Cosa succede se supero il limite di 10 GB per una raccolta di voci?

Se una determinata raccolta di voci supera il limite di 10 GB, non sarà possibile scrivere nuove voci o aumentare le dimensioni delle voci esistenti per quella chiave di partizione. Le operazioni di lettura e di scrittura che diminuiscono le dimensioni della raccolta di voci sono ancora possibili. Questo non incide sulle altre raccolte di voci.

Per risolvere il problema si possono eliminare delle voci o ridurre le dimensioni delle voci nella raccolta che ha superato i 10 GB. In alternativa, è possibile aggirare la limitazione aggiungendo nuove voci con un nuovo valore di chiave di partizione. Se la tabella include dati storici ai quali si accede raramente, si consiglia di archiviare questi dati su Amazon S3, Amazon Glacier o altri store di dati.

D: Come si esegue la scansione di un indice secondario globale?

Per eseguire la scansione di un indice secondario locale, si deve referenziare l'indice il modo esplicito, oltre al nome della tabella sulla quale di vuole eseguire la scansione. È necessario specificare il nome e il valore dell'attributo di partizione dell'indice. È anche possibile specificare una condizione relativa all'attributo di ordinamento della chiave dell'indice.

La scansione può recuperare attributi non progettati memorizzati nell'indice principale effettuando un'operazione di recupero di tabella, con il costo di unità di capacità in lettura supplementari.

D: Una scansione su un indice secondario locale mi permette di specificare attributi non proiettati da restituire nel gruppo dei risultati?

La scansione sugli indici secondari locali supporta il recupero di attributi non proiettati.

D: Qual è l'ordine dei risultati nella scansione di un indice secondario locale?

Per un indice secondario locale, l'ordine nella raccolta si baserà sull'ordine nell'attributo indicizzato.


D: Cos'è il controllo d'accesso specifico di DynamoDB?

Il controllo d'accesso specifico (FGAC) offre al proprietario di una tabella DynamoDB un controllo elevato sui dati nella tabella. Più precisamente, il proprietario della tabella può indicare chi (intermediario) può accedere a quali voci o attributi della tabella ed effettuare quali operazioni/chiamata (lettura/scrittura). FGAC è utilizzato in concorso con Identity and Access Management (IAM) di AWS, che gestisce le credenziali di sicurezza e i permessi associati.

D: Quali sono i casi d'uso comuni per FGAC per DynamoDB?

FGAC rappresenta un vantaggio per qualunque applicazione che tiene traccia delle informazioni in una tabella DynamoDB, in cui l'utente finale (o il client dell'applicazione che agisce per conto dell'utente finale) vuole leggere o modificare direttamente la tabella, senza un servizio di livello intermedio. Per esempio, lo sviluppatore di un'applicazione mobile chiamata Acme può utilizzare FGAC per tener traccia del punteggio massimo di ogni utente Acme in una tabella DynamoDB. FGAC consente al cliente dell'applicazione di modificare solo il punteggio massimo per l'utente che sta eseguendo l'applicazione in quel momento.

D: Posso utilizzare il controllo d'accesso specifico con i documenti JSON?

Sì. Si può utilizzare il controllo d'accesso specifico (FGAC) per limitare l'accesso ai propri dati sulla base di attributi di primo livello nel documento. Non si può utilizzare FGAC per limitare l'accesso sulla base di attributi annidati. Supponiamo per esempio che un documento JSON memorizzato contenga le informazioni seguenti su una persona: ID, nome, cognome e un elenco di tutti i suoi amici. Si può utilizzare FGAC per limitare l'accesso sulla base dell'ID, del nome o del cognome ma non dell'elenco degli amici.

D: Senza FGAC come può uno sviluppatore ottenere il controllo di accesso a livello della voce?

Per ottenere questo livello di controllo senza FGAC, uno sviluppatore ha poche possibilità potenzialmente onerose. Ecco qualche esempio:

  1. Proxy: il cliente dell'applicazione manda una richiesta a un proxy intermediario che effettua l'autenticazione e l'autorizzazione. Una soluzione simile aumenta la complessità dell'architettura di sistema e può risultare in un maggiore costo totale di proprietà (TCO).
  2. Tabella per cliente: ogni cliente dell'applicazione ha la sua tabella assegnata. Poiché i clienti dell'applicazione accesso a tabelle diverse, sono protetti l'uno dall'altro. Questo può richiedere potenzialmente che uno sviluppatore debba creare milioni di tabelle, rendendo così la gestione del database estremamente difficile.
  3. Token incorporato per client: un token segreto è incorporato nel client dell'applicazione. Il limite di questa soluzione è nella difficoltà di modificare il token e gestirne l'impatto sui dati memorizzati. In questo caso la chiave delle voci alla quale può accedere questo cliente contiene il token segreto.

D: Come funziona FGAC per DynamoDB?

Con FGAC, un'applicazione richiede un token di sicurezza che autorizza l'applicazione ad accedere solo a voci specifiche in una specifica tabella DynamoDB. Con questo token, l'agente dell'applicazione dell'utente finale può effettuare richieste direttamente a DynamoDB. Quando arriva una richiesta, le credenziali della richiesta sono dapprima valutate da DynamoDB, che usa IAM per autenticare la richiesta e determinare le funzionalità consentite all'utente. Se la richiesta dell'utente non è permessa, FGAC impedisce l'accesso ai dati.

D: Quanto costa FGAC per DynamoDB?

Non ci sono costi aggiuntivi per l'utilizzo di FGAC. Come sempre, si pagano solo il throughput assegnato e lo storage associato alla tabella DynamoDB.

D: Come si inizia a usarlo?

Consultare la sezione Fine-Grained Access Control della "DynamoDB Developer Guide" per creare una policy di accesso e un ruolo IAM per un'applicazione (per es. un ruolo chiamato AcmeFacebookUsers per un app_id di Facebook su 34567) e per assegnare una policy di accesso al ruolo. La policy di attendibilità del ruolo determina i provider di identità accettati (p es. accesso tramite Amazon, Facebook o Google) e la policy di accesso descrive a quali risorse di AWS si può accedere (per es. una tabella DynamoDB). Utilizzando questo ruolo, l'applicazione può ottenere delle credenziali temporanee per DynamoDB chiamando l'API AssumeRoleWithIdentityRequest dell'AWS Security Token Service (STS).

D: Come posso permettere agli utenti di eseguire una query su un indice secondario locale, impedendo al tempo stesso che recuperino la tabella per cercare degli attributi non proiettati?

Alcune operazioni di query su un indice secondario locale possono essere più costose di altre se includono attributi non proiettati in un indice. È possibile ridurre queste operazioni di "recupero" potenzialmente costose limitando i permessi solo agli attributi proiettati, mediante la chiave di contesto "dynamodb:Attributes".

D: Come si impedisce agli utenti di accedere ad attributi specifici?

Per impedire l'accesso ad attributi specifici si consiglia di seguire il principio del privilegio minimo e di permettere l'accesso solo ad attributi specifici.

In alternativa si può utilizzare una policy Rifiuto per specificare gli attributi non accessibili. Tuttavia questo non è consigliato per i motivi seguenti:

  1. Con una policy Rifiuto l'utente può scoprire i nomi nascosti degli attributi inviando richieste ripetute per ogni nome di attributo possibile finché non gli viene negato l'accesso.
  2. Le policy Rifiuto sono più fragili, poiché DynamoDB può introdurre una nuova funzionalità API nel futuro che permette uno schema di accesso che si voleva bloccare.

D: Come si impedisce agli utenti di aggiungere dati non validi alla tabella?

I controlli di FGAC disponibili possono determinare quali voci sono state modificate o lette e quali attributi possono essere modificati o letti. Gli utenti possono aggiungere nuove voci senza gli attributi bloccati e cambiare qualunque valore in qualunque attributo modificabile.

D: Posso concedere l'accesso a vari attributi senza elencarli tutti?

Sì, il linguaggio di policy IAM supporta un ampio gruppo di operazioni di confronto, tra le quali StringLike, StringNotLike e molte altre. Per ulteriori informazioni, consulta IAM Policy Reference.

D: Come si crea una policy appropriata?

Ti consigliamo di utilizzare il generatore di policy DynamoDB della console DynamoDB. Puoi anche confrontare la tua policy con quelle elencate nell'"Amazon DynamoDB Developer Guide" per assicurarti che tu stia seguendo uno schema raccomandato. Si possono anche pubblicare le policy nei forum AWS per scambiare idee con la comunità DynamoDB.

D: Posso permettere l'accesso sulla base di un id utente canonico invece di id distinti per l'utente sulla base del provider di identità a cui hanno avuto accesso?

Questo non è possibile senza un "distributore di token". Se un utente recupera un accesso federato al ruolo IAM usando direttamente le credenziali Facebook con STS, quelle credenziali temporanee contengono solo le informazioni sull'accesso dell'utente a Facebook e non sull'accesso ad Amazon o a Google. Se desideri memorizzare internamente una mappatura di ognuno di questi accessi all'identificatore, puoi eseguire un servizio che gli utenti dovranno contattare per ottenere l'accesso ed effettuare una chiamata STS fornendo loro le credenziali definite dal valore di chiave di partizione indicato come loro id utente canonico.

D: Quali informazioni non possono essere nascoste agli intermediari di FGAC?

Attualmente alcune informazioni riguardanti le voci della tabella non possono essere bloccate agli intermediari:

  • Parametri delle raccolte di voci. L'intermediario può richiedere il numero stimato di voci e le dimensioni in byte della raccolta di voci.
  • Throughput utilizzato. L'intermediario può richiedere i dettagli del throughput assegnato utilizzato dalle operazioni.
  • Casi di convalida. In alcuni casi, l'intermediario può essere a conoscenza dell'esistenza e dello schema della chiave principale di una tabella quando non si vuole concedergli accesso. Per impedire ciò, bisogna seguire il principio del privilegio minimo e permettere l'accesso solo alle tabelle e alle operazioni/chiamata cui si vuole permettere l'accesso.
  • Se si nega l'accesso ad attributi specifici invece di stabilire un elenco degli accessi ad attributi specifici consentiti, l'intermediario può in teoria stabilire i nomi degli attributi nascosti secondo la logica del "permetti tutto tranne". È più sicuro invece stabilire un elenco di nomi di attributi specifici consentiti.

D: Amazon DynamoDB supporta le autorizzazioni di IAM?

Sì, DynamoDB supporta le autorizzazioni a livello di API mediante l'integrazione del servizio AWS Identity and Access Management (IAM).

Per ulteriori informazioni su IAM, consulta le seguenti pagine:

D: Vorrei eseguire l'analisi di sicurezza o la risoluzione dei problemi operativi sulle mie tabelle DynamoDB. È possibile visionare uno storico di tutte le chiamate API DynamoDB effettuate sul mio account?

Sì. AWS CloudTrail è un servizio Web che registra le chiamate alle API di AWS per il tuo account e fornisce i relativi file di log. Lo storico delle chiamate API di AWS creato da AWS CloudTrail rende possibile analisi di sicurezza, monitoraggio delle modifiche alle risorse e audit di conformità. Ulteriori dettagli sul supporto DynamoDB per CloudTrail possono essere trovati su questa pagina. Per ulteriori informazioni su CloudTrail consultare la pagina dei dettagli di AWS CloudTrail, quindi attivare il servizio tramite la home page di CloudTrail nella Console di gestione AWS.


D: Come mi viene addebitato l'utilizzo di Amazon DynamoDB?

Ogni tabella DynamoDB è associata a un throughput di lettura e di scrittura assegnato. La capacità di throughput è fatturata all'ora se si supera il piano gratuito.

Si noti che viene applicato un addebito all'ora per la capacità di throughput indipendentemente dal fatto che si inviino o no richieste alla tabella. Per cambiare la capacità di throughput assegnata alla propria tabella, si può utilizzare la Console di gestione AWS, l'API UpdateTable o l'API PutScalingPolicy per Auto Scaling.

Inoltre DynamoDB fattura lo storage dei dati indicizzati e le spese standard di trasferimento dei dati su internet.

Per ulteriori informazioni sui prezzi di DynamoDB, consultare la pagina dei prezzi di DynamoDB.

D: Ci sono degli esempi di prezzi?

L'esempio seguente spiega come calcolare i costi di throughput nella Regione Stati Uniti orientali (Virginia settentrionale). Per consultare i prezzi delle altre Regioni, consultare la pagina dei prezzi di DynamoDB.

Se si crea una tabella e si richiedono 10 unità di capacità in scrittura e 200 unità di capacità in lettura di throughput assegnato, verranno addebitati:

0,01 USD + (4 x 0,01 USD) = 0,05 USD all'ora

Se il throughput deve essere modificato e si aumenta la richiesta di throughput riservato a 10.000 unità di capacità in scrittura e 50.000 unità di capacità in lettura, la fattura sarà la seguente:

(1.000 x 0,01 USD) + (1.000 x 0,01 USD) = 20 USD/ora

Per ulteriori informazioni sui prezzi di DynamoDB, consultare la pagina dei prezzi di DynamoDB.

D: I prezzi includono le tasse?

Per maggiori dettagli sulle tasse, consultare l'Assistenza di Amazon Web Services sulle imposte

D: Cos'è il throughput assegnato?

Amazon DynamoDB Auto Scaling adegua automaticamente la capacità di throughput in base alle variazioni dei volumi delle richieste, in base all'utilizzo di destinazione desiderato e ai limiti della capacità massima e minima o consente di specificare il throughput per le richieste che deve raggiungere la propria tabella manualmente. In pratica, il servizio gestisce il provisioning di risorse per raggiungere il tasso di throughput richiesto. Anziché preoccuparti di istanze, hardware, memoria e di altri fattori che possono influenzare il tasso di throughput, devi solo effettuare il provisioning del livello di throughput che vuoi ottenere. Questo è il modello di servizio di throughput assegnato.

Durante la creazione di una nuova tabella o di un indice secondario globale, per impostazione predefinita la funzione Auto Scaling è abilitata con le impostazioni predefinite per l'utilizzo di destinazione e la capacità massima e minima, oppure puoi specificare manualmente le tue necessità di capacità in lettura e in scrittura e Amazon DynamoDB partiziona automaticamente e prenota la quantità appropriata di risorse per soddisfare i tuoi requisiti di throughput.

D: In che modo la scelta di una chiave principale influenza la scalabilità che posso raggiungere?

Quando memorizza i dati, Amazon DynamoDB suddivide la tabella in più partizioni e distribuisce i dati sulla base dell'elemento chiave di partizione della chiave principale. Durante l'assegnazione delle risorse di capacità, Amazon DynamoDB presuppone uno schema di accesso relativamente casuale su tutte le chiavi principali. Bisogna impostare il modello dei dati in modo da distribuire il traffico delle richieste in modo uniforme sulle chiavi principali. Se la tabella contiene un numero esiguo di elementi di chiave di partizione di frequente accesso, verosimilmente un solo elemento chiave di partizione usato molto frequentemente, il traffico si concentra su un numero inferiore di partizioni, potenzialmente una sola. Se il carico di lavoro è molto sbilanciato, ovvero concentrato in modo sproporzionato su una sola o su poche partizioni, le operazioni non raggiungeranno il livello di throughput allocato generale. Per ottenere il massimo dal throughput di Amazon DynamoDB, occorre creare tabelle in cui l'elemento chiave di partizione dispone di molti valori differenti, e tali valori devono essere richiesti in modo sufficientemente uniforme, nel modo più casuale possibile. Un esempio di chiave principale efficace è CustomerID se l'applicazione ha molti clienti e le richieste fatte a vari record di clienti tendono ad essere uniformi. Une esempio di chiave principale altamente inefficace è "Nome categoria di prodotto" in cui certe categorie di prodotti sono più popolari di altre.

D: Cos'è un'unità di capacità in lettura?

Come faccio a calcolare di quante unità di capacità in lettura e in scrittura ho bisogno per la mia applicazione? Un'unità di capacità in scrittura permette di effettuare una scrittura al secondo per voci di dimensioni fino a 1 KB. Nello stesso modo, un'unità di capacità in lettura permette di effettuare una lettura fortemente consistente al secondo (oppure due letture consistenti finali al secondo) di voci fino a 4 KB. Le voci più voluminose richiederanno maggiore capacità. Per calcolare il numero di unità di capacità in lettura e in scrittura di cui hai bisogno, devi fare una stima del numero di letture o scritture al secondo che ti occorrono e moltiplicarlo per le dimensioni delle voci (arrotondato al numero di KB più vicino).

Unità di capacità necessarie per le scritture = numero di scritture di voci al secondo x dimensioni della voce in blocchi di 1 KB

Unità di capacità necessarie per le letture* = numero di letture di voci al secondo x dimensioni della voce in blocchi di 4 KB

*Se si usano le letture consistenti finali il throughput in termini di letture al secondo è raddoppiato.

Se le voci hanno dimensioni inferiori a 1 KB, ogni unità di capacità in lettura fornirà 1 lettura fortemente consistente al secondo e ogni unità di capacità in scrittura fornirà 1 scrittura al secondo di capacità. Per esempio, se le tue voci sono di 512 byte e hai bisogno di leggere 100 voci al secondo dalla tabella, devi effettuare il provisioning di 100 unità di capacità in lettura.

Se le voci superano 4 KB, devi calcolare il numero di unità di capacità in lettura e di scrittura di cui hai bisogno. Per esempio, se le tue voci sono di 4,5 KB e hai bisogno di 100 letture fortemente consistenti al secondo, devi effettuare il provisioning di 100 (letture al secondo) x 2 (numero dei blocchi necessari a memorizzare 4,5 KB) = 200 unità di capacità in lettura.

Si noti che il numero di unità di capacità in lettura richiesto è determinato dal numero di voci lette al secondo, non dal numero di chiamate API. Per esempio, se hai bisogno di leggere 500 voci al secondo dalla tabella e le voci non sono superiori a 4 KB, hai bisogno di 500 unità di capacità in lettura. Non ha importanza se esegui 500 chiamate individuali GetItem o 50 chiamate BatchGetItem che restituiscono 10 voci ciascuna.

D: Potrò sempre raggiungere il mio livello di throughput assegnato?

Amazon DynamoDB presuppone uno schema di accesso relativamente casuale su tutte le chiavi principali. Bisogna impostare il modello dei dati in modo da distribuire il traffico delle richieste in modo uniforme sulle chiavi principali. Se lo schema di accesso è irregolare o non diretto, è possibile che non si riesca a raggiungere il livello di throughput assegnato.

Quando memorizza i dati, Amazon DynamoDB suddivide la tabella in più partizioni e distribuisce i dati sulla base dell'elemento chiave di partizione della chiave principale. Anche il throughput assegnato associato alla tabella viene diviso fra le partizioni: il throughput di ogni partizione è gestito indipendentemente sulla base della quota che gli è stata assegnata. Il throughput assegnato non può essere condiviso fra le partizioni. Di conseguenza, una tabella in Amazon DynamoDB è la soluzione migliore per soddisfare i livelli di throughput allocati se il carico di lavoro è distribuito in modo abbastanza uniforme sui valori della chiave di partizione. Distribuendo le richieste sui valori chiave di partizione, le richieste vengono suddivise tra tutte le partizioni, facilitando il raggiungimento del livello di throughput allocato.

Se lo schema di carico di lavoro sulle chiavi principali è irregolare e non si riesce a raggiungere il livello di throughput assegnato, i bisogni di throughput possono essere soddisfatti aumentando il livello di throughput assegnato, in modo da assegnare un maggiore throughput a ogni partizione. Tuttavia si consiglia di modificare lo schema di richiesta o il modello dei dati per raggiungere uno schema di accesso relativamente casuale sulle chiavi principali.

D: Se recupero solo un singolo elemento di un documento JSON, mi verrà fatturato come una lettura della voce completa?

Sì. Quando si leggono dei dati da DynamoDB, si utilizza il throughput necessario a leggere l'intera voce.

D: Qual è il throughput massimo che posso assegnare per una singola tabella DynamoDB?

DynamoDB è stato concepito per dimensionarsi senza limiti. Tuttavia, se vuoi superare i tassi di throughput di 10.000 unità di capacità in scrittura o 10.000 unità di capacità in lettura per una singola tabella, devi prima contattare Amazon tramite questo formulario online. Se vuoi assegnare più di 20.000 unità di capacità in scrittura o 20.000 unità di capacità in lettura a un singolo account di sottoscrittore devi prima contattarci usando il formulario descritto sopra.

D: Qual è il throughput minimo che posso assegnare per una singola tabella DynamoDB?

Il throughput assegnato minimo che si può richiedere è 1 unità di capacità in scrittura e 1 unità di capacità in lettura per Auto Scaling e l'assegnazione manuale del throughput.

Questo rientra nel piano gratuito che comprende 25 unità di capacità in scrittura e 25 unità di capacità in lettura. Il piano gratuito è valido a livello dell'account, non a livello delle tabelle. In altre parole, se si aggiunge della capacità assegnata a tutte le tabelle e la capacità totale non supera 25 unità di capacità in scrittura e 25 unità di capacità in lettura, la capacità assegnata rientra nel piano gratuito.

D: C'è un limite a quanto posso cambiare il throughput assegnato in una singola richiesta?

Si può aumentare a piacere la capacità di throughput assegnata di una tabella utilizzando l'API UpdateTable. Per esempio, si può aumentare la capacità in scrittura assegnata di una tabella da 1 unità di capacità in scrittura a 10.000 unità di capacità in scrittura con una singola chiamata API. Il tuo account è ancora sottoposto ai limiti di capacità a livello delle tabelle e dell'account, come descritto nella pagina della documentazione. Se hai bisogno di aumentare i limiti della tua capacità assegnata, puoi visitare il Centro di supporto, fare clic su “Open a new case” e presentare una richiesta di aumento del limite di servizio.

D: Come mi viene addebitato il throughput assegnato?

Ogni tabella Amazon DynamoDB ha preassegnate le risorse di cui ha bisogno per raggiungere il tasso di throughput richiesto dal cliente. La fatturazione è oraria finché la tabella non supera quelle risorse. Per un elenco completo dei prezzi con esempi, consultare la pagina dei prezzi di DynamoDB.

D: Come si modifica il throughput assegnato per una tabella DynamoDB esistente?

Esistono due modi per aggiornare il throughput assegnato di una tabella Amazon DynamoDB. È possibile effettuare la modifica nella console di gestione o utilizzare la chiamata API UpdateTable. In entrambi i casi, Amazon DynamoDB resta disponibile mentre aumenta o diminuisce il livello di throughput.

D: Con quale frequenza posso modificare il throughput assegnato?

Il throughput assegnato può essere aumentato alla frequenza desiderata. Può essere diminuito fino a quattro volte al giorno. Un giorno è definito secondo il fuso orario GMT. Inoltre, se nelle ultime 4 ore non è stata effettuata alcuna riduzione, è consentita un'ulteriore riduzione, portando il numero massimo di riduzioni in un giorno a 9 (4 riduzioni nelle prime 4 ore e 1 riduzione per ciascuna delle successive 4 ore in un giorno).

Si noti che non si può modificare il throughput assegnato se la tabella Amazon DynamoDB sta ancora rispondendo all'ultima richiesta di modifica di throughput assegnato. Utilizzare la console di gestione o l'API DescribeTables per verificare lo stato della tabella. Se lo stato è “CREATING”, “DELETING” o “UPDATING”, non sarà possibile modificare il throughput della tabella. Bisogna aspettare che la tabella sia di nuovo nello stato “ACTIVE” e riprovare.

D: Il livello di consistenza influenza il tasso di throughput?

Sì. Per un'assegnazione data di risorse, il tasso di lettura che può raggiungere una tabella DynamoDB è diversa a seconda se la lettura è fortemente consistente o consistente finale. Se si richiedono "1.000 unità di capacità in lettura", DynamoDB assegnerà risorse sufficienti per raggiungere 1.000 letture fortemente consistenti al secondo di voci che non superano 4 KB. Se si vogliono raggiungere 1.000 letture consistenti finali di voci che non superano 4 KB, basterà la metà di quella capacità, ovvero 500 unità di capacità in lettura. Per informazioni ulteriori su come scegliere il tasso di throughput appropriato per la tua tabella, puoi consultare la guida sul throughput assegnato.

D: Le dimensioni della voce influiscono sul tasso di throughput?

Sì. Per una determinata assegnazione di risorse, il tasso di lettura che può raggiungere una tabella DynamoDB dipende dalle dimensioni della voce. Quando si specifica il throughput assegnato di lettura che si vuole raggiungere, DynamoDB effettua il provisioning delle risorse partendo dal presupposto che le voci siano inferiori a 4 KB. Ogni aumento fino a 4 KB aumenterà in modo lineare le risorse necessarie a raggiungere lo stesso tasso di throughput. Per esempio, se si allestisce una tabella DynamoDB con 100 unità di capacità in lettura, significa che può gestire 100 letture di 4 KB al secondo o 50 letture di 8 KB al secondo o 25 letture di 16 KB al secondo, e così via.

In modo simile il tasso di scrittura che può raggiungere una tabella DynamoDB dipende dalle dimensioni di una voce. Quando si specifica il throughput assegnato di scrittura che si vuole raggiungere, DynamoDB effettua il provisioning delle risorse partendo dal presupposto che le voci siano inferiori a 1 KB. Ogni aumento fino a 1 KB aumenterà in modo lineare le risorse necessarie a raggiungere lo stesso tasso di throughput. Per esempio, se si allestisce una tabella DynamoDB con 100 unità di capacità in scrittura, significa che può gestire 100 scritture da 1 KB al secondo o 50 scritture da 2 KB al secondo o 25 scritture da 4 KB al secondo, e così via.

Per informazioni ulteriori su come scegliere il tasso di throughput appropriato per la tua tabella, puoi consultare la guida sul throughput assegnato.

D: Cosa succede se la mia applicazione effettua più letture o scritture della capacità assegnata?

Se la tua applicazione effettua più letture o scritture al secondo di quanto lo consenta la capacità di throughput assegnata alla tabella, le richieste al di sopra della capacità assegnata saranno limitate e riceverai il codice errore 400. Per esempio, se hai richiesto 1.000 unità di capacità in scrittura e cerchi di effettuare 1.500 scritture al secondo, DynamoDB permetterà di completare solo 1.000 scritture e riceverai il codice errore 400 per le richieste supplementari. Si raccomanda di usare CloudWatch per controllare il tasso di richiesta, per assicurarsi di avere sempre sufficiente throughput assegnato per raggiungere il tasso di richiesta necessario.

D: Come faccio a sapere se sto superando la capacità di throughput assegnata?

DynamoDB pubblica la capacità di throughput utilizzata come parametro di CloudWatch. Si può predisporre un allarme su questo parametro in modo da ricevere una notifica se ci si avvicina al limite della capacità assegnata.

D: Quanto tempo richiede la modifica del livello di throughput assegnato di una tabella?

In generale, la riduzione di throughput può prendere da alcuni secondi ad alcuni minuti, mentre l'aumento di throughput prende da alcuni minuti fino ad alcune ore.

Consigliamo vivamente di non pianificare aumenti del throughput nei periodi in cui è necessario del throughput supplementare. Raccomandiamo di assegnare la capacità di throughput abbastanza in anticipo per assicurarsi che sia disponibile quando ce n'è bisogno.

D: Cos'è la capacità riservata?

La capacità riservata è una caratteristica della fatturazione che vi consente di ottenere sconti sulla capacità di throughput assegnata in cambio di:

  • un pagamento anticipato immediato
  • l'impegno di un livello minimo di uso mensile per la durata dei termini del contratto.

La capacità riservata è valida in una singola Regione AWS e può essere acquistata a 1 anno o a 3 anni. Ogni tabella DynamoDB ha una capacità di throughput assegnata associata, indipendentemente dal fatto che sia gestita da Auto Scaling o che l'assegnazione sia stata fatta manualmente in fase di creazione o aggiornamento di una tabella. La capacità è quello che determina il tasso di throughput di lettura e di scrittura che può raggiungere la tabella DynamoDB. La capacità riservata è un accordo di fatturazione e non ha impatto diretto sulle prestazioni o la capacità delle tabelle DynamoDB. Per esempio, se si acquistano 100 unità di capacità in scrittura di capacità riservata, bisogna pagare quella quantità di capacità per la durata del contratto (1 o 3 anni) in cambio di uno sconto.

D: Come si acquista la capacità riservata?

Accedi alla Console di gestione AWS, vai alla pagina della console DynamoDB e fai clic su "Reserved Capacity”. Arriverai alla pagina "Reserved Capacity Usage". Fai clic su "Purchase Reserved Capacity" e si aprirà un formulario da riempire per acquistare della capacità riservata. Assicurati di selezionare la Regione AWS in cui la capacità riservata sarà utilizzata. Dopo aver completato l'acquisto, questo sarà visibile nella pagina "Reserved Capacity Usage".

D: È possibile cancellare un acquisto di capacità riservata?

No, non è possibile cancellare l'acquisto di capacità riservata e il singolo pagamento non è rimborsabile. Durante il periodo di capacità riservata continuerai a pagare per tutte le ore, indipendentemente dall'utilizzo.

D: Qual è la quantità minima di capacità riservata che posso acquistare?

L'offerta minima di capacità riservata è di 100 unità di capacità (letture o scritture).

D: Esistono delle API che posso usare per acquistare della capacità riservata?

Non ancora. Nel futuro saranno disponibili delle API e ulteriori opzioni di capacità riservata.

D: È possibile spostare della capacità riservata da una Regione a un'altra?

No. La capacità riservata è associata a una singola Regione.

D: Posso effettuare il provisioning di una capacità di throughput maggiore della mia capacità riservata?

Sì. Quando acquisti della capacità riservata, accetti un livello minimo di uso e paghi una tariffa scontata per quel livello di uso. Se assegni una capacità maggiore di quel livello minimo, ti sarà addebitata la tariffa standard per la capacità supplementare.

D: Come si usa la capacità riservata?

La capacità riservata è applicata automaticamente alla tua fattura. Per esempio, se hai acquistato 100 unità di capacità in scrittura di capacità riservata e ne hai assegnate 300, la capacità riservata acquistata coprirà automaticamente il costo di 100 unità di capacità in scrittura e pagherai la tariffa standard per le 200 unità di capacità in scrittura rimanenti.

D: Cosa succede se assegno meno capacità di throughput della capacità riservata?

Un acquisto di capacità riservata è un accordo che prevede il pagamento di una quantità minima di capacità di throughput assegnata per la durata dei termini del contratto, in cambio di una tariffa scontata. Anche se usi meno della tua capacità riservata, ogni mese ti sarà addebitata la quantità minima di capacità di throughput assegnata.

D: Posso utilizzare la mia capacità riservata per più tabelle DynamoDB?

Sì. La capacità riservata è applicata alla capacità totale assegnata nella Regione nella quale hai acquistato la capacità riservata. Per esempio, se hai acquistato 5.000 unità di capacità in scrittura, puoi applicarle a una tabella con 5.000 unità di capacità in scrittura o a 100 tabelle con 50 unità di capacità in scrittura o a 1.000 tabelle con 5 unità di capacità in scrittura, ecc.

D: La capacità prenotata si applica all'uso di DynamoDB negli account di pagamento della fatturazione consolidata?

Sì. Se disponi di più account collegati con fatturazione consolidata, le unità di capacità prenotata acquistate a livello di account di pagamento o di account collegato sono condivise con tutti gli account collegati all'account di pagamento. La capacità prenotata sarà applicata prima all'account che l'ha acquistata e quindi, se ne rimane di inutilizzata, sarà applicata agli altri account collegati.

 

D: Cos'è una replica di DynamoDB in più Regioni?

La replica in più Regioni di DynamoDB consente di mantenere copie identiche (chiamate repliche) di una tabella DynamoDB (chiamata tabella master) in una o più Regioni AWS. Dopo aver attivato una replica in più Regioni di una tabella, delle copie identiche della tabella vengono create in altre Regioni AWS. Le scritture sulla tabella verranno propagate automaticamente a tutte le repliche.

 

D: Quando si deve usare la replica in più Regioni?

Si può usare la replica in più Regioni nei casi seguenti.

  • Disaster recovery efficiente: con la replica delle tabelle in più data center si può passare a usare le tabelle DynamoDB in un'altra Regione in caso di guasto in un data center.
  • Letture più rapide: se hai clienti in più Regioni puoi consegnare i dati più rapidamente leggendo una tabella DynamoDB nel data center di AWS più vicino.
  • Gestione del traffico semplificata: puoi usare le repliche per distribuire il carico di lavoro sulle tabelle e perciò utilizzare meno capacità in lettura nella tabella master.
  • Migrazione regionale semplificata: creando una replica di lettura in una nuova Regione e convertendola da replica a master, puoi trasferire la tua applicazione in quella Regione più facilmente.
  • Migrazione dei dati reali: per spostare una tabella DynamoDB da una Regione a un'altra si può creare una replica della tabella dalla Regione di origine alla Regione di destinazione. Quando le tabelle sono sincronizzate, si può cambiare l'applicazione perché scriva sulla Regione di destinazione.

D: Quali modi di replica in più Regioni sono supportati?

La replica in più Regioni supporta attualmente la modalità master singola. Una master singola possiede solo una tabella master e una o più tabelle di replica.

D: Come posso impostare una replica master singola su più Regioni per una tabella?

È possibile creare repliche in più Regioni utilizzando la libreria di replica in più Regioni DynamoDB.

D: Come si fa a sapere quando il processo di bootstrap è terminato?

Sull'applicazione di gestione di replica, lo stato di replica cambia da "Bootstrapping" ad "Active".

D: Posso avere più repliche per una tabella master singola?

Sì, non ci sono limiti al numero di tabelle di replica da una singola tabella master. Un lettore di flussi DynamoDB viene creato per ogni tabella di replica e copia i dati dalla tabella master, mantenendo le repliche sincronizzate.

D: Quando costa impostare una replica su più Regioni per una tabella?

La replica in più Regioni DynamoDB si attiva utilizzando la Libreria di replica in più Regioni DynamoDB. Anche se non sono previsti addebiti per la libreria di replica in più Regioni, saranno applicati i prezzi consueti per le risorse seguenti utilizzate dalla libreria. Addebiti applicati:

  • Throughput assegnato (letture e scritture) e storage per le tabelle di replica.
  • Trasferimento dei dati in più Regioni.
  • Lettura di dati dalla funzione Flusso di DynamoDB per mantenere sincronizzate le tabelle.
  • Istanze EC2 assegnate per l'hosting del processo di replica. Il costo delle istanze dipenderà dal tipo di istanza scelto e dalla Regione in cui viene eseguito l'hosting delle istanze.

D: In quale Regione viene eseguita l'istanza EC2 Amazon che esegue l'hosting della replica su più Regioni?

L'applicazione di replica su più Regioni è ospitata in un'istanza EC2 Amazon nella stessa Regione in cui l'applicazione di replica in più Regioni è stata lanciata in origine. Ti sarà addebitato il prezzo dell'istanza in quella Regione.

D: L'istanza EC2 Amazon esegue il dimensionamento automatico a seconda delle modifiche delle dimensioni e del throughput delle tabelle master e di replica?

Attualmente non è possibile ricalibrare le risorse dell'istanza EC2 automaticamente. È possibile selezionare le dimensioni dell'istanza al momento della configurazione della replica in più regioni di DynamoDB.

D: Cosa succede in caso di errore dell'istanza EC2 Amazon che gestisce la replica?

L'istanza EC2 Amazon è eseguita dietro un auto scaling group, che significa che l'applicazione passa automaticamente a un'altra istanza. L'applicazione sottostante usa la libreria client Kinesis (KCL), che controlla la copia. Nel caso di un errore dell'istanza, l'applicazione sa trovare il punto di controllo e riprende da quel punto.

D: Posso usare la mia tabella DynamoDB durante la creazione di una replica di lettura?

Sì, la creazione di una replica è un'operazione online. La tabella rimarrà disponibile per la lettura e la scrittura durante la creazione della replica di lettura. Il processo di bootstrap usa l'operazione di scansione per copiare dalla tabella di origine. Consigliamo di assegnare alla tabella abbastanza unità di capacità in lettura per supportare l'operazione di scansione.

 

D: Quanto tempo richiede la creazione di una replica?

Il tempo impiegato per copiare inizialmente la tabella master nella tabella di replica dipende dalle dimensioni della tabella master e dalla capacità assegnata alla tabella master e alla tabella di replica. Il tempo impiegato per propagare una modifica a livello di una voce dalla tabella master alla tabella di replica dipende dalla capacità assegnata alle tabelle master e di replica e dalle dimensioni dell'istanza EC2 Amazon che esegue l'applicazione di replica.

D: Se modifico la capacità assegnata alla tabella master, questo aggiorna anche la capacità assegnata alla tabella di replica?

Una volta che la replica è stata creata, nessuna modifica alla capacità assegnata alla tabella master può essere ripercossa sulla capacità assegnata alla tabella di replica.

 

D: Le tabelle di replica hanno gli stessi indici della tabella master?

Se si sceglie di creare la tabella di replica dall'applicazione di replica, gli indici secondari sulla tabella master NON vengono creati automaticamente nella tabella di replica. L'applicazione di replica non propaga le modifiche effettuate sugli indici secondari dalla tabella master alle tabelle di replica. Sarà necessario aggiungere/aggiornare/eliminare gli indici in ciascuna delle tabelle di replica tramite la Console di gestione AWS come per le normali tabelle DynamoDB.

 

D: La replica ha la stessa capacità di throughput assegnata della tabella master?

Quando crei una tabella di replica, ti consigliamo di assegnare almeno la stessa capacità in scrittura della tabella master per assicurarti che abbia capacità sufficiente per gestire tutte le scritture in arrivo. Puoi impostare la capacità in lettura della tabella di replica a qualunque livello che sia appropriato per la tua applicazione.

 

D: Qual è il modello di consistenza per le tabelle replicate?

Le repliche vengono aggiornate in modo asincrono. DynamoDB riconosce un'operazione di scrittura come riuscita quando è stata accettata dalla tabella master. La scrittura verrà allora propagata a ogni replica. Questo significa che ci sarà un leggero ritardo prima che la scrittura venga propagata a tutte le tabelle di replica.

D: Esistono dei parametri CloudWatch per la replica su più Regioni?

I parametri CloudWatch sono disponibili per ogni configurazione di replica. Per vedere i parametri, selezionare il gruppo di replica e andare alla scheda Monitoring. Sono disponibili i parametri sul throughput e il numero di registrazioni elaborate e si può controllare se ci sono discrepanze fra il throughput delle tabelle master e quello delle tabelle di replica.

D: Si può avere una replica nella stessa Regione della tabella master?

Sì, entrambe le tabelle possono coesistere nella stessa Regione, purché la tabella di replica e la tabella master abbiano nomi diversi.

D: Posso aggiungere o eliminare una replica dopo aver creato un gruppo di replica?

Sì, si può aggiungere o eliminare una replica da un gruppo di replica in qualunque momento.

D: Posso eliminare un gruppo di replica dopo che è stato creato?

Sì, eliminare un gruppo di replica elimina l'istanza EC2 per il gruppo. Tuttavia si dovrà eliminare la tabella di metadati DynamoDB.

D: Cos'è la funzione Trigger di DynamoDB?

La funzione Trigger di DynamoDB è una caratteristica che permette di effettuare azioni personalizzate basate su aggiornamenti a livello della voce su una tabella DynamoDB. L'azione personalizzata può essere specificata nel codice.

D: Cosa è possibile fare con la funzione Trigger di DynamoDB?

Esistono diversi scenari di applicazione in cui la funzione Trigger di DynamoDB può essere utile. Alcuni casi d'uso includono l'invio di notifiche, aggiornamenti a una tabella aggregata e la connessione di tabelle DynamoDB ad altre fonti di dati.

D: Come funzionano i trigger di DynamoDB?

La logica personalizzata per la funzione Trigger di DynamoDB è memorizzata in una funzione AWS Lambda come codice. Per creare un trigger per una tabella si può associare una funzione AWS Lambda al flusso (tramite DynamoDB Streams) su una tabella DynamoDB. Quando la tabella è aggiornata, gli aggiornamenti vengono pubblicati sul flusso di DynamoDB. A sua volta, AWS Lambda legge gli aggiornamenti dal flusso associato ed esegue il codice nella funzione.

D: Quanto costa utilizzare la funzione Trigger di DynamoDB?

Con la funzione Trigger di DynamoDB si paga solo il numero di richieste per la funzione AWS Lambda e il tempo che essa impiega ad eseguirle. Ulteriori informazioni sui prezzi per AWS Lambda sono disponibili su questa pagina. Non vengono applicati addebiti per le letture effettuate dalla funzione AWS Lambda nel flusso (tramite DynamoDB Streams) associato alla tabella.

D: C'è un limite al numero di trigger in una tabella?

Non c'è limite al numero di trigger in una tabella.

D: Quali sono i linguaggi supportati la funzione Trigger di DynamoDB?

Attualmente, la funzione Trigger di DynamoDB supporta Javascript, Java e Python per le funzioni trigger.

D: Esiste un supporto API per creare, modificare o eliminare i trigger di DynamoDB?

No, al momento non ci sono API native per creare, modificare o eliminare i trigger di DynamoDB. Si deve usare la console di AWS Lambda per creare una funzione AWS Lambda e associarla al flusso in DynamoDB Streams. Per ulteriori informazioni, consultare la pagina di domande frequenti AWS Lambda.

D: Come si crea un trigger di DynamoDB?

Si può creare un trigger creando una funzione AWS Lambda e associando l'origine evento per la funzione a un flusso in DynamoDB Streams. Per ulteriori informazioni, consultare la pagina di domande frequenti AWS Lambda.

D: Come si elimina un trigger di DynamoDB?

Si può eliminare un trigger eliminando la funzione AWS Lambda associata. Si può eliminare una funzione AWS Lambda dalla console di AWS Lambda o tramite una chiamata API AWS Lambda. Per ulteriori informazioni, consultare la pagina di domande frequenti su AWS Lambda e la pagina della documentazione.

D: Quando si ha una funzione AWS Lambda esistente, come si crea un trigger di DynamoDB usando questa funzione?

Si può modificare l'origine evento per la funzione AWS Lambda per puntare a un flusso in DynamoDB Streams. Lo si può fare dalla console di DynamoDB. Nella tabella nella quale è attivato il flusso, selezionare il flusso, premere il pulsante Associate Lambda Function e selezionare la funzione che si vuole utilizzare per il trigger di DynamoDB dall'elenco delle funzioni Lambda.

D: In quali Regioni è disponibile la funzione Trigger di DynamoDB?

I trigger di DynamoDB sono disponibili in tutte le Regioni in cui sono disponibili AWS Lambda e DynamoDB.

D: Cos'è la funzione Flusso di DynamoDB?

La funzione Flusso di DynamoDB fornisce una sequenza cronologica delle modifiche a livello delle voci effettuate su dati in una tabella nelle ultime 24 ore. Si può accedere a un flusso con una semplice chiamata API e utilizzarlo per tenere aggiornati gli altri archivi dati con le ultime modifiche a DynamoDB o eseguire operazioni/chiamata sulla base delle modifiche effettuate sulla tabella.

D: Quali sono i vantaggi di DynamoDB Streams?

Tramite l'API di DynamoDB Streams, gli sviluppatori acquisiscono gli aggiornamenti e ricevono i dati a livello di voce prima e dopo la loro modifica. In questo modo è possibile creare estensioni per le applicazioni che impiegano DynamoDB. Ad esempio, uno sviluppatore che desidera creare un gioco multiplayer che impiega DynamoDB può sfruttare le API di DynamoDB Streams per creare una topologia multi-master, mantenendo sincronizzati i master tramite DynamoDB Streams con ogni master e replicando gli aggiornamenti sui master remoti. Come altro esempi, gli sviluppatori possono usare le API della funzione Flusso di DynamoDB per creare applicazioni mobili che inviano notifiche automatiche ai dispositivi mobili di tutti gli amici di un gruppo non appena un utente carica un nuovo selfie. Gli sviluppatori possono anche utilizzare della funzione Flusso di DynamoDB per tenere gli strumenti di data warehousing, come Amazon Redshift, sincronizzati con tutte le modifiche della tabella DynamoDB per abilitare le analisi in tempo reale. Inoltre DynamoDB si integra con Elasticsearch utilizzando il plug-in Logstash di Amazon DynamoDB, consentendo agli sviluppatori di aggiungere una ricerca a testo libero per i contenuti di DynamoDB.

Si possono trovare ulteriori informazioni sulla funzione Flusso di DynamoDB nella documentazione.

D: Per quanto tempo sono disponibili le modifiche fatte alla mia tabella DynamoDB tramite la funzione Flusso di DynamoDB?

DynamoDB Streams conserva i record di tutte le modiche fatte a una tabella nelle ultime 24 ore. Dopo questo periodo, vengono eliminate.

D: Come si abilita la funzione Flusso di DynamoDB?

La funzione Flusso di DynamoDB va attivata per ogni tabella. Per abilitare la funzione DynamoDB Streams per una tabella DynamoDB esistente, selezionare la tabella nella Console di gestione AWS, selezionare la scheda Overview, fare clic sul pulsante Manage Stream, selezionare un tipo di visualizzazione e fare clic su Enable.

Per ulteriori informazioni, consultare la documentazione.

D: Come posso verificare se la funzione Flusso di DynamoDB è stata attivata?

Dopo aver attivato la funzione Flusso di DynamoDB, si può vedere il flusso nella Console di gestione AWS. Selezionare la tabella, quindi selezionare la scheda Overview. Sotto Stream details, verificare che il valore Stream enabled sia impostato su Yes.

D: Come si accede alla funzione Flusso di DynamoDB?

Si può accedere a un flusso disponibile tramite DynamoDB Streams con una semplice chiamata API utilizzando l'SDK di DynamoDB o la libreria client Kinesis (KCL). KCL ti aiuta a utilizzare ed elaborare i dati di un flusso e anche a gestire attività quali il bilanciamento del carico su lettori multipli, rispondendo a errori di istanza e controllando i record elaborati.

Per ulteriori informazioni sull'accesso alla funzione Flusso di DynamoDB, consultare la documentazione.

D: DynamoDB Streams visualizza tutti gli aggiornamenti fatti alla mia tabella DynamoDB nell'ordine?

Le modifiche fatte a ogni voce individuale appaiono in ordine cronologico. Le modifiche fatte a voci diverse possono apparire in DynamoDB Streams in un ordine diverso da quello nel quale sono state ricevute.

Per esempio, immaginiamo una tabella DynamoDB che tiene traccia dei punteggi massimi per un gioco e nella quale ogni voce rappresenta un giocatore individuale. Se si effettuano gli aggiornamenti seguenti in questo ordine:

  • Aggiornamento 1: Modificare il punteggio massimo del Giocatore 1 a 100 punti
  • Aggiornamento 2: Modificare il punteggio massimo del Giocatore 2 a 50 punti
  • Aggiornamento 3: Modificare il punteggio massimo del Giocatore 1 a 125 punti

Gli aggiornamenti 1 e 3 hanno effettuato modifiche sulla stessa voce (Giocatore 1), perciò DynamoDB Streams visualizzerà l'aggiornamento 3 dopo l'aggiornamento 1. Questo consente di recuperare il punteggio massimo più aggiornato per ogni giocatore. Il flusso può non mostrare che tutti e tre gli aggiornamenti sono stati effettuati nello stesso ordine (per es: che l'aggiornamento 2 è avvenuto dopo l'aggiornamento 1 e prima dell'aggiornamento 3) ma gli aggiornamenti del record di ogni giocatore individuale saranno in ordine cronologico.

D: Devo gestire la capacità di un flusso in DynamoDB Streams?

No, la capacità di un flusso è gestita automaticamente in DynamoDB Streams. Se il traffico sulla tabella DynamoDB cresce in modo significativo, DynamoDB aggiusta automaticamente la capacità del flusso per permettergli di continuare ad accettare tutti gli aggiornamenti.

D: A che ritmo si può leggere da DynamoDB Streams?

In DynamoDB Streams si possono leggere gli aggiornamenti dal flusso a un ritmo due volte più veloce della capacità in lettura assegnata della tabella DynamoDB. Per esempio, se si è assegnata abbastanza capacità per aggiornare 1.000 voci al secondo nella tabella DynamoDB, si possono leggere fino a 2.000 aggiornamenti al secondo dal flusso.

D: Se elimino la mia tabella DynamoDB, viene eliminato anche il flusso in DynamoDB Streams?

No, non immediatamente. Il flusso rimarrà in DynamoDB Streams per 24 ore per permetterti di leggere gli ultimi aggiornamenti fatti alla tua tabella. Dopo 24 ore, il flusso verrà eliminato automaticamente da DynamoDB Streams.

D: Cosa succede se disattivo la funzione Flusso di DynamoDB nella mia tabella?

Se si disattiva la funzione Flusso di DynamoDB, il flusso rimarrà per 24 ore ma non sarà aggiornato con nessuna modifica supplementare effettuata nella tabella DynamoDB.

D: Cosa succede se disattivo la funzione Flusso di DynamoDB e poi la riattivo?

Se si disattiva la funzione Flusso di DynamoDB, il flusso rimarrà per 24 ore ma non sarà aggiornato con alcuna modifica supplementare effettuata nella tabella DynamoDB. Se si riattiva la funzione Flusso di DynamoDB, si crea un nuovo flusso che contiene tutte le modifiche effettuate nella tabella DynamoDB a partire dal momento in cui il nuovo flusso è stato creato.

D: Ci possono essere duplicati o lacune nella funzione Flusso di DynamoDB?

No, la funzione Flusso di DynamoDB è stata concepita in modo che ogni aggiornamento effettuato sulla tabella sia rappresentato in modo esatto quando si trova nel flusso.

D: Quali informazioni sono incluse nella funzione Flusso di DynamoDB?

Un flusso di DynamoDB contiene informazioni sul valore precedente e il valore modificato della voce. Il flusso include anche il tipo di modifica (AGGIUNTA, ELIMINAZIONE e MODIFICA) e la chiave principale della voce che è stata modificata.

D: Come si sceglie quali informazioni includere nella funzione Flusso di DynamoDB?

Per le nuove tabelle, utilizzare la chiamata API CreateTable e specificare il parametro "ViewType" per scegliere le informazioni da includere nel flusso.
Per una tabella esistente, utilizzare la chiamata API UpdateTable e specificare il parametro "ViewType" per scegliere le informazioni da includere nel flusso.

Il parametro ViewType accetta i valori seguenti:

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

I valori hanno il significato seguente: KEYS_ONLY: solo i nomi della chiave delle voci che sono state modificate sono inclusi nel flusso.

  • NEW_IMAGE: il nome della chiave e la voce dopo l'aggiornamento (nuova voce) sono inclusi nel flusso.
  • OLD_IMAGE: il nome della chiave e la voce prima dell'aggiornamento (vecchia voce) sono inclusi nel flusso.
  • NEW_AND_OLD_IMAGES: il nome della chiave, la voce prima dell'aggiornamento (vecchia voce) e la voce dopo l'aggiornamento (nuova voce) sono inclusi nel flusso.

D: Posso utilizzare la libreria client Kinesis per accedere alla funzione Flusso di DynamoDB?

Sì, gli sviluppatori che conoscono le API di Kinesis possono usare DynamoDB Streams senza difficoltà. Si può utilizzare DynamoDB Streams Adapter, che implementa l'interfaccia di Amazon Kinesis, per consentire a un'applicazione di utilizzare le librerie client Amazon Kinesis (KCL) per accedere alla funzione Flusso di DynamoDB. Per ulteriori informazioni su come usare KCL per accedere a DynamoDB, consultare la documentazione.

D: Posso modificare il tipo di informazioni incluse nella funzione Flusso di DynamoDB?

Se si vuole modificare il tipo di informazioni memorizzate in un flusso dopo che è stato creato, bisogna disattivare il flusso e crearne uno nuovo utilizzando l'API UpdateTable.

D: Quando si modifica una tabella DynamoDB, quanto tempo ci vuole perché la modifica appaia in un flusso di DynamoDB?

Le modifiche di solito si ripercuotono nel flusso di DynamoDB in meno di un secondo.

D: Se elimino una voce, la modifica sarà inclusa nella funzione Flusso di DynamoDB?

Sì, ogni aggiornamento in un flusso di DynamoDB include un parametro che specifica se l'aggiornamento è un'eliminazione, l'aggiunta di una nuova voce o la modifica di una voce esistente. Per ulteriori informazioni sul tipo di aggiornamento, consultare la documentazione.

D: Quando si attiva la funzione Flusso di DynamoDB per una tabella, quando si può cominciare a leggere dal flusso?

Si può usare l'API DescribeStream per ottenere lo stato attuale del flusso. Quando lo stato diventa ENABLED, tutti gli aggiornamenti effettuati nella tabella sono rappresentati nel flusso.

Si può cominciare a leggere dal flusso non appena si comincia a crearlo, ma il flusso può non contenere tutti gli aggiornamenti effettuati nella tabella fino a che lo stato non diventa ENABLED.

D: Cos'è il plug-in Logstash di Amazon DynamoDB per Elasticsearch?

Elasticsearch è un motore di ricerca e di analisi open source di successo concepito per semplificare la ricerca e l'analisi di big data in tempo reale. Logstash è una pipeline di dati open source funzionante con Elasticsearch per rendere più facile l'elaborazione di log e altri dati evento. Il plug-in Logstash di Amazon DynamoDB facilita l'integrazione delle tabelle DynamoDB con i cluster Elasticsearch.

D: Quanto costa il plug-in Logstash di Amazon DynamoDB?

Il plug-in Logstash di Amazon DynamoDB può essere scaricato e utilizzato gratuitamente.

D: Come si scarica e si installa il plug-in Logstash di Amazon DynamoDB?

Il plug-in Logstash di Amazon DynamoDB è disponibile su GitHub Consultare la pagina di documentazione per ulteriori informazioni sull'installazione e l'esecuzione del plug-in.


D: Cos'è DynamoDB Storage Backend for Titan?

DynamoDB Storage Backend for Titan è un plug-in che consente ai clienti di utilizzare DynamoDB come layer di storage per un database a grafo Titan. Si tratta di una soluzione lato client che implementa un'adiacenza priva di indice per attraversamenti di grafi veloci su DynamoDB.

D: Cos'è un database a grafo?

Un database a grafo è uno store di vertici e archi orientati che collegano i vertici. Sia i vertici sia gli archi possiedono proprietà memorizzate come copie di valori chiave.

Un database a grafo utilizza liste di adiacenza per memorizzare gli archi per permettere un attraversamento semplice. Un grafo in un database a grafo può essere attraversato su tipi di archi specifici o sull'intero grafo. I database a grafo possono rappresentare le relazioni fra le entità utilizzando azioni, proprietà, origine, e così via.

D: Quali applicazioni sono adatte ai database a grafi?

Un database a grafo è la scelta migliore nei casi in cui le connessioni o relazioni fra entità sono al centro dei dati che si vogliono modellizzare. Perciò i database di grafi sono utili per modellizzare ed eseguire query su social network, relazioni d'affari, dipendenze, movimenti di spedizione e altro.

D: Come si comincia a utilizzare il back-end di storage DynamoDB per Titan?

Il modo più semplice per cominciare è di lanciare un'istanza EC2 eseguendo Gremlin Server con il back-end di storage DynamoDB per Titan, utilizzando i modelli di CloudFormation a cui si fa riferimento in questa pagina di documentazione. Si può anche clonare il progetto dal repository GitHub e cominciare a seguire i tutorial Marvel e Graph-Of-The-Gods sul proprio computer seguendo le istruzioni nella pagina di documentazione. Quando si è pronti a espandere il test o ad andare in produzione, si può cambiare il back-end per usare di nuovo il servizio DynamoDB. Consultare la documentazione AWS per ulteriori informazioni.

D: Qual è la differenza fra il back-end di storage DynamoDB per Titan e gli altri back-end di storage di Titan?

DynamoDB è un servizio gestito, perciò utilizzarlo come back-end di storage per Titan consente di far funzionare carichi di lavoro di grafi senza dover gestire il proprio cluster per lo storage di grafi.

D: Il back-end di storage DynamoDB per Titan un servizio completamente gestito?

No. Il back-end di storage DynamoDB per Titan gestisce il layer di storage per un carico di lavoro Titan. Tuttavia il plug-in non effettua il provisioning e la gestione del lato cliente. Per il provisioning semplice di Titan abbiamo sviluppato un modello CloudFormation che installa il back-end di storage DynamoDB per Titan con Gremlin Server; consultare le istruzioni su questa pagina.

D: Quanto costa utilizzare il back-end di storage DynamoDB per Titan?

Al cliente vengono addebitati i normali costi di throughput e storage di DynamoDB. Non ci sono costi supplementari per l'utilizzo di DynamoDB come back-end di storage per un carico di lavoro di grafi Titan.

D: Il back-end DynamoDB è pienamente compatibile con il gruppo di caratteristiche di Titan su altri back-end?

Si può consultare una tabella che confronta i gruppi di caratteristiche di diversi back-end di storage Titan nella documentazione.

D: Quali versioni di Titan supporta il plug-in?

Abbiamo rilasciato i plug-in di back-end di storage DynamoDB per le versioni di Titan 0.5.4 e 1.0.0.

D: Oggi utilizzo Titan con un back-end diverso. Posso migrare a DynamoDB?

Certamente. Il back-end di storage DynamoDB per Titan implementa l'interfaccia Titan KCV Store per consentirti di passare da un back-end di storage diverso a DynamoDB con modifiche minime per la tua applicazione. Consultare il confronto completo dei back-end di storage per Titan nella documentazione.

D: Oggi utilizzo Titan con un back-end diverso. Come si esegue la migrazione a DynamoDB?

Si può usare un caricamento in blocco per copiare il grafo da un back-end di storage al back-end di storage DynamoDB per Titan.

D: Come posso collegare un'istanza Titan da DynamoDB tramite il plug-in?

Se si crea un grafo e un'istanza di Gremlin Server con il back-end di storage DynamoDB per Titan installato, tutto quello che si deve fare per collegarsi a DynamoDB è fornire un gruppo di entità/credenziali alla catena predefinita del provider di credenziali AWS Questo può essere fatto con profilo di istanza EC2, variabili di ambiente o con il file di credenziali nella home directory. Infine, si deve scegliere un endpoint DynamoDB a cui collegarsi.

D: Quanto sono sicuri i miei dati quando utilizzo il back-end di storage DynamoDB per Titan?

Quando si utilizza il back-end di storage DynamoDB per Titan, i tuoi dati sono altamente protetti da DynamoDB, che funziona su data center sicuri e di elevata disponibilità. Il servizio replica i dati su tre strutture in una Regione AWS per offrire tolleranza ai guasti in caso di errore del server o di interruzione di corrente nella zona di disponibilità.

D: Quanto è sicuro il back-end di storage DynamoDB per Titan?

Il back-end di storage DynamoDB per Titan memorizza dati di grafi in più tabelle DynamoDB, perciò ha lo stesso livello elevato di sicurezza disponibile su tutti i carichi di lavoro di DynamoDB. Il controllo d'accesso specifico, i ruoli IAM e i gruppi di entità/credenziali di AWS controllano l'accesso alle tabelle DynamoDB e alle voci in esse contenute.

D: Come effettua il dimensionamento il back-end di storage DynamoDB per Titan?

Il back-end di storage DynamoDB per Titan si dimensiona come qualunque altro carico di lavoro di DynamoDB. Si può aumentare o diminuire il throughput necessario in qualunque momento.

D: Quanti vertici e archi può contenere un grafo?

I limiti sono quelli di Titan a (2^60) per il numero massimo di archi e la metà di questo numero di vertici in un grafo, purché si utilizzi il modello a voci multiple per edgestore. Se si usa il modello a voce singola, il numero di archi che si possono memorizzare in una chiave fuori vertice particolare è limitato alle dimensioni massime di una voce di DynamoDB, attualmente 400 KB.

D: Quali possono essere le dimensioni massime delle proprietà dei vertice e degli archi?

La somma di tutte le proprietà degli archi nel modello a voci multiple non può superare 400 KB, le dimensioni massime di una voce. Nel modello a voci multiple, ogni proprietà di vertice può essere di 400 KB. Nel modello a voce singola, le dimensioni totali della voce (incluse le proprietà dei vertici, gli archi e le proprietà degli archi) non può superare 400 KB.

D: Quanti modelli di dati ci sono? Quali sono le differenze?

Ci sono due modelli di storage diversi per il back-end di storage DynamoDB per Titan: il modello a voce singola e il modello a voci multiple. Nel modello di storage a voce singola, i vertici, le proprietà dei vertici e gli archi sono memorizzati in una sola voce. Nel modello a voci multiple, i vertici, le proprietà dei vertici e gli archi sono memorizzati in voci diverse. In entrambi i casi le proprietà degli archi sono memorizzate nelle stesse voci alle quali corrispondono gli archi.

D: Quale modello di dati devo usare?

In generale, consigliamo di usare il modello di dati a voci multiple per le tabelle edgestore e graphindex. Altrimenti si può limitare il numero delle proprietà degli archi/vertici che si possono memorizzare per una chiave fuori vertice oppure limitare il numero delle entità che possono essere indicizzate in una coppia nome-valore di proprietà particolare in un indice di grafi. In generale, si può usare il modello di dati a voce singola per gli altri 4 store KCV nelle versioni di Titan 0.5.4 e 1.0.0 perché le voci memorizzate sono di solito inferiori a 400 KB. Puoi trovare su questa pagina l'elenco completo delle tabelle create dal plug-in di Titan su DynamoDB.

D: Devo creare uno schema per i database a grafo di Titan?

Titan supporta la creazione automatica di tipi, quindi le nuove proprietà di archi/vertici e le etichette vengono registrate in tempo reale (consultare questa pagina per ulteriori dettagli) con il primo utilizzo. La struttura Gremlin (etichette Edge=MULTI, proprietà Vertex=SINGLE) viene utilizzata in modo predefinito.

D: Posso cambiare lo schema di un database a grafo Titan?

Sì, tuttavia non è possibile modificare lo schema delle proprietà e delle etichette di vertice/arco esistenti. Per ulteriori dettagli consultare questa pagina.

D: Come tratta i supernodi il back-end di storage DynamoDB per Titan?

DynamoDB tratta i supernodi tramite la partizione delle etichette dei vertici. Se si definisce un'etichetta di vertice come partizionata nel sistema di gestione al momento della creazione, a chiavi di partizione differenti dello spazio chiave di partizione-ordinamento nella tabella edgestore possono essere collegati sottoinsiemi differenti di proprietà dei lati e dei vertici provenienti da un vertice. Il risultato è che le partizioni delle etichette dei vertici virtuali vengono memorizzate in partizioni DynamoDB fisiche diverse, purché l'edgestore possieda più di una partizione fisica. Per calcolare il numero delle partizioni fisiche che supportano la tabella edgestore, consultare la documentazione.

D: Il back-end di storage DynamoDB per Titan supporta le operazioni batch di grafi?

Sì, il back-end di storage DynamoDB per Titan supporta i batch di grafi con l'implementazione Blueprints BatchGraph e tramite le opzioni di configurazione di caricamento in blocco di Titan.

D: Il back-end di storage DynamoDB per Titan supporta le transazioni?

Il back-end di storage DynamoDB per Titan supporta il blocco ottimistico. Questo significa che il back-end di storage DynamoDB per Titan può condizionare le scritture di coppie chiave-colonna individuali (nel modello a voci multiple) o di chiavi individuali (nel modello a voce singola) sul valore esistente di detta coppia chiave-colonna o chiave.

D: Posso avere un'istanza Titan in una Regione e accedere a DynamoDB in un'altra?

L'accesso a un endpoint di DynamoDB in una Regione diversa da quella dell'istanza Titan EC2 è possibile ma è sconsigliato. Quando esegue Gremlin Server da EC2, ti consigliamo di connetterti on l'endpoint di DynamoDB nella Regione dell'istanza EC2, per ridurre l'impatto di latenza delle richieste su più Regioni. Inoltre consigliamo di eseguire l'istanza EC2 in un VPC per migliorare le prestazioni della rete. Il modello CloudFormation effettua l'intera configurazione per te.

D: È possibile utilizzare questo plug-in con altre caratteristiche di DynamoDB come i flussi di aggiornamento e la replica su più regioni?

Si può utilizzare la replica su più Regioni con la funzione Flusso di DynamoDB per creare repliche di sola lettura delle tabelle di grafi in altre Regioni.


D: Amazon DynamoDB presenta i parametri CloudWatch?

Sì, Amazon DynamoDB presenta numerosi parametri a livello di tabella su CloudWatch. Si possono prendere decisioni operative sulle tabelle Amazon DynamoDB e intraprendere azioni specifiche, come impostare allarmi sulla base di questi parametri. Consultare la sezione Monitoring DynamoDB with CloudWatch della documentazione per ottenere l'elenco completo dei parametri presentati.

D: Dove posso trovare i parametri CloudWatch per una tabella Amazon DynamoDB?

Sulla console Amazon DynamoDB selezionare la tabella per la quale si vogliono vedere i parametri CloudWatch e poi selezionare la scheda "Metrics".

D: Con quale frequenza sono presentate i parametri?

La maggior parte di parametri CloudWatch per Amazon DynamoDB viene presentata a intervalli di 1 minuto e il resto dei parametri a intervalli di 5 minuti. Per ulteriori informazioni, consultare la sezione Monitoring DynamoDB with CloudWatch della documentazione.


D: Che cos'è un tag?

Un tag è un'etichetta che puoi assegnare a una risorsa di AWS. Ogni tag consiste di una chiave e di un valore, entrambi personalizzabili. AWS usa i tag per semplificare l'organizzazione dei costi delle risorse nel relativo report. Per ulteriori informazioni sull'applicazione di tag, consulta la AWS Billing and Cost Management User Guide.

D: A quali risorse DynamoDB è possibile applicare tag?

I tag possono essere applicati alle tabelle DynamoDB. Gli indici secondari locali e gli indici secondari globali associati con tali tabelle vengono automaticamente etichettati con gli stessi tag. I costi di indici secondari locali e indici secondari globali verranno visualizzati insieme ai tag utilizzati per le tabelle DynamoDB corrispondenti.

D: Qual è il vantaggio di utilizzare i tag per DynamoDB?

I tag per DynamoDB semplificano l'allocazione dei costi. I tag consentono di etichettare le risorse di DynamoDB per monitorarne i costi in base a progetti o altri criteri e tenere sotto controllo le spese della struttura.

D: In che modo è possibile usare i tag per l'allocazione dei costi?

È possibile utilizzare i tag per suddividere in categorie e tenere traccia dei costi di AWS. Lo strumento di esplorazione dei costi AWS Cost Explorer e i report di fatturazione permettono di analizzare le singole voci di costo mediante i tag. In genere, i clienti suddividono le risorse utilizzando tag di tipo aziendale, ad esempio in relazione a centri di costo o unità aziendali, clienti o progetti, in modo da associare i costi di AWS a parametri di allocazione dei costi tradizionali. Un report di allocazione dei costi può tuttavia includere qualsiasi tipo di tag. Questa possibilità permette di raggruppare i costi secondo parametri tecnici o di sicurezza, ad esempio in relazione ad applicazioni, ambienti o programmi di conformità specifici.

D: In che modo è possibile consultare i costi allocati alle risorse AWS con un determinato tag?

I costi allocati alle risorse AWS provviste di tag possono essere consultati tramite Cost Explorer o tramite il report di allocazione dei costi.

Cost Explorer è uno strumento gratuito di AWS che permette di visualizzare i costi dei 13 mesi precedenti e di effettuare previsioni sulle spese dei tre mesi successivi. Per consultare i costi correlati a uno specifico tag, è sufficiente applicare il filtro "Tag" e selezionare la coppia chiave-valore desiderata (seleziona "No tag" per non specificare alcun tag).

Il report di allocazione dei costi include tutti i costi di AWS per ciascun periodo di fatturazione. Il report include tutte le risorse provviste o non provviste di tag, perciò potrai organizzare i costi in base alle risorse con la massima semplicità. Se ad esempio applichi alle risorse un tag che corrisponde al nome di un'applicazione, puoi verificare i costi totali dell'applicazione che sfrutta tali risorse. Per ulteriori informazioni sull'allocazione dei costi, consulta la AWS Billing and Cost Management User Guide.

D: È possibile applicare tag all'utilizzo di DynamoDB Streams?

No, l'utilizzo di DynamoDB Streams al momento non supporta l'applicazione di tag.

D: L'utilizzo di prenotazioni di capacità per le tabelle verrà visualizzato nella fattura in base ai tag?

Sì, i costi correlati all'utilizzo di prenotazioni di capacità per le tabelle sarà visualizzato in base ai tag. Le prenotazioni di capacità vengono applicate all'utilizzo di DynamoDB in base all'ordine cronologico su tutti gli account AWS collegati. Quindi, anche se l'utilizzo di DynamoDB su tabelle e indici è simile da un mese all'altro, potrebbero comunque esserci differenze nei report di allocazione dei costi in base al tag, dato che la capacità prenotata sarà distribuita in base alle risorse DynamoDB che ne fanno richiesta prima.

D: I costi per l'utilizzo di dati per le tabelle verrà visualizzato nella fattura in base ai tag?

No, non è possibile applicare tag all'utilizzo di dati in DynamoDB. L'utilizzo dei dati, infatti, viene fatturato a livello di account e non a livello di tabella.

D: È necessario attribuire un valore ai tag?

No, i valore di un tag può rimanere vuoto.

D: I tag fanno distinzione tra maiuscole e minuscole?

Sì, chiavi e valori dei tag fanno distinzione tra maiuscole e minuscole.

D: Quanti tag è possibile aggiungere a una singola tabella DynamoDB?

Una singola tabella DynamoDB può supportare fino a 50 tag. I tag con il prefisso "aws:" non possono essere creati manualmente e non vengono considerate per il conteggio di questo limite.

D: È possibile applicare tag a tabelle DynamoDB con valore retroattivo?

No, i tag organizzano e monitorano i dati a partire dal giorno in cui vengono applicati. Se crei una tabella il giorno 1 gennaio ma non assegni tag fino al giorno 1 febbraio, l'utilizzo delle tabelle per il mese di gennaio non sarà etichettato.

D: Se viene rimosso un tag da una tabella DynamoDB prima della fine del mese, sarà comunque incluso nella fattura?

Sì, se crei un report per monitorare le spese in un determinato periodo di tempo, il report sui costi mostrerà i costi delle risorse provviste di tag durante tale periodo.

D: Cosa accade ai tag esistenti quando una tabella DynamoDB viene eliminata?

Quando una tabella DynamoDB viene eliminata, i relativi tag sono automaticamente rimossi.

D: Cosa accade se viene aggiunto un tag con la stessa chiave di un tag già esistente?

Una tabella DynamoDB può avere solo un tag con la stessa chiave. Se aggiungi un tag con la stessa chiave di un tag già esistente, il tag esistente viene aggiornato con il nuovo valore.


D: Cos'è la funzione Time-to-Live (TTL) di DynamoDB?

Il Time-to-Live (TTL) di DynamoDB è un meccanismo che permette di impostare un time stamp per eliminare gli elementi scaduti dalle tabelle. Una volta superato il time stamp, l'elemento corrispondente viene contrassegnato come scaduto e di conseguenza eliminato dalla tabella. Tramite questa funzionalità, è possibile tenere traccia dei dati scaduti e procedere manualmente ad eliminarli. La funzione TTL può esser utile per ridurre l'utilizzo dello storage e contenere di conseguenza i costi della memorizzazione dei dati non più importanti per l'attività.

D: Perché è utile la funzionalità TTL?

Sono due gli scenari in cui questa funzionalità risulta particolarmente utile:

  • Eliminazione di vecchi dati non più utili, ad esempio log di eventi, storico dell'utilizzo, dati di sessione e così via. Questo tipo di informazioni tende ad accumularsi, mentre i dati più vecchi perdono di rilevanza nel corso del tempo. In questi casi, conviene cancellare i record ormai inutili dal sistema per risparmiare sullo storage.
  • In alcuni casi potrebbe essere necessario conservare i dati in DynamoDB per una quantità specifica di tempo, per conformità alle policy di retention e di gestione. Una volta oltrepassati i termini di policy, però, può essere utile eliminare questi dati. TTL, tuttavia, funziona in modo da garantire il throughput necessario per il funzionamento delle attività aziendali. DynamoDB procederà ad eliminare gli elementi scaduti entro due giorni. Il tempo necessario per completare l'eliminazione potrebbe essere superiore in base all'effettivo volume di dati.

D: Come funziona la caratteristica TTL di DynamoDB?

Per abilitare la funzione TTL per una tabella, verifica che sia presente un attributo che possa memorizzare il time stamp relativo alla scadenza degli elementi nella tabella. Questo time stamp deve essere nel formato epoch. In tal modo vengono eliminate le differenze di fuso orario tra client e server.

DynamoDB esegue una scansione in background per monitorare tutti gli elementi. Se il time stamp è scaduto, il processo contrassegnerà l'elemento come scaduto e lo metterà in coda per l'eliminazione.

Nota: la funzione TTL necessita che la tabella DynamoDB disponga di un attributo numerico popolato con un time stamp in formato epoch, in cui specificare il criterio di scadenza per i dati. È importante fare attenzione al momento dell'impostazione del valore dell'attributo TTL, perché configurare un termine errato potrebbe anticipare l'eliminazione degli elementi.

D: In che modo viene specificata l'impostazione di TTL?

Per specificare un'impostazione di TTL, è necessario innanzitutto abilitare la relativa opzione, specificando un attributo da usare come valore di TTL. A mano a mano che vengono aggiunti elementi alla tabella, è possibile specificare un attributo TTL se desideri che DynamoDB lo elimini automaticamente alla scadenza. Questo valore corrisponderà alla data di scadenza, specificata in formato epoch. Qualsiasi altra operazione sarà eseguita automaticamente da DynamoDB. Il TTL può essere specificato dalla console, nella scheda generale della tabella. In alternativa, gli sviluppatori possono richiamare l'API TTL e configurarne il valore nella tabella. Consulta la documentazione e la API Guide.

D: È possibile impostare un TTL su tabelle esistenti?

Sì. Se la tabella è già stata creata e dispone di un attributo che può essere utilizzato come TTL per gli elementi, devi solo abilitare il TTL per la tabella e decidere il valore dell'attributo. Se la tabella non dispone di un attributo da utilizzare come TTL, sarà necessario crearlo e aggiornare gli elementi con il nuovo valore di TTL.

D: È possibile eliminare un'intera tabella impostando il TTL su tutti gli elementi?

No. Anche se è necessario definire un parametro di TTL a livello di tabella, la granularità dell'eliminazione è sempre a livello di elemento. Questo significa che, in una tabella, ogni elemento con una scadenza dovrà avere un valore per l'attributo TTL. Non è disponibile alcuna opzione per eliminare automaticamente l'intera tabella.

D: È possibile impostare un TTL solo per un sottoinsieme di elementi in una tabella?

Sì. Il TTL ha effetto solo sugli elementi per cui è stato definito un valore nel relativo attributo. Gli altri elementi nella tabella non sono interessati.

D: In quale formato è necessario specificare il TTL?

Il valore di TTL deve essere in formato epoch, ovvero secondo il numero di secondi a partire dal giorno 1 gennaio 1970 (UTC). Se il valore specificato nell'attributo TTL per un elemento non è nel formato corretto, il valore viene ignorato e l'elemento non viene eliminato. 

D: In che modo è possibile leggere il valore TTL per gli elementi nella tabella?

Il valore del TTL è analogo a quello di qualsiasi altro valore relativo a un elemento. Può essere letto esattamente come ogni altro attributo. Per semplificare avere una conferma visiva dei valori di TTL, la console di DynamoDB permette di passare il cursore del mouse su un attributo di TTL per consultarne il valore in formato leggibile e secondo il fuso orario UTC.

D: È possibile creare un indice basato sui valori di TTL assegnati agli elementi in una tabella?

Sì. Il TTL si comporta come qualsiasi altro attributo. È possibile creare indici come per qualsiasi altro attributo.

D: È possibile che l'attributo TTL venga proiettato in un indice?

Sì. Un attributo TTL può essere proiettato in un indice come qualsiasi altro attributo.

D: È possibile modificare il valore dell'attributo TTL di un elemento dopo che è stato impostato?

Sì. È possibile modificare il valore dell'attributo TTL come qualsiasi altro attributo.

D: È possibile modificare l'attributo TTL per una tabella.

Sì. Se in una tabella il TTL è già stato abilitato e desideri specificare un attributo TTL differente, è necessario disabilitare la funzione di TTL per la tabella, quindi abilitarla nuovamente con un nuovo attributo. Quando la funzione di TTL viene disattivata, l'applicazione in tutte le partizioni può richiedere fino a un'ora, durante la quale non sarà possibile riabilitare il TTL.

D: È possibile usare la Console di gestione AWS per visualizzare e modificare i valori di TTL?

Sì. La Console di gestione AWS permette di visualizzare, impostare e aggiornare il valore di TTL.

D: È possibile impostare un attributo in un documento JSON come attributo di TTL?

No. Al momento l'utilizzo di un attributo in un documento JSON come attributo di TTL non è supportato. Per impostare un TTL, devi aggiungerlo esplicitamente nell'attributo di TTL per ogni singolo elemento.

D: È possibile impostare un TTL per un elemento specifico in un documento JSON?

No. I valori di TTL possono essere impostati solo per documenti interi. L'eliminazione di elementi specifici in un documento JSON non è supportata.

D: Cosa accade se è necessario rimuovere il TTL da un elemento specifico?

Rimuovere un TTL è semplice come rimuovere il valore assegnato all'attributo TTL o rimuovere l'attributo da un elemento.

D: Cosa accade se il valore del time stamp di TTL viene impostato nel passato?

Aggiornare un elemento anticipandone la data del TTL è consentito. Quando il processo in background cerca gli elementi scaduti, troverà l'elemento, lo contrassegnerà e quindi lo eliminerà. Tuttavia, se l'attributo TTL contiene un valore epoch per un time stamp più vecchio di 5 anni, DynamoDB ignorerà il time stamp e non eliminerà l'elemento. Questo avviene per evitare che vengano eliminati accidentalmente elementi con valori estremamente bassi di TTL.

D: Qual è il ritardo tra la scadenza dettata dal TTL di un elemento e la sua eliminazione?

La funzione TTL cerca ed elimina gli elementi scaduti utilizzando il throughput in background disponibile nel sistema. Perciò gli elementi scaduti non saranno eliminati immediatamente dalla tabella. DynamoDB cercherà di eliminare gli elementi scaduti entro due giorni, per garantire la massima disponibilità di throughput dei sistemi in background per le altre operazioni sui dati. L'effettivo ritardo dell'eliminazione di un elemento dopo la sua scadenza dipender dal tipo di carico di lavoro e dalle dimensioni della tabella.

D: Cosa accade cercando un elemento scaduto secondo i termini di TTL tramite query o scansione?

Poiché può esserci uno scarto temporale tra la scadenza di un elemento e la sua effettiva eliminazione in background, se individui elementi scaduti non ancora eliminati, i risultati di ricerca restituiranno anche questi elementi. Se lo scopo della ricerca è individuare elementi scaduti ma non ancora eliminati, è possibile filtrare i risultati secondo il valore di TTL.

D: Cosa accade ai dati nell'indice secondario locale o LSI (Local Secondary Index) se sono scaduti?

I risultati non variano rispetto a qualsiasi altra operazione di eliminazione. L'indice secondario locale viene memorizzato nella stessa partizione dell'elemento stesso. Di conseguenza, un elemento contrassegnato per l'eliminazione viene rimosso anche dall'indice secondario locale.

D: Cosa accade ai dati nell'indice secondario globale o GSI (Global Secondary Index) se sono scaduti?

I risultati non variano rispetto a qualsiasi altra operazione di eliminazione. L'indice secondario globale offre consistenza finale, perciò quando l'elemento originale scaduto viene eliminato, l'aggiornamento del GSI potrebbe non essere immediato.

D: Come funziona il TTL con DynamoDB Streams?

La data di scadenza dei dati derivante dal valore di TTL in una tabella, attivando una rimozione, sarà registrata come un'operazione di eliminazione. Di conseguenza anche Streams registrerà l'operazione di eliminazione. La registrazione includerà un qualificatore aggiuntivo che consente di distinguere tra le eliminazioni manuali e quelle provocate dal valore di TTL. La voce relativa al flusso verrà trascritta nel momento dell'eliminazione invece che al momento stabilito dalla TTL, per riflettere data e ora effettive di cancellazione. Consulta la documentazione e la API Guide.

D: In quali casi è indicato eseguire un'operazione di eliminazione manuale oppure applicare il TTL?

Il TTL è ideale per rimuovere i record scaduti da una tabella. Tuttavia, si tratta di un'operazione che aiuta a rimuovere i dati che non si desidera conservare e non fornisce alcuna garanzia sui tempi esatti dell'eliminazione. Di conseguenza, se i dati di una tabella devono essere eliminati entro un periodo specifico oppure nell'immediato, è più consigliato il comando di eliminazione.

D: È possibile controllare chi può accedere all'impostazione o all'aggiornamento dei valori di TTL?

Sì. L'attributo TTL si comporta esattamente come qualsiasi altro attributo della tabella. Pertanto, è possibile controllarne gli accessi. Sarà possibile modificarlo solo in base alle impostazioni specificate per la tabella.

D: È possibile recuperare i dati eliminati dopo la scadenza del TTL?

No. Non viene eseguito alcun backup dei dati scaduti prima della loro eliminazione. È tuttavia possibile utilizzare DynamoDB Streams per tenere traccia delle modifiche apportate a una tabella e ripristinarne i valori. Il record di eliminazione è disponibile in Streams per 24 ore dopo la cancellazione.

D: In che modo si capisce se è stato impostato un TTL su una tabella?

È possibile consultare lo stato del TTL in qualsiasi momento richiamando l'API DescribeTable o visualizzare i dettagli della tabella nella console di DynamoDB. Consulta la documentazione e la API Guide.

D: In che modo è possibile tenere traccia degli elementi cancellati con la funzionalità TTL?

Se DynamoDB Streams è abilitato, tutte le eliminazioni determinate dal TTL vengono visualizzate nel servizio e saranno contrassegnate in modo da poterle distinguere dalle eliminazioni eseguite manualmente. Gli elementi possono essere letti da flussi e processi secondo necessità. Possono anche scrivere una funzione Lambda che archivi gli elementi separatamente. Consulta la documentazione e la API Guide.

D: L'utilizzo della caratteristica TTL prevede tariffe aggiuntive?

No. Per questa caratteristica non viene addebitata alcuna tariffa.

D: In che modo abilitare il TTL inciderà sul livello di throughput?

Le operazioni di scansione ed eliminazione necessarie per applicare il TTL vengono eseguite a livello di sistema e non contano ai fini della misurazione di throughput o utilizzo.

D: Le operazioni di scansione per il monitoraggio del TTL prevedono tariffe aggiuntive?

No. Le operazioni interne di scansione per il monitoraggio delle scadenze previste dal TTL non determinano alcun costo aggiuntivo. Tali operazioni non contano ai fini della misurazione di throughput o utilizzo.

D: Gli elementi di una tabella valgono ai fini del calcolo delle tariffe anche se sono scaduti, finché non vengono eliminati?

Sì. Quando un elemento supera la data di scadenza, viene aggiunto a una coda di eliminazione. Tuttavia, finché non è stato effettivamente eliminato, è valido come qualsiasi altro elemento ai fini del calcolo dei costi di storage.

D: Una query su un elemento scaduto vale nel conteggio della capacità di lettura?

Sì. Non c'è alcuna differenza tra il comportamento di una query di questo tipo e una che cerca una voce che non esiste nella tabella.


D: Cos'è Amazon DynamoDB Accelerator (DAX)?

Amazon DynamoDB Accelerator (DAX) è un sistema di caching in memoria completamente gestito e ad elevata disponibilità per DynamoDB che consente di approfittare di prestazioni in memoria rapide per applicazioni complesse. DAX ottimizza le prestazioni dei carichi di lavoro di DynamoDB con intenso traffico di lettura in modo che le letture ripetute di dati memorizzati nella cache possano essere utilizzate con una latenza molto bassa, senza bisogno di eseguire di nuovo la query da DynamoDB. DAX ricupera i dati automaticamente dalle tabelle DynamoDB in caso di mancato riscontro nella cache. Le scritture sono designate come write-through (i dati vengono scritti prima in DynamoDB e in seguito aggiornati nella cache DAX).

Esattamente come DynamoDB, DAX è un servizio tollerante al guasto e scalabile. Un cluster DAX ha un nodo primario e zero o più nodi di replica di lettura. In caso di problema al nodo primario, DAX esegue automaticamente il failover e designa un nuovo nodo primario. Per il dimensionamento, si possono aggiungere o rimuovere repliche di lettura.

Per iniziare, occorre creare un cluster DAX, scaricare l'SDK DAX per Java o Node.js (compatibile con le API di DynamoDB), ricreare l'applicazione per poter utilizzare un client DAX invece di un client DynamoDB e infine indirizzare il client DAX verso l'endpoint del cluster DAX. Non occorre implementare nessuna logica di cache nell'applicazione poiché il client DAX implementa le stesse chiamate API di DynamoDB.

D: Cosa significa "compatibile con DynamoDB"?

Significa che la maggior parte del codice, delle applicazioni e degli strumenti usati con DynamoDB possono essere usati con DAX con modifiche minime o senza alcuna modifica. Il motore DAX è progettato per supportare le API di DynamoDB per la lettura e la modifica dei dati in DynamoDB. Non sono supportate le operazioni per la gestione delle tabelle come CreateTable/DescribeTable/UpdateTable/DeleteTable.

D: Cos'è il caching in memoria e quali vantaggi può portare alla mia applicazione?

Il caching migliora le prestazioni delle applicazioni perché immagazzina informazioni critiche in una memoria che ha una latenza molto bassa e un throughput elevato all'accesso. Nel caso di DAX, i risultati delle operazioni di DynamoDB sono memorizzati nella cache. Quando un'applicazione richiede dati memorizzati nella cache, DAX può utilizzarli immediatamente senza dover eseguire una query sulle normali tabelle DynamoDB. Per stabilire una data di scadenza dei dati o espellerli da DAX, si può specificare un valore chiamato periodo minimo di scadenza o TTL (time-to-live) per i dati o, quando tutta la memoria disponibile è esaurita, le voci vengono espulse in base all'algoritmo chiamato utilizzato meno di recente o LRU (Least Recently Used).

D: Cos'è il modello di consistenza di DAX?

Quando leggono i dati provenienti da DAX, gli utenti possono specificare se vogliono che la lettura sia a consistenza finale o forte:

Operazioni di lettura a consistenza finale (impostazione predefinita): l'opzione di consistenza finale massimizza il throughput di lettura e minimizza la latenza. In caso di riscontro nella cache, il client DAX restituisce il risultato direttamente dalla cache. In caso di mancato riscontro nella cache, DAX esegue una query su DynamoDB, aggiorna la cache e restituisce il gruppo di risultati. Occorre notare che una lettura consistente finale può non riflettere i risultati di una scrittura completata di recente. Se la un’applicazione richiede una consistenza completa, consigliamo di utilizzare letture fortemente consistenti.

Operazioni di lettura fortemente consistenti: oltre alla consistenza finale, DAX fornisce ulteriore flessibilità e controllo dando la possibilità di richiedere una lettura fortemente consistente se l'applicazione, o un elemento dell'applicazione, lo richiede. Una lettura fortemente consistente funziona sempre, non memorizza i risultati nella cache e fornisce un risultato che riflette tutte le scritture che hanno ricevuto una risposta positiva in DynamoDB prima della lettura.

D: Quali sono i casi d'uso comuni per DAX?

DAX ha diversi casi d'uso che non si escludono a vicenda:

Applicazioni che necessitano i tempi di risposta più rapidi possibile per le letture. Fra gli esempi troviamo le offerte in tempo reale, i giochi social e le applicazioni di borsa. DAX fornisce prestazioni rapide di lettura in memoria per questi casi d'uso.

Applicazioni che leggono una piccola quantità di voci più spesso delle altre. Ad esempio, prendiamo un sistema di E-Commerce che effettua una vendita di un prodotto noto per un giorno solo. Durante la vendita, la richiesta di quel prodotto (e i dati ad esso relativi in DynamoDB) aumenta rapidamente in confronto a tutti gli altri prodotti. Per diminuire l'impatto di una distribuzione di dati fondamentale e non uniforme, l'attività di lettura può essere deviata verso una cache DAX fino a che la vendita non sia terminata.

Applicazioni con intenso traffico di lettura ma anche sensibili ai costi. Con DynamoDB, puoi effettuare il provisioning del numero di letture al secondo che occorre alla tua applicazione. Se l'attività di lettura aumenta, puoi aumentare il throughput di lettura assegnato della tabella (a un costo aggiuntivo). In alternativa, puoi deviare l'attività dalla tua applicazione verso un cluster DAX e ridurre la quantità di unità di capacità di lettura che dovresti altrimenti acquistare.

Applicazioni che necessitano letture ripetute su un set di dati di grandi dimensioni. Questo tipo di applicazione può potenzialmente sottrarre risorse di database da altre applicazioni. Ad esempio, un'analisi con lunghi tempi di elaborazione di dati meteorologici di una regione potrebbe utilizzare tutta la capacità di lettura in una tabella DynamoDB e quindi avrebbe un impatto negativo su altre applicazioni che necessitano l'accesso agli stessi dati. Con DAX, l'analisi meteorologica può essere effettuata invece sui dati memorizzati nella cache.

Come funziona

D: Quali attività gestisce DAX per mio conto?

DAX è un sistema di caching completamente gestito per DynamoDB. Gestisce il lavoro richiesto per impostare nodi di cache dedicati, dal provisioning delle risorse di server all'installazione del software DAX. Quando il cluster di cache DAX è operativo, il servizio automatizza le attività amministrative consuete quali il rilevamento di errori e il ripristino e le operazioni di patch di software. DAX offre parametri di monitoraggio CloudWatch dettagliati relativi al cluster, consentendo la rapida individuazione e correzione dei problemi. Utilizzando questi parametri, si possono impostare soglie per la ricezione di allarmi CloudWatch. DAX gestisce completamente la memorizzazione, il recupero e l'espulsione dei dati nella cache al posto della tua applicazione. Basta usare l'API DynamoDB per scrivere e recuperare dati e DAX gestisce tutta la logica di cache dietro le quinte per fornire prestazioni ottimizzate.

D: Quali tipi di dati DAX memorizza nella cache?

Tutte le chiamate di lettura API sono memorizzate nella cache da DAX, con richieste fortemente consistenti che vengono lette direttamente da DynamoDB, mentre le letture consistenti finali vengono lette da Dax se la voce è disponibile. Le chiamate di scrittura API sono write-through (scrittura sincrona in DynamoDB che viene aggiornata nella cache in caso di esito positivo della scrittura).

Le chiamate API successive risulteranno da un esame della cache. In caso di riscontro, la voce viene restituita. In caso di mancato riscontro, la richiesta funziona e, in caso di recupero, la voce verrà memorizzata nella cache e restituita.

• GetItem
• BatchGetItem
• Query
• Scan

Le seguenti chiamate API sono operazioni write-through.

• BatchWriteItem
• UpdateItem
• DeleteItem
• PutItem

D: Come gestisce DAX l'espulsione dei dati?

DAX gestisce l'espulsione dei dati in tre modi diversi. Il primo modo consiste nell'utilizzare il valore chiamato periodo minimo di scadenza o TTL (time-to-live) che indica il periodo di tempo assoluto durante il quale la voce è disponibile nella cache. Con il secondo, quando la cache è piena, un cluster DAX utilizza un algoritmo chiamato utilizzato meno di recente o LRU (Least Recently Used) per decidere quali voci espellere. Con il terzo, mediante la funzionalità write-through, DAX espelle i valori meno recenti mentre vengono scritti nuovi valori tramite DAX. Questo consente di mantenere la cache delle voci coerente con il datastore sottostante utilizzando una sola chiamata API.

D: DAX funziona con i GSI e gli LSI di DynamoDB?

Esattamente come le tabelle DynamoDB, DAX memorizza nella cache i gruppi di risultati delle operazioni di query e scansione sui GSI e gli LSI di DynamoDB.

D: In che modo DAX gestisce i gruppi di risultati delle operazioni di query e scansione?

In un cluster DAX ci sono due cache diverse: 1) la cache delle voci e 2) la cache delle query. La cache delle voci gestisce le richieste GetItem, PutItem e DeleteItem per le coppie singole di chiave-valore. La cache delle query gestisce i gruppi di risultati delle richieste di query e scansione. In questo caso, il testo scansione/query è la "chiave" e il gruppo di risultati è il "valore". Nonostante la cache della voce e la cache della query siano gestite nello stesso cluster (e si possono specificare valori TTL per ciascuna cache), non si sovrappongono. Ad esempio, la scansione di una tabella non inserisce dati nella cache delle voci ma registra un'immissione nella cache delle query che memorizza il gruppo di risultati della scansione.

D: Un aggiornamento della cache delle voci aggiorna o invalida i gruppi di risultati nella cache delle query?

No. Il modo migliore per diminuire le discrepanze fra i gruppi di risultati nella cache della voce e nella cache della query è di impostare il TTL per la cache della query a un periodo di tempo accettabile perché l'applicazione possa gestire le discrepanze.

D: È possibile collegare un cluster DAX dall'esterno di un VPC?

Il solo modo per collegare un cluster DAX dall'esterno di un VPC è tramite una connessione VPN.

D: Quando si usa DAX, che cosa succede se le tabelle DynamoDB sottostanti vengono limitate?

Se DAX sta leggendo o scrivendo in una tabella DynamoDB e riceve un'eccezione di limitazione, DAX restituisce l'eccezione al client DAX. Inoltre, il servizio DAX non effettua tentativi ulteriori lato server.

D: DAX supporta il pre-riscaldamento della cache?

DAX utilizza il lazy loading per immettere dati nella cache. Questo significa che, alla prima lettura di una voce, DAX preleva la voce da DynamoDB e la immette nella cache. Sebbene DAX non supporti il pre-riscaldamento della cache come caratteristica, la cache DAX può essere pre-riscaldata per un'applicazione eseguendo un'applicazione o script esterno che legge i dati desiderati.

D: Come funziona DAX con la caratteristica TTL di DynamoDB?

Sia DynamoDB sia DAX possiedono il concetto di una caratteristica periodo minimo di scadenza o TTL (time-to-live). Nel contesto di DynamoDB, TTL è una caratteristica che consente ai clienti di stabilire una data di scadenza dei dati applicando ai dati un tag con un attributo particolare e il time stamp corrispondente. Ad esempio, se un cliente vuole che i dati vengano eliminati quando è trascorso un mese, può usare la caratteristica TTL di DynamoDB per effettuare questa attività invece di gestire da solo il flusso di scadenza.

Nel contesto di DAX, il TTL specifica la durata di tempo al termine della quale una voce nella cache non è più valida. Ad esempio, se un TTL è impostato a 5 minuti, quando la voce è stata immessa nella cache continuerà ad essere valida e utilizzata dalla cache fino a che il periodo di 5 minuti non sia trascorso. Sebbene non sia fondamentale in questa descrizione, il TTL può essere annullato da scritture nella cache per la stessa voce oppure in caso di utilizzo elevato di memoria nel nodo DAX e l'LRU espelle le voci poiché sono state utilizzate meno di recente.

Sebbene i TTL di DynamoDB e DAX operino normalmente su scale di tempo molto diverse (per es. il TTL di DAX opera in un ambito di minuti o di ore mentre il TTL di DynamoDB opera in un ambito di settimane, mesi o anni), è possibile che i clienti debbano tener conto di come queste due caratteristiche si influenzano a vicenda. Ad esempio, immaginiamo uno scenario in cui il valore TTL per DynamoDB è inferiore al valore TTL per DAX. In questo scenario, una voce può verosimilmente essere memorizzata nella cache in DAX e di conseguenza essere eliminata dalla caratteristica TTL di DynamoDB. Ne risulterà una cache non coerente. Non pensiamo che questo scenario possa verificarsi spesso per la differenza di grandezza delle scale di tempo di queste due caratteristiche, ma è bene rendersi conto di come queste due caratteristiche sono correlate.

D: DAX supporta la replica su più regioni?

Attualmente DAX supporta solo tabelle DynamoDB nella stessa regione AWS in cui si trova il cluster DAX.

D: AWS CloudFormation supporta DAX come tipo di risorsa?

Sì. È possibile creare, aggiornare ed eliminare cluster DAX, gruppi di parametri e gruppi di sottoreti con AWS CloudFormation.

Nozioni di base

D: Come si inizia a usare DAX?
Si può creare un nuovo cluster DAX tramite la console AWS o l'SDK AWS per ottenere un endpoint di cluster DAX. Si deve scaricare un client compatibile con DAX e utilizzarlo nell'applicazione con il nuovo endpoint DAX.

D: Come si crea un cluster DAX?

Si può creare un cluster DAX utilizzando la Console AWS o l'interfaccia a riga di comando DAX. I cluster DAX variano da una cache da 13 GiB (dax.r3.large) a una cache da 216 GiB (dax.r3.8xlarge) nei tipi di istanza R3 e da una cache da 15,25 GiB (dax.r4.large) a una cache da 488 GiB (dax.r4.16xlarge) per i tipo di istanza R4. Con qualche clic nella Console AWS o una sola chiamata API, si possono aggiungere fino a 10 repliche in un cluster per aumentare il throughput.

La configurazione con un singolo nodo ti permette di iniziare a usare DAX in modo rapido ed economico e di passare a una configurazione a più nodi in base alla crescita delle tue esigenze. La configurazione a più nodi consiste in un nodo primario che gestisce le scritture e fino a nove nodi di replica di lettura. Il provisioning del nodo primario viene effettuato automaticamente.

Basta specificare i gruppi di sottorete o le zone di disponibilità (opzionali) desiderati, il numero di nodi, i tipi di nodi, il gruppo di sottorete del VPC e altre impostazioni di sistema. Una volta selezionata la configurazione desiderata, DAX effettua il provisioning delle risorse necessarie e configura il cluster di cache specificamente per DynamoDB.

D: Tutti i miei dati devono entrare nella memoria per poter utilizzare DAX?

No. DAX utilizza la memoria disponibile nel nodo. Usando TTL e/o LRU, le voci verranno espulse per fare posto a nuovi dati quando la memoria è esaurita.

D: Quali linguaggi supporta DAX?

DAX fornisce SDK DAX per Java e Node.js che puoi scaricare oggi stesso. Presto aggiungeremo supporto per altri client.

D: È possibile utilizzare simultaneamente DAX e DynamoDB?

Sì, è possibile accedere all'endpoint DAX e a DynamoDB simultaneamente tramite client diversi. Tuttavia DAX non sarà in grado di rilevare modifiche nei dati scritti direttamente in DynamoDB, a meno che queste modifiche siano immesse in modo esplicito in DAX tramite un'operazione di lettura dopo che è stato effettuato un aggiornamento direttamente in DynamoDB.

D: Si possono usare più cluster DAX per la stessa tabella DynamoDB?

Sì, si può effettuare il provisioning di più cluster DAX per la stessa tabella DynamoDB. Questi cluster forniscono differenti endpoint che possono essere utilizzati in diversi casi d'uso, garantendo una memorizzazione ottimale nella cache per ogni scenario. Due cluster DAX sono indipendenti l'uno dall'altro e non condividono lo stato o gli aggiornamenti, perciò gli utenti possono accedere meglio utilizzandoli per tabelle completamente diverse.

D: Come faccio a sapere quale tipo di nodo DAX mi occorre per il mio carico di lavoro?

Il dimensionamento di un cluster DAX è un processo iterativo. Si raccomanda di effettuare il provisioning di un cluster a tre nodi (per la disponibilità elevata) con sufficiente memoria perché il working set dell'applicazione possa entrare nella memoria. In base alle prestazioni e al throughput dell'applicazione, all'utilizzo del cluster DAX e al rapporto di riscontri/mancati riscontri, può essere necessario ricalibrare il cluster DAX per ottenere i risultati desiderati.

D: Su quali tipi di istanze EC2 può essere eseguito DAX?

Qui di seguito sono dei tipi di nodo validi:

R3:  

• dax.r3.large (13 GiB)
• dax.r3.xlarge (26 GiB)
• dax.r3.2xlarge (54 GiB)
• dax.r3.4xlarge (108 GiB)
• dax.r3.8xlarge (216 GiB)

R4:

• dax.r4.large (15,25 GiB)
• dax.r4.xlarge (30,5 GiB)
• dax.r4.2xlarge (61 GiB)
• dax.r4.4xlarge (122 GiB)
• dax.r4.8xlarge (244 GiB)
• dax.r4.16xlarge (488 GiB)

D: DAX supporta le istanze riservate o il piano di utilizzo gratuito AWS?

Al momento DAX supporta solo le istanze on demand.

D: Come viene calcolato il prezzo di DAX?

I prezzi di DAX si basano sulle ore di utilizzo del nodo, calcolate a partire dall'avvio di un nodo e fino al momento della sua interruzione. Ogni ora-nodo parziale consumata sarà fatturata come un'ora completa. I prezzi si applicano a tutti i singoli nodi nel cluster DAX. Ad esempio, in un cluster DAX a tre nodi, gli addebiti verranno applicati a ciascuno dei singoli nodi (tre nodi in totale) su base oraria.

Disponibilità

D: Come si può ottenere una disponibilità elevata con un cluster DAX?

DAX fornisce supporto integrato in Multi-AZ, consentendo di scegliere le zone di disponibilità preferite per i nodi di un cluster DAX. DAX usa la replica asincrona per garantire la coerenza fra i nodi, in modo che, in caso di errore, ci siano altri nodi che possono rispondere alle richieste. Per ottenere una disponibilità elevata per un cluster DAX, per interruzioni pianificate o no, raccomandiamo di distribuire almeno tre nodi in tre zone di disponibilità separate. Ciascuna zona di disponibilità viene eseguita su un'infrastruttura fisica propria, distinta e indipendente ed è progettata in modo da essere altamente affidabile.

D: Che cosa succede in caso di errore di un nodo DAX?

In caso di errore del nodo primario, DAX rileva automaticamente l'errore, seleziona una delle repliche di lettura disponibili e la converte in nodo primario. Inoltre, DAX effettua il provisioning di un nuovo nodo per sostituire la replica di lettura convertita nella stessa zona di disponibilità dell'errore del nodo primario. Questo nuovo nodo sostituisce la nuova replica di lettura. In caso di errore del nodo primario dovuto a un'interruzione temporanea della zona di disponibilità, la nuova replica verrà avviata non appena la zona di disponibilità sarà ripristinata. In caso di errore di un cluster a nodo singolo, DAX avvia un nuovo nodo nella stessa zona di disponibilità.

Scalabilità

D: Quale tipo di scalabilità supporta DAX?

Attualmente DAX supporta due tipi di dimensionamento. La prima opzione è un dimensionamento della lettura per ottenere throughput supplementare aggiungendo repliche di lettura a un cluster. Un singolo cluster DAX supporta fino a 10 nodi, consentendo milioni di richieste al secondo. L'aggiunta o l'eliminazione di repliche aggiuntive è un'operazione online. Il secondo modo per dimensionare un cluster è di ricalibrare le risorse selezionando tipi di istanza r3 più grandi o più piccole. I nodi di maggiori dimensioni consentiranno al cluster di memorizzare una quantità più grande di gruppi di dati dell'applicazione e in questo modo di ridurre i mancati riscontri e migliorare le prestazioni globali dell'applicazione. Quando si crea un cluster DAX, tutti i nodi del cluster devono appartenere allo stesso tipo di istanza. Inoltre, se si desidera modificare il tipo di istanza per un cluster DAX, (per es., ricalibrare da r3.large a r3.2xlarge), si deve creare un nuovo cluster DAX con il tipo di istanza desiderata. DAX non supporta al momento le operazioni di dimensionamento online.

D: Come si scrive-dimensiona un'applicazione?

In un cluster DAX, solo il nodo primario gestisce le operazioni di scrittura in DynamoDB. Perciò l'aggiunta di nodi supplementari al cluster DAX aumenterà il throughput di lettura ma non quello di scrittura. Per aumentare il throughput di scrittura di un'applicazione, occorre passare a una dimensione maggiore di istanza o effettuare il provisioning di più cluster DAX e suddividere in shard lo spazio chiave a livello di applicazione.

Monitoraggio

D: Come si monitorano le prestazioni di un cluster DAX?
I parametri relativi all’utilizzo di CPU, al conteggio dei riscontri/mancati riscontri e al traffico di lettura/scrittura dei cluster DAX sono disponibili tramite la Console di gestione AWS o le API di Amazon CloudWatch. È inoltre possibile aggiungere ulteriori parametri definiti dall'utente tramite le funzionalità di personalizzazione dei parametri di Amazon CloudWatch. Oltre ai parametri CloudWatch, DAX fornisce informazioni sulle prestazioni di riscontri, mancati riscontri, query e cluster anche tramite la Console di gestione AWS.

Manutenzione

D: Che cos'è una finestra di manutenzione? I cluster di DAX sono disponibili durante la manutenzione del software?

La finestra di manutenzione di DAX può essere considerata come un'opportunità di controllo durante modifiche del cluster quali un'operazione di patching. Se è programmato un evento di manutenzione per una determinata settimana, questo verrà avviato e concluso in un certo momento nella finestra di manutenzione indicata.

Le operazioni di patching necessarie vengono programmate automaticamente solo per le patch correlate alla sicurezza e all'affidabilità. Tali operazioni di patching vengono eseguite di rado (di solito alcune volte all'anno). Se non specifichi una finestra di manutenzione settimanale preferita durante la creazione del cluster, viene assegnato un valore predefinito. Se desideri cambiare il momento in cui viene eseguita la manutenzione per tuo conto, puoi modificare il tuo cluster nella Console di gestione AWS o tramite l'API UpdateCluster. Puoi definire finestre di manutenzione preferite differenti per ciascuno dei tuoi cluster.

Per i cluster multi-nodo, gli aggiornamenti del cluster vengono effettuati in sequenza e verrà aggiornato un nodo alla volta. Quando il nodo è aggiornato, si sincronizza con uno dei peer nel cluster in modo da avere un set di dati aggiornato. Per un cluster a nodo singolo, effettuiamo il provisioning di una replica (senza costi aggiuntivi per l'utente), sincronizziamo la replica con i dati più recenti e poi eseguiamo un failover per trasformare la nuova replica il nodo primario. In questo modo, non si perdono dati durante un aggiornamento per un cluster a nodo singolo.  

D: Cosa sono gli endpoint VPC per DynamoDB (VPCE per DynamoDB)?

Amazon Virtual Private Cloud (VPC) è un servizio AWS che offre agli utenti un cloud virtuale privato effettuando il provisioning di una sezione logicamente isolata del cloud di Amazon Web Services (AWS). L'endpoint VPC (VPCE) per DynamoDB è un'entità logica all'interno di un VPC che crea una connessione privata tra un VPC e DynamoDB senza richiedere l'accesso tramite Internet, tramite un dispositivo NAT o una connessione VPN. Per ulteriori informazioni sugli endpoint VPC, consulta il documento Amazon VPC User Guide.

D: Qual è il vantaggio di utilizzare VPCE per DynamoDB?

In passato, per accedere a DynamoDB dall'interno di un VPC era necessario passare per Internet, che poteva richiedere configurazioni complesse quali firewall e VPN. Gli endpoint VPC per DynamoDB migliorano la privacy e la sicurezza per i clienti, in particolare per quelli che gestiscono carichi di lavoro sensibili con requisiti di conformità e audit, consentendo l'accesso privato a DynamoDB dall'interno di un VPC senza la necessità di un gateway Internet o NAT. Gli endpoint VPC per DynamoDB supportano inoltre le policy AWS Identity and Access Management (IAM) per semplificare il controllo degli accessi a DynamoDB in modo da poter ora limitare facilmente l'accesso alle tabelle DynamoDB a un endpoint VPC specifico.

D: Come si inizia a usare VPCE per DynamoDB?

VPCE per DynamoDB viene creato mediante la Console di gestione AWS, il kit SDK AWS oppure l’interfaccia a riga di comando (CLI) di AWS. È necessario specificare il VPC e le tabella di routing esistenti nel VPC e descrivere la policy IAM da collegare all'endpoint. Un percorso viene automaticamente aggiunto a ciascuna delle tabella di routing del VPC specificate.

D: VPCE per DynamoDB assicura che il traffico non sia instradato al di fuori della rete Amazon?

Sì, quando utilizzi VPCE per DynamoDB, i pacchetti di dati tra DynamoDB e VpC rimarranno nella rete Amazon.

D: Posso collegarmi a una tabella DynamoDB in una regione differente dal mio VPC usando VPCE per DynamoDB?

No, gli endpoint VPC possono essere creati solo per le tabelle DynamoDB nella stessa regione del VPC.

D: VPCE per DynamoDB limita il throughput a DynamoDB?

No, continuerai ad avere lo stesso throughput su DynamoDB che hai oggi da un'istanza con un IP pubblico all'interno del VPC.

D: Quanto costa utilizzare VPCE per DynamoDB?

L'uso di VPCE per DynamoDB non prevede costi aggiuntivi.

D: Posso accedere alla funzione Flusso di DynamoDB usando VPCE per DynamoDB?

Al momento non è possibile accedere alla funzione Flusso di DynamoDB usando VPCE per DynamoDB.

D: Al momento utilizzo un gateway Internet e un gateway NAT per inviare richieste a DynamoDB. Devo modificare il codice della mia applicazione quando utilizzo un VPCE?

Non è necessario modificare il codice dell'applicazione. È sufficiente creare un endpoint VPC, aggiornare la tabella di routing affinché instradi il traffico DynamoDB sul VPCE DynamoDB e accedere direttamente a DynamoDB. Puoi continuare a utilizzare lo stesso codice e gli stessi nomi DNS per accedere a DynamoDB.

D: È possibile utilizzare un VPCE sia per DynamoDB che per un altro servizio AWS?

No, ogni VPC supporta un servizio. Puoi tuttavia crearne uno per DynamoDB e un altro per l'altro servizio AWS e utilizzare entrambi in una tabella di routing. 

D: Posso avere più endpoint VPC in un unico VPC?

Sì, puoi avere più endpoint VPC in un unico VPC. Ad esempio, è possibile avere un VPCE per S3 e un VPCE per DynamoDB.

D: Posso avere più VPCE per DynamoDB in un unico VPC?

Sì, puoi avere più VPCE per DynamoDB in un unico VPC. VPCE individuali possono avere policy VPCE differenti. È ad esempio possibile avere un VPCE che è di sola lettura e un altro che è disponibile in lettura e scrittura. Tuttavia, una tabella di routing singola in un VPC può essere associata solo a un VPCE singolo per DynamoDB, poiché la tabella di routing instraderà tutto il traffico a DynamoDB tramite il VPCE specificato.

D: Quali sono le differenze tra VPCE per S3 e VPCE per DynamoDB?

Le principali differenze sono che questi due VPCE supportano servizi differenti: S3 e DynamoDB.

D: Quale indirizzo IP viene visualizzato nei log di AWS CloudTrail per il traffico proveniente dal VPCE per DynamoDB?

I log di AWS CloudTrail per DynamoDB conterranno l'indirizzo IP privato dell'istanza EC2 nel VPC e l'identificatore VPCE (ad es. sourceIpAddress=10.89.76.54, VpcEndpointId=vpce-12345678).

D: Come posso gestire i VPCE usando l'interfaccia a riga di comando (CLI)?

È possibile utilizzare i seguenti comandi CLI per gestire i VPCE: create-vpc-endpoint, modify-vpc-endpoint, describe-vpc-endpoints, delete-vpc-endpoint e descrive-vpc-endpoint-services. È necessario specificare il nome del servizio DynamoDB specifico sul VPC e la regione DynamoDB region, ad es. ‘com.amazon.us.east-1.DynamoDB’. Ulteriori informazioni sono reperibili qui.

D: Per usare VPCE per DynamoDB i clienti devono conoscere e gestire gli indirizzi IP pubblici di DynamoDB?

No, per poter utilizzare questa funzionalità i clienti non devono conoscere o gestire gli intervalli degli indirizzi IP pubblici per DynamoDB. Verrà fornito un prefisso da utilizzare nelle tabelle di routing e nei gruppi di sicurezza. AWS conserva gli intervalli degli indirizzi nell'elenco. Il nome dell'elenco di prefissi è: com.amazonaws. .DynamoDB. Ad esempio: com.amazonaws.us-east-1.DynamoDB.

D: È possibile utilizzare le policy IAM su un VPCE per DynamoDB?

Sì. Puoi collegare una policy IAM al VPCE che sarà quindi applicabile a tutti il traffico che passa tramite questo endpoint. Ad esempio, un VPCE che utilizza questa policy consente solo di descrivere* le chiamate API:
{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:describe*",
            "Effect":"Allow",
            "Resource": "arn:aws:dynamodb:region:account-id:table/table-name",
            "Principal": "*"
        }
    ]
}

D: È possibile limitare l'accesso alla tabella DynamoDB da un endpoint VPC?

Sì, puoi creare una policy IAM per limitare un utente, gruppo o ruolo IAM a un particolare VPCE per le tabelle DynamoDB.

Questa operazione può essere eseguita impostando l'elemento Resource della policy IAM su una tabella DynamoDB e la chiave dell'elemento Condition su aws:sourceVpce. Ulteriori dettagli sono disponibili nel documento IAM User Guide.

Ad esempio, la seguente policy IAM limita l'accesso alle tabelle DynamoDB a meno che sourceVpce corrisponda a “vpce-111bbb22”

{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:*",
            "Effect":"Deny",
            "Resource": "arn:aws:dynamodb:region:account-id:*",
            "Condition": { "StringNotEquals" : { "aws:sourceVpce": "vpce-111bbb22" } }
        }
    ]
}

D: VPCE per DynamoDB supporta le condizioni delle policy IAM per il controllo granulare degli accessi (FGAC)?

Sì. VPCE per DynamoDB supporta tutte le chiavi di accesso FGAC. Puoi utilizzare le condizioni delle policy IAM per FGAC per controllare l'accesso a singole voci di dati e attributi. Ulteriori informazioni su FGAC sono reperibili qui.

D: È possibile utilizzare il generatore di policy AWS per creare policy di endpoint VPC o DynamoDB?

È possibile utilizzare il generatore di policy AWS per creare policy di endpoint VPC.

D: DynamoDB supporta le policy basate su risorse simili alle policy dei bucket S3?

No, DynamoDB non supporta le policy basate su risorse inerenti tabelle individuali, voci e simili.