【发布时间】：2013-06-06 10:56:19
【问题描述】：
我需要在数据库中存储一堆时间序列，但我担心大小和处理时间。
为了减小我已经在另一个项目中使用的大小，压缩/JSON 来存储整个时间序列，这在存储空间方面非常有效。 但问题是要搜索一些数据，您必须首先检索整个时间序列，解压缩并反序列化它，当然您不能使用数据库集成查询功能，如 SQL SELECT/WHERE。
所以你消耗带宽来获取数据，CPU来解压缩，RAM来存储，即使你只需要一点......
这对上一个项目来说不是问题，因为时间序列总是作为一个整体进行操作，本质上是在图表或 Excel 中显示，但这次我希望有一个最小的搜索数据的能力数据库。
在数据操作方面允许这种灵活性，例如使用 SQL，有“标准格式”：按日期一行，但我有两个顾虑：
- 10 年以上的时间序列可能有 3000 个值，所以这意味着 3000 行，所以想象一下，如果我有 1M 时间序列，我可以有 3G 行！ 我不确定像 MySQL 或 PostgreSQL 这样的“普通”数据库是否可以处理如此大量的行，但希望我错了
- 我不知道 DBMS 是否擅长优化所有单元所需的空间，虽然它不是“太大”但没关系
我可以选择任何免费的数据库，所以如果可以提供帮助，也欢迎 NoSQL。
您有什么建议，或者更好的一些反馈？
感谢您的任何意见。
【问题讨论】：
-
30 亿行虽然很大但并不极端。使用适当的索引，您应该获得完全合理的性能。但是您不会将其放入 20GB（每个数据点仅超过 6 个字节）。为什么 20GB 是数据库表的限制？
-
@Dems：很高兴你认为这不是极端，这是个好消息，但我从来没有处理过超过 1M 的行。 :) 20GB 是一个相当随意的限制，因为一些托管数据库非常昂贵，但我看到了更合理的计划。我会删除它。谢谢:)
-
仅供参考，看看酷炫的 Heroku 计划：postgres.heroku.com/pricing 没有限制（1T 似乎对我的需要来说是无限的；））在数据库大小但在缓存大小方面，不知道是否合理800Mo就足够了。但是，云的好处是您可以随着需求的变化顺利更改计划。
-
@Hazzit：差不多，但它已有两年多的历史了，而且数据库格局已经发展。 PerformanceDBA 的最佳答案与Dems 刚才所说的一致。 +1 似乎我会采用 PostgreSQL Heroku 的方式并处理索引。谢谢
-
如果我理解你的情况，同一个查询不太可能连续运行多次。如果这是真的，缓存不会对性能产生太大影响。另外，请注意，每月 100 美元，您有很多选择，既可以作为平台即服务（云解决方案），也可以作为自我管理（您自己的服务器）。
标签： sql database database-design nosql time-series