我们在Cassandra建立了数据模型。由于不同系统生成的事件,数据上会发生连续写操作。表的模式定义如下。写操作在表上运行良好,但用id的where子句读取在第99百分位上最多占用9秒。请帮我把这张table设计得更好。数据列包含一个最大为2kb的json字符串。
CREATE TABLE table (
id text,
p1 text,
o1 text,
s1 text,
data text,
enabled boolean,
PRIMARY KEY (id, p1, o1, s1)
) WITH CLUSTERING ORDER BY (p1 ASC, o1 ASC, s1 ASC)
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', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
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 = '99PERCENTILE';
CREATE INDEX table_enabled_idx ON table (enabled);
1条答案
按热度按时间yqhsw0fo1#
这个
table_enabled_idx
指数将非常缓慢,最终会崩溃。算了吧。leveledcompactionstrategy将完全提高读取性能。只有当你从未读过数据或在古老的磁盘上时,STC才会更好。套
dclocal_read_repair_chance
归零(不会真正起作用,但也可以)。需要一个跟踪,以确定是否有其他东西,如太宽,太多的墓碑等,你所提供的没有告诉。也可以是来自不相关事物的gcs,如压缩、坏的jvm设置、系统上的其他数据模型等。如果gcs不常见,则启用驱动程序上的推测性执行来绕过gcs。