A quale dimensione dei dati diventa utile passare da SQL a NoSQL?

Quanto sono grandi i dati?

Ci sono due soglie significative:

1. interi dati si inseriscono nella RAM
2. i dati dell'indice intero si adattano alla RAM

Con gli SSD veloci, la prima soglia è diventata un po 'meno problematica, a meno che tu non abbia un traffico intenso.

acidità

Uno dei problemi con il ridimensionamento degli RDBMS è che, in base alla progettazione, sono ACID, ovvero transazioni e blocchi a livello di riga (o persino livello di tabella in alcuni RDBMS più vecchi / più semplici). Può essere un fattore limitante se hai molte query che modificano molti dati in esecuzione contemporaneamente. Le soluzioni NoSQL solitamente utilizzano il modello consistenza finale .

In che modo RDBMS scala in base alla dimensione dei dati?

Non è del tutto vero che RDBMS non può scalare le dimensioni dei dati, ci sono due alternative: partizionamento verticale e orizzontale partizionamento (aka sharding).

Il partizionamento verticale è fondamentalmente mantenendo tabelle non correlate su server DB separati, mantenendo così le dimensioni di ciascuno al di sotto delle soglie sopra menzionate. Ciò rende possibile unire queste tabelle utilizzando SQL semplice, meno diretto e meno efficiente.

Sharding significa distribuire i dati da una tabella tra vari server, in base a una chiave specifica. Ciò significa che per le ricerche sai quale server interrogare in base a quella chiave. Tuttavia, questo complica le query che non sono lookup sulla chiave di sharding.

In caso di entrambi i tipi di partizionamento, se si va agli estremi, si finisce fondamentalmente con la stessa situazione dei database NoSQL.

Non penso che la dimensione dei dati sia l'unico fattore. Anche il "modello dei dati" è una parte molto importante.

Le pagine del catalogo E-Commerce (Solr, ElasticSearch), i dati di analisi web (Riak, Cassandra), i prezzi delle azioni (Redis), le connessioni di relazioni nei Social Network (Neo4J, FleetDB) sono solo alcuni esempi quando una soluzione NoSQL brilla davvero.

IMHO, il modello di dati ha un ruolo più importante della dimensione dei dati quando si considera una soluzione NoSQL o RDBMS.

Se i database relazionali non vengono ridimensionati, non esiste nulla. Non preoccuparti dei problemi di ridimensionamento.

SQL ha problemi con alcuni tipi di analisi, ma non ci vogliono molti dati per innescare il problema. Ad esempio, considera una singola tabella con una colonna che faccia riferimento ad altre righe in base a una chiave univoca. In genere, questo potrebbe essere usato per creare una struttura ad albero. È possibile scrivere istruzioni SQL veloci che fanno riferimento alla riga correlata. O la riga relativa della riga correlata. In effetti puoi fare qualsiasi numero specifico di salti. Ma se, per ogni riga, vuoi selezionare un campo sulla prima riga correlata della catena che soddisfa qualche criterio, allora diventa complicato.

