La guida definitiva ai database NoSQL

Non c'è dubbio che il modo in cui le applicazioni Web gestiscono i dati è cambiato in modo significativo negli ultimi dieci anni. Vengono raccolti più dati e più utenti accedono a questi dati contemporaneamente che mai. Ciò significa che la scalabilità e le prestazioni rappresentano una sfida più che mai per i database relazionali basati su schemi e pertanto possono essere più difficili da scalare.

L'evoluzione di NoSQL

Il problema della scalabilità SQL è stato riconosciuto dalle aziende Web 2.0 con esigenze di dati e infrastrutture enormi e in crescita, come Google, Amazon e Facebook. Hanno escogitato le proprie soluzioni al problema: tecnologie come BigTable, DynamoDB e Cassandra.

Questo crescente interesse ha portato a una serie di NoSQL Database Management Systems (DBMS), con particolare attenzione a prestazioni, affidabilità e coerenza. Un certo numero di strutture di indicizzazione esistenti sono state riutilizzate e migliorate allo scopo di migliorare le prestazioni di ricerca e lettura.

In primo luogo, c'erano tipi proprietari (closed source) di database NoSQL sviluppati da grandi aziende per soddisfare le loro esigenze specifiche, come BigTable di Google, che si ritiene sia il primo sistema NoSQL, e DynamoDB di Amazon.

Il successo di questi sistemi proprietari ha avviato lo sviluppo di una serie di sistemi di database proprietari e open source simili, i più popolari sono Hypertable, Cassandra, MongoDB, DynamoDB, HBase e Redis.

Cosa rende NoSQL diverso?

Una differenza fondamentale tra i database NoSQL ei database relazionali tradizionali è il fatto che NoSQL è una forma di archiviazione non strutturata .

Ciò significa che i database NoSQL non hanno una struttura di tabelle fissa come quelle che si trovano nei database relazionali.

Vantaggi e svantaggi dei database NoSQL

Vantaggi

I database NoSQL presentano molti vantaggi rispetto ai database relazionali tradizionali.

Una delle principali differenze di fondo è che i database NoSQL hanno una struttura semplice e flessibile. Sono privi di schemi.

A differenza dei database relazionali, i database NoSQL si basano su coppie chiave-valore.

Alcuni tipi di archivio di database NoSQL includono archivio colonne, archivio documenti, archivio valori chiave, archivio grafici, archivio oggetti, archivio XML e altre modalità di archivio dati.

Di solito, ogni valore nel database ha una chiave. Alcuni archivi di database NoSQL consentono inoltre agli sviluppatori di archiviare oggetti serializzati nel database, non solo semplici valori di stringa.

I database NoSQL open source non richiedono costi di licenza costosi e possono essere eseguiti su hardware poco costoso, rendendo la loro distribuzione conveniente.

Inoltre, quando si lavora con database NoSQL, siano essi open-source o proprietari, l'espansione è più semplice ed economica rispetto a quando si lavora con database relazionali. Questo perché viene eseguito ridimensionando orizzontalmente e distribuendo il carico su tutti i nodi, piuttosto che il tipo di ridimensionamento verticale che viene solitamente eseguito con i sistemi di database relazionali, che sostituisce l'host principale con uno più potente.

Svantaggi

Naturalmente, i database NoSQL non sono perfetti e non sono sempre la scelta giusta.

Per prima cosa, la maggior parte dei database NoSQL non supporta funzionalità di affidabilità supportate in modo nativo dai sistemi di database relazionali. Queste caratteristiche di affidabilità possono essere riassunte come atomicità, consistenza, isolamento e durabilità. Ciò significa anche che i database NoSQL, che non supportano tali funzionalità, scambiano coerenza con prestazioni e scalabilità.

Per supportare le funzionalità di affidabilità e coerenza, gli sviluppatori devono implementare il proprio codice proprietario, che aggiunge maggiore complessità al sistema.

Ciò potrebbe limitare il numero di applicazioni che possono fare affidamento sui database NoSQL per transazioni sicure e affidabili, come i sistemi bancari.

