SQL (MySQL) vs NoSQL (CouchDB) [chiuso]

Sto progettando un'applicazione altamente scalabile che deve archiviare molti dati. Ad esempio, memorizzerà molto sugli utenti e quindi cose come molti dei loro messaggi, commenti, ecc. Ho sempre usato MySQL prima, ma ora mi viene in mente di provare qualcosa di nuovo come couchdb o simile che non è 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 e i database NoSQL sono come la trasmissione manuale. Una volta che si passa a NoSQL, si diventa responsabili di un sacco di lavoro che il sistema si occupa automaticamente di un sistema di database relazionale. Simile a ciò che accade quando si seleziona la trasmissione manuale su quella automatica. In secondo luogo, NoSQL consente di ottenere maggiori prestazioni dal sistema eliminando molti controlli di integrità effettuati dai database relazionali dal livello del database. Ancora una volta, questo è simile al modo in cui puoi ottenere più prestazioni dalla tua auto guidando una trasmissione manuale rispetto a un veicolo con trasmissione automatica.

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

A cui posso aggiungere solo quel passaggio da MySQL, dove hai almeno qualche esperienza, a CouchDB, dove non hai esperienza, significa che dovrai affrontare una serie completamente nuova di problemi e apprendere concetti e best practice diversi. Mentre da solo è meraviglioso (sto giocando a casa con MongoDB e mi piace molto), sarà un costo che devi calcolare per stimare il lavoro per quel progetto e porta rischi sconosciuti promettendo benefici sconosciuti. Sarà molto difficile valutare se è possibile eseguire 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 dai un'occhiata. 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 che hai iniziato, ecco due interessanti articoli di persone nel campo SQL. :-)

Non vedo l'ora che muoia NoSQL (l'articolo originale è sparito, ecco una copia )
Combattere la mentalità NoSQL, anche se questo non è un
aggiornamento anti-NoSQL : Bene, ecco un articolo interessante su NoSQL che dà
senso a NoSQL

Sembra che solo le soluzioni reali oggi ruotino attorno al ridimensionamento o allo sharding. Tutti i database moderni (NoSQLs e NewSQLs) supportano immediatamente il ridimensionamento orizzontale, a livello di database, senza che l'applicazione abbia codice di sharding o qualcosa del genere.

Sfortunatamente, per il fidato vecchio MySQL, lo sharding non è fornito "out of the box". ScaleBase (dichiarazione di non responsabilità: ci lavoro) è un creatore di una soluzione di ridimensionamento completa una "macchina automatica di sharding", se lo desideri. ScaleBae analizza i dati e il flusso SQL, suddivide i dati tra nodi DB e aggregati in fase di esecuzione, quindi non sarà necessario! Ed è il download gratuito.

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

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

Spero che abbia aiutato.

Una delle migliori opzioni è 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 faster che segue lo sharding dei dati. per garantire la garanzia dei dati che mantiene più server con il server db primario come base. Indipendente dalla lingua. Flessibile da usare