开发基于 SaaS 的事件分析的最佳方法

Best Approach for Developing a SaaS-based Event Analytics

我的公司正在开发 SaaS 服务来存储事件并通过仪表板提供分析。

由于我们不会有删除或更新,我们的想法是创建一个基于列的 OLAP 架构,以从它提供的压缩和延迟中获益,而 PostgreSQL Citus 是我们打算评估的一个平台。

整体架构非常标准:API 将接收事件,然后以 JSON 格式将它们存储在 Kafka 上。然后,这些事件将被发送到 PostgreSQL。一些字段将是“jsonb”数据类型。

通过阅读文档,最佳做法是按租户 ID 分配表。

只是想仔细检查一些事情,非常感谢有人的意见:

  1. 上述架构有意义吗?有什么需要改变或注意的地方吗?
  2. 对于这种柱状方法,可以扩展的节点或分片的数量是否有限制?
  3. 是否支持GIN索引? (我相信是的,因为它没有在 'Limitations' 中列出)

谢谢!

我已经将 citus 用于多租户服务,并且按租户 ID 分发 tables 效果很好。

您描述的总体架构很有道理,但我不确定来自外部的人或至少没有一些细节的人是否可以为您提供更多工作。通过 Kafka 发送事件并处理它们以将其存储在某个地方是当今处理事件的一种非常标准的方式,因此那里没有发生任何疯狂的事情。

在节点数量方面似乎没有扩展限制,但您应该记住的是,如何设置分片从一开始就很重要。重新平衡将锁定您的 tables 并且可能需要一段时间才能完成,因此您希望尽可能保持它的小且易于处理。在这里查看更多详细信息:https://docs.citusdata.com/en/v10.2/faq/faq.html#how-do-i-choose-the-shard-count-when-i-hash-partition-my-data

支持 GIN 索引,因为他们在示例中使用了它:https://docs.citusdata.com/en/v10.2/use_cases/multi_tenant.html?highlight=GIN#when-data-differs-across-tenants

另外请注意,社区版本不支持故障转移。您必须使用支持故障转移的企业版,并且还允许您重新平衡 tables 而无需锁定整个 table.

我写了一个简单的服务来处理您可以使用的故障转移:https://github.com/Navid2zp/citus-failover