Altre forme di complessità riscontrate nella maggior parte dei database NoSQL includono l'incompatibilità con le query SQL. Ciò significa che è necessario un linguaggio di interrogazione manuale o proprietario, aggiungendo ancora più tempo e complessità.

NoSQL e database relazionali

Questa tabella fornisce un breve confronto delle funzionalità tra NoSQL e i database relazionali:

Si noti che la tabella mostra un confronto a livello di database , non i vari sistemi di gestione di database che implementano entrambi i modelli. Questi sistemi forniscono le proprie tecniche proprietarie per superare alcuni dei problemi e delle carenze in entrambi i sistemi e, in alcuni casi, migliorare significativamente le prestazioni e l'affidabilità.

Tipi di archivio dati NoSQL

Negozio di valori chiave

Nel tipo di archivio Valore chiave viene utilizzata una tabella hash in cui una chiave univoca punta a un elemento.

Le chiavi possono essere organizzate in gruppi logici di chiavi, richiedendo solo che le chiavi siano univoche all'interno del proprio gruppo. Ciò consente chiavi identiche in diversi gruppi logici. La tabella seguente mostra un esempio di un negozio chiave-valore, in cui la chiave è il nome della città e il valore è l'indirizzo dell'Ulster University in quella città.

Alcune implementazioni del key value store forniscono meccanismi di memorizzazione nella cache, che ne migliorano notevolmente le prestazioni.

Tutto ciò che serve per gestire gli elementi archiviati nel database è la chiave. I dati vengono archiviati sotto forma di stringa, JSON o BLOB (Binary Large OBject).

Uno dei maggiori difetti in questa forma di database è la mancanza di coerenza a livello di database. Questo può essere aggiunto dagli sviluppatori con il proprio codice, ma come accennato in precedenza, ciò aggiunge più impegno, complessità e tempo.

Il database NoSQL più famoso basato su un key value store è DynamoDB di Amazon.

Archivio documenti

Gli archivi documenti sono simili agli archivi valori chiave in quanto sono privi di schema e basati su un modello valore chiave. Entrambi, quindi, condividono molti degli stessi vantaggi e svantaggi. Entrambi mancano di coerenza a livello di database, il che lascia spazio alle applicazioni per fornire funzionalità di maggiore affidabilità e coerenza.

Ci sono, tuttavia, differenze fondamentali tra i due.

Negli archivi documenti, i valori (documenti) forniscono la codifica per i dati archiviati. Tali codifiche possono essere XML, JSON o BSON (JSON con codifica binaria).

Inoltre, è possibile eseguire query basate sui dati.

L'applicazione di database più popolare che si basa su un Document Store è MongoDB.

Negozio di colonne

In un database Column Store, i dati vengono archiviati in colonne, invece di essere archiviati in righe come avviene nella maggior parte dei sistemi di gestione di database relazionali.

Un archivio colonne è costituito da una o più famiglie di colonne che raggruppano logicamente determinate colonne nel database. Una chiave viene utilizzata per identificare e puntare a un numero di colonne nel database, con un attributo keyspace che definisce l'ambito di questa chiave. Ogni colonna contiene tuple di nomi e valori, ordinati e separati da virgole.

I Column Store hanno un rapido accesso in lettura/scrittura ai dati archiviati. In un archivio di colonne, le righe che corrispondono a una singola colonna vengono archiviate come una singola voce del disco. Ciò consente un accesso più rapido durante le operazioni di lettura/scrittura.

I database più popolari che utilizzano l'archivio colonne includono BigTable, HBase e Cassandra di Google.

Base del grafico

In un database NoSQL Graph Base, per rappresentare i dati viene utilizzata una struttura a grafo orientato. Il grafico è composto da archi e nodi.

Formalmente, un grafico è una rappresentazione di un insieme di oggetti, in cui alcune coppie di oggetti sono collegate da collegamenti. Gli oggetti interconnessi sono rappresentati da astrazioni matematiche, dette vertici, e i collegamenti che connettono alcune coppie di vertici sono detti spigoli. Un insieme di vertici e gli spigoli che li collegano è detto un grafo.

