NoSQL è adatto per un'app di grafica e come posso confrontare diversi server NoSql?

1

Sono tradizionalmente uno sviluppatore MsSQL o MySQL - Ho realizzato una nuova applicazione per la memorizzazione di dati da molti obiettivi.

Ho visto che l'app sembra rallentare dopo il ridimensionamento a 10k target dopo aver inserito circa 300.000 risultati per ciascuno (64 bit int) - specialmente una volta che inizio a provare a calcolare e / o rappresentare graficamente alcuni bersagli contemporaneamente.

Una volta distribuita l'app, dovrò aggiungere circa 1k di target al mese e memorizzare un punto dati da ciascuno per ogni minuto per circa 2 anni.

Non ho mai usato NoSql, ma dalla lettura, mi sembra una buona idea: creare un documento per ogni target e continuare ad aggiungere campi per ciascun target.

Quindi, mi stavo chiedendo, NoSQL è la strada da seguire per questo progetto o dovrei attenermi al tradizionale SQL - e / o qualcuno può offrire qualche consiglio?

E la seconda parte - Se NoSQL è una soluzione, chiunque può consigliare un confronto equo perché mi sto perdendo in recensioni distorte che sembrano dire che ogni soluzione è superiore!?

    
posta wilhil 05.03.2013 - 01:04
fonte

2 risposte

3

per capire se uno dei DB SQL o un tipo di NoSQL è giusto, dovresti prima analizzare quale causa il tuo problema.

è la quantità di dati stessa, è la quantità di scritture parallele, è la quantità di letture parallele, o è la quantità di letture e scritture parallele

per quello che hai, dovresti controllare come risolvere questo problema con SQL, (i sistemi SQL sono betten quindi i sistemi NoSQL ne parlano)

se capisci che anche un grosso cluster di SQL con molti dati HD e partizionati diversi non aiuta a verificare a seconda del problema quali sistemi NoSQL ci sono.

come già accennato ci sono i DB grafici, sono buoni per leggere e scrivere molti dati connessi. ma le connessioni per i dati non possono essere illimitate.

per una lettura veloce ci sono mongodb, buona community e anche supporto commerciale.

per la scrittura veloce, c'è hypertable e hbase. dove hypertable è il più veloce, ma è scritto in c, e java o php o ... apis sono disponibili solo come librerie di risparmio, che ha bisogno di un po 'più di lettura su come usarlo. la community è attiva e risponde per entrambi.

mongodb, hypertable e hbase, hanno tutti il supporto per creare un lavoro di riduzione della mappa. questo è utile se vuoi qualcosa da fare sui tuoi dati che richiede più tempo.

significa se non hai bisogno di una risposta a una query (sql speaking) in questo momento, ma durante l'ora successiva questo è l'approccio giusto per te.

ma per tutto il sistema NoSQL, è necessario iniziare a pensare da zero, quindi se si inizia a dimenticare tutto da SQL e si concentra solo sull'unico NoSQL che si desidera utilizzare. e progetta i tuoi dati attorno a questo sistema

una cosa che la maggior parte di NoSQL ha in comune è che i dati possono essere archiviati due volte, su SQL si creano join di chiavi esterne e così via. su NoSQL è semplice scrivere i dati due volte (un passo per pensare a tali sistemi), (molti eventi di sistema non hanno un metodo di aggiornamento)

    
risposta data 05.03.2013 - 12:20
fonte
0

i database dei grafici sono sotto categorie di NoSQL. Ti consiglierei di utilizzare un DB specializzato per la tua app. dalla descrizione della tua app, penso che qualsiasi archivio grafico / valore-chiave svolgerà il lavoro. sembra che tu abbia scritto e testato la tua app su SQL, passare a noSQl ti richiederà di riscrivere / rimodellare la tua app. InfiniteGraph, Neo4j e FlockDB sono buoni DB grafici supportati dalla mia strong community. persone che provengono da SQL hanno cambiato paradigmi quando lavorano con la soluzione NOSQL, quindi per la prima immersione scegli la soluzione più semplice. Non sono il fan boy di nessuno di questi, per lo più noSQL DB sono gratuiti e open source non ci vuole molto tempo per provare alcuni database.

    
risposta data 05.03.2013 - 05:47
fonte

Leggi altre domande sui tag