【问题标题】:How do model data in Cassandra for faster reads?如何在 Cassandra 中对数据进行建模以加快读取速度?
【发布时间】:2019-11-27 16:46:09
【问题描述】:

我们在 Cassandra 中对数据进行了建模。由于不同系统生成的事件,数据上会发生连续写入。表的模式定义如下。 WRITE 在表上工作正常,但在第 99 个百分位上使用 id 的 where 子句读取最多需要 9 秒。请帮助我更好地设计这张桌子。数据列包含最大 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);

【问题讨论】:

  • 您能否提及您的阅读查询最耗时?您提到了“数据”列的大小也很好,但是您是否还可以估计特定“id”键将存在多少行。我们可以使用它来查看分区大小。
  • 目前行数接近 160 万。这就是查询的样子。这是唯一一个具有不同 id 值的查询被触发。 select * from table where id = '961:3387:2019-06-30';

标签: cassandra data-modeling cassandra-3.0


【解决方案1】:

table_enabled_idx 索引将非常缓慢并最终中断。放弃它。

LeveledCompactionStrategy 将彻底提高读取性能。如果您从不读取数据或在古代磁盘上恕我直言,STCS 只会更好。将dclocal_read_repair_chance 设置为零(不会真正有所作为,但也可以)。

需要一个跟踪来确定它是否有其他的东西,比如太宽、太多的墓碑等等,而你提供的东西并没有说明。也可以是来自不相关事物的 GC,例如压缩、错误的 jvm 设置、系统上的其他数据模型等。启用驱动程序上的推测执行以解决不常见的 GC。

【讨论】:

  • 摆脱索引的好方法。极低基数列上的二级索引会快速变宽,最终变得无用。
  • 我可以想象您选择的分区键会导致巨大的分区。但只是猜测。能否提供 nodetool tablehistograms 的输出?
猜你喜欢
  • 2015-11-07
  • 2019-06-17
  • 2017-03-16
  • 2021-02-09
  • 2019-04-03
  • 1970-01-01
  • 2011-01-25
  • 2016-03-17
  • 2018-04-24
相关资源
最近更新 更多