Mi respuesta es similar a la dada para esta otra pregunta.
Si principalmente estás utilizando los datos para backtesting, hay muy poca razón para almacenar los datos en una base de datos MySQL. Los datos generalmente siguen un patrón de escribir una vez, leer muchas veces (WORM), sin necesidad de semántica ACID. Tampoco es necesario imponer integridad referencial en la mayoría de los datos. Si deseas hacerlo para las partes relacionadas con las definiciones de instrumentos (por ejemplo, subyacente, precio de ejercicio, fecha de vencimiento, put/call), puedes separar solo las definiciones y ponerlas en una base de datos MySQL.
Generalmente veo a las personas almacenando los datos en una base de datos MySQL solo por (1) experiencia limitada con otros formatos de almacenamiento y herramientas, (2) exceso de exposición a MySQL debido a un fondo no financiero o de desarrollo web. Es razonable comenzar con MySQL porque es una herramienta con la que estás familiarizado, pero una vez que comiences a encontrar limitaciones de rendimiento aquí, sería una de las piezas más obvias en tu stack para optimizar.
Si todavía deseas usar un DBMS para este caso de uso para que no tengas que escribir rutinas personalizadas para procesar los datos, te sugiero algo como Clickhouse, con el que he tenido buenas experiencias. No tiene los costos ni las limitaciones de licencia que vienen con kdb o Vertica, y definitivamente es más adecuado para el caso de uso que InfluxDB. ~2B+ registros son en realidad bastante pequeños, ya que hay implementaciones de producción de Clickhouse que ejecutan consultas y vistas materializadas en un conjunto de datos que está creciendo 6 millones de entradas por segundo.
Otra observación es que estás almacenando todos esos datos en 1 sola tabla grande con 1 campo que identifica el tick. Esto suele ser un anti-patrón para este caso de uso porque:
- Los datos de opciones son bastante dispersos: hay una gran cantidad de ticks sobre los que la mayoría tienen muy pocas entradas.
- Casi nunca tienes una estrategia que necesita backtestear sobre todos o la mayoría de los ticks al mismo tiempo.
A menudo, tendrá más sentido dividir los datos en tablas más pequeñas, por ejemplo, 1 por instrumento. En teoría, esto parecerá poco intuitivo porque tienes que pagar tiempo lineal para fusionar las tablas ordenadas más pequeñas y recomponer el conjunto de ticks. Sin embargo, generalmente es más eficiente que mantener los datos en 1 gran tabla y filtrar/descartar entradas de la tabla. Esto se debe a consideraciones prácticas:
- El número de entradas de interés es pequeño en relación con el número total de entradas.
- Estás ahorrando costos significativos de E/S que dominarán el tiempo de procesamiento para este tipo de carga de trabajo.
Por supuesto, 1 "tabla" por instrumento podría ser difícil de administrar ya sea en un DBMS o en archivos planos en un sistema de archivos, por lo que es posible que desees idear algún tipo de estrategia de "sharding", por ejemplo, distribuir los datos por algún hash del tick, de modo que termines con un número más manejable de "tablas", digamos, algo en el orden de 16 a 1024. La estrategia de hash más ingenua es dividirlas por el primer carácter del tick. Otra estrategia de hash ingenua es dividir por la longitud del tick.
Nota: En mi trabajo diario, almacenamos datos completos del libro de órdenes para mercados con miles de millones de registros por día por mercado. Mis sugerencias están motivadas por la experiencia en la gestión de implementaciones a escala de petabytes para tales datos.
