我的老板要求我们至少存储半年的数据。快速计算估计需要大约3500万条记录。虽然这些记录很小(每个记录大约500字节),但我仍然想知道将它们存储在我们的数据库(Postgres)中是否是正确的决定。
有人有关于如何处理这么多信息的好参考资料和/或建议吗?
通过适当的索引来避免缓慢查询,我不会期望任何像样的关系型数据库管理系统在处理那种数据集时出现问题。许多人正在使用PostgreSQL来处理比那更多的数据。
这就是数据库存在的意义 :)
首先,我建议您进行性能测试 - 编写一个程序生成测试条目,这些条目对应于半年内将看到的条目数量,插入它们并检查结果以查看查询时间是否令人满意。如果不是,请尝试像其他答案建议的那样进行索引。顺便说一句,还值得尝试编写性能以确保您实际上可以在15分钟内插入您正在生成的数据量.. 15分钟或更短时间。
进行测试将避免所有问题的根源 - 假设 :-)
还要考虑生产性能 - 您的试点将拥有2000个用户 - 您的生产环境将在一两年内拥有4000个用户或200000个用户吗?
如果我们谈论的是一个非常大的环境,您需要考虑一种解决方案,该解决方案允许您通过添加更多节点来扩展,而不是依赖于始终能够向单个机器添加更多CPU、磁盘和内存。您可以通过跟踪多个数据库机器中哪个机器托管特定用户的详细信息,在应用程序中执行此操作,或者您可以使用其中一种Postgresql集群方法,或者您可以走完全不同的道路 - NoSQL方法,其中您完全放弃RDBMS并使用构建为水平扩展的系统。
有许多这样的系统。我只有Cassandra的个人经验。你必须从关系型数据库世界完全不同的角度去思考,这是一种挑战 - 更多地考虑如何访问数据,而不是如何存储它。对于你的例子,我认为将数据以用户ID作为键存储,然后添加一个列,其中列名称是时间戳,列值是该时间戳的数据,这样做是有意义的。然后,你可以请求这些列的片段,例如用于Web UI中的绘图结果 - Cassandra对于UI应用程序的响应时间足够好。
学习和使用nosql系统的好处是,当你需要更多空间时 - 你只需添加一个新节点。如果你需要更多的写入性能或读取性能也是一样的。
你不考虑不保留完整时间段的单个样本吗?你可以实现某种合并机制,将每周/每月的样本连接成一个记录,并按计划运行该合并。
你的决定必须取决于你需要在数据库上运行的查询类型。
有很多处理这个问题的技巧。只有在您触及最少的记录数量时,您才能获得性能方面的提升。在您的情况下,您可以使用以下技巧。
如有任何进一步的查询,请发送电子邮件至ranjeet1985@gmail.com