Quanto influisce il modello di dati sulla scalabilità e le prestazioni nel cosiddetto database "NoSQL"?

Non si può mai parlare del cosiddetto database "NoSQL" senza portare il teorema CAP (Coerenza, Disponibilità, Partizione: sceglierne due). Se devi scegliere, diciamo, tra MongoDB (Partizione, Coerenza) e CouchDB (Disponibilità, Partizione), il primo che devi pensare è "Ho bisogno di dati corretti o ho bisogno di accedere tutto il tempo?".

Questi nuovi database sono stati creati per essere partizionati. Ma cosa succede se non lo faccio ? Cosa succede se penso che sia abbastanza bello avere una chiave / valore, colonna, documento, qualunque database invece di uno relazionale, e creare solo un'istanza del server e non condividerla mai? In tal caso, non avrei disponibilità e coerenza? MongoDB non avrebbe bisogno di replicare nulla, quindi sarebbe disponibile. E CouchDB avrebbe solo una fonte di dati, quindi sarebbe abbastanza coerente.

Quindi ciò significherebbe che, in tal caso, MongoDB e CouchDB avrebbero poca differenza nel caso di utilizzo? Bene, tranne ovviamente le prestazioni, API e altri, ma sarebbe più come scegliere tra PostgreSQL e MySQL che avere due serie di requisiti fondamentalmente diversi.

Sono qui? Posso cambiare un database AP o CP in uno AC non creando più di un'istanza? O c'è qualcosa che mi manca?

Facciamo la domanda al contrario. Cosa succede se prendo un database relazionale, diciamo MySQL e lo metto in una configurazione master / slave. Non utilizzo transazioni ACID Se richiedo che qualsiasi scrittura sia sincronizzata immediatamente con lo slave, non lo trasformerei in un database CP? E se lo sincronizzassi ad intervalli predefiniti, e non importa se un client legge dati non aggiornati da uno slave. Non lo renderebbe un database AP? Ciò non significherebbe che se rinuncio alla conformità ACID posso ancora utilizzare il modello relazionale per un database con partizionamento?

In sostanza: la scalabilità di ciò a cui sei pronto a rinunciare nel teorema CAP, più del modello di dati sottostante? Avere colonna, documento, valore chiave, qualunque cosa dia una spinta alla scalabilità rispetto a un modello relazionale? Potremmo progettare un database relazionale progettato da zero per la tolleranza della partizione? (Forse esiste già). Potremmo rendere ACID conforme al database NoSQL?

Siamo spiacenti, è un sacco di domande, ma ho letto molto sul database NoSQL di recente e mi sembra che il più grande vantaggio di usarli è che si adattano meglio alla "forma" dei tuoi dati, piuttosto che alla semplice partizione, CAP e rinunciare alla conformità ACID. Dopotutto, non tutti hanno così tanti dati che devono essere partizionati. C'è un vantaggio in termini di prestazioni / scalabilità nel non utilizzare il modello relazionale prima ancora di pensare al partizionamento dei miei dati?

L'uso di un database NoSQL migliora la scalabilità anche se non si condividono dati? Bene, definiamo la scalabilità. Se ti riferisci alla scalabilità per quanto riguarda i sistemi di database / backend, in quanto hai un ridimensionamento verticale e orizzontale in cui il ridimensionamento orizzontale È la condivisione dei dati, allora questa diventa una domanda banale perché la risposta sarebbe assolutamente no, perché l'unica opzione che ti è rimasta è il ridimensionamento verticale (ovvero ottenere un hardware migliore). Se tuttavia si sta parlando di scalabilità in senso lato riferendosi alla flessibilità dell'applicazione, al valore dei dati, ecc ... Quindi questa è una domanda completamente diversa con un numero di risposte. E come hai già detto, spesso dipenderà da cosa stai facendo con i dati e come dovrebbero essere archiviati. Permettetemi di prefigurare tutto qui con l'affermazione che nella maggior parte dei casi dovreste ancora usare un RDBMS e NoSQL dovrebbe riempire quello di nicchia. La seguente è una descrizione di un'istanza specifica in cui un database NoSQL sarebbe più vantaggioso dati requisiti specifici e dove possiamo ignorare il ridimensionamento orizzontale.

