Cassandra中的大数据使群集无响应

时间:2016-12-21 23:02:03

标签: cassandra cassandra-2.2

我在AWS上用Cassandra 2.2.0创建了一个表,结构简单:

CREATE TABLE data_cache (
    cache_id text,
    time timeuuid,
    request_json_data text,
    PRIMARY KEY (cache_id, time)
) WITH CLUSTERING ORDER BY (time DESC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 3600
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

我在AWS-eu和us-east上有2个数据中心。

我遇到的问题是表格快速填满了系统上没有更多磁盘空间的程度。截断表也是有问题的,因为READ在CQLSH中变得不负责任。

正如您所看到的 - 我将默认TTL更改为3600秒(或1小时),并且GC宽限秒短于默认10天。

目前,每个群集的数据现在为101GB,系统无响应。 如果我尝试一个简单的select count(*) from data_cache它会给我一个连接超时 - 经过3次尝试后,群集本身就会​​丢失。错误日志表明java内存不足。

我应该做些什么?我究竟做错了什么?

目前TTL是存在的,所以数据不会破坏服务器,直到我们知道我们将使用缓存多长时间,因此它只设置为1小时 - 但如果我们认为缓存应该构建1天 - 我们将相应地扩展容量,但我们还需要从中读取,并且由于崩溃,我们无法这样做。

2 个答案:

答案 0 :(得分:4)

您需要经历的是什么。 Cassandra擅长检索一个特定的记录,但不是一次检索数十亿行。实际上,您的简单SELECT COUNT(*) FROM data_cache正在阅读所有数据集。由于Cassandra的性质,counting is hard

如果你同时查询cache_idtime一切都很好,但是如果你不这样做,那就是一个麻烦的呼唤,特别是如果你不知道你的行有多宽。

请注意TTL会生成墓碑,迟早会打到你。即使您降低宽限期,TTL也不能保证您的可用空间将被收集。实际上,使用默认参数,SizeTieredCompactionStrategy采用大小相等的4个SSTable,但是如果你没有这样相等的表,那么压缩就没有了。在最糟糕的情况下,SizeTieredCompactionStrategy要求磁盘上的可用空间至少是要压缩的最大CF的大小

在我看来,您正在尝试使用Cassandra作为缓存,但您目前正在使用它像队列一样。我会重新考虑数据模型。如果你来这里有更好的规范,你可以帮助你。

答案 1 :(得分:1)

我认为你的第一个问题与压缩有关,更准确地说与写吞吐量和压缩之间的比例有关。在cassandra.yaml文件中有一个字段compaction_throughput_mb_per_sec。如果它的值低于你的写入负载,Cassandra将无法清空空间,最终没有dsik空间和节点崩溃。

我想知道您的数据是否在您的群集中正确传播。我在这里看到您使用PARTITION_KEY cache_id和CLUSTERING_KEY time。这意味着具有相同cache_id的任何插入都将转到同一节点。因此,如果同一cache_id中的time cache_id太少slider= true,则工作负载将无法均等分配,并且存在无响应节点的风险。您必须记住的限制是每个分区不超过100 000行,每个分区不超过100 Mb。