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