Questo illustra la struttura di un database di base di grafici che utilizza bordi e nodi per rappresentare e archiviare i dati. Questi nodi sono organizzati da alcune relazioni tra loro, rappresentate da bordi tra i nodi. Sia i nodi che le relazioni hanno alcune proprietà definite.

I database di grafi sono in genere utilizzati nelle applicazioni di social network. I database Graph consentono agli sviluppatori di concentrarsi maggiormente sulle relazioni tra oggetti piuttosto che sugli oggetti stessi. In questo contesto, consentono infatti un ambiente scalabile e facile da usare.

Attualmente, InfoGrid e InfiniteGraph sono i database di grafici più popolari.

Sistemi di gestione di database NoSQL

Per un breve confronto dei database, la tabella seguente fornisce un breve confronto tra diversi sistemi di gestione di database NoSQL.

MongoDB ha uno schema di archiviazione flessibile, il che significa che gli oggetti archiviati non devono necessariamente avere la stessa struttura o campi. MongoDB ha anche alcune funzionalità di ottimizzazione, che distribuiscono le raccolte di dati, con conseguente miglioramento delle prestazioni complessive e un sistema più equilibrato.

Anche altri sistemi di database NoSQL, come Apache CouchDB, sono database di tipo archivio documenti e condividono molte funzionalità con MongoDB, con l'eccezione che è possibile accedere al database utilizzando le API RESTful.

REST è uno stile architettonico costituito da un insieme coordinato di vincoli architettonici applicati a componenti, connettori ed elementi di dati, all'interno del World Wide Web. Si basa su un protocollo di comunicazione senza stato, client-server, memorizzabile nella cache (ad esempio, il protocollo HTTP).

Le applicazioni RESTful utilizzano le richieste HTTP per pubblicare, leggere dati ed eliminare dati.

Per quanto riguarda i database di base di colonne, Hypertable è un database NoSQL scritto in C++ e si basa su BigTable di Google.

Hypertable supporta la distribuzione di archivi dati tra i nodi per massimizzare la scalabilità, proprio come MongoDB e CouchDB.

Uno dei database NoSQL più utilizzati è Cassandra, sviluppato da Facebook.

Cassandra è un database di archivi di colonne che include molte funzionalità volte all'affidabilità e alla tolleranza ai guasti.

Invece di fornire uno sguardo approfondito a ciascun DBMS NoSQL, nelle prossime sottosezioni verranno esaminati Cassandra e MongoDB, due dei sistemi di gestione di database NoSQL più utilizzati.

Cassandra

Cassandra è un sistema di gestione di database sviluppato da Facebook.

L'obiettivo alla base di Cassandra era creare un DBMS che non avesse un singolo punto di errore e fornisse la massima disponibilità.

Cassandra è principalmente un database di archivio di colonne. Alcuni studi hanno indicato Cassandra come un sistema ibrido, ispirato a BigTable di Google, che è un database di archivio di colonne, e DynamoDB di Amazon, che è un database di valori-chiave.

Ciò si ottiene fornendo un sistema chiave-valore, ma le chiavi in ​​Cassandra puntano a un insieme di famiglie di colonne, facendo affidamento sul file system distribuito BigTable di Google e sulle funzionalità di disponibilità di Dynamo (tabella hash distribuita).

Cassandra è progettato per archiviare enormi quantità di dati distribuiti su diversi nodi. Cassandra è un DBMS progettato per gestire enormi quantità di dati, distribuiti su molti server, fornendo al contempo un servizio altamente disponibile senza un singolo punto di errore, essenziale per un grande servizio come Facebook.

Le caratteristiche principali di Cassandra includono:

