【问题标题】:cassandra wide row column slice performancecassandra 宽行列切片性能
【发布时间】:2013-07-01 23:25:35
【问题描述】:

我正在使用 2GB 内存的 vm 上测试 cql/cassandra 1.2 和 python-cql 库。我有一个带有复合索引(宽行)的表。当对单个节点运行查询时,我的性能比 mysql 差 10 倍。请求是串行的,没有并发,但我对单个请求的速度感兴趣。

  • 最重要的是,我可以做些什么来优化查询宽行(特别是这个查询)?
  • 这些数字是否反映了 cassandra 与 mysql 在单个请求情况下的性能?
  • 我有限的 ram/vm 能有这么大的不同吗?
  • 多节点 cassandra / 分区 mysql 是否会接近 10 倍?
  • 我做错了什么?

测试代码:

"""
CREATE TABLE foo_bars (
     foo_id text,
     bar_id bigint,
     content text,
     PRIMARY KEY (foo_id, bar_id)
)
WITH CLUSTERING ORDER BY (bar_id DESC);
"""

#content is up to 64k text and te number of bar columns in a foo row will be ever growing but will probably never reach over 2million


t1 = time.time()
for i in range(1, 1000):
    sql_query = "SELECT * FROM foo_bars WHERE foo_id IN(%s) ORDER BY id DESC LIMIT 40" % random_foo_ids
    result = db_cursor.execute(sql_query)
t2 = time.time()
print "Sql time = %s" % str(t2 - t1)


t1 = time.time()
for i in range(1, 1000):
    cql_query = "SELECT * FROM foo_bars WHERE foo_id IN(%s) LIMIT 40" % radom_foo_ids
    result = cassandra_cursor.execute(cql_query)
t2 = time.time()
print "Cql time = %s" % str(t2 - t1)

Sql time = 4.2
Cql time = 58.7

提前致谢!

【问题讨论】:

  • 您的列族有多大? nodetool cfstats 'space used (live)' 的输出是最好的指标。
  • *已用空间(实时):31749778 *已用空间(总计):31749778 *压缩行最小大小:447 *压缩行最大大小:654949 *压缩行平均大小:68740
  • 这是 31 MB,因此很容易放入缓存中。那就不能和内存有关了。可能仅仅是因为 Cassandra 的读取延迟比 MySQL 高。虽然吞吐量可能更高,但您需要并发。
  • 谢谢,我很担心 :( 我正在考虑操作 column_index_size_in_kb(当前设置为 64),但我不知道对我的用例有什么好的价值。
  • 这不应该有任何区别,因为您正在读取一行的前 40 列。列索引仅在从大行中读取特定列时才有帮助。

标签: performance cassandra cql


【解决方案1】:

启用行缓存可能会更快一些。将 cassandra.yaml 中的 row_cache_size_in_mb 设置为大于 CF 大小的值 - 这样 100 就可以了。然后为您的列族设置caching = 'all'。当您阅读时,您应该会看到nodetool info 报告的命中率增加。

但是,我怀疑你会得到 10 倍的加速。

问题在于 Cassandra(尤其是读取)是为高吞吐量而不是低延迟而构建的。 Cassandra 内部有很多队列会增加延迟。添加更多节点将进一步增加延迟(但增加节点数量远远超出复制因子不应该进一步增加延迟),但可以近似线性地提高吞吐量。

解决方案是使用并发:单个客户端或多个客户端中的队列、线程和多个连接。但是,如果这对于您的用例来说是不可能的,我希望 MySQL 对于这种读取​​会更快。事实上,如果您只希望拥有 31 MB 的数据,那么 MySQL 可能更适合您的用例。

【讨论】:

  • 您好,感谢您的信息。生产数据将比这大数千倍。只是为了测试单个请求的延迟。
猜你喜欢
  • 2014-04-24
  • 1970-01-01
  • 2017-06-15
  • 2017-11-21
  • 2013-07-31
  • 1970-01-01
  • 2018-08-20
  • 1970-01-01
  • 2016-07-07
相关资源
最近更新 更多