Redis vs MySQL para datos financieros?

Question

Me doy cuenta de que esta pregunta está bastante discutida, sin embargo me gustaría obtener su opinión en el contexto de mis necesidades específicas.

Estoy desarrollando una base de datos financieros en tiempo real que toma las cotizaciones de acciones de la red varias veces por minuto y las almacena en una base de datos. Actualmente estoy trabajando con SQLAlchemy en MySQL, pero me encontré con Redis y parece interesante. Se ve bien, especialmente por su rendimiento, que es crucial en mi aplicación. Sé que MySQL también puede ser rápido, solo tengo ganas de implementar un pesado almacenamiento en caché que va a ser un problema.

Los datos que estoy guardando son en gran medida en su mayoría valores decimales. También estoy haciendo una cantidad significativa de divisiones y multiplicaciones con estos valores decimales (en una aplicación diferente).

En términos de tamaño de datos, estoy agarrando aproximadamente 10,000 símbolos varias veces por minuto. Esto equivale a alrededor de 3 TB de datos al año.

También me preocupa la limitación de cantidad de claves de Redis (2^32). ¿Redis es una buena solución aquí? ¿Qué otros factores pueden ayudarme a tomar la decisión ya sea hacia MySQL o Redis?

¡Gracias!

Answer 1

Redis es una tienda en memoria. Todos los datos deben caber en la memoria. Entonces, excepto si tiene 3 TB de RAM por año de datos, no es la opción correcta. El límite de 2^32 no es realmente un problema en la práctica, porque probablemente tenga que fragmentar sus datos de todos modos (es decir, usar instancias múltiples) y porque el límite es en realidad 2^32 teclas con 2^32 elementos por tecla.

Si tiene suficiente memoria y aún desea utilizar (fragmentada) Redis, aquí es cómo se puede almacenar eficiente del espacio de series de tiempo: https://github.com/antirez/redis-timeseries

También es posible que desee parchear Redis con el fin de añadir una serie de tiempo adecuado estructura de datos. Véase aplicación de Luca Sbardella en:

https://github.com/lsbardel/redis

http://lsbardel.github.com/python-stdnet/contrib/redis_timeseries.html

Redis es excelente para las estadísticas globales en tiempo real y almacenar el resultado de estas caclulations (es decir, aplicaciones de tierra). Sin embargo, el almacenamiento de datos históricos en Redis es mucho menos interesante, ya que no ofrece un lenguaje de consulta para realizar cálculos fuera de línea en estos datos. Las tiendas basadas en Btree que admiten sharding (MongoDB por ejemplo) son probablemente más convenientes que Redis para almacenar grandes series temporales.

Las bases de datos relacionales tradicionales no son tan malas para almacenar series de tiempo. La gente se ha dedicado libros enteros a este tema:

Developing Time-Oriented Database Applications in SQL

Otra opción es posible que desee considerar es el uso de una solución bigdata:

storing massive ordered time series data in bigtable derivatives

OMI el punto principal (cualquiera que sea el motor de almacenamiento) es evaluar los patrones de acceso a estos datos. ¿Para qué quieres usar estos datos? ¿Cómo accederá a estos datos una vez que se hayan almacenado? ¿Necesita recuperar todos los datos relacionados con un símbolo dado? ¿Necesita recuperar la evolución de varios símbolos en un rango de tiempo dado? ¿Necesita correlacionar valores de diferentes símbolos por tiempo? etc ...

Mi consejo es intentar listar todos estos patrones de acceso. La elección de un mecanismo de almacenamiento dado solo será una consecuencia de este análisis.

En cuanto al uso de MySQL, definitivamente consideraría table partitioning debido al volumen de datos. Dependiendo de los patrones de acceso, también consideraría el ARCHIVE engine. Este motor almacena datos en archivos planos comprimidos. Es eficiente en el espacio. Se puede usar con particiones, por lo tanto, a pesar de que no indexa los datos, puede ser eficiente para recuperar un subconjunto de datos si se selecciona cuidadosamente la granularidad de la partición.

Answer 2

Primero debe comprobar las características que ofrece Redis en términos de selección y agregación de datos. Comparado con una base de datos SQL, Redis es limitado.

De hecho, 'Redis vs MySQL' no suele ser la pregunta correcta, ya que son manzanas y peras. Si está actualizando los datos en su base de datos (también se eliminan regularmente), consulte la partición de MySQL. Ver p. la respuesta que escribió a What is the best way to delete old rows from MySQL on a rolling basis?

>

Salida MySQL Partitioning:

datos que pierde su utilidad a menudo puede ser eliminado fácilmente de una tabla con particiones dejando caer la partición (o particiones) que contiene sólo eso datos. Por el contrario, el proceso de agregar nuevos datos puede, en algunos casos, verse facilitado al agregar una o más particiones nuevas para almacenar específicamente esos datos.

See v.g. este post para obtener algunas ideas sobre cómo aplicarlo:

Using Partitioning and Event Scheduler to Prune Archive Tables

Y éste:

Partitioning by dates: the quick how-to

Answer 3

Deberías considerar Cassandra o Hbase. Ambos permiten el almacenamiento contiguo y los anexos rápidos, por lo que cuando se trata de consultas, obtienes un gran rendimiento. Ambos consumirán fácilmente decenas de miles de puntos por segundo.

El punto clave es a lo largo de una de las dimensiones de su consulta (por lo general, mediante el ticker), está accediendo al disco (ssd o spinning), contiguamente. No tienes que pulsar índices millones de veces. Puedes modelar cosas en Mongo/SQL para obtener un rendimiento similar, pero es más complicado, y lo obtienes "gratis" de la caja con los chicos columnares, sin tener que hacer ningún chanchullos del lado del cliente para unir los blobs.

Mi experiencia con Cassandra es 10 veces más rápida que MongoDB, que es mucho más rápida que la mayoría de las bases de datos relacionales, para el uso de series de tiempo, y a medida que aumenta el tamaño de los datos, también crece. Eso es cierto incluso en una sola máquina. Here es donde debería comenzar.

Lo único negativo en Cassandra al menos es que no tienes consistencia durante unos segundos a veces si tienes un gran grupo, por lo que necesitas forzarlo, ralentizarlo, o aceptar que el mismo la última impresión veces tendrá algunos segundos de antigüedad. En una sola máquina habrá cero problemas de consistencia y obtendrá los mismos beneficios columnares.

Menos familiarizado con Hbase pero afirma ser más consistente (habrá un costo en otro lugar - teorema CAP), pero es mucho más un compromiso para configurar la pila Hbase.