2010-08-27 6 views
5

Ho iniziato a esaminare NoSql e mi chiedevo cosa pensano gli altri dell'idoneità di tali soluzioni per l'archiviazione e l'interrogazione dei dati delle serie temporali finanziarie?NoSql (ad esempio RavenDB) per i dati delle serie temporali finanziarie?

Ad esempio, in uno scenario semplice, memorizzerei il simbolo di serie, aperto, alto, basso, chiuso, volume e una data/ora. Vorrei quindi interrogare quei dati in base al simbolo e all'intervallo di data e ora.

Quale pensi che sarebbe una buona struttura del documento per questo scenario?

Grazie,

Tom

Edit: Sono soprattutto preoccupato per le prestazioni di query di lettura di dati in base serie temporali in una soluzione NoSQL vs una soluzione RMDBS tradizionale

risposta

3

Tom, i dati finanziari tendono ad avere rigidi requisiti di coerenza e persistenza. A prima vista e senza ulteriori informazioni sulla tua applicazione, mi aspetto che tu abbia bisogno delle proprietà ACID di un RDBMS in contrasto con le proprietà BASE che di solito definiscono le soluzioni NoSQL. Forse se descrivi il tuo modello di utilizzo e perché pensi di aver bisogno di un modello non relazionale, sarò in grado di trovare una soluzione più adatta a te.

Allo stato attuale, i dati sembrano essere facilmente strutturati dal modello relazionale e hanno uno schema piuttosto rigido, quindi non vedo la necessità di uno schema db (MongoDB, CouchDB, Riak ...). Di solito le quotazioni di borsa devono avere una consistenza forte (essere sempre aggiornate) quindi non vedo alcun punto in un clone di dinamo (Cassandra, Voldemort ...). E a meno che non si disponga di un'enorme quantità di dati e di un muro per quanto riguarda le velocità di elaborazione e l'utilizzo delle risorse non andrei per un db basato su colonna (HBase, Hypertable)

+0

Le proprietà ACID non sono un requisito per me qui. I dati archiviati vengono aggiornati durante la notte solo in un processo batch e riceveranno query di sola lettura per tutto il giorno. Quello che mi interessa è se una soluzione NoSQL andrà meglio in una query basata su "serie storiche" (selezione dei dati entro un intervallo di tempo) rispetto alle soluzioni RMDBS tradizionali – TJF

+0

Non sembra che tu abbia un requisito di disponibilità qui, tu voglio solo query veloci su un database di sola lettura. Sembra quasi che qualsiasi database decente possa fornire tutto ciò di cui hai veramente bisogno è un indice sul timestamp. Non credo che una soluzione NoSQL sarebbe meglio, ma dipende dalla scala.Onestamente vorrei usare un motore di ricerca come Solr (o Lucene) e solo modificare la memorizzazione nella cache poiché i tuoi dati sono di sola lettura possono essere molto veloci. – Asaf

3

Take a look at ESENT.

Per il tuo scenario, prenderei in considerazione l'uso dell'indice primario su 2 colonne: simbolo + timestamp (se hai intenzione di cercare singoli simboli su un intervallo) o timestamp + simbolo (se stai andando a prendere tutto simboli su un intervallo).

3

Tom. Cosa stai cercando di ottenere esattamente? RavenDB può certamente gestire questo scenario, ma devi essere consapevole del fatto che gli indici di RavenDB vengono aggiornati sullo sfondo. Lo scenario sembra adatto per un RDBMS, quindi devo chiedere perché stai cercando una soluzione NoSQL.

+0

l'aggiornamento in background degli indici non è un problema per questo caso d'uso. La mia domanda riguarda principalmente le prestazioni di lettura. Una soluzione NoSql andrà meglio in una "serie temporale" (intervallo di tempo) di una soluzione tradizionale RMDBS? – TJF

+0

Probabilmente, con RavenDB, probabilmente puoi fare la maggior parte del lavoro direttamente sopra l'indice costruito, che sarebbe _very_ fast –