Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Best practice per la modellazione dei dati relazionali in DynamoDB

Questa sezione fornisce best practice per la modellazione dei dati relazionali in Amazon DynamoDB. Innanzitutto, presentiamo i concetti tradizionali di modellazione dei dati. Quindi, descriviamo i vantaggi dell'utilizzo di DynamoDB rispetto ai tradizionali sistemi di gestione di database relazionali: come elimina la necessità di operazioni e riduce il sovraccarico. JOIN

Illustriamo quindi come progettare una tabella DynamoDB dimensionabile in modo efficiente. Infine, forniamo un esempio di come modellare i dati relazionali in DynamoDB.

Modelli di database relazionali tradizionali

Un sistema di gestione di database relazionali tradizionale (RDBMS) archivia i dati in una struttura relazionale normalizzata. L'obiettivo del modello di dati relazionali è ridurre la duplicazione dei dati (attraverso la normalizzazione) per supportare l'integrità referenziale e ridurre le anomalie dei dati.

Lo schema seguente è un esempio di modello di dati relazionale per un'applicazione generica di immissione degli ordini. L'applicazione supporta uno schema delle risorse umane che supporta i sistemi di supporto operativi e aziendali di un produttore ipotetico.

In quanto servizio di database non relazionale, DynamoDB offre molti vantaggi rispetto ai tradizionali sistemi di gestione di database relazionali.

In che modo DynamoDB elimina la necessità di operazioni JOIN

An RDBMS utilizza un linguaggio di interrogazione strutturale (SQL) per restituire dati all'applicazione. A causa della normalizzazione del modello di dati, tali query richiedono in genere l'uso dell'operatore JOIN per combinare i dati di una o più tabelle.

Ad esempio, per generare un elenco di articoli dell'ordine di acquisto ordinati in base alla quantità disponibile in magazzino in tutti i magazzini che possono spedire ciascun articolo, è possibile eseguire la seguente SQL query sullo schema precedente.

SELECT * FROM Orders
  INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID
  INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID
  INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID
  ORDER BY Quantity_on_Hand DESC

SQLinterrogazioni di questo tipo possono fornire un accesso flessibile API ai dati, ma richiedono una notevole quantità di elaborazione. Ogni join nella query aumenta la complessità del runtime della query perché i dati di ogni tabella devono essere suddivisi in fasi e quindi assemblati per restituire il set di risultati.

Altri fattori che possono influire sul tempo impiegato per l'esecuzione delle query sono la dimensione delle tabelle e la presenza di indici nelle colonne da unire. La query precedente avvia query complesse in diverse tabelle e poi ordina il set di risultati.

Eliminare la necessità di JOINs è alla base di No SQL data modeling. Ecco perché abbiamo creato DynamoDB per supportare Amazon.com e perché DynamoDB può offrire prestazioni costanti a larga scala. Data la complessità di runtime delle SQL queryJOINs, le RBDMS prestazioni non sono costanti su larga scala. Ciò causa problemi di prestazioni man mano che le applicazioni dei clienti aumentano.

Sebbene la normalizzazione dei dati riduca la quantità di dati archiviati su disco, spesso le risorse più limitate che influiscono sulle prestazioni sono il CPU tempo e la latenza di rete.

DynamoDB è progettato per ridurre al minimo entrambi i vincoli eliminando JOINs (e incoraggiando la denormalizzazione dei dati) e ottimizzando l'architettura del database per rispondere completamente a una query dell'applicazione con una singola richiesta a un elemento. Queste qualità consentono a DynamoDB di fornire prestazioni a una cifra in millisecondi su qualsiasi scala. Questo perché la complessità del runtime delle operazioni DynamoDB è costante, indipendentemente dalla dimensione dei dati, per i modelli di accesso comuni.

In che modo le transazioni DynamoDB eliminano il sovraccarico del processo di scrittura

Un altro fattore che può rallentare un RDBMS è l'uso di transazioni per scrivere su uno schema normalizzato. Come mostrato nell'esempio, le strutture di dati relazionali utilizzate dalla maggior parte delle applicazioni di elaborazione delle transazioni online (OLTP) devono essere suddivise e distribuite su più tabelle logiche quando sono archiviate in un. RDBMS

Pertanto, è necessario un framework di transazioni ACID conforme per evitare condizioni di gara e problemi di integrità dei dati che potrebbero verificarsi se un'applicazione tenta di leggere un oggetto in fase di scrittura. Un tale framework di transazioni, se abbinato a uno schema relazionale, può aggiungere un sovraccarico significativo al processo di scrittura.

L'implementazione delle transazioni in DynamoDB vieta i problemi di scalabilità comuni riscontrati con un. RDBMS DynamoDB esegue questa operazione emettendo una transazione come API singola chiamata e limitando il numero di elementi a cui è possibile accedere in quella singola transazione. Le transazioni di lunga durata possono causare problemi operativi mantenendo i dati bloccati per un lungo periodo di tempo o in modo permanente, poiché la transazione non viene mai chiusa.

Per prevenire tali problemi in DynamoDB, le transazioni sono state implementate con due operazioni API distinte: e. TransactWriteItems TransactGetItems Queste API operazioni non hanno semantiche di inizio e fine comuni in un. RDBMS Inoltre, DynamoDB ha un limite di accesso di 100 elementi in una transazione per prevenire allo stesso modo transazioni di lunga durata. Per ulteriori informazioni sulle transazioni DynamoDB, consulta Utilizzo delle transazioni.

Per questi motivi, quando la tua azienda richiede una risposta a bassa latenza a query ad alto traffico, sfruttare un SQL sistema No in genere ha senso dal punto di vista tecnico ed economico. Amazon DynamoDB aiuta a risolvere i problemi che limitano la scalabilità del sistema relazionale evitandoli.

Le prestazioni di un in genere RDBMS non offrono una buona scalabilità per i seguenti motivi:

DynamoDB si ridimensiona bene per questi motivi:

Le query sull'archivio dei dati diventano molto più semplici, spesso come segue:

SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"

DynamoDB fa molto meno lavoro per restituire i dati richiesti rispetto RDBMS all'esempio precedente.