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.SQL (MySQL) vs NoSQL (CouchDB)
Qualcuno ha qualche idea o guida su questo?
Ecco una citazione da un recente blog post from Dare Obasanjo.
database SQL sono come cambio automatico e database NoSQL sono come cambio manuale. Quando si passa a NoSQL , si diventa responsabili di un sacco di lavoro che il sistema gestisce automaticamente in un sistema di database relazionale. Simile a a ciò che accade quando si seleziona il manuale sulla trasmissione automatica. Secondariamente, NoSQL consente di ottenere più prestazioni dal sistema tramite eliminando un sacco di controlli di integrità eseguiti da database relazionali dal livello di database . Ancora una volta, questo è lo simile a come è possibile ottenere più prestazioni dall'auto guidando una trasmissione manuale rispetto a un veicolo di trasmissione automatico .
Tuttavia la somiglianza più evidente è che, proprio come la maggior parte di noi non può davvero usufruire dei vantaggi di un veicolo di trasmissione manuale perché la maggior parte della nostra guida è seduto nel traffico sulla strada per e dal funziona, c'è una realtà dura simile in quanto la maggior parte dei siti non sono su Google o nella scala di Facebook e quindi non hanno bisogno di per un Bigtable o Cassandra.
Per cui posso solo aggiungere che il passaggio da MySQL, dove si ha almeno una certa esperienza, per CouchDB, in cui non si ha esperienza, significa che si avrà a che fare con tutta una nuova serie di problemi e imparare diverso concetti e buone pratiche. 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 nel team c'è un esperto nel campo NoSQL, quindi 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.:-)
I Can't Wait for NoSQL to Die (Articolo originale è andato, ecco una copy)
Fighting The NoSQL Mindset, Though This Isn't an anti-NoSQL Piece
Aggiornamento: Beh qui è un interessante articolo su NoSQL
Making Sense of NoSQL
Il processo di ridimensionamento delle soluzioni SQL è il processo di rimozione di caratteristiche e relazioni. Quindi non penso che questa sia una valutazione assolutamente giusta. Inoltre, non raggrupperei i database NoSQL in questo modo, per esempio Cassanda si concentra esclusivamente sul ridimensionamento * su * mentre CouchDB si occupa di ridimensionare l'api * in basso * e renderlo facile da usare e tenta di consentire a tale API di scalare fino a il più possibile – mikeal
Potrebbe essere questo il link alla citazione? http://www.25hoursaday.com/weblog/2010/03/29/TheNoSQLeasesAutomaticVsManualTransmission.aspx – edosoft
Ah, sì, certo. Ho perso il fatto che ha fatto anche un post sul blog pubblico. Aggiornerò il post –
Sembra come uniche soluzioni reali oggi ruotano attorno ridimensionamento o sharding. 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 (dichiarazione di non responsabilità: io lavoro lì) è un produttore di una soluzione di scale-out completa e una "macchina di sharding automatica", se lo desideri. ScaleBae analizza i dati e il flusso SQL, divide i dati tra i nodi DB e aggregati in runtime, quindi non dovrai farlo! Ed è un download gratuito.
Non fraintendetemi, NoSQLs sono fantastici, sono nuovi, nuovi sono più scelta e la scelta è sempre buona !! Ma la scelta NoSQL ha un prezzo, assicurarsi la possibilità di pagare ...
Potete vedere qui alcuni più dati su MySQL, NoSQL ...: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding
Speranza che ha 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 che seguono lo shradding del data.Utilizza replicaset per garantire la garanzia dei dati che mantiene come server base server multipli con server db primario. Lingua indipendente. Flessibile da usare
È necessario eseguire il backup della propria opinione su "migliore" perché Couchbase, Cassandra, AeroSpike, ecc. e tutti i database che supportano le funzionalità citate. –
Gah, CW. E speravo di ottenere qualche rappresentante reale e un po 'di strada qui. :-) –
puoi spiegare un po 'di più sul tuo set di dati? – mikeal