我们正在评估是否将基于PostGres构建的多租户EAV系统移至Cassandra，我希望对我们的架构方法进行输入，以确定使用Cassandra进行测试是否有意义。我们的多租户系统层次结构由account-＆gt; app组成，其中一个帐户可以运行多个应用。查询需要按应用或帐户进行隔离（聚合帐户的所有应用数据）。帐户可以在我们的EAV模型中使用自己的自定义字段创建自己的数据对象。
我考虑过采用Cassandra的两种方法。第一种是在一个列族中保留一定数量的应用程序（比如说20个）（以减少使用的列族数）。每行将由accountid-＆gt; appid-＆gt; dataobjectid-＆gt; recordid的复合列标识。根据该应用的需要，可以为每个应用的数据对象动态添加列。这意味着如果列族有两个应用程序，则第一个应用程序的1行可能定义了20个列，而第二个应用程序可能定义了30个列。这意味着这两个应用程序总共有50个潜在列。现在，应用程序的平均列数为19.这意味着列族中的平均列数为400.似乎合理并利用了Cassandra的广泛列支持。事实上，我们可能很容易支持每列家庭更多的应用程序。缺点是二级索引很难，因为我们不允许用户创建自己的索引，因此如果没有，查询就无法提高效率。
第二种方法是让两个列家族保存1000个应用程序的所有数据。第一列系列将具有与上面相同的复合列，但它将在JSON文档中保存该行的整个数据对象。第二列系列将具有相同的复合键，但会向键添加另一个值，该键是表示json文档中的字段的fieldid（我们的应用程序元数据管理器存储UUID以标识JSON文档中的每个“字段”），但是每个数据类型都有一个“fieldvalue”列 - 字符串，数字，小数，浮点数（日期和bool转换为数字）。这里的一个很好的功能是我们可以轻松地为每个列编制索引以用于搜索目的，并且我们正在最小化我们创建的列系列的数量。
上述两种方法的优点和缺点是什么？在上面的场景中，我是否遗漏了一些明显或误解Cassandra的东西（例如，我可以首先使用如此宽的复合列）吗？对于这种类型的应用程序，是否还有其他更好的架构建议？
答案 0 :(得分：2)
我认为在决定数据模型时需要回答的第一个问题是“我打算如何查询这些数据？”一般来说，在任何一个模型中，你在CFs，列或组合数量方面都没有接近极限，所以我不担心。
考虑到您担心第一个模型中缺少辅助字符，这告诉我按值查询功能可能很重要。如果是这样，第二个模型可能为您提供更好的服务。需要注意的是，在基数较低的情况下，辅助数据库效果最好，而且您的数据可能不适合这种情况。如果没有，您可以很容易地创建自己的索引，在这种情况下，任何一个模型都可以。
我的建议是弄清楚你打算如何阅读你的数据，然后计划你的模型以符合你的阅读模式。如果您不确定，可以使用两种型号来查看哪种型号效果最佳。根据我的经验，通常需要不止一次迭代才能得出一个好的模型，而且您不应该害怕以多种方式编写数据。规范化不是这里的目标。如果您想更深入地讨论您的模型，请查看freenode（#cassandra）上的Cassandra IRC频道。