如何在Postgresql中设计最佳且可扩展的唯一page_view表？

Question

在为PostgreSQL设计可伸缩的page_view日志sql模型时，我想出了最佳解决方案

我设计了一个模型

create table views(
uuid,
chapterid,
createdAt
)

将uuid和Chapterid索引为主键

create table daily_views(
day,
chapterid,
view_count
)

带有日期的预聚合表，chapterid被索引为主键

create table monthly_views(
monthyear,
chaperid,
view_count)

带有月年的预汇总表，chapterid被索引为主键

和带有年份的类似表格

但是，如果网站的访问量达到了如此之高，views表将膨胀数十亿行，但是由于它跟踪每个章节（针对书本）页面的唯一视图，因此我无法删除它。

我应该继续使用此架构还是使用时间序列数据库（我不能将timescaledb用于postgresql，因为rds（aws服务）不支持它）并为此托管我自己的ec2数据库实例？

我从这些数据中需要的是能够计算趋势，并能够计算与该章有关的每本书的总浏览量。...

Answer 1

理想地，这是PipelineDB扩展的完美用例，因为它允许以很少的开销进行实时统计（但会丢弃实际的输入数据）。为了保留实际（原始）数据，您应该真正考虑将Timescale扩展名随着时间的推移和不断增长的数据集具有合理的写延迟。 Citus还特别支持时间序列数据。

您也可以将两者结合使用，尽管目前尚不支持一流的服务。

• https://github.com/timescale/timescaledb/issues/14
• https://github.com/pipelinedb/pipelinedb/issues/1876

如果您真的不能使用其中任何一个，则基本上有2个选项可以决定要在哪里应用附加性能损失：

1. 写入性能下降：创建一个触发器，将触发器插入/更新到单独的统计表中
2. 读取性能下降：创建视图或直接执行聚合查询

物化视图的选项也适用，但是对当今的分析应用程序还提出了额外的近期要求。

最后但并非最不重要的一点是，不要忘记，不断增长的数据集本身将成为一个严重的问题。因此，从长远来看，如果您需要某种可扩展的东西，那么您绝对需要，即使在没有动态分区或其他技术的情况下开始，如果事情开始变慢，也应该有一个计划B

关于已经预见的数据集大小和不断增长的性质问题，您还应该考虑结果的精确度（不是 SHOULD ，而是必须根据业务要求）。请记住，所有较大的分析提供商都将向您显示近似值，但非常接近真实数字。

为此，请在其他counting options上进行阅读（例如，RDS至少支持Citus的HLL扩展名）。