Prendi ad esempio l'idea che stai creando un sistema di archiviazione di file cloud simile a google drive, dropbox o box ma invece di utilizzare un vero file system decidi che sarebbe più vantaggioso per te virtualizzare il file system. Ora hai un problema perché il tuo modello di dati è improvvisamente la struttura ad albero che sarà terribilmente inefficiente in un RDBMS (nonostante sia così che tutto viene indicizzato). Perché ora hai una tabella a 3 colonne con Nome, Utente e Padre. L'utente è una chiave esterna per una tabella di utenti e Parent è una chiave esterna nullable autoreferenziale (nullable perché la directory principale non può avere un parent). Quindi qual è la chiave primaria? In questo caso è una chiave composta su tutte le colonne ... Il che rende improvvisamente Parent il nostro peggior nemico.

Ora invece pensi a come lo inseriresti in una qualche forma di archivio documenti? Invece di combattere i dati, è possibile lavorare con essi e archiviarli come struttura ad albero, che a sua volta diminuirà i tempi di sviluppo e diminuirà i costi di manutenzione. Se stai riducendo i costi, ciò non consente un diverso tipo di scalabilità? Inoltre, in questo caso, stai creando il sistema correttamente da zero, il che dovrebbe dare maggiore flessibilità all'applicazione stessa. Attualmente sto eseguendo questo su un singolo server usando MongoDB, che come mi hai spiegato mi dà un modello disponibile, coerente che non è molto diverso dal guardare la differenza di MySQL o Postgres.

Almeno con MongoDB è possibile definire il numero di server con cui è necessario comunicare affinché una query abbia esito positivo, quindi sì, è possibile convertirla in un modello coerente e disponibile se si comunica a tutte le query di comunicare con tutte le istanze del server.

Quindi penso che tu ne abbia il diritto in quanto vi è un grande vantaggio nel modo in cui i dati vengono archiviati. Ci sono cose che non si adattano bene in un modello relazionale che si adattano bene ad altri modelli (come un altro breve esempio, Amazon utilizza una qualche forma di Database Graph per il loro motore di raccomandazione per i prodotti).

Ho capito correttamente la tua domanda?

Modifica: più dati rallenteranno le cose? Sì. Quanto rallenterà le cose? Onestamente non ho abbastanza esperienza per dare una risposta adeguata. Chiave / Valore: essenzialmente una tabella di ricerca con grandi quantità di dati associati alla chiave di ricerca. Questo sarà davvero molto veloce perché puoi solo cercare le cose con la chiave. Colonna / Famiglia: essenzialmente un archivio chiave / valore molto più strutturato. Puoi solo eseguire query in base alla colonna e quindi anche questo dovrebbe essere molto veloce. Documento: schema di stile di aggregazione. Qui vorrai aggregare dati simili insieme. La denormalizzazione è ok e prevista per questo tipo di database. A seconda che tu stia facendo molte scritture o letture puoi organizzare i tuoi dati in modo che vengano distribuiti su più frammenti per distribuire le scritture o le letture (nota che puoi creare un approccio ibrido che sia buono per entrambi ma generalmente tu è necessario scegliere l'ottimizzazione per l'uno o l'altro) Grafico: il punto di forza di questo è che può creare e abbattere relazioni molto rapidamente. Se hai alcuni dati in cui hai relazioni che devono cambiare tra i dati (pensa a una qualche forma di motore di raccomandazione), dovresti usare questo.

Il modo in cui archiviate i dati in uno di questi database influenzerà le prestazioni (analogamente al fatto che se archiviate i dati in modo errato in alcuni RDBMS, ciò influenzerà le prestazioni). Quindi, si spera, per renderlo più chiaro: è necessario sapere quale sistema di database è necessario utilizzare e come archiviare i dati in quel sistema di database.