Database NewSQL

Completato

I database NoSQL si sono dimostrati piuttosto efficaci in domini molto specifici. L'uso più diffuso per i sistemi NoSQL è l'archiviazione di Big Data per aziende con scalabilità Web le cui applicazioni possono tollerare garanzie di coerenza ridotte. Questo approccio tuttavia comporta alcune sfide di archiviazione per lo sviluppatore di applicazioni. Il modello di dati non relazionali implica, ad esempio, che gli sviluppatori debbano implementare i propri join se devono combinare i dati di due tabelle. Devono inoltre gestire i dati con coerenza finale e garantire che le applicazioni non riscontrino problemi di correttezza con la mancanza di transazioni. Non tutte le applicazioni, tuttavia, possono rinunciare a questa semantica transazionale rigorosa. C'è una richiesta di sistemi di database in grado di combinare il meglio di quanto offerto dai sistemi relazionali e da quelli NoSQL. Questi sistemi funzionano usando un modello relazionale e SQL, con transazioni ACID, offrendo però prestazioni scalabili simili a quelle dei sistemi NoSQL.

I database NewSQL rappresentano la prossima generazione di sistemi DBMS relazionali che offrono scalabilità come i sistemi NoSQL, senza rinunciare completamente a SQL o a un certo livello di proprietà ACID per le transazioni. È possibile raggiungere questo risultato usando più tecniche, le più diffuse delle quali verranno illustrate di seguito:

  • Architetture senza condivisione: un modello di progettazione comune nei sistemi NewSQL è l'adozione di un'architettura senza condivisione. Si tratta di un sistema in cui ogni nodo è completamente indipendente (a volte fino al livello dei singoli thread), in modo da garantire che non ci siano singoli punti di contesa nel sistema. Ciò consente ai sistemi di ottenere prestazioni elevate su larga scala, perché non sono necessari protocolli di blocco costosi.
  • Sistemi in memoria: un altro modo per migliorare le prestazioni nei sistemi di database consiste nel ridurre il numero di viaggi effettuati su disco per una determinata query. Una versione estrema di questa filosofia consiste nel gestire un intero database dalla memoria, in modo che il database non debba mai accedere al disco.

H-Store e VoltDB

H-Store è un esempio sperimentale di sistema NewSQL progettato da un team di Brown University, Carnegie Mellon University, Massachusetts Institute of Technology e Yale University. Il sistema H-Store è distribuito in un cluster di nodi, usando un'architettura di tipo shared-nothing. Il fulcro di H-Store è un motore di database a thread singolo altamente ottimizzato che elabora rapidamente le singole query. Il database viene quindi partizionato nel cluster in modo che ogni singolo core sia responsabile di un subset non contiguo di dati. I dati in H-Store vengono archiviati nella memoria di ogni nodo del sistema.

Poiché ogni motore ha accesso esclusivo a tutti i dati in una partizione, solo una transazione alla volta può accedere ai dati archiviati nella partizione, eliminando la necessità di blocchi e latch nel sistema. Di conseguenza, nessuna transazione resterà in attesa di un'altra transazione una volta avviata, almeno per le query che non si estendono a una singola partizione.

I sistemi H-Store hanno alcuni limiti. Per prima cosa, a causa della mancanza di un'archiviazione durevole (in quanto il sistema H-Store archivia tutti i dati in memoria) e dell'architettura di tipo shared-nothing, gli errori dei nodi possono causare la perdita di dati.

Sebbene H-Store sia stato un progetto accademico, la sua realizzazione commerciale è avvenuta tramite VoltDB. VoltDB ha apportato miglioramenti e aggiunto funzionalità a H-Store per ovviare ai difetti, inclusa una modalità di registrazione per migliorare la durabilità del sistema di archiviazione.

Verificare le conoscenze

1.

Quali sono i compromessi principali nella maggior parte dei database NoSQL?

2.

Un sito Web per la creazione e la distribuzione di opere artistiche online consente agli utenti di caricare le opere e condividerle con altri utenti. Gli altri utenti possono aggiungere commenti e, se l'utente che ha effettuato il caricamento lo consente, remixare l'opera inviata dall'artista originale. Il sito Web è diventato popolare e ora sta valutando opzioni di archiviazione che consentano la scalabilità del sito Web man mano che la sua popolarità aumenta. In base alle esigenze del sito Web, quale tipo di database è più adatto per archiviare le opere degli utenti?