Question

我们创建了一个包含9个节点的cassandra集群。每个都配备4Cores和16G RAM。我们正在撰写15-25百万条记录，共28列。

我们设计的数据模型如下（我只是重命名了列并缩短了实际的架构，使其简短。）

CREATE TABLE main_table(
col1 ... col28,
PRIMARY KEY((col1,col2),col_date,col_with_some_seq_number))
WITH CLUSTERING ORDER BY (col_date DESC,col_with_some_seq_number desc) AND  default_time_to_live = 5270400;

CREATE MATERIALIZED VIEW mv_for_main_table AS
SELECT [col1.. col11],
FROM main_table 
WHERE col1 IS NOT NULL AND col2 IS NOT NULL AND col_date IS NOT NULL AND col_with_some_seq_number IS NOT NULL
PRIMARY KEY ((col1),col2, col_date, col_with_some_seq_number)
WITH CLUSTERING ORDER BY (col_date DESC, col_with_some_seq_number DESC, col2 DESC);

它只是将一个分区键移动到聚类键中物化观点。

我们正在加载来自spark的数据，并且不会修改任何与cassandra相关的配置。

在摄取大约1.5亿条记录后，摄取开始失败，每个节点都发生了很多突变失败。

物化视图是否存在任何性能问题。或者我使用的定义效率不高。？

我们尝试了一些配置更改，例如减少并发写入，吞吐量MB。在所有尝试之后，我们放弃了物化视图，然后每件事情都开始运作良好。

我们已经做了足够的测试，得出的结论是，只有在物化视图包含之后，写入速度才会大幅提升，并且突变会逐渐消失。

我们计划为上述配置设置单独的表而不是物化视图，但我想知道我们使用的物化视图或数据模型是否有任何错误。

Answer 1

深入理解物化视图（MV）的地方：http://www.doanduyhai.com/blog/?p=1930

拥有MV时，基表的分区上有锁。这个本地锁具有成本（参见我的博客文章）

我还有关于你的硬件规模的另一个评论，4CPU低于官方建议，即8个CPU：http://cassandra.apache.org/doc/latest/operating/hardware.html

Cassandra中的写入工作负载是CPU绑定的。在您的情况下，您的CPU也被Spark使用，这可以解释您的瓶颈。

请在此处发布dstat和htop

的截屏

Answer 2

物化视图的作用是创建另一个表并在写入主表时写入它。所以，如果你放弃物化视图并手动创建另一张桌子，恐怕你会在同一条船上。

在我看来，性能问题是由于一个特定节点过载造成的。实际上，当你将一个PARTITION KEY列降级为CLUSTERING KEY列时，假设相同的数据提取模式（该假设明确成立，因为每个写入“反映”到另一个表），将创建热点，因为更多的数据往往位于相同的分区。这转化为更长的压缩和读取修复，以及对集群的更多压力（例如，因为每个节点必须为每个分区排序更多数据）。

Cassandra MaterializedViews的性能问题

2 个答案: