我们正在评估是否将基于 PostGres 构建的多租户 EAV 系统迁移到 Cassandra，我希望输入我们的模式方法，看看使用 Cassandra 进行测试是否有意义。我们的多租户系统层次结构由帐户-> 应用程序组成，其中一个帐户可以运行多个应用程序。查询需要按应用或帐户进行隔离（聚合帐户的所有应用数据）。帐户可以在我们的 EAV 模型中使用自己的自定义字段创建自己的数据对象。
我考虑过对 Cassandra 采用两种方法。第一种是在 1 个列族中保存一定数量的应用程序（比如 20 个）（以减少使用的列族数量）。每行将由 accountid->appid->dataobjectid->recordid 的复合列标识。将根据应用程序的需要为每个应用程序的数据对象动态添加列。这意味着如果列族有两个应用程序，第一个应用程序的 1 行可能定义了 20 列，而第二个应用程序可能定义了 30 列。这意味着这两个应用程序总共将有 50 个潜在的列。现在，应用程序的平均列数为 19。这意味着列族中的平均列数为 400。看起来很合理，并利用了 Cassandra 的宽列支持。实际上，我们可能很容易支持每个列族的更多应用程序。缺点是二级索引会很困难，因为我们不允许用户创建自己的索引，因此如果没有 .
第二种方法是让两个列族保存 1000 个应用程序的所有数据。第一个列族将具有与上述相同的复合列，但它将在 JSON 文档中保存该行的整个数据对象。第二个列族将具有相同的复合键，但会向键添加另一个值，即 fieldid 表示 json 文档中的字段（我们的应用程序元数据管理器存储 UUID 以识别 JSON 文档中的每个“字段”），但会每种数据类型都有一个“字段值”列 - 字符串、数字、小数、浮点数（日期和布尔值转换为数字）。这里的好功能是我们可以轻松地索引每个列以进行搜索，并且我们正在最大限度地减少我们创建的列族的数量。
上述两种方法的优缺点是什么？在上述场景中，我是否遗漏了一些明显或误解的 Cassandra（例如，我是否可以首先拥有如此宽的复合列）？对于这种类型的应用程序还有其他更好的架构建议吗？