La cortese interpretazione di "NoSQL" è diventata Not Only SQL . Se disponi di dati veramente relazionali, o se la tua funzionalità dipende da cose come join e ACIDity, allora dovresti archiviare quei dati in modo relazionale. In questo post, spiegherò come utilizzo MySQL insieme a due archivi dati NoSQL. L'archiviazione dei dati moderna e su scala Web consiste nel capire come scegliere gli strumenti migliori per il lavoro.
Detto questo, NoSQL è davvero una reazione al fatto che il metodo relazionale e il modo di pensare sono stati applicati a problemi in cui in realtà non si adattano molto bene (tipicamente tabelle enormi con decine di milioni di righe o più). Una volta che le tabelle diventano così grandi, la tipica "best practice" SQL è stata quella di shard manualmente i dati, ovvero inserire i record da 1 a 10.000.000 nella tabella A, da 10.000.001 a 20.000.001 nella tabella B e così via. Quindi, in genere nel livello del modello dell'applicazione, le ricerche vengono eseguite secondo questo schema. Questo è ciò che viene chiamato application-aware ridimensionamento. È dispendioso in termini di tempo e soggetto a errori, ma per ridimensionare qualcosa mantenendo MySQL per il long table store, è diventato un MO più o meno standard. NoSQL rappresenta, per me, l'application-unaware alternativa.
Valore-chiave
Quando ho avuto un prototipo MySQL che ha iniziato a diventare troppo grande per il suo bene, ho spostato personalmente quanti più dati possibile nella velocissima Membase , che supera Memcached e aggiunge persistenza. Membase è un negozio di valori-chiave distribuito che scala più o meno linearmente (Zynga lo usa per gestire mezzo milione di operazioni al secondo, per esempio) aggiungendo più server merci in un cluster:è quindi un ottimo adatto all'era del cloud di Amazon EC2 , Joyent , ecc.
È risaputo che i negozi con valori chiave distribuiti sono il modo migliore per ottenere una scala lineare enorme. Il punto debole del valore-chiave è la possibilità di interrogazione e l'indicizzazione. Ma anche nel mondo relazionale, la migliore pratica per la scalabilità è scaricare quanto più sforzo possibile sui server delle applicazioni, eseguendo join in memoria sui server delle app di consumo invece di chiedere al cluster RDB centrale di gestire tutta quella logica. Poiché simple select più application logic sono davvero il modo migliore per ottenere risultati su vasta scala anche su MySQL, il passaggio a qualcosa come Membase (o suoi concorrenti come Riak
) non è poi così male.
Documenti
A volte, anche se direi meno spesso di quanto molti pensino, il design di un'applicazione richiede intrinsecamente indici secondari, interrogabilità dell'intervallo, ecc. L'approccio NoSQL a questo è attraverso un document store come MongoDB
. Come Membase, Mongo è molto valido in alcune aree in cui i database relazionali sono particolarmente deboli, come application-unaware ridimensionamento, auto-sharding , e maintaining flat response times even as dataset size balloons . È significativamente più lento di Membase e un po' più complicato da fare in scala orizzontale pura, ma il vantaggio è che è altamente interrogabile. Puoi eseguire query su parametri e intervalli in tempo reale oppure puoi utilizzare Mappa/Riduci per eseguire complesse operazioni batch su set di dati davvero enormi.
Nello stesso progetto che ho menzionato sopra, che utilizza Membase per servire tonnellate di dati di giocatori dal vivo, utilizziamo MongoDB per archiviare dati analitici/metrici, ed è proprio qui che MongoDB brilla.
Perché mantenere le cose in SQL
Ho accennato brevemente al fatto che le informazioni "veramente relazionali" dovrebbero rimanere nei database relazionali. Come sottolinea il commentatore Dan K., ho perso la parte in cui discuto degli svantaggi di lasciare RDBMS, o almeno di lasciarlo del tutto.
In primo luogo, c'è lo stesso SQL. SQL è noto ed è stato per molto tempo uno standard del settore. Alcuni database "NoSQL" come App Engine
di Google Datastore (costruito su Big Table) implementa il proprio linguaggio simile a SQL (quello di Google è chiamato, in modo carino, GQL per Google Query Language ). MongoDB adotta un nuovo approccio al problema delle query con i suoi deliziosi oggetti query JSON
. Tuttavia, lo stesso SQL è un potente strumento per ottenere informazioni dai dati, che spesso è il punto centrale dei database per cominciare.
Il motivo più importante per rimanere con RDBMS è ACID
o Atomicity, Consistency, Isolation, Durability . Non eseguirò nuovamente l'hash dello stato di Acid-NoSQL, poiché è ben indirizzato in questo post
su SO. Basti dire che c'è una ragione razionale RDBMS di Oracle
ha un mercato così vasto che non va da nessuna parte:alcuni dati richiedono la pura conformità ACID . Se i tuoi dati lo fanno (e se lo fanno, probabilmente ne sei ben consapevole), lo fa anche il tuo database. Tieni quel pH
basso!
Modifica: Dai un'occhiata al post di Aaronaught qui. Rappresenta la prospettiva business-to-business molto meglio di me, in parte perché ho trascorso tutta la mia carriera nello spazio dei consumatori.
