我的用例如下：我从7个数据源并行运行大约60个websockets来记录股票行情（所以时间序列数据）。目前，我正在将数据写入托管在Google Cloud VM上的mongodb，这样每个数据源都有自己的集合，所有集合都托管在同一个数据库中。
但是，仅仅五天的数据后，数据库已经增长到0.6 GB和大约1000万行。我对这些问题很陌生，但我觉得这不是一个可行的长期解决方案。我永远不会需要所有数据，但我需要所有数据才能按日期/货币查询。但是，据我所知，一旦数据集大于我的RAM，这些查询可能变得不可能，那是真的吗？
此外，这是一个研究项目，但不幸的是我目前无法使用大学集群，因此我将数据托管在私有虚拟机上。然而，这受到预算约束，并且高性能的机器很快变得非常昂贵。这就是我质疑我的设计选择的原因。目前，我正在考虑转换到另一种类型的数据库，但担心我再次遇到相同的问题，或者每周/每月导出数据库一次/无论是CSV还是消失。这将是一个很大的麻烦，我也害怕丢失数据。
所以我的问题是，我如何设计这个数据库，以便即使数据库的长度大于机器的RAM，我也可以按每个键（datetime或ticker_id）对数据进行子集化？磁盘空间不是问题。
除了Alex Blex已经对存储和性能做出评论之外。
查询响应时间在5天内接近10M行，随着数据集的增长而恶化。您可以查看sharding以将表分解为合理的块，并且仍然具有所有数据的ace，以用于查询目的。