【问题标题】:Estimating the space requirement in Cassandra估计 Cassandra 中的空间需求
【发布时间】:2018-09-12 09:04:04
【问题描述】:

估计 Cassandra 所需空间的最佳/可靠方法是什么。我的集群由 Cassandra 3.11.2 上的 2 个节点(RHEL 6.5)组成。我想估计每个表中每行在我的数据库中的平均大小,以便我可以相应地进行计划。我知道一些方法,例如 nodetool status 命令、数据目录中使用的 du -sh 命令、nodetool cfstats 等。但是,这些方法中的每一个都给出了不同的值,因此我不确定在计算中应该使用哪一个。

我还发现,除了实际数据之外,Cassandra 还将各种元数据存储在各种特定于系统的表中,如 size_estimates、sstable_activity 等。这些元数据是否也随着数据而不断增加?此类元数据占用的空间与数据库中实际数据占用的空间的比例是多少?另外我应该记住 YAML 中的哪些特定配置(如果有)可能会影响数据的大小。

之前有人问过类似的question,但我对答案并不满意。

【问题讨论】:

  • 看这个:stackoverflow.com/questions/42736040/… 并看一下 datastax 学院 DS220 课程的幻灯片——那里有相应的公式......
  • 从 DS220 开始,在我看来,元数据大约会随着表中的行数线性增加。因此,在我看来,估计表每行大小的最佳方法是先在表中输入一些样本数据行,然后在数据目录上使用“du -sh”找出大小的变化,然后除以按行数。
  • 您指的是哪种元数据?公式中考虑了分区键等。您只需要知道文本或其他可变长度字段的平均大小
  • 有各种表,如 size_estimates、sstable_activity(都在系统键空间中)等,它们也存储一些数据。我不知道这些表存储的这些数据是否会随着我们数据库中的行数而增加,但是 DS220 中给出的公式(计算磁盘上的分区大小)也有一个组件(除了主键的大小和其他列),8*Nv,其中 Nv 是值的数量(之前解释过一些幻灯片)。我假设,这个组件代表我们添加一行时添加的所有元数据。
  • 从长远来看,系统表应该不会有太大的影响,也许除了痕迹。 8*Nv属于数据表中分区大小的计算

标签: cassandra cassandra-3.0


【解决方案1】:

如果您预计每天有 20 GB 的数据,这里是计算方法。

1 天 = 20 GB,1 个月 = 600 GB,1 年 = 7.2 TB,因此一年的原始数据大小为 7.2 TB,复制因子为 3,一年的数据约为 21.6 TB。

如果您使用大小分层压缩,则考虑到压缩和您的用例编写繁重。您将需要两倍的原始数据空间。

因此您需要大约 43 TB 到 45 TB 的磁盘空间。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-07-22
    • 1970-01-01
    • 2015-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-24
    • 1970-01-01
    相关资源
    最近更新 更多