0

首先，对不起我的英语。这不是我的母语。我正在将 SQL 数据库移至 Cassandra，但我有一个无法解决的问题。假设我有一个存储歌曲的 SQL 表。每首歌曲都有一个 ID 作为主键，它允许访问其所有相关数据，这些数据存储在由键给出的行的字段中。我还有一些索引可以使用一些不同的标准进行搜索，例如作者、性别、标题......

当我考虑将其移至 Cassandra 模式时，我围绕着这样一个想法，即我可以创建一个等效的列族，其中歌曲 ID 是行键，歌曲属性是列。然后，我可以创建 5 或 6 个手动索引来按作者、标题、性别等进行搜索。作者，标题...将是列键（添加一些额外的数据以保持它们的唯一性，使用复合列名），值将是用于在静态列族中搜索的歌曲 ID，其中每一行由歌曲ID。

但我在这里出现了我的怀疑。哪个更好：每个索引 CF 只存储 ID 还是存储所有属性？第一个选项允许我减少必要的内存量，但我需要（至少）2 次读取来获取每首歌曲的属性。使用第二个选项，我需要更多内存，因为每个索引重复一次相同的信息，但是通过一次读取，我可以获得我需要的所有属性。如果这将是一个更快的模式，我想我可以假设需要额外的内存，但是，它真的会更快吗？拥有更大的数据库不会使其工作速度变慢吗？或者由于 Cassandra 存储行的方式和 2 次读取，较慢的操作是搜索索引 CF 给出的每一行？

另一个细节：我计算出使用第二个选项（将所有属性存储在作为“索引”的 CF 中）我需要比使用第一个选项多 80% 的内存（CF 确实可以作为索引来查找正确的数据）歌曲的“主要”CF）。

任何帮助将不胜感激。

提前致谢！

4

2 回答 2

0

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

于 2013-01-15T19:30:29.793 回答
0

您还需要查看宽行模式。像 PlayOrm 这样的一些库会为您执行该模式，因此您可以执行诸如 Scalable SQL（即带有分区）之类的操作。您可以拥有任意数量的分区。我相信未来也会有越来越多的 NoSql 对象映射库存在……PlayOrm 的 wiki 上也有一个模式页面，其中包含 noSql 模式和 PlayOrm 模式……你可能想查看 nosql 的.

于 2013-01-16T00:12:32.680 回答