Questa è semplicemente la domanda sbagliata da porre.
"NoSQL" non fa riferimento a un database specifico, fa riferimento a un'intera superclasse di database, inclusi database di documenti, archivi di valori chiave distribuiti, database di grafici e database di oggetti.
La velocità è generalmente il minimo fattore importante nel prendere decisioni in merito all'archiviazione dei dati, indipendentemente da ciò che alcune persone potrebbero dirti. Una tabella SQL Server con un miliardo di righe può eseguire ricerche di indici e chiavi all'incirca alla stessa velocità di una raccolta MongoDB con un miliardo di documenti o un database db4o con un miliardo di oggetti. L'eccezione è ovviamente se si può fare sharding, nel qual caso si vorrà un prodotto che lo supporti, ma se i tuoi utenti sono ansiosi sull'installazione di SQL Express, allora stai sicuro che correranno per le colline se gli dirai di afferrare 200 vecchi PC desktop e taglia una istanza HBase su tutti loro.
Hai bisogno di ricerca full-text? Lo standard industriale per questo è Lucene. Non è un vero e proprio database da solo, è qualcosa che è imbullonato su altri database e talvolta è più facilmente impacchettato da strumenti come Elastic Search o Solr. La maggior parte dei database SQL ha anche una qualche forma di ricerca full-text; è generalmente più lento e inferiore a Lucene. Alcuni database NoSQL hanno una ricerca full-text (ad esempio, RavenDB usa effettivamente Lucene) ma la maggior parte non ha supporto o è in uno stadio molto primitivo.
Hai bisogno di memorizzare gerarchie molto profonde di oggetti tutti in una volta , gerarchie che hanno sempre una sola radice aggregata ben nota? Se è così, i database di documenti come MongoDB o CouchDB potrebbero funzionare bene per te. Ma se hai mai bisogno di cambiare la tua gerarchia, o di trovare che hai bisogno di coerenza transazionale (e non del tipo "finale"), allora sei pronto per un mondo di dolore.
I tuoi dati sono coerenti con più entità correlate che hanno una vita indipendente? In tal caso, un database relazionale come SQL Server o mysql è di gran lunga la scelta migliore. I database relazionali consentono di rinviare o ignorare molte decisioni di modellazione difficili e, in generale, sarà sufficiente modellare una sola volta, rispetto ai database di documenti o agli archivi di valori-chiave in cui potrebbe essere necessario modificare frequentemente il modello o mantenere più modelli paralleli in ordine per risolvere vari casi d'uso diversi. Se vuoi mantenere le cose semplici , sicuramente vuoi restare con SQL.
Se hai bisogno di un database incorporato , considera SQLite. Non è potente come SQL Server, ma è veloce e facile da usare e facile da distribuire, e troverai la sintassi per essere per lo più familiare.
Per inciso, se sei che preoccupato per la velocità (e dal suono, i tuoi bisogni sono troppo piccoli per giustificare una tale preoccupazione) allora potresti voler guardare < un href="http://servicestack.net/benchmarks/"> benchmark fatto qualche tempo fa dai ragazzi di ServiceStack. Entity Framework arriva in extremis e anche con un ampio margine. NHibernate è probabilmente la scelta migliore quando si bilanciano i requisiti reciprocamente esclusivi di compatibilità e prestazioni. Anche se personalmente preferisco non usare alcun ORM e sicuramente non sarai in grado di utilizzare un ORM piuttosto piccolo se passi a NoSQL. Buona fortuna per l'apprendimento dei 11.000 comandi Redis se non hai precedenti esperienze con il prodotto.