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

我们拥有32个节点的cassandra集群，平均节点大小约为1TB。节点配置1x英特尔至强E3-1271v3,32GB RAM，2x3TB硬盘。我们有一个带有一些小表和一个大表的数据库，它占据了总群集大小的90-95％。DCE Cassandra 3.9加入现有集群期间缓慢创建二级索引

我尝试向此群集添加其他节点，但突然发现，将一个节点添加到现有群集服务大约需要13-14天才能加入群集。建立二级索引需要大部分时间，并且所有这一次我看到所有压缩机线程都采用所有可用的CPU。

我已经改变卡桑德拉config来扩展限制：

concurrent_compactors：4
compaction_throughput_mb_per_sec：0

Cassandra full config

Schema

是约1年股份公司o我们还向该群集添加新节点，并将其从16个节点扩展到32个节点群集，在群集扩展之前，平均节点大小为1TB。 Cassandra版本是2.1。一个节点加入时间为1-1.5天。

那么问题我们该如何加快这个过程呢？我们错过了什么吗？

感谢。

来源

2017-04-14 Eugene Zhuzhnev

你能想到更好的架构无需二次指数？非规范化可能的帮助。 – DineMartine

@DineMartine是基本上只是出于好奇，你可以添加数据模式和访问查询的问题？有足够的材料和堆栈溢出的答案建议不要这样做：http://stackoverflow.com/questions/43367076/cassandra -cqlsh-not-working-where-clause-on-non-partition-key –

@ marko-Švaljek我们没有任何关于查询的问题。现在我们在新节点引导期间索引建立缓慢，例如next 2个索引版本每次运行约2天，那么我们可以加快这个过程吗？： 63944d90-196e- 11e7-bfc7-f36cff62987e二级索引构建密钥空间文档1348751623 1377995424字节97.88％ 8de03eb0-196e-11e7-bfc7-f36cff62987e二级索引构建密钥空间文档1145629997 1236396184字节92.66％ –

这一个有点长，所以我不能把它评论...对不起。

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

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放入搜索表中，然后在主表中进行第二次加载。我在一些项目上使用了这个空间是个问题，但是因为你已经将所有主要东西编入索引空间可能不会成为问题，因为你已经使用了许多比您想象的更多的。（我敢打赌，你也可能在空间上节省很多）

无论如何所有的索引都应该成为表...如果一致性问题，使用批次（不要使用物化视图，因为你可能会丢失数据）。

我的老实说法是，你远离索引。我知道这是地狱重构这个再加上它很难让时间来重构:(但我觉得应该是可控的。

来源

2017-04-14 16:55:59

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

回答

相关问题