Caratteristiche comuni di NoSQL - dummies

I libri e i blog NoSQL offrono opinioni diverse su cosa sia un database NoSQL. Le quattro funzioni principali di NoSQL, riportate nell'elenco seguente, si applicano alla maggior parte dei database NoSQL. L'elenco confronta NoSQL con il DBMS relazionale tradizionale:

• Agnostico dello schema: Uno schema di database è la descrizione di tutti i possibili dati e strutture di dati in un database relazionale. Con un database NoSQL, non è richiesto uno schema, offrendoti la libertà di archiviare le informazioni senza eseguire la progettazione dello schema iniziale.

• Non correlato: Le relazioni in un database stabiliscono connessioni tra tabelle di dati. Ad esempio, un elenco di dettagli della transazione può essere collegato a un elenco separato di dettagli di consegna. Con un database NoSQL, queste informazioni vengono archiviate come un aggregato - un singolo record con tutto ciò che riguarda la transazione, incluso l'indirizzo di consegna.

• Hardware delle merci: Alcuni database sono progettati per funzionare al meglio (o solo) con hardware di archiviazione e elaborazione specializzati. Con un database NoSQL, è possibile utilizzare server off-the-shelf economici. L'aggiunta di più di questi server economici consente ai database NoSQL di scalare per gestire più dati.

• Altamente distribuibile: I database distribuiti possono memorizzare ed elaborare una serie di informazioni su più di un dispositivo. Con un database NoSQL, è possibile utilizzare un cluster di server per contenere un singolo database di grandi dimensioni.

Schema agnostic

I database NoSQL sono indipendenti dallo schema. Non è necessario eseguire molto lavoro di progettazione iniziale prima di poter archiviare i dati nei database NoSQL. È possibile avviare la codifica e archiviare e recuperare i dati senza sapere come il database memorizza e lavora internamente. (Se e quando hai bisogno di funzionalità avanzate, puoi aggiungere manualmente ulteriori indici o modificare strutture di archiviazione dei dati.) L'agnosticismo dello schema può essere la differenza più significativa tra NoSQL e database relazionali.

Il grande vantaggio di un database agnostico dello schema è che i tempi di sviluppo si riducono. Questo vantaggio aumenta man mano che si passano più versioni di sviluppo e occorre modificare le strutture di dati interne nel database.

Ad esempio, in un RDBMS tradizionale, si passa attraverso un processo di riprogettazione dello schema. Lo schema istruisce il database su quali dati aspettarsi. Modificare i dati memorizzati o le strutture ed è necessario reinstruct il database utilizzando uno schema modificato. Se dovessi apportare una modifica, dovresti dedicare molto tempo a decidere come ri-progettare i dati esistenti. Nei database NoSQL, è sufficiente memorizzare una diversa struttura di dati. Non è necessario comunicare preventivamente al database.

Potrebbe essere necessario modificare le query di conseguenza, magari aggiungere l'indice specifico occasionale (come un indice dell'intervallo intero per consentire meno e più delle query specifiche di tipo dati), ma l'intero processo è molto meno doloroso di un RDBMS.

RDBMS è decollato per la sua flessibilità e perché, utilizzando SQL, ha velocizzato la modifica di una query. I database NoSQL offrono questa flessibilità per modificare sia lo schema che la query, che è uno dei motivi principali per cui saranno sempre più adottati nel tempo.

Anche in caso di query, potrebbe non essere necessario preoccuparsi troppo di conoscere le modifiche dello schema: prendere in considerazione un indice su un numero di account di campo, dove numero di conto può essere posizionato ovunque in un documento archiviato in un database NoSQL. È possibile modificare la struttura e spostare dove numero di conto è memorizzato, e se l'elemento ha lo stesso nome altrove nel documento, è ancora disponibile per la query senza modifiche al meccanismo di query.

Si noti che non tutti i database NoSQL sono completamente indipendenti dallo schema. Alcuni, come HBase, richiedono di interrompere il database per modificare le definizioni delle colonne. Sono ancora considerati database NoSQL perché non tutti i campi definiti (in questo caso le colonne) devono essere conosciuti in anticipo per ogni record, solo le famiglie di colonne.

RDBMS consente di identificare singoli campi nei record come valori null . Il problema con un RDBMS è che le dimensioni e le prestazioni dei dati memorizzati sono influenzate negativamente quando la memoria è riservata ai valori nulli, nel caso in cui il record possa avere in futuro un valore in quella colonna. In Cassandra, semplicemente non fornite i dati di quella colonna, il che risolve il problema.

I sistemi di gestione dei database relazionali non relazionali

sono stati il ​​modo dominante per archiviare i dati delle applicazioni per oltre 20 anni. Una grande quantità di lavoro matematico è stato fatto per dimostrare la teoria che li sta alla base.

Questa sottostruttura descrive come le tabelle si correlano tra loro. Una singola riga ordine può riguardare molte righe Indirizzo di consegna, ma ogni riga Indirizzo consegna si riferisce anche a più righe ordine. Questo è un molti - a - molti rapporti .

