Cassandra Wide Vs适用于大型柱子

cs_*_*nus 17 performance schema cassandra

我需要每天向cassandra插入60GB的数据.

这分为
100组
密钥每组150,000个密钥每个密钥
4KB数据

在写入性能方面,最好
每组使用1行,每行150,000个密钥,每行
10行,每行15,000个密钥,每行
100行,每行1,500个密钥,每行
1000行,每行150个密钥

另一个要考虑的变量,我的数据在24小时后到期,所以我使用TTL = 86400来自动过期

有关我配置的更多具体细节:

CREATE TABLE stuff (
  stuff_id text,
  stuff_column text,
  value blob,
  PRIMARY KEY (stuff_id, stuff_column)
) WITH COMPACT STORAGE AND
  bloom_filter_fp_chance=0.100000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=39600 AND
  read_repair_chance=0.100000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'tombstone_compaction_interval': '43200', 'class': 'LeveledCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};
Run Code Online (Sandbox Code Playgroud)

访问模式详细信息:
4KB值是一组1000个4字节浮点数打包到字符串中.

一个典型的请求是需要随机选择20-60个浮点数.

最初,这些浮点数都存储在同一逻辑行和列中.这里的逻辑行表示在给定时间的一组数据,如果它全部写入具有150,000列的一行.

随着时间的推移,一些数据被更新,在列集内的逻辑行内,将更新打包字符串中的随机级别集.新级别不是就地更新,而是写入与其他新数据相结合的新逻辑行,以避免重写仍然有效的所有数据.这会导致碎片化,因为现在需要访问多行来检索该组20-60个值.现在,请求通常会在1-5个不同的行中从同一列读取.

测试方法 我为每个配置写了5个随机数据样本并对结果求平均值.费率计算为(Bytes_written /(时间*10 ^ 6)).以毫秒精度测量时间,以秒为单位.Pycassa被用作Cassandra界面.使用Pycassa批量插入操作符.每个插入插入多个列到一行,插入大小限制为12 MB.队列刷新为12MB或更少.大小不考虑行和列开销,只考虑数据.数据源和数据接收器位于不同系统上的同一网络上.

写入结果 请记住,由于Cassandra配置的复杂性,还有许多其他变量在起作用.
1行每行150,000个密钥:14 MBps
10行每行15,000个密钥:15 MBps
100行每行1,500个密钥:18 MBps
1000行每行150个密钥:11 MBps

Nik*_*hil 3

答案取决于您的数据检索模式是什么,以及数据的逻辑分组方式。总的来说,我的想法是这样的:

  • 宽行(每组 1 行):这可能是最好的解决方案,因为它可以防止请求同时命中多个节点,并且通过二级索引或复合列名称,您可以根据需要快速过滤数据。如果您需要每个请求访问一组数据,那么这是最好的选择。但是,在宽行上执行过多的多重获取可能会增加节点上的内存压力,并降低性能。
  • 细行(每组 1000 行):另一方面,宽行会在集群中产生读取热点。如果您需要对完全存在于一个宽行中的数据子集发出大量请求,则尤其如此。在这种情况下,瘦行将在整个集群中更均匀地分配您的请求,并避免热点。另外,根据我的经验,“更瘦”的行在多重获取时往往表现得更好。

我建议,分析您的数据访问模式,并基于此最终确定您的数据模型,而不是相反。

  • 我认为相反:如果主键仅包含分区键,则表的行数很薄。如果主键包含分区键以外的列,则表具有宽行 (2认同)