Qual è la differenza tra database NoSQL e database relazionali?
Azure Cosmos DB è caratterizzato come non relazionale e scalabile orizzontalmente.
Scalabilità orizzontale e scalabilità verticale
I database relazionali in genere crescono se aumentano le dimensioni della macchina virtuale o del calcolo in cui sono ospitati. I database NoSQL come Azure Cosmos DB vengono ridimensionati aggiungendo altri server o nodi. Questa operazione è nota come scale-out. In Cosmos DB questi nodi sono chiamati anche partizioni fisiche. I dati archiviati in queste partizioni fisiche devono essere organizzati in modo che sia possibile accedervi in modo efficiente in un secondo momento.
I dati vengono indirizzati a partizioni fisiche diverse usando il valore di una proprietà richiesta per ogni documento. Questa proprietà è denominata chiave di partizione di un contenitore. Questa chiave di partizione deve essere specificata quando si crea il contenitore. Il passaggio della chiave di partizione quando i dati vengono scritti o letti da un contenitore garantisce che le operazioni siano efficienti indirizzando solo la richiesta alla partizione in cui è archiviata.
Anche se la necessità di una chiave di partizione può sembrare vincolante, presenta alcuni vantaggi enormi. In genere, i database relazionali possono crescere fino a un massimo di 100 TB. Un database NoSQL può crescere illimitatamente e senza alcun impatto sui tempi di risposta quando accede ai dati da una singola partizione.
Inoltre, man mano che si aggiungono partizioni, si aggiunge anche più potenza di calcolo e la quantità di elaborazione supportata dal database cresce simultaneamente. Ciò significa che può supportare anche più utenti simultanei. Inoltre, senza alcun impatto sulle prestazioni.
Database relazionali e non relazionali
La seconda caratteristica che definisce un database NoSQL è che non sono presenti chiavi esterne, vincoli o relazioni attivate di qualsiasi tipo tra le parti di dati. Poiché i dati in un database NoSQL vengono archiviati in server fisici diversi, l'applicazione di vincoli o relazioni oppure l'inserimento di blocchi sui dati comporterà prestazioni negative o imprevedibili.
Tuttavia, il fatto di non avere relazioni applicate non significa che non si possano gestire entità che hanno relazioni in un database NoSQL, ma solo che bisogna farlo in modo diverso.
Perché questi tipi di database sono così diversi?
Comprendere il modo in cui gli aspetti economici dell'elaborazione sono cambiati dopo l'introduzione dei database relazionali può aiutare a spiegare perché questi due tipi di database sono così diversi.
Quando nel 1970 sono stati inventati i database relazionali, il costo dell'archiviazione e della memoria rispetto al calcolo era elevato. L'obiettivo della normalizzazione di un modello di database era ridurre i dati duplicati e di conseguenza i costi all'interno di un database. Il motore di database applicava blocchi e latch per imporre una rigorosa semantica ACID (atomicità, coerenza, isolamento, durabilità) mentre eseguiva operazioni su tutti i dati necessari insieme. I blocchi sui dati garantivano dati coerenti, ma a scapito di concorrenza, latenza e disponibilità.
Oggi, il costo dell'archiviazione e della memoria è relativamente basso rispetto a quello del calcolo e quindi, perché siano convenienti, non è più necessario ottimizzare l'efficienza dell'archiviazione. Con carichi di lavoro che richiedono livelli crescenti di concorrenza e disponibilità e latenze più basse, era necessario un nuovo tipo di database ottimizzato per questi requisiti e quindi sono nati i database NoSQL.
È anche per questi motivi che uno degli obiettivi della modellazione dei dati per un database NoSQL è quello di farlo in modo da garantire che la lettura o la scrittura dei dati sia efficiente in termini di calcolo. In parte perché gli operatori relazionali, come i join tra documenti, non esistono nei database NoSQL, i dati devono essere archiviati così come vengono usati dall'applicazione perché siano più efficienti. Spesso i dati devono essere denormalizzati, duplicati o altrimenti archiviati in modo da infrangere molte delle regole di normalizzazione relazionale usate per la modellazione dei dati relazionali.
È possibile usare NoSQL per i carichi di lavoro relazionali?
A questo punto, ci si potrebbe chiedere se i database NoSQL sono appropriati per l'uso con i carichi di lavoro relazionali. E la risposta è sì. I database NoSQL possono assolutamente essere usati per i carichi di lavoro in cui esistono relazioni tra entità diverse.
I database NoSQL vengono spesso usati quando un database relazionale non riesce a soddisfare le esigenze in termini di disponibilità, scalabilità o prestazioni desiderate dell'applicazione.
Le tecniche per la progettazione di un database NoSQL sono diverse dalle tecniche per la modellazione dei dati per un database relazionale. Inoltre queste tecniche non sono intuitive per chi ha un background di progettazione di database relazionali. Alcune delle procedure consigliate apprese per la creazione di database relazionali sono spesso antipattern durante la progettazione di un database NoSQL.
Per il resto di questo modulo e nel modulo sulla modellazione avanzata, verranno illustrate in dettaglio le tecniche usate per modellare i dati in modo da ottenere un database NoSQL ad alte prestazioni.