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


24

Come programmatore di database relazionali (la maggior parte delle volte), ho letto articoli su come i database relazionali non si ridimensionano e soluzioni NoSQL come MongoDB. Poiché la maggior parte dei database che ho sviluppato finora sono stati di dimensioni medio-piccole, non ho mai avuto problemi che non sono stati risolti da indicizzazione, ottimizzazione delle query o riprogettazione degli schemi.

Con che tipo di dimensioni mi aspetto di vedere MySQL alle prese con. Quante file?

(So ​​che dipenderà dall'applicazione e dal tipo di dati archiviati. Quello che mi ha fatto fare era sostanzialmente un database di genetica, quindi avrebbe una tabella principale, con 3 o 4 tabelle di ricerca. La tabella principale conterrà tra altre cose, un riferimento cromosomico e una coordinata di posizione. Probabilmente verrà interrogato per un numero di voci tra due pozioni su un cromosoma, per vedere cosa è memorizzato lì).


4
Probabilmente non dovresti lavorare supponendo che MySQL sia il limite superiore per il numero di righe che un database relazionale può gestire. Stai davvero ponendo due domande: quando MySQL esaurisce la stringa? e Quali sono i limiti della capacità di RDBMS SQL? A quale vuoi rispondere?
Blrfl,

Risposte:


13

Quanto sono grandi i dati?

Esistono due soglie significative:

  1. interi dati si adattano alla RAM
  2. tutti i dati dell'indice si adattano alla RAM

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

Acidità

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

In che modo RDBMS si adatta alle dimensioni dei dati?

Non è del tutto vero che RDBMS non può ridimensionare sulla dimensione dei dati, ci sono due alternative: il partizionamento verticale e il partizionamento orizzontale (aka sharding).

Il partizionamento verticale mantiene sostanzialmente tabelle non correlate su server DB separati, mantenendo così le dimensioni di ciascuna al di sotto delle soglie sopra menzionate. Questo rende unire queste tabelle usando il semplice SQL meno semplice e meno efficiente.

Frammentazione significa distribuire dati da una tabella tra vari server, in base a chiave specifica. Ciò significa che per le ricerche si conosce quale server interrogare in base a quella chiave. Tuttavia, ciò complica le query che non vengono cercate nella chiave di sharding.

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


9
Oracle, PostgreSQL, MySQL, MS SQL Server e Sybase sono tutti in grado di eseguire join su tabelle su server remoti senza che il client debba eseguire alcuna operazione.
Blrfl,

4
A proposito di "dati interi nella RAM", tieni presente che si tratta del set di lavoro effettivo. Spesso i database sono più grandi della memoria, ma raramente si accede alla maggior parte, avendo quello sul disco non è male finché gli indici, le righe spesso recuperate ecc. Sono in memoria
johannes,

2
@vartec Quindi vuoi eliminare la mia posta di 2 anni dal mio database di posta mentre cerco solo una volta al mese mentre il mio set di lavoro principale sono solo le ultime dieci mail?
johannes,

3
Suggerimento @wobbily_col: non lo è. a meno che non ti interessi di coerenza, affidabilità o durata. in tal caso, puoi disattivare molte cose che rendono l'una molto più veloce dell'altra, o viceversa se vuoi. indovina quali sono le configurazioni predefinite su ognuna? (ovviamente, MySQL non è neanche l'apice della sicurezza dei dati ...)
Javier,

1
@vartec "Sharding automatico" è carino, dove è applicabile. Ma all'improvviso non puoi più unire tutti i dati - oh aspetta, non puoi farlo con un database di documenti anche la ricerca di tutti i dati o la creazione di report diventa noiosa ... sì, i database di documenti hanno il loro posto, quando il modello di dati e le operazioni corrispondono, lo stesso per altri sistemi ... la quantità di dati da sola non è un fattore (conosco un numero sufficiente di istanze MySQL in esecuzione con dati nell'area terabyte con successo ... e progetti con alcune centinaia di MB non riusciti)
johannes

13

Non penso che la dimensione dei dati sia l'unico fattore. Anche il "modello di 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 alle 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.


9
Esattamente. tutto questo "big data" merda bla bla è marketing parlare e l'intero "NoSQL per big data!" anche le cose. NoSQL è utile per set di dati di grandi dimensioni perché è più veloce di un RDBMS tradizionale, ma è più veloce a causa degli enormi compromessi delle funzionalità. Molti modelli di dati soffriranno in modo significativo a causa di tali compromessi, mentre alcuni funzioneranno correttamente. Si tratta di sapere cosa stai perdendo quando vai su NoSQL e di utilizzare NoSQL solo per i dati che possono subire tali perdite.
Jimmy Hoffa,

1
Sebbene sia vero, non è la risposta alla domanda posta.
Vartec,

Questa non è solo NON la risposta, ma NON è vera. Puoi creare un documento come una tabella nel database SQL semplicemente usando il tipo di dati JSON e far risplendere il database SQL su NoSQL.
Yevgeniy Afanasyev il

6

Se i database relazionali non si ridimensionano, nulla lo fa. 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 fa riferimento ad altre righe in base a una chiave univoca. In genere, questo potrebbe essere utilizzato 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 è possibile effettuare un numero specifico di salti. Ma se, per ogni riga, vuoi selezionare un campo sulla prima riga correlata nella catena che soddisfa alcuni criteri, allora diventa complicato.

Prendi in considerazione 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. Non vi è alcuna garanzia che l'ufficio rapporti di ciascun ufficio abbia solo un livello superiore. Per un set 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. (Ero solito ottenere 30 secondi su una selezione di 30 uffici, ma era tanto tempo fa - e il passaggio a procedure memorizzate mi ha aiutato un po '.)