• Nessun singolo punto di errore. Affinché ciò avvenga, Cassandra deve essere eseguita su un cluster di nodi, anziché su una singola macchina. Ciò non significa che i dati su ciascun cluster siano gli stessi, ma il software di gestione lo è. Quando si verifica un errore in uno dei nodi, i dati su quel nodo saranno inaccessibili. Tuttavia, altri nodi (e dati) saranno comunque accessibili.
• Hashing distribuito è uno schema che fornisce funzionalità di tabella hash in modo tale che l'aggiunta o la rimozione di uno slot non modifichi in modo significativo la mappatura delle chiavi sugli slot. Ciò offre la possibilità di distribuire il carico su server o nodi in base alla loro capacità e, a sua volta, ridurre al minimo i tempi di inattività.
• Interfaccia client relativamente facile da usare . Cassandra utilizza Apache Thrift per la sua interfaccia client. Apache Thrift fornisce un client RPC multilingua, ma la maggior parte degli sviluppatori preferisce alternative open source basate su Apple Thrift, come Hector.
• Altre caratteristiche di disponibilità. Una delle caratteristiche di Cassandra è la replica dei dati. Fondamentalmente, esegue il mirroring dei dati su altri nodi nel cluster. La replica può essere casuale o specifica per massimizzare la protezione dei dati posizionandola in un nodo in un data center diverso, ad esempio. Un'altra caratteristica trovata in Cassandra è la politica di partizionamento. La politica di partizionamento decide dove su quale nodo posizionare la chiave. Questo può anche essere casuale o in ordine. Quando si utilizzano entrambi i tipi di criteri di partizionamento, Cassandra può trovare un equilibrio tra il bilanciamento del carico e l'ottimizzazione delle prestazioni delle query.
• Consistenza. Funzionalità come la replica rendono difficile la coerenza. Ciò è dovuto al fatto che tutti i nodi devono essere aggiornati in qualsiasi momento con i valori più recenti o nel momento in cui viene avviata un'operazione di lettura. Alla fine, tuttavia, Cassandra cerca di mantenere un equilibrio tra le azioni di replica e le azioni di lettura/scrittura fornendo questa personalizzazione allo sviluppatore.
• Leggi/Scrivi azioni. Il client invia una richiesta a un singolo nodo Cassandra. Il nodo, in base alla politica di replica, archivia i dati nel cluster. Ogni nodo esegue prima la modifica dei dati nel log di commit, quindi aggiorna la struttura della tabella con la modifica, entrambe eseguite in modo sincrono. Anche l'operazione di lettura è molto simile, una richiesta di lettura viene inviata a un singolo nodo e quel singolo nodo è quello che determina quale nodo contiene i dati, in base alla politica di partizionamento/posizionamento.

MongoDB

MongoDB è un database orientato ai documenti privo di schemi scritto in C++. Il database è basato sull'archivio documenti, il che significa che memorizza i valori (denominati documenti) sotto forma di dati codificati.

La scelta del formato codificato in MongoDB è JSON. Questo è potente, perché anche se i dati sono nidificati all'interno di documenti JSON, saranno comunque interrogabili e indicizzabili .

Le sottosezioni che seguono descrivono alcune delle funzionalità chiave disponibili in MongoDB.

Frammenti

Lo sharding è il partizionamento e la distribuzione dei dati su più macchine (nodi). Uno shard è una raccolta di nodi MongoDB, in contrasto con Cassandra dove i nodi sono distribuiti simmetricamente. L'uso di frammenti significa anche la possibilità di scalare orizzontalmente su più nodi. Nel caso in cui sia presente un'applicazione che utilizza un singolo server di database, può essere convertita in cluster partizionato con pochissime modifiche al codice dell'applicazione originale perché il modo in cui lo sharding viene eseguito da MongoDB. oftware è quasi completamente disaccoppiato dalle API pubbliche esposte lato client.

Linguaggio di query Mongo

Come discusso in precedenza, MongoDB utilizza un'API RESTful. Per recuperare determinati documenti da una raccolta db, viene creato un documento di query contenente i campi che devono corrispondere ai documenti desiderati.

Azioni

In MongoDB c'è un gruppo di server chiamato router. Ognuno funge da server per uno o più client. Allo stesso modo, il cluster contiene un gruppo di server chiamati server di configurazione. Ognuno contiene una copia dei metadati che indica quale shard contiene quali dati. Le azioni di lettura o scrittura vengono inviate dai client a uno dei server router nel cluster e vengono automaticamente instradate da quel server agli shard appropriati che contengono i dati con l'aiuto dei server di configurazione.

