Cassandra multitenant配置选项

Question

我们正在评估是否要将构建于PostGres上的多租户EAV系统移至Cassandra，并且希望通过我们的架构方法获取输入以查看Cassandra是否合理。我们的多租户系统分层结构由帐户 - >应用程序组成，帐户可以运行多个应用程序。查询需要根据应用程序或帐户进行分隔（聚合帐户的所有应用程序数据）。帐户可以在我们的EAV模型中使用自己的自定义字段创建自己的数据对象。

有两种方法，我考虑采用卡桑德拉。首先是在1列系列中保存一定数量的应用程序（比如20）（以减少使用的列族数量）。每行将由accountid-> appid-> dataobjectid-> recordid的组合列标识。根据应用的需要，将为每个应用的数据对象实时添加列。这意味着如果列家族有两个应用程序，第一个应用程序的1行可能定义了20列，而第二个应用程序可能定义了30列。这意味着这两个应用程序总共会有50个可能的列。目前，应用程序的平均列数为19.这意味着列系列中的平均列数将为400.看起来合理并利用了Cassandra的广泛列支持。实际上，我们可能很容易为每个列族支持更多的应用程序。缺点是二级索引会很困难，因为我们不允许用户创建他们自己的索引，因此查询在没有索引的情况下效率不高。

第二种方法是让两个列家族拥有1000个应用的所有数据。第一列家族将具有与上面相同的组合列，但它将在JSON文档中保存该行的整个数据对象。第二列家族将具有相同的组合键，但是会为表示json文档中的字段的fieldid的键添加另一个值（我们的应用元数据管理器存储UUID以标识JSON文档中的每个“字段”），但会每个数据类型都有一个“fieldvalue”列 - 字符串，数字，小数点，浮点数（日期和布尔值被转换为数字）。这里的优点是，我们可以很容易地为搜索目的索引每个列，并且我们正在最小化我们创建的列家族的数量。

以上两种方法的优缺点是什么？我是否在上述场景中错过了明显或误解Cassandra的东西（例如，我可以拥有首先是如此宽的复合列）？对于这种类型的应用程序是否还有其他更好的架构建议？

Answer 1

我认为在决定数据模型时需要回答的第一个问题是“我该如何查询这些数据？”一般来说，在任何一个模型中，您都无法接近CF，列或组合中的组件数量，所以我不担心这一点。

考虑到您担心第一个模型中缺少辅助数据，这告诉我，按值查询功能可能很重要。如果是这样，第二个型号可能为您提供更好的服务。需要注意的是，辅助人员在基数较低的情况下工作得最好，而且您的数据可能不适合这种情况。如果没有，你可以很容易地创建你自己的索引，在这种情况下，任何模型都可以工作。

我的建议是弄清楚你打算如何读取你的数据，然后计划你的模型来匹配你的读取模式。如果您不确定，请与两种模型一起玩，看看哪种模式效果最好。根据我的经验，通常需要不止一次迭代才能制定出一个好的模型，并且您不应该害怕以不止一种方式编写数据。规范化不是这里的目标。如果您想更深入地讨论您的模型，请查看freenode上的Cassandra IRC频道（#cassandra）。