我主持了一个流行的网站，并希望存储某些用户事件以供稍后分析。比如：点击项目，添加到购物车，从购物车中删除，等等。我想每天大约会有5000000多个新事件出现。
我的基本想法是接收事件，并将其与一个唯一的用户id一起存储在Postgres中。
处理这么多数据的策略是什么？我无法想象一张巨大的桌子是现实的。我有几个人推荐过这样的东西：每天结束时将表转储到Amazon Redshift、Snowflake、Google BigQuery、Hadoop。
你会怎么做？
我会对表进行分区，一旦您不需要实时系统中的详细数据，就分离一个分区并将其导出到存档和/或聚合，并将结果放入数据仓库进行分析。
我们对PostgreSQL 10和11有类似的用例。我们从客户的网站收集不同的指标。
我们有几个用于不同数据的分区表，每天总共收集超过3亿行，即每天50-80GB的数据。在一些特殊的日子里，甚至是2x-3x。
收集数据库可以保存当前和最后一天的数据(因为尤其是在午夜前后，来自世界不同地区的时间戳可能会一团糟)。
在以前的版本PG 9.x上，我们每天向我们的主要PostgreSQL仓库数据库传输1次数据(目前为20+TB)。现在我们实现了从收集数据库到仓库的逻辑复制，因为最近整个分区的同步非常繁重和漫长。
除此之外，我们每天都会将新数据复制到Bigquery中进行非常繁重的分析处理，这在PostgreSQL上需要大约24小时以上的时间(现实生活中的结果-相信我)。在BQ上，我们几分钟就能得到结果，但有时会为此付出很多…
所以日常分区是合理的分区。尤其是使用逻辑复制时，您不必担心。根据我们的经验，我建议不要从收集数据库中向BQ等进行任何导出。仅来自仓库。