**已关闭。**此问题正在寻求书籍、工具、软件库等的建议。它不符合Stack Overflow guidelines。目前不接受答复。
我们不允许问题寻求书籍，工具，软件库等的建议。您可以编辑问题，以便可以用事实和引用来回答。
5天前关闭。
Improve this question
我们正在建立一个网站，将持有每个用户的时间序列数据。我们期望有大量的时间序列数据，因此我们正在考虑对保存数据的表进行分区，以便即使在增长时也能保持较高的性能。
我们预计每个用户有300个不同的时间序列，这将每天增加300个新的数据点。如果我们每个数据点使用一行，那么每个用户每天将有300个新行。我们预计在未来的某个时候会有10，000个用户或更多，因此每天将有3，000，000个新行，每月将有90，000，000个新行，这意味着每年将增加超过10亿行。因此，我们考虑使用分区。
我们研究了像TimescaleDB这样的时间序列数据库，但在研究之后，它们似乎按天间隔分区，但在我们的用例中，当用户访问他们的数据时，他们将需要访问与他们的帐户相关的所有数据。这意味着它将需要搜索所有分区以找到与该特定用户相关的数据，因此看起来TimescaleDB不会提高我们用例的性能。
我的解决方案是按用户划分时间序列数据。例如，具有用户id 1-10的用户的数据将是一个分区，11-20将是另一个分区，等等。这样，当用户访问他们的数据时，搜索将只需要查看一个分区。
我的解决方案是否有缺点，或者有更好的解决方案？
我们计划在Django上建立网站，并使用Postgresql作为数据库，但很高兴考虑其他选择。
1条答案
按热度按时间6yoyoihd1#
根据用例和数据模式，答案可能会有所不同。然而，大多数时候你的答案并不是最好的解决方案。
例如;如果你把你的表分成300个固定的部分（列表分区），第一年可能是可以接受的。不过，可能会有一个问题。当您有10000或更多用户时，您将如何管理？逐个添加分区可能不是一个优雅的解决方案，操作成本将很高。此外，如果您将300个用户的分区数量减少到10个，他们仍然可以访问其他用户的数据。
然而，如果你每天都对表进行分区，到年底你将有365个分区，这对于第一年来说会更好。当岁月流逝，业绩的收获会越来越多。如果这对你来说还不够，那么也许你需要看看子分区，或者从here。添加哈希子分区可能是一个很好的结构。
为了解决用户只列出自己的数据的问题，可以看看row security policies。
最后，如果你想比较解决方案;
对于第一种情况，您将有30个分区，并且使用像
where userid=userid1这样的 predicate ，在这种情况下，数据库将修剪29个分区，但在第二种情况下，根据您的 predicate 数据库，可能会修剪更多的分区（在第一年年底）。假设用户希望列出最近7天的数据。那么它将类似于date > now() - interval '7 days' and userid=userid1，并且数据库将修剪358个分区以用于基本分区。当然，这些都只是你的假设。