cassandra - 了解cassandra存储的内部数据

cassandra - 了解cassandra存储的内部数据,第1张

我有这张桌子

create table comment_by_post
(
    postId uuid,
    userId uuid,
    cmntId timeuuid,
    cmntTxt text,   
    cmntBy text,
    time bigint, 
    primary key ((postId, userId),cmntId)
)

这是此表中的内部数据

RowKey: 4978f728-0f96-11e5-a6c0-1697f925ec7b:4978f728-0f96-12e5-a6c0-1697f92e537a
=> (name=d3f02a30-126f-11e5-879b-e700f669bcfc:, value=, timestamp=1434270721107000)
=> (name=d3f02a30-126f-11e5-879b-e700f669bcfc:cmnttxt, value=636d6e743434, timestamp=1434270721107000)
-------------------
RowKey: 4978f728-0f96-11e5-a6c0-1697f925ec7b:4978f728-0f96-12e5-a6c0-1697f92eec7a
=> (name=465fee30-126f-11e5-879b-e700f669bcfc:, value=, timestamp=1434270483603000)
=> (name=465fee30-126f-11e5-879b-e700f669bcfc:cmnttxt, value=636d6e7432, timestamp=1434270483603000)
=> (name=4ba89f40-126f-11e5-879b-e700f669bcfc:, value=, timestamp=1434270492468000)
=> (name=4ba89f40-126f-11e5-879b-e700f669bcfc:cmnttxt, value=636d6e7431, timestamp=1434270492468000)
=> (name=504a61f0-126f-11e5-879b-e700f669bcfc:, value=, timestamp=1434270500239000)
=> (name=504a61f0-126f-11e5-879b-e700f669bcfc:cmnttxt, value=636d6e7433, timestamp=1434270500239000)
-------------------
RowKey: 4978f728-0f96-11e5-a6c0-1697f925ec7b:4978f728-0f96-12e5-a6c0-1697f92e237a
=> (name=cd1e8f30-126f-11e5-879b-e700f669bcfc:, value=, timestamp=1434270709667000)
=> (name=cd1e8f30-126f-11e5-879b-e700f669bcfc:cmnttxt, value=636d6e7433, timestamp=1434270709667000)

如果我primary key (postId, userId,cmntId)那么它就像:

RowKey: 4978f728-0f96-11e5-a6c0-1697f925ec7b
=> (name=4978f728-0f96-12e5-a6c0-1697f92eec7a:971da150-1260-11e5-879b-e700f669bcfc:, value=, timestamp=1434264176613000)

=> (name=4978f728-0f96-12e5-a6c0-1697f92eec7a:971da150-1260-11e5-879b-e700f669bcfc:cmnttxt, value=636d6e7431, timestamp=1434264176613000)

=> (name=4978f728-0f96-12e5-a6c0-1697f92eec7a:a0d4a900-1260-11e5-879b-e700f669bcfc:, value=, timestamp=1434264192912000)

=> (name=4978f728-0f96-12e5-a6c0-1697f92eec7a:a0d4a900-1260-11e5-879b-e700f669bcfc:cmnttxt, value=636d6e7432, timestamp=1434264192912000)

=> (name=4978f728-0f96-12e5-a6c0-1697f92eec7a:a5d94c30-1260-11e5-879b-e700f669bcfc:, value=, timestamp=1434264201331000)

为什么会这样,两者的好处是什么?

最佳答案:

2 个答案:

答案 0 :(得分:4)

Christopher已经解释了如何将分区键连接在一起以生成用于存储的rowkey,因此我不会重新哈希(没有双关语)。但我将解释这两种方法的优缺点。

PRIMARY KEY (postId, userId,cmntId)

使用此PRIMARY KEY,您的数据将按postId进行分区,并按userIdcmntId进行聚类。这意味着,帖子上发表的所有评论都将由postId存储在磁盘上,然后分别按userIdcmntId排序。

这里的优势在于您具有查询灵活性。您可以查询帖子的所有评论,也可以查询特定用户对帖子的所有评论。

缺点是,与其他解决方案相比,您获得无限行增长的可能性更高。如果您的每列postId的总列数超过20亿,那么您最多可以为每个postId存储多少数据。但是你每个帖子存储那么多评论数据的可能性很低,所以你应该没问题。

PRIMARY KEY ((postId, userId),cmntId)

此解决方案通过将postIduserId(按cmntId排序的串联行键存储评论数据,有助于否定无限行增长的可能性。这就是优于其他解决方案。

缺点是失去了查询灵活性,因为现在您需要为每个查询提供postIduserId。这个PRIMARY KEY定义根本不支持仅postId的注释查询,因为Cassandra CQL要求您为查询提供整个分区键。

答案 1 :(得分:2)

第一个主键使用postIduserId作为分区键,cmntId作为群集列。请注意,RowKey使用的值包含postIduserId之间由:分隔的值。接下来,聚类列的值将用于行中每个单元格的名称。

在第二个示例中,主键缺少分区键周围的括号。它们可以省略,但通常优选存在,因为我们可以明确地确定主键的哪些部分用于分区和群集。如果未包含额外括号,则仅使用第一列作为分区键(在cassandra-cli的RowKey值中可见)。假设所有后续列都是聚类列,我们可以通过查看单元名称进行验证。

本文经用户投稿或网站收集转载,如有侵权请联系本站。

发表评论

0条回复