Differenza tra indici locali e globali in DynamoDB

Sono curioso di conoscere questi due indici secondari e le differenze tra loro. È difficile immaginare come sia. E penso che questo aiuterà più persone di me.

Gli indici secondari locali si basano ancora sulla chiave hash originale. Quando fornisci una tabella con hash + range, pensa a LSI come hash + range1, hash + range2 .. hash + range6. Ottieni altri 5 attributi di intervallo su cui interrogare. Inoltre, esiste un solo throughput di provisioning.

Global Secondary Indexes definisce un nuovo paradigma: chiavi hash / range diverse per indice.
Ciò interrompe l'utilizzo originale di una chiave hash per tabella. Questo è anche il motivo per cui quando si definisce GSI è necessario aggiungere un throughput di provisioning per indice e pagarlo.

Informazioni più dettagliate sulle differenze sono disponibili nell'annuncio GSI

Ecco la definizione formale dalla documentazione:

Indice secondario globale : un indice con una chiave hash e range che può essere diverso da quelli nella tabella. Un indice secondario globale è considerato "globale" perché le query sull'indice possono comprendere tutti i dati di una tabella, in tutte le partizioni.

Indice secondario locale : un indice che ha la stessa chiave hash della tabella, ma una chiave di intervallo diversa. Un indice secondario locale è "locale", nel senso che ogni partizione di un indice secondario locale è impostata su una partizione di tabella che ha la stessa chiave hash.

Tuttavia, le differenze vanno ben oltre le possibilità in termini di definizioni chiave. Di seguito sono riportati alcuni fattori importanti che influiranno direttamente sui costi e gli sforzi per mantenere gli indici:

• Portata :

Gli indici secondari locali utilizzano la velocità effettiva dalla tabella. Quando si eseguono query sui record tramite l'indice locale, l'operazione utilizza le unità di capacità di lettura dalla tabella. Quando si esegue un'operazione di scrittura (creazione, aggiornamento, eliminazione) in una tabella con un indice locale, ci saranno due operazioni di scrittura, una per la tabella e un'altra per l'indice. Entrambe le operazioni consumeranno unità di capacità di scrittura dalla tabella.

Gli indici secondari globali hanno il proprio throughput di provisioning, quando si esegue una query sull'indice l'operazione consumerà capacità di lettura dall'indice, quando si esegue un'operazione di scrittura (creazione, aggiornamento, eliminazione) in una tabella che ha un indice globale, ci saranno due operazioni di scrittura, una per la tabella, un'altra per l'indice *.

* Quando si definisce la velocità effettiva fornita per l'Indice secondario globale, assicurarsi di prestare particolare attenzione ai seguenti requisiti:

Affinché una scrittura della tabella abbia esito positivo, le impostazioni della velocità effettiva fornita per la tabella e tutti i suoi indici secondari globali devono avere una capacità di scrittura sufficiente per adattarsi alla scrittura; in caso contrario, la scrittura sul tavolo verrà ridotta.

• Gestione :

Gli indici secondari locali possono essere creati solo quando si crea la tabella, non è possibile aggiungere l'indice secondario locale a una tabella esistente, inoltre una volta creato l'indice non è possibile eliminarlo.

Gli indici secondari globali possono essere creati quando si crea la tabella e si aggiunge a una tabella esistente, è anche consentito eliminare un indice secondario globale esistente.

• Leggi coerenza:

Gli indici secondari locali supportano la coerenza eventuale o forte, mentre l'indice secondario globale supporta solo l'eventuale coerenza.

• Proiezione:

Gli indici secondari locali consentono di recuperare attributi che non sono proiettati nell'indice (anche se con costi aggiuntivi: prestazioni e unità di capacità consumata). Con Global Secondary Index è possibile recuperare solo gli attributi proiettati sull'indice.

Considerazione speciale sull'unicità delle chiavi definite negli indici secondari:

In un indice secondario locale, il valore chiave dell'intervallo NON DEVE essere univoco per un dato valore chiave hash, la stessa cosa vale per gli indici secondari globali, i valori chiave (hash e intervallo) NON devono essere univoci.

Fonte: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

Queste sono le possibili ricerche per indice:

• Di Hash
• Di Hash + Range
• Per hash + indice locale
• Per indice globale
• Per indice globale + indice di gamma

Indici di hash e intervallo di una tabella: questi sono i soliti indici delle versioni precedenti di Amazon AWS SDK.

Indici globali e locali: si tratta di indici "aggiuntivi" creati su una tabella, oltre agli indici hash e range esistenti della tabella. L'indice globale è simile a un hash. L'indice di intervallo si comporta in modo simile all'indice di intervallo utilizzato con l'hash della tabella. Nel modello di entità nel codice, il getter deve essere annotato in questo modo:

• Per gli indici globali:

  @DynamoDBIndexHashKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_USER)
  public String getUser() {
      return user;
  }
  

• Per l'indice di intervallo associato all'indice globale:

  @DynamoDBIndexRangeKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_TIMESTAMP)
  public String getTimestamp() {
      return timestamp;
  }
  

Inoltre, se leggi una tabella da un indice globale, deve essere una lettura finale (lettura non coerente):

queryExpression.setConsistentRead(false);

Un modo per dirlo è questo:

LSI: consente di eseguire una query su una singola chiave hash mentre si utilizzano più attributi diversi per "filtrare" o limitare la query.