Considera una tabella delle posizioni degli uffici a livello di nazione, provincia / stato, contea, città e villaggio, con ogni ufficio che fa riferimento all'ufficio a cui riferisce. C'è no garanzia che l'ufficio di reporting di ogni ufficio è solo a un livello. Per un gruppo selezionato di uffici, non tutti su un livello, si desidera elencare l'ufficio nazionale associato di ciascuno. Ciò richiede cicli di istruzioni SQL e richiederà molto tempo anche oggi. (Avevo 30 secondi su una selezione di 30 uffici, ma quello era un lungo tempo fa - e il passaggio alle stored procedure mi aiutava un po '.)

Quindi l'alternativa è mettere l'intera struttura in un unico grande blocco di dati, etichettarlo e memorizzarlo. Quando si desidera analizzare i dati, leggerli tutti in memoria in una volta sola, impostare i puntatori per tracciare la struttura e elaborare un paio di milioni di uffici in un batter d'occhio.

Nessuno di questi ha molto a che fare con la quantità di dati. La chiave è la natura dell'organizzazione dei dati. Se un layout relazionale aiuta, allora un RDBMS è ciò che desideri. In caso contrario, una sorta di archiviazione di massa sarà di qualche cosa da leggermente a un quadrilione volte più veloce.

Si noti che se uno di questi insiemi di dati diventa troppo grande per adattarsi alla memoria, il database non SQL non funziona più. Un altro problema è quando hai bisogno di dati da più di un blocco alla volta; puoi fare questo if e solo se, tutti i blocchi si adattano subito alla memoria. E l'utente deve aspettare mentre li carichi.

Se il tuo database relazionale causerà problemi, lo farà prima di inserire molti dati in esso. L'unico problema di ridimensionamento che potresti avere è con il tuo programma quando il blocco di dati che stai assemblando per un DB nosql - se devi usarne uno - diventa troppo grande per questo. (Leggi gli errori di memoria esaurita. I linguaggi più recenti a volte fanno cose strane con la memoria.)

Penso che la prima ragione per passare a una soluzione NoSQL o Distributed non sia tanto la dimensione di tutti i dati, quanto la dimensione delle tabelle. Le soluzioni distribuite funzionano bene dividendo le tabelle in nodi diversi, quindi quando hai bisogno di interrogare le tabelle, ogni nodo elaborerà il loro pezzo di tabella.

Gli RDBMS possono farlo, ma la nuova ondata di database NoSQL è stata creata per fare ciò. Oracle, MSSQL, MySQL hanno preso il loro modello centralizzato e l'hanno ottimizzato per farlo funzionare in un ambiente distribuito. Tuttavia, continuano ad attenersi alle rigide regole ACID mentre alcuni dei nuovi database non rispettano le rigide regole, ad esempio utilizzando la coerenza finale.

Non esiste una quantità prestabilita di dati in cui dovresti scegliere l'una rispetto all'altra. Ciò che deve essere preso in considerazione sono le esigenze del database e la quantità di utilizzo che riceve. I database NoSQL possono elaborare più rapidamente set di dati più grandi mentre i database relazionali ti danno la certezza che i tuoi dati siano corretti con i principi ACID.

Potrebbe anche essere utile menzionare che il tuo modello di dati ha una grande influenza sulle cose. Se ti ritrovi a dover creare una qualche forma di struttura ad albero (ad esempio, hai una chiave esterna autoreferenziale su una tabella che contiene detta chiave esterna in una chiave primaria composta) dovresti probabilmente cercare di farlo in qualche forma di database che gestisce quelli tipi di dati veramente buoni (come mongodb o couchdb).

Come altre persone hanno detto che dovresti anche prendere in considerazione ciò che sta accadendo nella tua applicazione. se hai davvero bisogno di ACID su più tavoli, allora hai davvero bisogno di attenersi a un RDBMS, ma se hai qualcosa in cui puoi avere alcuni dati leggermente obsoleti e hai bisogno della flessibilità di uno schema NoSQL (chiamalo schemaless se vuoi, ma ha ancora qualche forma di schema implicito) quindi potresti prendere in considerazione l'acquisizione di un negozio NoSQL ( link ecco un esempio del perché craigslist è cambiato oltre ... ma ammettiamo che archiviano circa 10 TB di dati, che so non si adattano affatto alle dimensioni del database di piccole e medie dimensioni, ma il caso d'uso potrebbe essere utile).

Tieni presente che i sistemi NoSQL non sono necessariamente lì per sostituire RDMS, ma in molti casi puoi integrare il tuo RDBMS con l'idea di Polyglot Persistence e puoi memorizzare la maggior parte dei tuoi dati in un RDBMS ma in specifiche istanze di nicchia che puoi scaricare alcuni dei tuoi dati in qualche forma di archivio NoSQL.

Mongo può essere installato su un numero di computer / nodi. PostgreSQL non fornisce lo strumento integrato per il sharding, tuttavia citus è disponibile.

MongoDB supporta database fino a 64 terabyte e la dimensione del documento è di 16 megabyte.

MySQL ha un limite di database di 256 terabyte, 64 terabyte la dimensione massima per una tabella e il limite di registrazione di 4 gigabyte

PostgreSQL non ha limiti sul database (4 terabyte esiste da qualche parte per il test) e ha un limite di 1 gigabyte per le dimensioni di qualsiasi campo in una tabella e ancora 64 terabyte la dimensione massima per un tavolo.