In che misura il modello di dati influenza la scalabilità e le prestazioni nel cosiddetto database "NoSQL"?

L'utilizzo di un database NoSQL incrementa la scalabilità anche se non si stanno analizzando i dati? Bene, consente di definire la scalabilità. Se ci si riferisce alla scalabilità come sistemi di database / back-end, in quanto si dispone di un ridimensionamento orizzontale e verticale in cui il ridimensionamento orizzontale sta dividendo i dati, allora questa diventa una domanda banale perché la risposta sarebbe assolutamente no, perché l'unica opzione che hai lasciato è il ridimensionamento verticale (cioè ottenere un hardware migliore). Se invece stai parlando di scalabilità in senso più ampio riferendosi alla flessibilità dell'applicazione, al valore dei dati, ecc ... Allora questa è una domanda completamente diversa con un numero di risposte. E come hai detto, spesso si riduce a quello che stai facendo con i dati e come dovrebbe essere memorizzato. Consentitemi di prefigurare tutto qui con la dichiarazione che nella maggior parte dei casi dovreste ancora usare un RDBMS e NoSQL dovrebbe riempire di nicchia. Di seguito è riportata una descrizione di un'istanza specifica in cui un database NoSQL sarebbe più vantaggioso in base a requisiti specifici e in cui è possibile 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 usare 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à orribilmente inefficiente in un RDBMS (nonostante sia così che tutto è indicizzato). Perché ora hai una tabella di 3 colonne con Nome, Utente e Genitore. L'utente è una chiave esterna per una tabella utenti e Parent è una chiave esterna nullable che fa riferimento a sé (nullable perché la directory radice non può avere un genitore). Quindi qual è la chiave primaria? In questo caso è una chiave composta su tutte le colonne ... Che improvvisamente rende il genitore il nostro peggior nemico.

Ora pensa invece a come lo metteresti in qualche forma di archivio di documenti? Invece di combattere i dati, è possibile lavorarci sopra e archiviarli come struttura ad albero che a sua volta ridurrà i tempi di sviluppo e ridurrà i costi di manutenzione. Se si stanno riducendo i costi non è possibile prevedere un diverso tipo di scalabilità? Inoltre in questo caso si sta creando il sistema correttamente da zero che dovrebbe dare maggiore flessibilità all'applicazione stessa. Attualmente sto lavorando su un singolo server usando MongoDB, che come hai spiegato mi dà un modello Disponibile, Consistente che non è molto diverso rispetto alla differenza di MySQL o Postgres.

Almeno con MongoDB puoi definire quanti server hai bisogno di comunicare per fare in modo che una query abbia successo, sì, puoi convertirlo in un modello coerente e disponibile se dici a tutte le query di comunicare con tutte le istanze del server.

Quindi penso che ne hai il diritto in quanto c'è un grande vantaggio nel modo in cui i dati vengono archiviati. Ci sono cose che non si adattano bene a un modello relazionale che si adatta bene ad altri modelli (come un altro breve esempio, Amazon usa una qualche forma di Graph Database 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 guardare le cose con la chiave. Colonna / famiglia: essenzialmente un archivio chiave / valore molto più strutturato. Puoi interrogare solo 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 un sacco di 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 è positivo per entrambi, ma in generale tu bisogno di scegliere l'ottimizzazione per l'uno o l'altro) Grafico: la forza di questo è che può creare e distruggere le relazioni molto velocemente. Se hai dati in cui hai relazioni che devono cambiare tra i dati (pensa qualche forma di motore di raccomandazione) dovresti usare questo.

Il modo in cui memorizzi i dati in uno qualsiasi di questi database influenzerà le prestazioni (in modo simile al fatto che se archivi dati in modo errato in alcuni RDBMS influenzerà le prestazioni). Quindi, si spera, rendi questo più chiaro: devi sapere quale sistema di database dovresti usare e come conservare i dati in quel sistema di database.