我目前正致力于家庭自动化项目，该项目为用户提供了在一段时间内查看其能源使用情况的可能性。目前我们每15分钟请求一次数据，我们预计我们的第一个大型飞行员将有大约2000名用户。
我的老板要求我们存储至少半年的数据。快速总和可以估计大约3500万条记录。虽然这些记录很小（每个大约500字节），但我仍然想知道将它们存储在我们的数据库（Postgres）中是否是一个正确的决定。
有没有人有一些很好的参考资料和/或建议如何处理这些信息？
答案 0 :(得分：4)
我们经常点击看起来像这样的表格。显然，根据用法构建索引（你读或写了很多，等等），并从一开始就考虑基于数据的高级分组的表分区。
此外，您可以实施归档构思以保持实时表的精简。在我看来，历史记录要么从未被触及，要么被报告，这两种对于生活表都没有好处。
值得注意的是，我们有大约100万条记录表，我们并不认为存在性能问题。很多这些性能改进可以在之后轻微的痛苦，所以你总是可以从常识解决方案开始，只有在性能被证明是差的时才进行调整。
答案 1 :(得分：4)
目前，每个0.5K的35M记录意味着37.5G的数据。这适合您的飞行员的数据库，但您也应该考虑飞行员之后的下一步。当飞行员取得巨大成功时，你的老板不会高兴，而且你会告诉他在接下来的几个月里你不能在系统中添加100.000用户而不重新设计所有东西。此外，VIP用户在每分钟请求数据的新功能如何......
这是一个复杂的问题，您所做的选择将限制软件的发展。
对于飞行员，尽量保持尽可能便宜的产品 - ＆gt;好的数据库。但是告诉老板你不能打开这样的服务，并且你必须在每周获得10,000个新用户之前改变一些东西。
下一个版本有一件事：拥有许多数据存储库：一个用于经常更新的用户数据，一个用于查询/统计系统，...
您可以查看RRD以获取下一个版本。
另请注意更新频率：2000个用户每15分钟更新一次数据意味着每秒更新2.2次 - ＆gt;好; 100.000用户每5分钟更新一次数据意味着每秒333.3次更新。我不确定一个简单的数据库可以跟上它，而单个Web服务服务器肯定不能。
答案 2 :(得分：1)
首先，我建议您进行性能测试 - 编写一个程序，生成与半年内看到的条目数相对应的测试条目，插入它们并检查结果以查看查询时间很满意。如果没有，请尝试按其他答案的建议进行索引。顺便说一下，也值得尝试写入性能，以确保您可以在15分钟或更短的时间内在15分钟内插入您正在生成的数据量。
进行测试将避免所有问题的母亲 - 假设： - ）
还要考虑生产性能 - 您的飞行员将拥有2000名用户 - 您的生产环境将在一两年内拥有4000名用户或20万用户？
如果我们谈论的是一个非常大的环境，您需要考虑一个解决方案，它允许您通过添加更多节点来扩展，而不是依赖于始终能够为单个计算机添加更多CPU，磁盘和内存。您可以在应用程序中执行此操作，方法是跟踪多个数据库计算机中哪些托管特定用户的详细信息，或者您可以使用Postgresql集群方法之一，或者您可以使用完全不同的路径 - {{3方法，你完全离开RDBMS并使用为水平扩展而构建的系统。
有很多这样的系统。我只有NoSQL的亲身经历。你必须认为与你习惯的RDBMS世界完全不同，这是一个挑战 - 想想你想要的更多 访问数据而不是如何存储它。对于您的示例，我认为使用user-id作为键存储数据，然后添加列名称为时间戳的列，列值作为该时间戳的数据将是有意义的。然后，您可以要求对这些列进行切片，例如在Web UI中绘制结果 - Cassandra具有足够好的UI应用程序响应时间。
在学习和使用nosql系统方面投入时间的好处是，当您需要更多空间时 - 您只需添加一个新节点。如果您需要更高的写入性能或更高的读取性能，也一样。
答案 3 :(得分：0)
使用适当的索引来避免慢查询，我不希望任何体面的RDBMS与这种数据集斗争。很多人使用PostgreSQL处理的数据远不止这些。
这是为数据库制作的：）
答案 4 :(得分：0)
最好不要在整个期间保留个别样品吗？您可以实现某种合并机制，将每周/每月样本连接到一个记录中。按计划进行合并。
您的决定必须依赖于您需要能够在数据库上运行的查询类型。
答案 5 :(得分：0)
有很多技术可以解决这个问题。如果您触摸最小记录数，您将只获得表现。在您的情况下，您可以使用以下技术。
如有任何进一步的查询，您可以发送邮件至ranjeet1985@gmail.com