I database NoSQL non hanno questo concetto di relazioni tra i loro record. Invece denormalizzano i dati. Ciò significa che in un database NoSQL avrebbe una struttura di ordine con l'indirizzo di consegna incorporato. Ciò significa che l'indirizzo di consegna è duplicato in ogni riga di ordine che lo utilizza. Questo approccio ha il vantaggio di non richiedere complessi join di tempo di query su più strutture di dati (tabelle).

I database NoSQL non memorizzano informazioni su come i singoli record si riferiscono ad altri record nel database, il che può sembrare una limitazione. Tuttavia, i database NoSQL sono più flessibili in termini di strutture di dati che è possibile archiviare.

Considera un ordine da un rivenditore online. L'ordine potrebbe includere codici di prodotto, quantità, prezzi degli articoli e descrizioni degli articoli, nonché informazioni sull'ordinazione della persona, come l'indirizzo di consegna e le informazioni di pagamento.

Invece di inserire dieci righe in una varietà di tabelle in un database relazionale, è possibile invece memorizzare una singola struttura per tutte le informazioni di questo ordine, ad esempio come documento JSON o XML.

Nella teoria dei database relazionali, l'obiettivo è normalizzare i dati (ovvero, organizzare i campi e le tabelle per rimuovere i dati duplicati). Nei database NoSQL, in particolare i database Documento o Aggregazione, spesso si denormalizzano i dati, memorizzando alcuni dati più volte.

È possibile memorizzare, ad esempio, "Indirizzo di consegna del cliente" più volte su molti ordini effettuati da un cliente nel corso del tempo, anziché archiviarlo una sola volta e fare riferimento ad esso in più ordini. Ciò richiede spazio di archiviazione aggiuntivo e un po 'di accortezza nella gestione dell'applicazione. Allora perché farlo?

Esistono due vantaggi per l'archiviazione dei dati più volte:

• Archiviazione e recupero semplici: Basta salvare e ottenere un singolo record.

• Velocità della query: Nei database relazionali, si uniscono le informazioni e si aggiungono i vincoli tra le tabelle al momento della query. Ciò potrebbe richiedere al motore del database di valutare molte tabelle. Maggiore è il vincolo di query tra più tabelle, più si riduce la velocità della query. (Questo è il motivo per cui un RDBMS ha viste precalcolate.) In un database NoSQL, tutte le informazioni necessarie per valutare la query sono contenute in un singolo documento. Pertanto, è possibile determinare rapidamente l'elenco di documenti corrispondenti.

Le viste relazionali e le denormalizzazioni NoSQL sono approcci diversi al problema della diffusione dei dati tra i record. In NoSQL, potrebbe essere necessario mantenere più denormalizzazioni che rappresentano viste differenti degli stessi dati. Questo approccio aumenta il costo dello storage ma ti offre tempi di interrogazione molto migliori.

Dato il costo sempre più ridotto dello storage e la maggiore velocità di sviluppo e query, i dati denormalizzati (ovvero visualizzazioni materializzate ) non sono un motivo killer per scontare soluzioni NoSQL. È solo un modo diverso di affrontare lo stesso problema, con i suoi vantaggi e svantaggi.

NoSQL è altamente distribuibile e utilizza hardware commodity

In molti database NoSQL, una decisione progettuale chiave è quella di utilizzare più computer per memorizzare i dati per un singolo database, anziché avere l'intero database su un singolo server.

È difficile memorizzare i dati su più macchine e consentirne l'interrogazione. È necessario inviare la query a tutti i server e attendere una risposta. Si spera che si configurino le macchine in modo che siano abbastanza veloci da comunicare tra loro per gestire le query distribuite!

Il vantaggio principale di questo approccio è nel caso di dataset di grandi dimensioni, perché per alcuni requisiti di archiviazione, anche il più grande singolo server disponibile non può archiviare o elaborare tutti i dati necessari. Prendi in considerazione tutti i messaggi su Twitter e Facebook. Hai bisogno di un meccanismo distribuito per gestire in modo efficace tutti quei dati, anche se si tratta principalmente di ciò che le persone hanno per colazione e simpatici video di gatti.

Un vantaggio della distribuzione del database è che è possibile utilizzare server più economici, denominati server commodity .Anche per i set di dati più piccoli, potrebbe essere più economico acquistare tre server commodity anziché un singolo server con più potenza.

Un altro vantaggio chiave è che l'aggiunta di alta disponibilità è più semplice; sei già a metà strada distribuendo i tuoi dati. Se si replicano i propri dati una o due volte su altri server nel cluster, i dati saranno ancora accessibili, anche se uno dei server si arresta in modo anomalo, brucia e muore.

Non tutti i database open source supportano l'alta disponibilità a meno che non si acquisti la versione supportata e pagata del database dalla società che lo sviluppa.

Un'eccezione alla regola altamente distribuibile è quella dei database di grafici. Per rispondere efficacemente a determinate query di grafici in modo tempestivo, i dati devono essere archiviati su un singolo server. Nessuno ha ancora risolto questo particolare problema.

Valuta attentamente se hai bisogno di un negozio triplo o di un negozio di grafici. I negozi tripli sono generalmente distribuibili, mentre i negozi di grafici no. Quale è necessario dipende dalle query che è necessario supportare.