R: ¿Qué tan factible es almacenar - y trabajar con - datos de ticks en una base de datos conectada a R?

Question

Estoy buscando convertir algunos archivos .csv de tickdata en una base de datos en un disco local y luego usar R para llamar los datos y realizar mis diversos análisis y modelados.

¿Cuáles son algunas mejores prácticas / técnicas de implementación que se podrían recomendar para minimizar cualquier dolor de cabeza?

Se ha notado que paquetes como mmap ayudan enormemente, pero me gustaría intentar encontrar una solución más 'permanente'.

¿Cuál es la mejor base de datos con la que jugar? MySQL parece ser subóptimo ya que es relacional (en lugar de orientado a columnas). q/KDB parece tener una versión de prueba para jugar, pero tiene una curva de aprendizaje muy empinada. ¿Cuál es la mejor base de datos para manejar y servir solicitudes de ticks?

Cualquier ayuda es muy apreciada. Plataforma agnóstica, pero supongo que Linux es mi plataforma preferida.

Answer 1

Hay muchos productos especializados para datos tick de HF. Además de KDB que mencionaste, están OneTick, Vertica, Infobright, y algunos de código abierto como MonetDB, etc. (ver http://en.wikipedia.org/wiki/Column-oriented_DBMS).

En mi experiencia, las Bases de Datos Orientadas a Columnas están sobrevaloradas cuando se trata de datos tick, porque muy a menudo se solicita todo el tick o el registro completo (en lugar de solo una columna de un registro, es decir, para lo que las bases de datos orientadas a columna están optimizadas). En mi experiencia, la clave para la velocidad es más que uses un índice clusterizado para tu base de datos, definiendo así el orden en el que los datos se almacenan en el disco duro. Si principalmente consultas la serie temporal de un instrumento dado (en lugar de los últimos precios de un grupo de instrumentos), entonces querrás clusterizar por (Instrumento, TickTimestamp), haciendo que las consultas sean extremadamente rápidas incluso para tamaños de tablas enormes.

Luego está también la corriente de pensamiento que juega con nuevas alternativas desde el campo de NoSQL, como BigTable, MongoDB, etc. Es un área interesante, pero mi creencia personal es que están hechas principalmente para modelos de datos flexibles, lo cual no es nuestro requisito principal. Puedes hacer que funcionen, y funcionarán muy rápido, pero esto viene a costa de un soporte de herramientas más arcaico, curvas de aprendizaje más empinadas, etc.

He estado usando muchas bases de datos diferentes (Oracle, MySQL, SQLServer, MongoDB, MonetDB) a lo largo de los años, y mi conclusión es que la mayoría de ellas funcionan bastante bien para almacenar datos de series temporales financieras si las comprendes y las diseñas en consecuencia. Actualmente, estoy usando principalmente SQLServer, que es algo más rápido que MySQL, gratuito para conjuntos de datos más pequeños, y hace la mayoría de las cosas que necesito. El soporte para R (y Matlab y muchos otros entornos) es bastante bueno a través del paquete ODBC de R.

Answer 2

Usar MySQL para datos financieros no es irrazonable. Pero para datos de ticks ¿alguna vez vas a hacer algo más que una consulta en un rango de fechas? Para analizar datos de ticks en R generalmente los mantengo en un archivo de disco, un archivo por día, y los cargo a medida que los necesito. Usar archivos .RData en lugar de archivos csv es más rápido.

También he utilizado clases personalizadas en C++ antes, para realmente ser rápido, pero si los datos van a ser analizados en R, no tiene mucho sentido.

Answer 3

He tenido éxito usando MySQL para almacenar tanto datos OHLCV, datos de opciones y metadatos como fechas de ganancias en MySQL y accediendo a ambos para lecturas y escrituras desde R.

Para mí esto funciona muy bien y es eficiente para datos diarios, si estás haciendo HFT es posible que quieras considerar una base de datos especializada en ticks, pero a escalas diarias (252 retornos por año por ticker, MySQL es lo suficientemente rápido). Además, es mucho mejor que los archivos planos porque en algún momento te darás cuenta de que quieres emitir consultas relacionales para encontrar series temporales que coincidan con ciertos patrones agregados.

Ejemplos que suelo hacer son hacer JOIN de datos OHLC con datos de opciones para un determinado ticker y fusionar por fecha, claro que XTS::merge de R puede ayudar aquí también, pero a menudo es más eficiente emitir consultas SQL directamente y usar los dataframes/XTS de R para 'ajustar' una vez que hayas reducido de gigabytes de datos (en lo que R no es bueno) a unos pocos MB.

Si hay interés, podría considerar compartir mis módulos .R para la interfaz con MySQL tanto para la descarga diaria como para el almacenamiento de datos (por ejemplo, de Yahoo para OHLC, por supuesto), así como para realizar consultas.

Mi consejo es no sobrediseñarlo - si no necesitas el rendimiento de una base de datos especializada en ticks, y para escalas diarias no creo que lo necesites, ve con lo probado y simple. MySQL funciona.