卡桑德拉：哪个是手工索引的最佳选择

Question

首先，请原谅我的英文。这不是我的母语。我正在将SQL数据库移动到Cassandra，但我有一个问题，我无法解决。假设我有一个存储歌曲的SQL表。每首歌都有一个ID作为主键，它允许访问所有相关数据，这些数据存储在由键给出的行的字段中。我也有一些索引使用一些不同的标准作为作者，性别，标题...

当我想到移动到卡桑德拉模式，我工作围绕的想法，我可以创建一个等效的列家庭，其中歌曲ID是行键，歌曲属性是列。然后，我可以创建5或6个手动索引来按作者，标题，性别等进行搜索。作者，标题...将作为列键（添加一些额外的数据以使它们保持唯一性，使用复合列名称），并且该值将是静态列族中用于搜索的歌曲ID，其中每行由歌曲ID。

但我在这里出现我的疑问。什么更好：每个索引CF只存储ID还是存储所有属性？第一个选项允许我减少必要的内存量，但是我需要（至少）2次读取才能获得每首歌曲的属性。有了第二个选项，我需要更多的内存，因为每个索引重复一次相同的信息，但通过一次读取，我可以获得我需要的所有属性。我想我可以假设需要额外的内存，如果这将是一个更快的模式，但它会更快？拥有更大的数据库不会使其工作变慢？或者较慢的操作是由于Cassandra存储行的方式以及由于2次读取而搜索由索引CF给出的每一行？我使用第二个选项（在CF中存储所有作为“索引”的属性）计算出我比第一个选项需要大约80％的内存（CFs真的可以作为索引来查找歌曲的“主要”CF中的正确数据）。

任何帮助将不胜感激。

在此先感谢！

Answer 1

你也想看看宽行模式。一些类似PlayOrm的库为你做了这种模式，这样你就可以做一些类似可伸缩SQL的事情（即使用分区）。你可以拥有任意数量的分区。我确信将来会有越来越多的NoSql对象映射库存在...... PlayOrm的wiki上还有一个模式页面，它没有Sql模式和PlayOrm模式......您可能想要检出nosql的模式。

Answer 2

当然，在不同的数据模型中有各种各样的权衡，但听起来你最关心的是数据集大小和访问速度。 Cassandra可以线性扩展的方式处理大量的数据，只要您可以为其提供必要的资源来完成这项工作。另一方面，当你做钥匙时，做两次查找是非常便宜的。我的直觉是只存储ID，如果没有其他原因，它会更容易更新您的属性。然后，如果您发现查询速度不够快，您可以进行优化。不过，从RDBMS来看，我猜测它会很快。