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

Question

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

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

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

通过读取文档，最佳实践是按租户id分发表。

我只想检查几件事，并非常感谢别人的意见：

1. ，上面描述的体系结构是否有意义？我们有什么需要改变或注意的地方吗？
2. ，对于这种列式方法，节点或碎片的数量是否有限制？
3. 是否支持GIN索引？(我认为是的，因为它没有在'Limitations')

中列出

谢谢!

Answer 1

我已经将citus用于多租户服务，并且承租者id的分发表运行得很好。

您所描述的总体架构是有意义的，但我不确定来自外部的人或者至少没有一些细节的人是否能给您更多的工作机会。通过Kafka发送事件并将其存储在某个地方是目前处理事件的一种非常标准的方式，因此没有什么疯狂的事情发生。

在节点数量方面，似乎没有扩大的限制，但您应该记住的是，从一开始就设置了碎片计数。再平衡会锁定你的桌子，并可能需要一段时间来完成，所以你想保持它尽可能小和容易处理。想了解更多细节，请看这里：https://docs.citusdata.com/en/v10.2/faq/faq.html#how-do-i-choose-the-shard-count-when-i-hash-partition-my-data

在示例中使用GIN索引时，支持GIN索引：https://docs.citusdata.com/en/v10.2/use_cases/multi_tenant.html?highlight=GIN#when-data-differs-across-tenants

另外，请注意，在社区版本中，您将没有故障转移支持。您必须使用支持故障转移的企业版，并且允许您在不锁定整个表的情况下重新平衡表。

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