5

我目前正在从事一个家庭自动化项目,该项目为用户提供了在一段时间内查看他们的能源使用情况的可能性。目前,我们每 15 分钟请求一次数据,预计我们的第一个大型试点将有大约 2000 名用户。

我的老板要求我们至少存储半年的数据。一个快速的总和导致估计大约 3500 万条记录。虽然这些记录很小(每个大约 500 字节),但我仍然想知道将这些记录存储在我们的数据库(Postgres)中是否是一个正确的决定。

有没有人有一些很好的参考资料和/或关于如何处理这些信息的建议?

4

6 回答 6

4

我们经常打看起来像这样的桌子。显然,根据使用情况(你读或写很多,等等)来构建你的索引,并且从一开始就考虑基于一些高级数据分组的表分区。

此外,您可以实施归档理念以保持活动表精简。历史记录要么从未被触及,要么被报道,在我看来,这两者都不适合活表。

值得注意的是,我们有大约 1 亿条记录的表,我们不认为存在性能问题。许多这些性能改进可以在事后毫不费力地进行,因此您总是可以从一个常识性的解决方案开始,只有在性能被证明很差时才进行调整。

于 2011-07-20T10:27:26.857 回答
4

目前,3500 万条 0.5K 的记录意味着 37.5G 的数据。这适合您的试点数据库,但您还应该考虑试点后的下一步。当试点取得巨大成功时,你的老板会不高兴,你会告诉他,如果不重新设计一切,你就无法在接下来的几个月内向系统添加 100,000 个用户。此外,VIP用户每分钟请求数据的新功能怎么样......

这是一个复杂的问题,您所做的选择将限制您的软件的发展。

对于试点,尽可能保持简单,以尽可能便宜地推出产品 --> 对于数据库来说没问题。但是告诉你老板,你不能像那样打开服务,你必须在每周获得 10.000 个新用户之前做出改变。

下一版本的一件事:拥有许多数据存储库:一个用于您经常更新的用户数据,一个用于您的查询/统计系统,...

您可以在下一个版本中查看RRD

还要记住更新频率:2000 个用户每 15 分钟更新一次数据意味着每秒 2.2 次更新 --> ok;100.000 个用户每 5 分钟更新一次数据意味着每秒更新 333.3 次。我不确定一个简单的数据库可以跟上这个速度,而单个 Web 服务服务器肯定不能。

于 2011-07-20T10:52:46.217 回答
1

使用适当的索引来避免缓慢的查询,我不希望任何体面的 RDBMS 与那种数据集作斗争。许多人正在使用 PostgreSQL 来处理比这更多的数据。

这就是数据库的用途:)

于 2011-07-20T10:27:10.203 回答
1

首先,我建议您进行性能测试 - 编写一个程序,生成与您将在半年内看到的条目数量相对应的测试条目,插入它们并检查结果以查看查询时间是否令人满意。如果没有,请尝试按照其他答案的建议进行索引。顺便说一句,也值得尝试写入性能,以确保您可以在 15 分钟内实际插入生成的数据量。15 分钟或更短的时间。

进行测试将避免所有问题的根源-假设:-)

还要考虑生产性能——你的试点将有 2000 个用户——你的生产环境在一两年内会有 4000 个用户还是 200000 个用户?

如果我们谈论的是一个非常大的环境,您需要考虑一种解决方案,该解决方案允许您通过添加更多节点来横向扩展,而不是依赖始终能够向单个机器添加更多 CPU、磁盘和内存。您可以在您的应用程序中执行此操作,方法是跟踪多台数据库机器中哪些主机正在为特定用户托管详细信息,或者您可以使用 Postgresql 集群方法之一,或者您可以采用完全不同的路径 - NoSQL方法,您完全摆脱 RDBMS 并使用为水平扩展而构建的系统。

有许多这样的系统。我只有Cassandra的亲身经历。与您在 RDBMS 世界中所习惯的相比,您必须思考完全不同的想法,这有点挑战 - 更多地考虑您希望如何访问数据而不是如何存储数据。对于您的示例,我认为使用用户 ID 作为键存储数据,然后添加一个列,列名是时间戳,列值是该时间戳的数据是有意义的。然后,您可以请求这些列的切片,例如用于在 Web UI 中绘制结果 - Cassandra 对 UI 应用程序有足够好的响应时间。

花时间学习和使用 nosql 系统的好处是,当您需要更多空间时 - 您只需添加一个新节点。如果您需要更高的写入性能或更高的读取性能,同样的事情。

于 2011-07-20T10:57:58.450 回答
0

您最好不要在整个期间保留单个样本吗?您可能会实施某种合并机制,将每周/每月的样本连接到一个记录中。并按计划运行所述合并。

您的决定必须取决于您需要能够在数据库上运行的查询类型。

于 2011-07-20T10:32:40.600 回答
0

有很多技术可以解决这个问题。只有当您触及最小记录数时,您才会获得性能。在您的情况下,您可以使用以下技术。

  1. 尝试将旧数据保存在单独的表中,您可以使用表分区或使用不同类型的方法,您可以将旧数据存储在文件系统中,并且可以直接从应用程序提供它们而无需连接到数据库,这样您的数据库将是自由的。我正在为我的一个项目执行此操作,它已经拥有超过 50GB 的数据,但运行非常顺利。
  2. 尝试索引表列,但要小心,因为它会影响您的插入速度。
  3. 尝试对插入或选择查询进行批处理。你可以在这里非常聪明地处理这个问题。示例:假设您每 1 秒后收到在任何表中插入记录的请求,那么您创建了一种机制,以 5 条记录的批次处理此请求,这样您将在 5 秒后访问您的数据库,这要好得多。是的,您可以让用户等待 5 秒钟以等待插入他们的记录,就像在您发送电子邮件的 Gmail 中一样,它要求您等待/处理。对于选择,您可以定期将结果集放入文件系统中,并可以直接将它们提供给用户,而无需像大多数股票市场数据公司那样接触数据库。
  4. 您还可以使用一些 ORM,例如 Hibernate。他们将使用一些缓存技术来提高数据的速度。

如有任何进一步的疑问,您可以通过 ranjeet1985@gmail.com 给我发邮件

于 2014-05-30T12:57:44.610 回答