我意识到这个问题已经得到很好的讨论，但是我想根据我的具体需求征求您的意见。
我正在开发一个实时金融数据库，它每分钟多次从网上获取股票报价并将其存储在数据库中。我目前正在通过 MySQL 使用 SQLAlchemy，但我遇到了 Redis，它看起来很有趣。它看起来不错，尤其是因为它的性能，这在我的应用程序中至关重要。我知道 MySQL 也可以很快，我只是觉得实现大量缓存会很痛苦。
到目前为止，我保存的数据大多是十进制值。我还对这些十进制值进行了大量的除法和乘法运算(在不同的应用程序中)。
就数据大小而言，我每分钟抓取大约 10,000 个符号。这相当于每年大约 3 TB 的数据。
我也担心 Redis 的 key 数量限制(2^32)。 Redis在这里是一个很好的解决方案吗？还有哪些其他因素可以帮助我做出选择 MySQL 还是 Redis 的决定？
谢谢!
最佳答案
Redis 是一个内存存储。所有数据必须适合内存。因此，除非您每年拥有 3 TB 的 RAM 数据，否则这不是正确的选择。 2^32 限制在实践中并不是真正的问题，因为无论如何您可能都必须对数据进行分片(即使用多个实例)，并且因为限制实际上是 2^32 个键 with 2^每个键 32 项。
如果您有足够的内存并且仍想使用(分片)Redis，以下是存储空间高效时间序列的方法:https://github.com/antirez/redis-timeseries
您可能还需要修补 Redis 以添加适当的时间序列数据结构。请参阅 Luca Sbardella 的实现:
https://github.com/lsbardel/redis
http://lsbardel.github.com/python-stdnet/contrib/redis_timeseries.html
Redis 非常适合实时汇总统计信息并存储这些计算的结果(即 DIRT 应用程序)。然而，在 Redis 中存储历史数据就没那么有趣了，因为它没有提供查询语言来对这些数据执行离线计算。支持分片的基于 Btree 的存储(例如 MongoDB)可能比 Redis 更方便存储大型时间序列。
传统的关系数据库存储时间序列并没有那么糟糕。人们已经将整本书都专门用于这个主题:
Developing Time-Oriented Database Applications in SQL
您可能要考虑的另一个选择是使用大数据解决方案:
storing massive ordered time series data in bigtable derivatives
IMO 的重点(无论存储引擎如何)是评估对这些数据的访问模式。你想用这些数据做什么？存储这些数据后，您将如何访问它们？您是否需要检索与给定符号相关的所有数据？您是否需要检索给定时间范围内多个符号的演变？您是否需要按时间关联不同符号的值？等等……
我的建议是尝试列出所有这些访问模式。给定存储机制的选择只是该分析的结果。
关于 MySQL 的使用，我肯定会考虑 table partitioning因为数据量大。根据访问模式，我还会考虑 ARCHIVE engine .该引擎将数据存储在压缩的平面文件中。它是节省空间的。它可以与分区一起使用，因此尽管它不索引数据，但如果仔细选择分区粒度，它可以有效地检索数据子集。
关于mysql - Redis vs MySQL 用于财务数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9626379/