我们的网上商店中有大约170万种产品，我们要记录该产品在1年的时间里有多少次浏览，我们希望至少每2小时记录一次浏览，问题是要使用哪种结构来执行此任务？
现在，我们尝试将统计信息保留在具有2列的记录中30天， classified_id,stats其中统计信息就像带格式date：views，date：views …的剥离的json …例如，一条记录看起来像
classified_id,stats
345422,{051216:23212,051217:64233} where 051216,051217=mm/dd/yy and 23212,64233=number of views
如果您想回溯1年，这当然是愚蠢的，因为如果您想获得1000种产品的视图总数，则需要从数据库中获取30mb之类的数据并自己计算。
我们现在想到的另一种方法是拥有一个具有3列的大型表classified_id,date,view并将其记录存储在其自己的行上，这当然将导致一个具有亿万行的巨大表，例如，如果我们有1.8数百万的分类广告，并每隔2小时保持一年24/7的记录
classified_id,date,view
1800000 * 365 * 12 = 7.884.000.000（十亿个带B的行）虽然在postgres的理论极限之内，但我想想它的查询（例如更新视图）即使有正确的索引也会被占用一段时间
有什么建议？我什至无法想象Google Analytics（分析）如何存储统计信息…
这个数字不像您想的那样高。在当前的工作中，我们存储网站的指标数据，而我们拥有的总行数要高得多。在之前的工作中，我使用了pg数据库，该数据库从移动网络收集了指标，每天收集约20亿条记录。因此，不要害怕数十亿的记录。
您肯定需要对数据进行分区- 最有可能是按天。有了这么多的数据，您会发现索引毫无用处。取决于您将在EXPLAIN命令输出中看到的平面。例如，该电信应用程序根本不使用任何索引，因为它们只会降低整个引擎的速度。
EXPLAIN
另一个问题是您需要如何快速响应查询。以及您允许用户查询的粒度（每小时，几天，几周之和的总和）中的哪一步。您甚至可能需要对诸如周，月或季度之类的粒度进行一些汇总。
添加：
每天，该电信应用程序中约20亿条记录的每日消耗量约为290GB。这意味着使用带有COPY命令的大容量插入每秒可插入约23000条记录。每个批量都有数千条记录。原始数据按分钟划分。为了避免磁盘等待，db在4个不同的磁盘/阵列上有4个表空间，并在其上分配了分区。PostreSQL能够处理所有问题。因此，您也应该考虑正确的硬件配置。
好的主意也是将pg_xlog目录移动到单独的磁盘或阵列。不只是不同的文件系统。所有这些都必须是单独的硬件。我只能在具有正确错误检查的阵列中推荐SSD。最近，我们遇到了单个SSD上数据库损坏的问题。
