SQL (MySQL) vs NoSQL (CouchDB)

Sono nel bel mezzo della progettazione di un’applicazione altamente scalabile che deve memorizzare molti dati. Solo per esempio memorizzerà molti utenti e poi cose come molti dei loro messaggi, commenti, ecc. Ho sempre usato MySQL in precedenza, ma ora ho intenzione di provare qualcosa di nuovo come couchdb o simile che non sia SQL.

Qualcuno ha qualche pensiero o guida su questo?

Ecco una citazione da un recente post sul blog di Dare Obasanjo .

I database SQL sono come la trasmissione automatica ei database NoSQL sono come la trasmissione manuale. Una volta passato a NoSQL, diventi responsabile di un sacco di lavoro che il sistema gestisce automaticamente in un sistema di database relazionale. Simile a ciò che accade quando si seleziona la trasmissione manuale o automatica. In secondo luogo, NoSQL consente di aumentare le prestazioni del sistema eliminando molti controlli di integrità eseguiti dai database relazionali dal livello del database. Ancora una volta, questo è simile al modo in cui è ansible ottenere più prestazioni dalla propria auto guidando una trasmissione manuale rispetto a un veicolo di trasmissione automatica.

Tuttavia, la somiglianza più notevole è che proprio come la maggior parte di noi non è in grado di sfruttare i vantaggi di un veicolo di trasmissione manuale perché la maggior parte della nostra guida è seduta nel traffico sulla strada da e per il lavoro, c’è una realtà dura simile in quanto molti siti non sono su Google o su scala di Facebook e quindi non hanno bisogno di un Bigtable o di Cassandra.

A cui posso solo aggiungere che passare da MySQL, dove hai almeno una certa esperienza, a CouchDB, dove non hai esperienza, significa che dovrai affrontare una nuova serie di problemi e apprendere concetti e best practice diversi. Mentre da solo questo è meraviglioso (sto giocando a casa con MongoDB e mi piace molto), sarà un costo che dovrai calcolare quando valuti il ​​lavoro per quel progetto, e porta rischi sconosciuti mentre prometti benefici sconosciuti. Sarà molto difficile giudicare se si può fare il progetto in tempo e con la qualità che si desidera / deve avere successo, se si basa su una tecnologia che non si conosce.

Ora, se hai nel team un esperto nel campo NoSQL, allora guardalo bene. Ma senza alcuna esperienza nel team, non saltare su NoSQL per un nuovo progetto commerciale.

Aggiornamento : solo per gettare un po ‘di benzina nel fuoco aperto che hai iniziato, qui ci sono due articoli interessanti da persone sul campo SQL. 🙂

Non posso aspettare che NoSQL muoia (l’articolo originale è finito, eccone una copia )
Combattere la mentalità NoSQL, anche se questo non è un pezzo anti-NoSQL
Aggiornamento : ecco un interessante articolo su NoSQL
Making Sense of NoSQL

Sembra che solo le soluzioni reali oggi ruotino attorno al ridimensionamento o alla divisione. Tutti i database moderni (NoSQL e NewSQL) supportano il ridimensionamento orizzontale immediatamente, a livello di database, senza che l’applicazione abbia il codice di condivisione o qualcosa del genere.

Sfortunatamente, per il vecchio MySQL fidato, la condivisione non è “pronta all’uso”. ScaleBase (disclaimer: I work there) è un produttore di una soluzione di scale-out completa e una “macchina sharding automatica”, se lo desideri. ScaleBae analizza i dati e il stream SQL, divide i dati tra i nodes DB e aggregati in runtime, quindi non dovrai farlo! Ed è un download gratuito.

Non fraintendetemi, i NoSQL sono fantastici, sono nuovi, nuovi sono più una scelta e la scelta è sempre buona !! Ma scegliere NoSQL ha un prezzo, assicurati di poterlo pagare …

Puoi vedere qui altri dati su MySQL, NoSQL …: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding

Spero che questo abbia aiutato.

Una delle migliori opzioni è quella di andare per MongoDB (NOSql dB) che supporta la scalabilità. Memorizza grandi quantità di dati nient’altro che bigdata sotto forma di documenti a differenza di righe e tabelle in sql. Si tratta di dispositivi di fissaggio che seguono lo shradding dei dati. per garantire la garanzia dei dati che mantiene come server base server multipli con server db primario. Lingua indipendente. Flessibile da usare