Quali dovrebbero essere le considerazioni per la scelta di SQL/NOSQL? [Chiuso

Question

L'applicazione target è un sito Web di medie dimensioni creato per supportare da diverse centinaia a diverse migliaia di utenti all'ora, con un'opzione per ridimensionare sopra. Il modello di dati è piuttosto semplice e il potenziale di memorizzazione nella cache è piuttosto elevato (rapporto ~ 10: 1 tra le letture e le azioni di modifica).

Quali dovrebbero essere le considerazioni quando si arriva a scegliere tra un dataStore relazionale basato su SQL a un'opzione NoSQL (come Hbase e Cassandra)?

Answer 1

Per me, non hai alcun problema particolare da risolvere. Se hai bisogno di acidità, utilizzare un database; Se non lo fai, allora non importa. Alla fine basta costruire la tua app. E lasciami citare NoSQL: se solo fosse così facile:

La cosa reale da sottolineare è che se vieni trattenuto dal fare qualcosa di super fantastico perché non puoi scegliere un database, lo stai sbagliando. Se conosci MySQL, l'ho appena usato. Ottimizza quando è necessario effettivamente. Usalo come Ak/V Store, usalo come un RDBMS, ma per l'amor di Dio, costruisci la tua app killer! Niente di tutto ciò avrà importanza per la maggior parte delle app. Facebook usa ancora MySQL, molto. Wikipedia usa MySQL, molto. FriendFeed usa MySQL, molto. NoSQL è un ottimo strumento, ma certamente non sarà il tuo vantaggio competitivo, non renderà la tua app calda e, soprattutto, i tuoi utenti non se ne fregano nulla di tutto ciò.

Answer 2

Digg ne ha un po ' interessante articoli Su questa domanda. In sostanza, stai spostando l'onere dell'elaborazione verso le scritture piuttosto che le letture, che possono essere desiderabili in applicazioni altamente scalabili. Anche Cassandra è anche altamente disponibile.

Semplisticamente, Cassandra è un database distribuito con un modello di dati Bigtable in esecuzione su una dinamo come l'infrastruttura. È orientato alla colonna e consente l'archiviazione di dati relativamente strutturati. Ha un modello completamente decentralizzato; Ogni nodo è identico e non esiste un singolo punto di fallimento. È anche estremamente tollerante alle guasti; I dati vengono replicati a più nodi e tra i data center. Cassandra è anche molto elastico; La throughput di lettura e scrittura aumenta linearmente quando vengono aggiunte nuove macchine.

Answer 3

I liked Ian Eure's rule of thumb: “if you’re deploying memcache on top of your database, you’re inventing your own ad-hoc, difficult to maintain NoSQL system.”

http://www.rackspacecloud.com/blog/2010/02/25/should-you-switch-to-nosql-too/

Answer 4

When you say, data modell is rather simple, this could speak for the NoSQL option.

When you have plenty of attributes to make selections, heavy transaction load or complicated table structures, that would speak for traditional SQL tables.

I would recommend to find out how difficult it would be to implement the data modell with one or two NoSQL databases. When this is rather difficult, you could also make a classical table schema to compare with.

When you have difficulties with NoSQL, this could speak for the SQL option. But also it could be, that the heavy load is better handled with NoSQL -- but also it could be that a good SQL database scales sufficiently ...

Buffering can also be done with a simple Proxy-Server ...

On difficulties, a mix of NoSQL and SQL could be also considered.