Home/ Questions/Q 7612725
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T01:59:08+00:00

I realize that this question is pretty well discussed, however I would like to

  • 0

I realize that this question is pretty well discussed, however I would like to get your input in the context of my specific needs.

I am developing a realtime financial database that grabs stock quotes from the net multiple times a minute and stores it in a database. I am currently working with SQLAlchemy over MySQL, but I came across Redis and it looks interesting. It looks good especially because of its performance, which is crucial in my application. I know that MySQL can be fast too, I just feel like implementing heavy caching is going to be a pain.

The data I am saving is by far mostly decimal values. I am also doing a significant amount of divisions and multiplications with these decimal values (in a different application).

In terms of data size, I am grabbing about 10,000 symbols multiple times a minute. This amounts to about 3 TB of data a year.

I am also concerned by Redis’s key quantity limitation (2^32). Is Redis a good solution here? What other factors can help me make the decision either toward MySQL or Redis?

Thank you!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Redis is an in-memory store. All the data must fit in memory. So except if you have 3 TB of RAM per year of data, it is not the right option. The 2^32 limit is not really an issue in practice, because you would probably have to shard your data anyway (i.e. use multiple instances), and because the limit is actually 2^32 keys with 2^32 items per key.

    If you have enough memory and still want to use (sharded) Redis, here is how you can store space efficient time series: https://github.com/antirez/redis-timeseries

    You may also want to patch Redis in order to add a proper time series data structure. See Luca Sbardella’s implementation at:

    https://github.com/lsbardel/redis

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

    Redis is excellent to aggregate statistics in real time and store the result of these caclulations (i.e. DIRT applications). However, storing historical data in Redis is much less interesting, since it offers no query language to perform offline calculations on these data. Btree based stores supporting sharding (MongoDB for instance) are probably more convenient than Redis to store large time series.

    Traditional relational databases are not so bad to store time series. People have dedicated entire books to this topic:

    Developing Time-Oriented Database Applications in SQL

    Another option you may want to consider is using a bigdata solution:

    storing massive ordered time series data in bigtable derivatives

    IMO the main point (whatever the storage engine) is to evaluate the access patterns to these data. What do you want to use these data for? How will you access these data once they have been stored? Do you need to retrieve all the data related to a given symbol? Do you need to retrieve the evolution of several symbols in a given time range? Do you need to correlate values of different symbols by time? etc …

    My advice is to try to list all these access patterns. The choice of a given storage mechanism will only be a consequence of this analysis.

    Regarding MySQL usage, I would definitely consider table partitioning because of the volume of the data. Depending on the access patterns, I would also consider the ARCHIVE engine. This engine stores data in compressed flat files. It is space efficient. It can be used with partitioning, so despite it does not index the data, it can be efficient at retrieving a subset of data if the partition granularity is carefully chosen.

    • 0