Quindi l'alternativa è mettere l'intera struttura in un unico grande blocco di dati, etichettarlo e archiviarlo. Quando vuoi analizzare i dati, leggili tutti in memoria in una sola volta, impostando i puntatori per tracciare la struttura e puoi elaborare un paio di milioni di uffici in un batter d'occhio.

Niente di tutto ciò 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 è quello che vuoi. Altrimenti, una sorta di memoria di massa sarà qualcosa da leggermente a un quadrilione di volte più veloce.

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 farlo se , e solo se, tutti i blocchi si adattano alla memoria contemporaneamente. E l'utente deve attendere mentre li carichi.

Se il tuo database relazionale ti causerà problemi, lo farà prima di averci inserito molti dati. 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 esso. (Leggi errori di memoria insufficiente. Le lingue più recenti a volte fanno cose strane con la memoria.)


0

Penso che il primo motivo per passare a una soluzione NoSQL o distribuita non sia tanto la dimensione di tutti i dati, ma la dimensione delle tabelle. Ciò che le soluzioni distribuite fanno bene è suddividere le tabelle in nodi diversi, quindi quando è necessario interrogare le tabelle, ciascun nodo elaborerà il proprio pezzo di tabella.

Gli RDBMS possono farlo, ma la nuova ondata di database NoSQL è stata creata per farlo. Oracle, MSSQL, MySQL hanno preso il loro modello centralizzato e lo hanno modificato per farlo funzionare in un ambiente distribuito. Tuttavia, continuano ad aderire alle rigide regole ACID mentre alcuni dei nuovi database non aderiscono alle rigide regole, ad esempio utilizzando l'eventuale coerenza.

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


0

Potrebbe anche valere la pena ricordare che il tuo modello di dati ha una grande influenza sulle cose. Se ti trovi nella necessità di creare una qualche forma di struttura ad albero (ovvero hai una chiave esterna autoreferenziale su una tabella che contiene detta chiave esterna in una chiave primaria composta), probabilmente dovresti cercare di farlo in una qualche forma di database che gestisce quelle tipi di dati davvero bene (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ù tabelle, allora hai davvero bisogno di rimanere con un RDBMS, ma se hai qualcosa in cui puoi avere alcuni dati leggermente obsoleti e hai bisogno della flessibilità di uno schema NoSQL (chiamalo schematico se ti piace ma ha ancora una qualche forma di schema implicito) quindi potresti prendere in considerazione l'idea di prendere un negozio NoSQL ( http://www.10gen.com/customers/craigslist qui è un esempio del motivo per cui Craigslist è passato ... ma è vero che stanno archiviando ~ 10 TB di dati, che conosco non si adattano affatto alle dimensioni del database da piccole a medie. Ma il caso d'uso potrebbe essere utile).

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


0

Mongopuò essere installato su un numero di computer / nodi. PostgreSQLnon fornisce uno strumento integrato per lo sharding, tuttavia citus è in circolazione.

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 un limite di record di 4 gigabyte

PostgreSQL non ha limiti al database (4 terabyte esistono da qualche parte per i test) e ha un limite di 1 gigabyte per la dimensione di un campo in una tabella e di nuovo 64 terabyte la dimensione massima per una tabella.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.