【问题标题】:cassandra: `sstabledump` output questionscassandra:`sstabledump` 输出问题
【发布时间】:2018-04-27 09:06:44
【问题描述】:

我正在检查sstabledump 的输出,以便更好地了解 cassandra 数据模型,我有一些问题

sstabledump的输出看来

  1. 表是分区列表(按分区键分割)
  2. 分区是行的列表(根据集群键拆分)
  3. 一行是键值对的映射,其中的键属于预定义列表

问题 1:对于每个分区,以及分区内的每一行,都有一个 position 键。这个值对应什么?物理存储详细信息?具体如何?

问题2:每个分区内的每一行都有一个type: row键值对。这种类型会是别的吗?如果是,是什么?如果没有

  • 为什么有一个始终相同的值?
  • 为什么cassandra被归类为宽列等类似术语?看起来更像是两级行存储。

【问题讨论】:

    标签: cassandra nosql


    【解决方案1】:

    分区键是您指定为主键的 murmur3 哈希值。 Consistent hashing 与该哈希一起用于确定该分区属于集群中的哪个节点及其副本。在每个分区内,数据按聚类键排序,然后按行内的单元格名称排序。该结构被使用,因此如果一次为一行插入时间戳等冗余内容,则仅作为分区中的 vint delta 序列插入一次以节省空间。

    在磁盘上,分区按此散列键的顺序排序。 position 键的输出只是指它在 sstable 的数据文件中的位置(解压缩的字节偏移量)。 type 还可以在该位置识别为静态块,该块位于每个分区的开头,用于任何静态单元或远程墓碑标记(开头或结尾)。请注意,即使没有物理写入磁盘(即重复的时间戳),有时也会在 json 中重复用于 sstabledump 的值以提高可读性。

    您可以在一个分区中包含许多这样的行,例如时间序列的一个常见数据模型是使用时间戳作为集群键,它可以创建具有数百万行的非常宽的分区。 Pre 3.0 以及数据存储更接近big table 的设计。它本质上是一个Map<byte[], SortedMap<byte[], Cell>>,其中排序映射的比较器根据模式进行了更改。它没有区分分区内的行和列,并且会导致大量冗余数据,并且经过重新设计以更好地适应查询语言。

    更多参考资料:

    【讨论】:

    • 那么,"type": "row" 是早期版本的遗留物吗?没有其他"type" 值吗?
    • 其他类型有static_blockrange_tombstone_boundrange_tombstone_boundary
    • @ChrisLohfink 这些是否记录在某处?具体来说,我想更好地理解range_tombstone_boundrange_tombstone_boundary
    • 目前不是,存储引擎表示是一种内部细节,可以从版本到版本(即它在 3.0 中完全重写,但从查询和模式级别的角度来看大部分是不可见的)。墓碑发生了很大变化,但行为相同,只是范围墓碑变得更有效。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-08-31
    • 2011-09-05
    • 1970-01-01
    • 2012-06-15
    • 1970-01-01
    • 1970-01-01
    • 2018-12-18
    相关资源
    最近更新 更多