Un database NoSQL è adatto a me? [chiuso]

1

Sto sviluppando un'applicazione WPF la cui funzionalità principale prevede la creazione di un grande oggetto grafico (spesso decine di migliaia di entità) che l'utente può modificare alcune parti, quindi salvare in un database. Un grafico può anche essere successivamente recuperato, modificato e salvato di nuovo. È possibile che un utente possa creare dozzine di questi grafici al giorno.

L'app fornisce anche all'utente diversi modi per cercare le entità nel database (prevalentemente ricerche di testo su vari campi), presentando i risultati della ricerca all'utente e consentendo all'utente di selezionarne uno, che risulterà nell'entità pertinente il grafico viene recuperato per intero e presentato all'utente affinché possa visualizzarlo e modificarlo come sopra.

Attualmente sto utilizzando Entity Framework e SQL Express, ma sono a disagio per alcuni aspetti dell'architettura e del design e il client non è entusiasta di dover installare SS. Recentemente mi sono imbattuto nel concetto di database NoSql e sembra che potrebbero essere adatti a quello che sto facendo, ma ho un paio di domande.

In primo luogo, presumo che le prestazioni non siano peggiori di EF quando leggi o scrivi uno di questi oggetti grafici?

E la funzionalità di ricerca della mia app? Un db NoSql supporterà questo tipo di cose, e come sarebbe la performance, tenendo presente le dimensioni e la quantità di "documenti" che probabilmente avrò.

E i dati di ricerca (riferimento)? Dovrei duplicare tali dati in ogni documento NoSQL o conserverei tutto in un unico documento NoSql e conserverei i loro ID nei documenti principali?

Infine, qualche consiglio per un prodotto? MongoDb e RavenDb sembrano essere i principali contendenti OSS per Windows.

    
posta Andrew Stephens 04.09.2013 - 20:50
fonte

4 risposte

6

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.

    
risposta data 04.09.2013 - 21:42
fonte
5

Non esiste una cosa come noSQL. C'è solo un mucchio di nuove tecnologie di database con filosofie e casi d'uso completamente diversi, e tutto ciò che hanno in comune sono cose che hanno anche in comune con i database SQL. Ciò significa che quando pianifichi un progetto e non sei sicuro della tecnologia del database, devi valutare singolarmente ogni database noSQL.

Quando i tuoi dati sono basati su grafici di grandi dimensioni, sembra un caso d'uso perfetto per un database orientato ai grafici come Neo4j .

I database orientati ai documenti come MongoDB non sono generalmente adatti per i grafici, perché non supportano molto bene le connessioni tra documenti.

    
risposta data 04.09.2013 - 21:16
fonte
2

Progetta prima, acquista più tardi

Dovresti progettare il tuo sistema prima di iniziare a fare acquisti per implementazioni specifiche. In particolare:

  1. Progetta le tue strutture dati in base a come intendi cercare e recuperare dati.
  2. Valuta l'efficienza e le prestazioni di soluzioni comparabili che implementano i tuoi requisiti di progettazione.

Non c'è davvero alcun sostituto per l'analisi comparativa di varie soluzioni su un corpus rappresentativo di dati, e nessun altro tranne la tua organizzazione può valutare i vari compromessi per il tuo progetto tuo .

grafica? Quindi grafico!

La scelta della giusta struttura dati per rappresentare i dati è essenziale per prevenire l'invecchiamento precoce dei programmatori. Selezionare i modelli giusti per cercare, archiviare e recuperare i dati dipende molto dal contesto, ma è il primo passo essenziale nella progettazione di un nuovo sistema.

Non ne ho mai avuto un'esigenza pratica da solo, ma se la struttura dei dati fondamentali è un grafico, perché non dare un'occhiata a una soluzione per database grafici? Neo4j sembra progettato per risolvere il tuo problema, ma non riesco a farlo perché non l'ho mai usato .

Anche se Neo4j non è la soluzione giusta per il tuo progetto, dovresti sicuramente indagare su tutte le opzioni che rendono più semplice lavorare con le tue strutture dati principali. Un obiettivo chiave è ridurre il numero di trasformazioni necessarie per la conversione dei dati tra i formati di input e di output, quindi concentrati su come utilizzare la soluzione.

    
risposta data 04.09.2013 - 21:57
fonte
0

È probabile che un database NoSQL soddisfi le tue esigenze meglio di un database SQL, ma tutto ciò aumenta le tue opzioni di scelta.

Quasi tutti i tipi di database possono archiviare il set di dati, ma ciò che conta davvero è il tipo di ricerche che devi fare. I diversi tipi di database hanno abilità molto diverse in quest'area, e questo è ciò che ti aiuterà a identificare i tipi di database adatti da usare.

Questo link contiene un buon elenco di diversi prodotti NoSQL raggruppati nei loro comportamenti allentati.

Tuttavia, direi che la maggior parte di questi prodotti non è mirata all'ambiente Windows. Ciò significa che avresti bisogno di un server di database linux e che hai un server applicazioni separato che ospita l'applicazione Windows.

    
risposta data 05.09.2013 - 14:05
fonte

Leggi altre domande sui tag