DCE Cassandra 3.9 在加入现有集群期间创建二级索引缓慢

Posted

技术标签:

【中文标题】DCE Cassandra 3.9 在加入现有集群期间创建二级索引缓慢【英文标题】:DCE Cassandra 3.9 slow secondary index creation during joining existing cluster 【发布时间】:2017-04-14 06:33:06 【问题描述】:

我们有 32 个节点的 cassandra 集群,平均节点大小约为 1TB。节点配置 1xIntel Xeon E3-1271v3,32GB 内存,2x3TB HDD。 我们有一个带有一些小表和一个大表的数据库,其中包含大约 90-95% 的总集群大小。

我尝试向这个集群添加额外的节点,但突然发现,向现有集群添加一个节点大约需要 13-14 天才能加入集群。构建二级索引花费了大部分时间,而且我看到所有压缩线程都占用了所有可用的 CPU。

我已将 cassandra 配置更改为扩展限制:

concurrent_compactors:4 compaction_throughput_mb_per_sec: 0

Cassandra full config

Schema

大约 1 年前,我们还向这个集群添加了新节点,并将其从 16 个节点扩展到 32 个节点的集群,集群扩展之前的平均节点大小为 1TB。 Cassandra 版本是 2.1。一个节点加入时间为1-1.5天。

那么问题是我们如何加快这个过程?我们错过了什么吗?

谢谢。

【问题讨论】:

你能想出一个没有二级索引的更好的模式吗?非规范化可能会有所帮助。 @DineMartine 基本上是对的,只是出于好奇,您能否在问题中添加数据架构和访问查询?堆栈溢出有足够多的材料和答案,建议不要这样做:***.com/questions/43367076/… @marko-Švaljek 我们对查询没有任何问题。现在我们在新节点引导期间索引构建速度很慢,例如接下来的 2 个索引构建运行大约是 2 天,所以我们可以加快这个过程吗?:63944d90-196e-11e7-bfc7-f36cff62987e 二级索引构建密钥空间文档 1348751623 1377995424字节 97.88% 8de03eb0-196e-11e7-bfc7-f36cff62987e 二级索引构建密钥空间文档 1145629997 1236396184 字节 92.66% 查询最终使用索引,使用大量二级索引通常意味着数据模型有问题。基本上我只是想弄清楚为什么它们甚至首先被使用。我知道重写等需要做很多工作。但是退后一步重新审视你的查询可能是有意义的,因为二级索引在大多数情况下都是不可扩展的。关于这个pantheon.io/blog/cassandra-scale-problem-secondary-indexes tl 有很多故事;必须为集群中每个节点上的所有数据建立dr 二级索引 @marko-Švaljek DB Schema 已添加到原始帖子中 【参考方案1】:

这个有点长,所以我不能发表评论......对不起。

我知道这听起来有点奇怪,尤其是对于后期 你的项目,但问题是索引情况不会得到 随着时间的推移会更好。我强烈建议您开始自己制作 表而不是仅仅将索引放在以下内容上。根据 您可以使用“倒排索引”访问数据的频率。

CREATE INDEX links_by_author_url_idx ON keyspace.links_by_author (url);


CREATE INDEX docs_url_idx ON keyspace.docs (url);


CREATE INDEX om_master_object_id_idx ON keyspace.om (master_object_id);


CREATE INDEX actions_pday_idx ON keyspace.actions (pday);


CREATE INDEX authors_yauid_idx ON keyspace.authors (yauid);

CREATE INDEX authors_login_lr_idx ON keyspace.authors (login_lr);

CREATE INDEX authors_login_idx ON keyspace.authors (login);

CREATE INDEX authors_email_idx ON keyspace.authors (email);

CREATE INDEX authors_name_idx ON keyspace.authors (name);

基本上,您在此处拥有的每个索引都可以让您在基础上“搜索” 实体通过某种条件找到它们。大多数条件是 实际上很窄,这是一个好消息。但问题是索引 将变得庞大(已经如此),尤其是在文档和作者上。但我猜 doc的问题更大。

您应该考虑为此制作单独的表格。每个索引 您创建的将出现在集群中的每个节点上,最后 你将拥有比你真正需要的更多的数据,因为在 引擎盖数据按节点相乘。当您向此添加复制因子时 系统在您不知不觉中占用了大量空间。

加入节点的问题是当它们接收到新数据时 集群中的数据需要重建......对于每个节点 在集群中,这会花费您很多时间。所以基本上你松了 cassandra 具有“轻松加入节点”的所有好处。

现在你可能认为写入数据时空间会成为问题 进入非规范化的新模式....

如果空间是问题,您可以使用一种称为倒排索引的技术 您只需将信息的 id 放入搜索表中,然后 然后你在主表中进行第二次加载。我在一些项目中使用了这个 空间是问题所在,但是因为您已将所有主要内容编入索引 空间可能不会成为问题,因为您已经使用了很多 比你想象的更多。 (我敢打赌,您也可能会大大节省空间)

无论如何,所有索引都应该变成表......如果一致性是问题, 使用批处理(不要使用物化视图,因为您可能会丢失数据)。

老实说,您应该远离索引。我知道 重构它是地狱,而且很难有时间重构:(但是 我认为它应该是可管理的。

【讨论】:

以上是关于DCE Cassandra 3.9 在加入现有集群期间创建二级索引缓慢的主要内容,如果未能解决你的问题,请参考以下文章

cassandra 调试问题

在 Cassandra 的现有集群(数据中心)中添加节点时面临的问题

将节点添加到现有 Cassandra 集群

如何加快 cassandra 集群中的节点加入过程

将节点添加到 Cassandra 集群会导致现有节点上的 CPU 过载

OpsCenter 6.7.7 不会管理在以下平台上运行的现有 cassandra 集群 (dse 6.7.7):redhat 7.6 Maipo