Simile a Cassandra, uno shard in MongoDB ha uno schema di replica dei dati, che crea un set di repliche di ogni shard che contiene esattamente gli stessi dati. Esistono due tipi di schemi di replica in MongoDB: replica master-slave e replica set di repliche. Replica-Set fornisce maggiore automazione e una migliore gestione degli errori, mentre Master-Slave richiede talvolta l'intervento dell'amministratore. Indipendentemente dallo schema di replica, in qualsiasi momento in un set di repliche, solo uno shard funge da shard principale, tutti gli altri frammenti di replica sono shard secondari. Tutte le operazioni di scrittura e lettura vanno allo shard principale e vengono quindi distribuite uniformemente (se necessario) agli altri shard secondari nel set.

Nel grafico seguente, vediamo l'architettura MongoDB spiegata sopra, che mostra i server router in verde, i server di configurazione in blu e gli shard che contengono i nodi MongoDB.

Va notato che lo sharding (o la condivisione dei dati tra shard) in MongoDB è completamente automatico, il che riduce il tasso di errore e rende MongoDB un sistema di gestione del database altamente scalabile.

Strutture di indicizzazione per database NoSQL

L'indicizzazione è il processo di associazione di una chiave con la posizione di un record di dati corrispondente in un DBMS. Esistono molte strutture di dati di indicizzazione utilizzate nei database NoSQL. Le sezioni seguenti discuteranno brevemente alcuni dei metodi più comuni; vale a dire, indicizzazione B-Tree, indicizzazione T-Tree e indicizzazione O2-Tree.

Indicizzazione dell'albero B

B-Tree è una delle strutture di indice più comuni nei DBMS.

Negli alberi B, i nodi interni possono avere un numero variabile di nodi figli all'interno di un intervallo predefinito.

Una delle principali differenze rispetto ad altre strutture ad albero, come AVL, è che B-Tree consente ai nodi di avere un numero variabile di nodi figli, il che significa meno bilanciamento dell'albero ma più spazio sprecato.

Il B+-Tree è una delle varianti più popolari di B-Trees. Il B+-Tree è un miglioramento rispetto al B-Tree che richiede che tutte le chiavi risiedano nelle foglie.

Indicizzazione dell'albero a T

La struttura dei dati di T-Trees è stata progettata combinando le caratteristiche di AVL-Trees e B-Trees.

Gli alberi AVL sono un tipo di alberi di ricerca binari autobilanciati, mentre gli alberi B sono sbilanciati e ogni nodo può avere un numero diverso di figli.

In un T-Tree, la struttura è molto simile all'AVL-Tree e al B-Tree.

Ogni nodo memorizza più di una tupla {key-value, pointer}. Inoltre, la ricerca binaria viene utilizzata in combinazione con i nodi a tuple multiple per produrre una migliore archiviazione e prestazioni.

Un T-Tree ha tre tipi di nodi: un T-Node che ha un figlio destro e sinistro, un nodo foglia senza figli e un nodo a mezza foglia con un solo figlio.

Si ritiene che i T-Trees abbiano prestazioni complessive migliori rispetto agli AVL-Trees.

Indicizzazione dell'albero O2

L'albero O2 è fondamentalmente un miglioramento rispetto agli alberi rosso-nero, una forma di albero di ricerca binaria, in cui i nodi foglia contengono le tuple {valore chiave, puntatore}.

O2-Tree è stato proposto per migliorare le prestazioni degli attuali metodi di indicizzazione. Un albero O2 di ordine m (m ≥ 2), dove m è il grado minimo dell'albero, soddisfa le seguenti proprietà:

• Ogni nodo è rosso o nero. La radice è nera.
• Ogni nodo foglia è colorato di nero ed è costituito da un blocco o una pagina che contiene coppie "valore chiave, record-puntatore".
• Se un nodo è rosso, entrambi i suoi figli sono neri.
• Per ogni nodo interno, tutti i percorsi semplici dal nodo ai nodi foglia discendenti contengono lo stesso numero di nodi neri. Ogni nodo interno contiene un singolo valore chiave.
• I nodi foglia sono blocchi che hanno tra ⌈m/2⌉ e m coppie "valore-chiave, puntatore record".
• Se un albero ha un singolo nodo, allora deve essere una foglia, che è la radice dell'albero, e può avere da 1 a m elementi di dati chiave.
• I nodi foglia sono collegati in due direzioni in avanti e indietro.

