Single-Table Design in DynamoDB

Venendo da SQL, l'istinto è una tabella per entità: customers, orders, order_items. In DynamoDB quell'istinto è di solito sbagliato. Una tabella singola che memorizza ogni entità, distinta da prefissi di chiave sovraccaricati, ti permette di recuperare un genitore e i suoi figli in una Query — niente join, niente N+1.

Cos'è la single-table design in DynamoDB?

La single-table design memorizza ogni entità — customer, order, order item — in un'unica tabella DynamoDB, distinta da partition key e prefissi di sort key sovraccaricati. Poiché le chiavi sono progettate attorno ai tuoi pattern di accesso piuttosto che alle tue entità, un genitore e tutti i suoi figli vivono in una sola item collection e tornano in una singola Query — niente join, niente letture N+1.

L'idea

Scegli nomi di chiave generici (PK, SK) e codifica il tipo di entità nel valore:

Ora una Query PK = "CUSTOMER#42" restituisce il profilo e ogni ordine in un' unica lettura fatturata. SK begins_with "ORDER#" la restringe ai soli ordini.

Visivamente, gli Item sovraccaricati si impilano sotto un'unica partition key come una singola item collection:

Una lettura della partizione restituisce il customer e ogni ordine insieme.

GSI sovraccaricati

Lo stesso trucco funziona sugli indici. Metti un GSI1PK/GSI1SK generico sugli Item, e un singolo GSI serve più pattern di accesso a seconda di cosa ogni Item scrive in quegli attributi:

Ora Query GSI1 WHERE GSI1PK = "STATUS#OPEN" elenca gli ordini aperti per data — un pattern a cui la tabella di base non può rispondere. Un'entità diversa può riusare GSI1 con il proprio significato (per es. CATEGORY#books). Un indice, molte query.

Molti-a-molti: la adjacency list

Per le relazioni (un utente in molti team, un team con molti utenti), scrivi l'arco due volte con gli id scambiati: PK=USER#1, SK=TEAM#9 e PK=TEAM#9, SK=USER#1. Interrogare uno dei due lati elenca l'altro — il sostituto DynamoDB di una tabella di join.

Quando non usare la tabella singola

Non è gratis. Una tabella sovraccaricata è più difficile da ragionare, più difficile da evolvere e ostile all'analisi. Se i tuoi pattern di accesso sono davvero sconosciuti o cambiano di continuo, o i dati sono per lo più analitici, tabelle separate (o un archivio diverso) possono essere la scelta più assennata. La tabella singola vince quando i pattern sono noti e ad alto volume.

Il costo della forma sbagliata

Modellare come tabelle separate impone uno Scan o un join lato client per ricomporre un customer, e questo è il trabocchetto dello Scan. Modella prima i pattern di accesso, poi progetta le chiavi per rendere ciascuno una Query. (Per la domanda ad-hoc tra entità che non hai modellato, SQL Workbench di DynoTable esegue la JOIN lato client — l'esplorazione non deve aspettare una rimodellazione.)

Abbozza il design con lo strumento gratuito di Single-Table Design — trasforma la tua lista di pattern di accesso in un piano PK/SK/GSI con Item di esempio e stime dei costi. Stima quanto costano questi Item per lettura con il calcolatore dimensione Item e capacità, e prova DynoTable per sfogliare uno schema a tabella singola e vedere le collezioni sovraccaricate affiancate.