【问题标题】:How to run cassandra queries with non-primary key columns in where clause faster.?如何更快地在 where 子句中使用非主键列运行 cassandra 查询。
【发布时间】:2017-01-04 22:27:38
【问题描述】:

我正在通过性能基准测试将 cassandra 视为我们项目的数据库解决方案。我创建了一个包含 28 列的表,其中几列作为主键。

我加载了包含大约 250 多万条记录的数据表。

当我在 where 子句中使用主键列进行查询时,结果非常令人满意。当我在 5 个线程中并行化查询时,我可以在 2.5 分钟内完成近 100 万个查询。

但是,当我尝试在 where 子句中使用非主键列进行查询时,1000 次查询花费了将近 2 个小时。

我知道,没有主键是很大的劣势,但我们可能还会遇到这种情况。

  1. 我尝试查看是否可以使用二级索引,但它们似乎仅限于一列。

  2. 我找不到自定义索引的正确示例,因为它需要索引类型类。

  3. 如果我使用了主键中的所有列,至少会有 5% 的帮助吗?

  4. 如果我们期望更多的查询情况在 where 子句中没有主键列,那么 cassandra 真的是一个很好的解决方案吗?

我坚信有人肯定会遇到这种情况,所以如果有人能分享他们的经验,那就太好了。

【问题讨论】:

  • 您能否使用不满足您要求的确切列族架构和查询更新问题。
  • 您好 Jaya,我在创建表时没有任何其他参数。它只是普通表,28 列中的几列作为主键,另一列用于排序。这就像创建包含所有列的表 + PRIMARY KEY (("col1", "col6"),"col10")

标签: cassandra


【解决方案1】:

如果我们期望更多的查询情况在 where 子句中没有主键列,那么 cassandra 真的是一个很好的解决方案吗?

这是一个先验 Cassandra 不是最佳解决方案的用例。 但如果您有 250+ 百万条记录,其他数据库也会遇到性能问题。

一种解决方案是在其他表中构建您自己的索引。 如果您没有太多不同类型的 where 子句,它应该可以解决问题。 即使您必须执行多个更新或选择命令来更新或选择单行,这些命令中的每一个都应该与您所做的工作台一样快。

【讨论】:

  • 我同意托马斯的观点。这些被称为倒排索引,我们在拥有超过 1.2 亿条记录的数据集上经常使用它们。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-02-01
  • 2016-06-02
  • 2020-10-19
  • 1970-01-01
  • 2019-01-22
  • 2020-08-18
  • 1970-01-01
相关资源
最近更新 更多