NoSql (por ejemplo, RavenDB) para datos de series de tiempo financieras?

Empecé a investigar NoSql y me preguntaba qué opinan los demás acerca de la idoneidad de tales soluciones para almacenar y consultar datos de series de tiempo financieras.NoSql (por ejemplo, RavenDB) para datos de series de tiempo financieras?

Por ejemplo, en un escenario simple, almacenaría el símbolo de la acción, abrir, alto, bajo, cerrar, volumen y una marca de tiempo. Querría consultar esos datos según el símbolo y el rango de la marca de tiempo.

¿Cuál cree que sería una buena estructura de documento para este escenario?

Gracias,

Tom

Editar: estoy principalmente preocupado por el rendimiento de las consultas de lectura de los datos de series de tiempo basado en una solución NoSQL vs una solución RMDBS tradicional

Fuente

2010-08-27 TJF

Tom, los datos financieros tienden a tener estrictos requisitos de consistencia y persistencia. A primera vista y sin un mayor conocimiento de su aplicación, esperaría que necesitara las propiedades ACID de un RDBMS en comparación con las propiedades BASE que generalmente definen las soluciones NoSQL. Quizás si describes tu patrón de uso y por qué crees que necesitas un modelo no relacional, podré encontrar una solución más adecuada para ti.

Tal como está, los datos parecen estructurados fácilmente por el modelo relacional y tienen un esquema bastante rígido, por lo que no veo la necesidad de un archivo Schemaless db (MongoDB, CouchDB, Riak ...). Por lo general, las cotizaciones deben tener una gran consistencia (siempre estar actualizado), así que no veo ningún punto en un clon de dínamo (Cassandra, Voldemort ...). Y a menos que ya tenga una enorme cantidad de datos y pegue un muro en cuanto a las velocidades de procesamiento y el uso de recursos, no accedería a una columna basada en db (HBase, Hypertable)

Fuente

2010-08-28 09:32:47 Asaf

Las propiedades ACID no son un requisito para mí aquí. Los datos que se almacenan se actualizan durante la noche solo en un trabajo por lotes y recibirán consultas de solo lectura durante todo el día. Lo que me llama la atención es si una solución NoSQL tendrá mejores resultados en una consulta basada en "series de tiempo" (seleccionando datos dentro de un rango de tiempo) que las soluciones RMDBS tradicionales – TJF

No parece que tenga un requisito de disponibilidad aquí, solo quiero consultas rápidas en una base de datos de solo lectura. Eso suena como algo que casi cualquier base de datos decente puede proporcionar, todo lo que realmente necesita es un índice sobre la marca de tiempo. No creo que una solución NoSQL sea mejor, pero depende de la escala.Honestamente usaría un motor de búsqueda como Solr (o Lucene) y simplemente modificaría el almacenamiento en caché ya que sus datos son de solo lectura, pero pueden ser muy rápidos. – Asaf

Take a look at ESENT.

Para su escenario, consideraría usar el índice principal sobre 2 columnas: símbolo + marca de tiempo (si va a buscar símbolos individuales sobre algún intervalo) o marca de tiempo + símbolo (si va a buscar todos símbolos durante algún intervalo).

Fuente

2010-08-27 15:24:52 Soonts

Tom. ¿Qué estás tratando de lograr exactamente? RavenDB ciertamente puede manejar este escenario, pero debe tener en cuenta que los índices de RavenDB se actualizan en segundo plano. Su escenario parece ser adecuado para un RDBMS, así que tengo que preguntarle por qué está buscando una solución NoSQL.

Fuente

2010-08-27 22:20:05

actualización de índices no es un problema para este caso de uso Mi pregunta es principalmente sobre el rendimiento de lectura. ¿Le irá mejor a una solución NoSql en una consulta de "series temporales" (rango de tiempo) que una solución RMDBS tradicional? – TJF

Probablemente, con RavenDB, probablemente pueda hacer la mayor parte del trabajo directamente sobre el índice construido, lo que sería muy rápido –

NoSql (por ejemplo, RavenDB) para datos de series de tiempo financieras?

Respuesta

Cuestiones relacionadas