我们的eShop中有大约170万个产品，我们想记录该产品在1年期间有多少观点，我们希望在每个至少2小时的情况下记录观点问题是该任务要使用什么结构？
现在，我们尝试在具有2列classified_id,stats的记录中保存统计数据，其中统计数据就像是带有格式日期的剥离JSON：视图，日期：视图：例如，记录看起来像
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，我们需要
1800000*365*12 = 7.884.000.000（数十亿个带有b）行，虽然它位于邮政的理论限制内，但我想象的查询（例如更新视图），即使使用正确的索引，有正确的索引，将花一些时间。
有什么建议吗？我什至无法想象Google Analytics（Google Analytics）如何存储统计信息...
这个数字不如您想象的那么高。在当前的工作中，我们存储网站的指标数据，我们拥有的行总量要高得多。在以前的工作中，我与PG数据库合作，该数据库收集了移动网络的指标，并且每天收集了约20亿个记录。因此，不要害怕数十亿的记录。
您肯定需要分区数据 - 很可能是一天。有了这一数量的数据，您可以发现索引毫无用处。取决于您将在EXPLAIN命令输出中看到的平面。例如，电信应用程序根本没有使用任何索引，因为它们只会放慢整个引擎。
另一个问题是您需要的查询响应速度有多快。以及您将允许用户允许的查询的粒度步骤（总计数小时/天/周等）。您甚至可能需要为诸如每周，一个月或季度等粒度的粒子进行一些聚合。
加法：
该电信应用程序中每天约有200千万张记录每天约为290GB。这意味着使用copy命令使用散装插入物插入约23000条记录。每个体积都是数千个记录。原始数据按几分钟分配。为了避免磁盘等待，DB在4个不同的磁盘/阵列上有4个表格，并且在它们上分配了分区。Posttresql能够无需任何问题就可以处理所有问题。因此，您也应该考虑适当的HW配置。
好主意也是将pg_xlog目录移至单独的磁盘或数组。不仅仅是不同的文件系统。所有这些都必须是单独的HW。SSD我只能在适当错误检查的数组中推荐。最近，我们在单SSD上遇到了损坏数据库的问题。
首先，请勿使用数据库记录统计信息。或者，至少使用其他数据库。日志的写作开销将降低您的WebApp的响应能力。而且您的日常备份将需要更长的时间，因为不需要如此频繁地备份的大桌子。
我选择的"自己动手"解决方案是将异步写入日志文件，然后然后处理这些文件以在分析数据库中构造统计信息。在此响应中，有很好的代码段。或者，您可以基准为Java可用的许多登录器中的任何一个。
还要注意，有一些专门设计用于收集此类信息的产品。
另一种可能性是在HBase或Cassandra（例如HBase或Cassandra）中创建一个时间序列。在这种情况下，您将有每个产品的一排，并且列的列与命中率一样多。
最后，如果您要使用数据库进行操作，如@josmac所指向的那样，创建分区，请尽可能多地避免索引。将FillFactor存储参数设置为100。您也可以考虑未加入的表。但是，在关闭书面日志之前，请彻底阅读postgresql文档。
只是为您提出另一个非RDBMS选项（因此，一个偏离主题），您可以将文本文件（CSV，TSV，JSON，PARCOET，ORC）发送到Amazon S3并使用AWS Athena使用SQL直接查询。
由于它会查询免费文本文件，因此您可能只能发送未过滤的博客，并通过JDBC查询它们。