Qui, vediamo un semplice confronto delle prestazioni tra O2-Tree, T-Tree, B+-Tree, AVL-Tree e Red-Black Tree:

L'ordine di T-Tree, B+-Tree e O2-Tree utilizzati era m = 512.

Il tempo viene registrato per le operazioni di ricerca, inserimento ed eliminazione con rapporti di aggiornamento variabili tra 0% e 100% per un indice di 50 milioni di record, con le operazioni che comportano l'aggiunta di altri 50 milioni di record all'indice.

È chiaro che con un rapporto di aggiornamento dello 0-10%, B-Tree e T-Tree si comportano meglio di O2-Tree. Tuttavia, con l'aumento del rapporto di aggiornamento, l'indice O2-Tree ha prestazioni significativamente migliori rispetto alla maggior parte delle altre strutture di dati, con le strutture B-Tree e Red-Black Tree che soffrono di più.

Il caso di NoSQL?

Una rapida introduzione ai database NoSQL, evidenziando le aree chiave in cui i database relazionali tradizionali non sono all'altezza, porta al primo asporto:

Sebbene i database relazionali offrano coerenza, non sono ottimizzati per prestazioni elevate in applicazioni in cui vengono archiviati ed elaborati frequentemente dati di grandi dimensioni.

I database NoSQL hanno guadagnato molta popolarità grazie alle prestazioni elevate, all'elevata scalabilità e alla facilità di accesso; tuttavia, mancano ancora di funzionalità che forniscano coerenza e affidabilità.

Fortunatamente, numerosi DBMS NoSQL affrontano queste sfide offrendo nuove funzionalità per migliorare la scalabilità e l'affidabilità.

Non tutti i sistemi di database NoSQL funzionano meglio dei database relazionali.

MongoDB e Cassandra hanno prestazioni simili, e nella maggior parte dei casi migliori, rispetto ai database relazionali nelle operazioni di scrittura ed eliminazione.

Non esiste una correlazione diretta tra il tipo di archivio e le prestazioni di un DBMS NoSQL. Le implementazioni NoSQL subiscono modifiche, quindi le prestazioni possono variare.

Pertanto, le misurazioni delle prestazioni tra tipi di database in diversi studi dovrebbero essere sempre aggiornate con le ultime versioni del software di database affinché quei numeri siano accurati.

Anche se non posso offrire un verdetto definitivo sulle prestazioni, ecco alcuni punti da tenere a mente:

• L'indicizzazione tradizionale B-Tree e T-Tree è comunemente usata nei database tradizionali.
• Uno studio ha offerto miglioramenti e miglioramenti combinando le caratteristiche di più strutture di indicizzazione per creare l'O2-Tree.
• L'O2-Tree ha superato le altre strutture nella maggior parte dei test, specialmente con enormi set di dati e rapporti di aggiornamento elevati.
• La struttura B-Tree ha fornito le prestazioni peggiori di tutte le strutture di indicizzazione trattate in questo articolo.

Ulteriore lavoro può e deve essere fatto per migliorare la coerenza dei DBMS NoSQL. L'integrazione di entrambi i sistemi, NoSQL e database relazionali, è un'area da esplorare ulteriormente.

Infine, è importante notare che NoSQL è una buona aggiunta agli standard di database esistenti, ma con alcune importanti avvertenze. NoSQL scambia le funzionalità di affidabilità e coerenza con prestazioni e scalabilità allo stato puro. Ciò la rende una soluzione specializzata, poiché il numero di applicazioni che possono fare affidamento sui database NoSQL rimane limitato.

Il vantaggio? La specializzazione potrebbe non offrire molto in termini di flessibilità, ma quando vuoi svolgere un lavoro specializzato nel modo più rapido ed efficiente possibile, non hai bisogno di un coltellino svizzero. Hai bisogno di NoSQL.