GSI: consente di eseguire query su più Hash-Keys in una tabella, ma di conseguenza ha un costo aggiuntivo.

Una suddivisione più ampia dei tipi di tabella e di come funzionano, di seguito:

Solo hash

Come probabilmente già saprai; una chiave hash di per sé deve essere unica in quanto la scrittura su una chiave hash già esistente sovrascriverà i dati esistenti.

Hash + Gamma

Un tasto cancelletto + tasto intervallo consente di avere più tasti hash uguali, purché abbiano un tasto intervallo diverso. In questo caso, se si scrive su una chiave hash che esiste già, ma si utilizza una chiave di intervallo che non è già utilizzata da quella chiave di hash, si crea un nuovo elemento, mentre se un articolo con la stessa combinazione di hash + intervallo esiste già, sovrascrive l'elemento corrispondente.

Un altro modo di pensare a questo è come un file con un formato. Puoi avere un file con lo stesso nome (hash) di un altro, nella stessa cartella (tabella), purché il loro formato (intervallo) sia diverso. Allo stesso modo, puoi avere più file dello stesso formato purché il loro nome sia diverso.

LSI

Un LSI è fondamentalmente lo stesso di un Hash-Key + Range-Key e segue le stesse regole di quando, durante la creazione di elementi, tranne per il fatto che è necessario fornire anche valori per gli LSI; non possono essere lasciati vuoti / nulli.

Dire che un LSI è "Range-Key 2" non è del tutto corretto in quanto non è possibile avere (usando il mio file e la mia analogia dei formati precedenti) un file chiamato: file.format.lsie file.format.lsi2. È possibile, tuttavia, avere file.format.lsie file.format2.lsio file.format.lsie file2.format.lsi.

Fondamentalmente, un LSI è solo un "filtro-chiave", non un vero intervallo di chiave; la combinazione di valori Hash e Range di base deve essere comunque unica mentre i valori LSI non devono essere univoci, per niente. Un modo più semplice di osservarlo potrebbe essere quello di pensare a LSI come dati all'interno dei file. È possibile scrivere codice che trova tutti i file con il nome "PROJECT101", indipendentemente dal loro fileFormat, quindi legge i dati all'interno per determinare cosa deve essere incluso nella query e cosa è omesso. Questo è fondamentalmente il modo in cui funziona LSI (solo senza il sovraccarico aggiuntivo di aprire il file per leggere il suo contenuto).

GSI

Per GSI, stai essenzialmente creando un'altra tabella per ogni GSI, ma senza il fastidio di mantenere più tabelle separate che rispecchiano i dati tra loro; ecco perché costano più throughput.

Quindi, per un GSI, è possibile specificare fileNamecome chiave di hash di base e fileFormatcome chiave di intervallo di base. È quindi possibile specificare un GSI che ha una chiave hash di fileName2e una chiave di intervallo di fileFormat2. È quindi possibile eseguire una query su uno fileNameo fileName2se lo si desidera, a differenza di LSI in cui è possibile eseguire solo query fileName.

I principali vantaggi sono che devi mantenere solo una tabella, anziché 2, e ogni volta che scrivi nell'Hash / Range primario o negli Hash / Range GSI, anche gli altri verranno automaticamente aggiornati, quindi non puoi "dimenticare" di aggiornare le altre tabelle come puoi con un'impostazione a più tabelle. Inoltre, non è possibile che si verifichi una perdita di connessione dopo averne aggiornato uno e prima di aggiornare l'altro, come nel caso dell'installazione multi-tavolo.

Inoltre, un GSI può "sovrapporre" la combinazione Hash / Range di base. Quindi, se volevi creare un tavolo con fileNamee fileFormatcome Hash / Range di base e filePrioritye fileNamecome GSI, puoi farlo.

Infine, una combinazione Hash + Range di GSI non deve essere unica, mentre la combinazione Hash + Range di base deve essere unica. Questo è qualcosa che non è possibile con una configurazione a doppia / multi-tabella, ma con GSI. Di conseguenza, È NECESSARIO fornire i valori sia per la base AND GSI Hash + Range, durante l'aggiornamento; nessuno di questi valori può essere vuoto / nullo.

Un altro modo per spiegare: LSI ti aiuta a fare query aggiuntive sugli oggetti con la stessa chiave hash. GSI ti aiuta a fare domande simili sugli elementi "attraverso la tabella". Molto utile

Se hai una tabella di profili utente: ID-univoco, nome, e-mail. Qui se è necessario rendere la tabella interrogabile su nome, e-mail - l'unico modo è renderli GSI (LSI non aiuterà)

Questo documento fornisce una spiegazione abbastanza buona:

https://aws.amazon.com/blogs/aws/now-available-global-secondary-indexes-for-amazon-dynamodb/

Non ho potuto commentare questa domanda, ma che è meglio in termini di prestazioni di scrittura e lettura:

(Indice locale con velocità di lettura e scrittura della tabella di 100) o (Indice globale con velocità di lettura / scrittura di 50 insieme a velocità di lettura / scrittura della tabella di 50?)

Non ho bisogno di una chiave di partizione separata per il mio caso d'uso, quindi l'indice locale dovrebbe essere sufficiente per la funzionalità richiesta.

I GSI non possono essere utilizzati per letture coerenti.

Gli LSI possono essere utilizzati per letture coerenti ma limitano la dimensione della partizione principale a 10 GB. Inoltre, gli LSI possono essere creati solo durante la creazione di tabelle.