我们在上一家公司尝试使用Postgres进行大规模分析 https://threekit.com 但……

>在用户会话期间记录了20亿条用户事件。当数据量超过5亿条时，发现几乎无法实时查询这个表——它基本上无法操作，因为太慢了。 这是一个已经解决的问题，看起来那里的技术人员缺乏让它正常工作的技能。有索引只是冰山一角。组合索引、分区、分片、缓存等方法可以将磁盘上的读取时间降低到几秒钟。

> 一个包含大约20亿条用户会话事件记录的快速增长的表。当它超过5亿条记录时，发现无法以接近实时的方式查询这个表。 我的意思是，我不确定你所说的“接近实时”是什么意思，以及你做了什么样的查询，但我用Postgres处理一个200亿行的表请求时，情况还不错，只需要对索引和分区做一些轻微调整（我并不是数据库管理员）。 除非我们深入探讨数据和查询的具体细节，否则我认为从任何一方的经验中都无法得出任何结论。

>> 明确一点，标准的SQL数据库不适合大规模分析。 你所说的“标准”SQL是什么意思？当你遇到这些困难时，你使用的是OLTP还是OLAP数据库？另外，什么让BigQuery不被视为“标准SQL数据库”——它们使用GoogleSQL，没错，但许多数据库都有轻微的SQL变体。

你使用的是普通的Postgres表，还是像Timescale、Citus或pg_mooncake这样的列式扩展？ 没有谁会理智地认为没有列式存储的Postgres适合分析。然而，这些扩展似乎相当不错，至少在查询方面（你可能仍然会遇到写入性能问题，因为Postgres的OLTP架构，但我从未进行过基准测试）。从OLAP的角度来看，你的数据量很小，这可能运行得非常好。 我个人非常推崇专门的数据库，比如ClickHouse。随着数据和查询量的增长，BigQuery会变得非常昂贵。

作为一名处理数十亿条记录的人，BigQuery远非便宜；G会为你存储数据收取很少的费用，但会为查询和数据传输收取很多费用。 据我所知，GCP上最便宜的Postgres服务器相比普通的Postgres安装（性价比）要贵得多。

> 它基本上是无法触及的，因为它太慢了。 我曾经在Snowflake上处理过一个包含50亿行的表，可能没有索引，虽然有点慢，但你仍然可以在一两分钟内运行合理的查询。

同样。我开始将数据写入parquet，然后从那里进行分析，性能和托管成本都有了显著提升

> 基本上我们开始收集详细的分析数据，因此我们有一个快速增长的表，包含大约20亿条用户会话中的事件记录。当它增长到超过5亿条记录时，发现几乎不可能在接近实时的情况下查询这个表。 分析通常不需要实时能力，这是一方面。 > 一个快速增长的表[强调部分是我加的] 我认为我看到了问题的一部分。如果你有一个单独的表，这意味着它完全反规范化了，所以你的模式可能看起来像这样（或更宽）： CREATE TABLE UserEvent ( id UUID PRIMARY KEY, user_id UUID NOT NULL, user_ip_address TEXT NOT NULL, user_agent TEXT NOT NULL, event_data JSONB, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), event_type TEXT ); CREATE INDEX UserEvent_user_id_idx ON UserEvent (user_id); CREATE INDEX UserEvent_created_at_idx ON UserEvent (created_at); …