I dati nel nostro DBMS relazionale stanno diventando grandi, è il momento di passare a NoSQL?

Abbiamo creato un'applicazione di social network per scopi di e-learning. È un progetto sperimentale su cui stiamo effettuando ricerche nel nostro laboratorio. È stato usato in alcuni casi di studio per un po 'di tempo e i dati nel nostro DBMS relazionale (SQL Server 2008) stanno diventando grandi. Sono pochi gigabyte ora e i tavoli sono altamente collegati tra loro. Le prestazioni sono ancora buone, ma quando dovremmo considerare altre opzioni? È questione di prestazioni?

Alcuni gigabyte non sono molto " grandi ". È più simile alla dimensione normale di un DB aziendale. Fintanto che vai su PK quando ti unisci ai tavoli, dovrebbe funzionare davvero bene, anche in futuro (purché non ricevi TB di dati al giorno).

La maggior parte dei professionisti che lavorano in un ambiente di big data considera > ~ 5 TB come l' inizio del termine big data. Ma anche in questo caso non è sempre il modo migliore per installare il prossimo miglior database nosql. Dovresti sempre pensare all'attività che desideri archiviare con i dati (aggregati, leggi, cerca, i miei, ..) per trovare gli strumenti migliori per il tuo problema.

cioè se fai molte ricerche nel tuo database sarebbe probabilmente meglio eseguire un'istanza / cluster solr e denormalizzare i tuoi dati da un DBMS come Postgres o il tuo SQL Server di volta in volta e metterli in solr invece di spostare semplicemente i dati da sql a nosql in termini di persistenza e prestazioni.

Per rispondere a questa domanda devi rispondere a quale tipo di compromesso puoi permetterti. RDBM implementa ACID . Questo è costoso in termini di risorse. Non ci sono soluzioni NoSQL che sono ACID. Vedi il teorema di CAP per approfondire queste idee.

Quindi devi capire ogni compromesso dato da ciascuna soluzione e scegliere quello che è il più appropriato per il tuo problema.

I Big Data in realtà non riguardano il "quanto è grande".

Innanzitutto, pochi gigabyte non sono affatto grandi, è quasi nulla. Quindi non preoccuparti, il tuo sistema continuerà a funzionare in modo efficiente per qualche tempo, penso.

Quindi devi pensare a come utilizzi i tuoi dati.

• Approccio SQL: ogni dato è prezioso, ben raccolto e selezionato e l'attenzione è rivolta alla memorizzazione di dati di alto valore e ben strutturati. Questo può essere costoso, tutto è interconnessione ed è buono per i sistemi ben strutturati e dati funzionali.
• Approccio ai Big Data: nei big data in pratica memorizzi quasi tutto, indipendentemente dal valore che ha, e quindi esegui un processo di analisi attivo. Le cose non sono collegate, sono copiate. Ad esempio diciamo che ho un post sul blog. Nei Big Data non ci sarà un link al suo autore, ma l'autore sarà incorporato nel blog. Molto più scalabile, ma richiede un approccio diverso e più complesso.

Se la memorizzazione dei dati "funzionali" viene utilizzata dall'applicazione, ti suggerirò di rimanere su SQL. Se i tuoi dati di archiviazione per poterli cercare in un secondo momento o per creare rapporti e se questa quantità di dati può aumentare rapidamente, suggerirò i big data. A mio avviso, i big data sono utili quando si hanno a che fare con dati reali che devono essere raccolti e analizzati continuamente.

Ho pubblicato una risposta abbastanza dettagliata su StackOverflow su quando è appropriato utilizzare il database relazionale vs documento (o NoSQL), qui:

Motivazioni per l'utilizzo del database relazionale / ORM o del database dei documenti / ODM

Sommario:

• per piccole cose, scegli qualsiasi strumento tu abbia familiarità

• alcuni gigabyte sono decisamente piccoli: non diventano grandi fino a quando non sono troppo grandi per essere inseriti in un singolo cluster MySQL con un numero ragionevole di nodi (16-32), il che significa forse 8-16 TB di dati e qualche milione di transazioni al secondo (o un database basato su disco rigido più convenzionale con fino a 100 di dati TB e alcune migliaia di transazioni al secondo).

• se sei bloccato con un altro database (non MySQL Cluster), ottieni più chilometri da esso lanciando l'hardware FusionIO.

• una volta che hai dati più grandi di qualche TB e più veloci di migliaia di transazioni al secondo, è un buon momento guardare prima al passaggio allo sharding logico nel codice dell'applicazione e poi a NoSQL.

• Cassandra :)

È il momento di passare a NoSQL dipenderà da 2 cose:

1. La natura / struttura dei tuoi dati
2. La tua performance attuale

I database SQL eccellono quando i dati sono ben strutturati (ad es. Quando possono essere modellati come una tabella, un foglio di calcolo Excel o un insieme di righe con un numero fisso di colonne). Ottimo anche quando è necessario eseguire molti join di tabella (cosa che sembra che tu faccia).

I database NoSQL eccellono quando i dati non sono strutturati oltre le coppie chiave-valore.

Per quanto riguarda le prestazioni, ti devi porre una domanda: la tua attuale soluzione SQL è lenta ?

In caso contrario, seguire il principio " IIABDFI ".