当前位置: 首页 > 知识库问答 >
问题:

Spark cassandra connector直接联接在查询中无效

韦安顺
2023-03-14

我在cassandra中有一个表,其中A(String)和B(int)是partiton键,我正在用spark sql编写sql查询

select ("SELECT * from table where A IN ("221",...) and B IN(32,323...));

在解释计划中,它似乎是在执行批扫描,而不是在分区键上直接联接

== Physical Plan ==
Project [A,B ... other columns]
+- BatchScan[A,B ... other columns] Cassandra Scan: dev.table
  • Cassandra筛选器:[[“A”在(?,?,?,?),D],[“B”在(?,?,?,?,?,?,?,?,?),D]]
  • 请求列:[A、B...]

另外,在文档中https://github.com/datastax/spark-cassandra-connector/blob/master/doc/reference.md spark.cassandra.sql.inclauseToJoinConversionThreshold设置为25.

我很好奇,在主键上的in子句是否会比直接联接更有效

共有1个答案

许嘉珍
2023-03-14
cqlsh> CREATE TABLE IF NOT EXISTS test.tab4 (k1 varchar, k2 int, PRIMARY KEY (k1, k2));

bin/spark-shell --packages com.datastax.spark:spark-cassandra-connector_2.12:3.0.0-beta --conf spark.cassandra.sql.inClauseToJoinConversionThreshold=10

scala> spark.conf.set(s"spark.sql.catalog.mycatalog", "com.datastax.spark.connector.datasource.CassandraCatalog")
scala> spark.sql("""SELECT * FROM mycatalog.test.tab4 where k1 in ("1","2","3","4") and k2 in (3,4,5,6,7)""").explain
== Physical Plan ==
*(1) Project [k1#43, k2#44]
+- BatchScan[k1#43, k2#44] class com.datastax.spark.connector.datasource.CassandraInJoin

如果这没有帮助,我需要查看您的模式、您发出的确切查询和SCC/Spark版本。

 类似资料:
  • 问题内容: 这个问题已经在这里有了答案 : 在同一网页上显示两个表的数据 (1个答案) 7年前关闭。 我在CodeIgniter中使用联接查询,但无法使其正常工作。它仅显示一个表数据,而不显示其他表数据。我是CodeIgniter的新手,无法解决此问题。请别人帮我。提前谢谢。 看法 控制器 模型 编辑 的结果 是一个如下数组: 表结构 证书 cid(PRIMARY),姓名,second_name,

  • 我需要从数据库中选择具有活动地址的公司(address.address_status_id=1)。如果地址不活动,则地址列应包含NULL。 有没有一种方法可以重新表述SQL语句,使它可以用JPA/QueryDSL表示? 编辑:我们将使用Oracle DB和Hibernate JPA provider(如果它能起作用的话)。

  • 问题内容: 对于开发人员何时使用联接而不是子查询是否有经验法则还是相同的? 问题答案: 取决于RDBMS。您应该比较两个查询的执行计划。 根据我对Oracle 10和11的经验,执行计划始终是相同的。

  • 问题内容: 我是一个老派的MySQL用户,并且始终喜欢子查询。但是如今,每个人都使用子查询,而我讨厌它。我不知道为什么 我缺乏理论知识来自行判断是否存在差异。子查询是否与a一样好,因此不必担心吗? 问题答案: 取自MySQL手册 (13.2.10.11将子查询重写为Joins): LEFT [OUTER] JOIN可以比同等子查询更快,因为服务器可能可以更好地对其进行优化-这不仅限于MySQL S

  • 问题内容: 我重构了从另一家公司继承来的应用程序的慢速部分,以使用内部联接而不是子查询,例如: 重构查询的运行速度大约快100倍。 (约50秒,约0.3秒)我期望有所改善,但是谁能解释为什么如此剧烈?where子句中使用的列均已建立索引。SQL是否在where子句中每行执行一次查询? 更新 -说明结果: 区别在于查询“(id)in()”的第二部分- vs 1带有连接的索引行: 问题答案: “相关子

  • 问题内容: 我重构了从另一家公司继承来的应用程序的慢速部分,以使用内部联接而不是子查询,例如: 重构后的查询运行速度提高了约100倍。 (约50秒,约0.3秒),我期望有所改善,但谁能解释为什么如此剧烈?where子句中使用的列均已建立索引。SQL是否在where子句中每行执行一次查询? 更新 -说明结果: 区别在于“(())中的id”查询的第二部分- vs 1带有连接的索引行: 问题答案: “相