计算Cassandra中表的大小

时间:2017-03-11 13:53:12

标签: cassandra

In" Cassandra The Definitive Guide" (第2版)作者:Jeff Carpenter& Eben Hewitt,下面的公式用于计算磁盘上表的大小(模糊部分的道歉):

table size equation

  • ck:主键列
  • cs:静态列
  • cr:常规列
  • cc:群集列
  • Nr:行数
  • Nv:它用于计算时间戳的总大小(我不完全得到这个部分,但现在我忽略它)。

在这个等式中,有两件事我不明白。

首先:为什么每个常规列都会计算群集列大小?我们不应该将它乘以行数吗?在我看来,通过这种方式计算,我们说每个聚类列中的数据都会被复制到每个常规列中,我认为不是这样。

第二:为什么主键列不会乘以分区数?根据我的理解,如果我们有一个带有两个分区的节点,那么我们应该将主键列的大小乘以2,因为我们在该节点中有两个不同的主键。

3 个答案:

答案 0 :(得分:12)

这是因为Cassandra的版本< 3内部结构。

  • 每个不同的分区键值只有一个条目。
  • 对于每个不同的分区键值,静态列只有一个条目
  • 群集密钥
  • 有一个空条目
  • 对于一行中的每一列,每个群集键列都有一个条目

我们举一个例子:

CREATE TABLE my_table (
    pk1 int,
    pk2 int,
    ck1 int,
    ck2 int,
    d1 int,
    d2 int,
    s int static,
    PRIMARY KEY ((pk1, pk2), ck1, ck2)
); 

插入一些虚拟数据:

 pk1 | pk2 | ck1 | ck2  | s     | d1     | d2
-----+-----+-----+------+-------+--------+---------
   1 |  10 | 100 | 1000 | 10000 | 100000 | 1000000
   1 |  10 | 100 | 1001 | 10000 | 100001 | 1000001
   2 |  20 | 200 | 2000 | 20000 | 200000 | 2000001

内部结构将是:

             |100:1000:  |100:1000:d1|100:1000:d2|100:1001:  |100:1001:d1|100:1001:d2|  
-----+-------+-----------+-----------+-----------+-----------+-----------+-----------+
1:10 | 10000 |           |  100000   |  1000000  |           |  100001   |  1000001  |


             |200:2000:  |200:2000:d1|200:2000:d2|
-----+-------+-----------+-----------+-----------+ 
2:20 | 20000 |           |  200000   |  2000000  |

因此表格的大小为:

Single Partition Size = (4 + 4 + 4 + 4) + 4 + 2 * ((4 + (4 + 4)) + (4 + (4 + 4))) byte = 68 byte

Estimated Table Size = Single Partition Size * Number Of Partition 
                     = 68 * 2 byte
                     = 136 byte
  • 这里所有的字段类型都是int(4字节)
  • 有4个主键列,1个静态列,2个聚类键列和2个常规列

更多:http://opensourceconnections.com/blog/2013/07/24/understanding-how-cql3-maps-to-cassandras-internal-data-structure/

答案 1 :(得分:7)

作为作者,我非常感谢您提出的问题和您对材料的参与!

关于原始问题 - 请记住,这不是计算表大小的公式,而是计算单个分区大小的公式。目的是将这个公式用于"最坏情况"用于标识过大分区的行数。您需要将此等式的结果乘以分区数,以估算表的总数据大小。当然,这不会考虑复制。

还要感谢回答原始问题的人。根据您的反馈,我花了一些时间查看新的(3.0)存储格式,看看是否会影响公式。我同意Aaron Morton的文章是一个有用的资源(上面提供的链接)。

该公式的基本方法对于3.0存储格式仍然是合理的。公式的工作方式,您基本上都在添加:

  • 分区键和静态列的大小
  • 每行的聚类列的大小,乘以行数
  • 每个单元格的8个字节的元数据

更新3.0存储格式的公式需要重新访问常量。例如,原始等式假定每个单元格有8个字节的元数据来存储时间戳。新格式将单元格上的时间戳视为可选,因为它可以在行级别应用。因此,现在每个单元的元数据量可变,可能低至1-2个字节,具体取决于数据类型。

在阅读了本章的反馈并重新阅读本章的这一部分之后,我计划更新文本以添加一些说明以及关于此公式作为近似而非精确值有用的更强有力的警告。它根本没有考虑因素,例如分布在多个SSTable上的写入以及墓碑。我们实际上计划在今年春天(2017年)进行另一次印刷以纠正一些勘误,所以很快就会看到这些变化。

答案 2 :(得分:7)

以下是Artem Chebotko的更新公式:

Formula

t_avg是每个单元格的平均元数据量,可以根据数据的复杂程度而变化,但8是最差的估计值。