2

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

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

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

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

只是想仔细检查一些事情，并非常感谢某人的意见：

  1. 上面描述的架构有意义吗？有什么我们应该改变或注意的吗？
  2. 对于这种列式方法，可以横向扩展的节点或分片数量是否存在限制？
  3. 是否支持 GIN 索引？（我相信是，因为它没有在“限制”中列出）

谢谢！

4

1 回答 1

1

我已经将 citus 用于多租户服务，并且按租户 ID 分配表效果很好。

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

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

支持 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

于 2021-11-22T07:46:24.300 回答