lookup 语法使用问题

LOOKUP ON player 
WHERE player.name == "Tony Parker" 
YIELD properties(vertex).name as name

给出的例子中,感觉混杂了nGQL和openCypher的语法.
使用以下语句会存在语法问题, where clause 不支持nGQL的schema function?

LOOKUP ON player
WHERE properties(vertex).name == "Tony Parker"
YIELD properties(vertex).name as name

相较于FETCH,GO语句

FETCH PROP ON player "player100" YIELD vertex as v
| YIELD $-.v as v WHERE properties($-.v).name == "Tony Parker"
GO FROM "player100", "player102" OVER serve
WHERE properties(edge).start_year > 1995
YIELD DISTINCT properties($).name AS team_name

是否有计划支持LOOKUP whereClause的expression使用schema function?

struct LookupContext final : public AstContext {
  bool isEdge{false};
  bool dedup{false};
  bool isEmptyResultSet{false};
  int32_t schemaId{-1};
  Expression* filter{nullptr};
  YieldColumns* yieldExpr{nullptr};
  std::vector<std::string> idxReturnCols;
  std::vector<std::string> idxColNames;
  // order by
};
struct FetchVerticesContext final : public AstContext {
  Starts from;
  bool distinct{false};
  YieldColumns* yieldExpr{nullptr};
  ExpressionProps exprProps;

  // store the result of the previous sentence
  std::string inputVarName;
};

LookupContext#filter属性替换为ExpressionProps会存在什么问题?

或者用这种语句请求

LOOKUP on player
YIELD vertex as v 
| YIELD $-.v where properties($-.v).age > 25

explain 该语句是多了个project的算子, 性能上会有很大的差异么?

这个例子是在哪里找到的? 在之前的版本里已经禁止了混用 nGQL 和 cypher 语法混用

你想做的查询是什么?

希望支持该查询方式

LOOKUP ON player
WHERE properties(vertex).name == "Tony Parker"
YIELD properties(vertex).name as name

你用的是什么版本, 我在3.3版本可以执行这个查询

(root@nebula) [nba]> LOOKUP ON player WHERE player.name == "Tony Parker" YIELD properties(vertex).name as name
+---------------+
| name          |
+---------------+
| "Tony Parker" |
+---------------+
Got 1 rows (time spent 3.922ms/4.335883ms)

Thu, 10 Nov 2022 11:24:00 CST

我没有说明官方文档中给出的例子执行有问题.
麻烦请认真查阅我给出的信息.

差很多哈,重点是 indexscan 有差别,你 profile 一下, where filter 是没下推的, indexscan 扫了所有数据哈

感觉曾经是支持的,因为多了一个 function 处理,比如 GO 中间 dst(edge) 比 follow._dst 就有额外大的开销,主要是这样需要做很多额外的事儿才能把类型推断做进去,就禁止掉了这里的灵活性。

你是特别喜欢 properties() 的写法哈,为了自己维护通用的模板么?还是别的原因?

是的,公司内部维护了相关的OGM框架,考虑到模板渲染的问题.
目前的做法是维护了一套字典,字典映射不到的情况会用properties()作处理.
字典映射的值是数组,会根据属性引用(vertex/edge/$$/$^)来决定下标.
e.g.

Map<String, String[]> SCHEMA_COLUMN_MAP = Collections.unmodifiableMap(new HashMap<String, String[]>() {
    {
        put(Model.ID, new String[]{"id(vertex)", null, "id($^)", "id($)"});
        put(Model.TAG, new String[]{"head(labels(vertex))", "type(edge)", "head(labels($^))", "head(labels($))"});
        put(Model.SRC, new String[]{null, "src(edge)", null, null});
        put(Model.DST, new String[]{null, "dst(edge)", null, null});
        put(NModel.RANK, new String[]{null, "rank(edge)", null, null});
    }
});

String[] SCHEMA_PROPERTIES = {"properties(vertex).", "properties(edge).", "properties($^).", "properties($$)."};


TagIndexFullScan 这里怎么确认filter下推?

这两个TagIndexFullScan的算子描述是一致的?

看 indexCtx columnHints

调优一些小细节可以参考下 nGQL 简明教程,第二期 nGQL 执行计划详解与调优 - siwei.io

2 个赞

因为 LOOKUP ON <foo> 里是有 foo 的建议改成

-        put(Model.SRC, new String[]{null, "src(edge)", null, null});
+        put(Model.SRC, new String[]{null, "{edge_type}._src", null, null});

..
- String[] SCHEMA_PROPERTIES = {"properties(vertex).", "properties(edge).", "properties($^).", "properties($$)."};
+ String[] SCHEMA_PROPERTIES = {"{tag}.", "{edge_type}.", "properties($^).", "properties($$)."};

关于 LOOKUP WHERE 中的 properties 表达感觉是合理的哈 ? @Aiee

我提了 issue support properties expression in WHERE clause for LOOKUP · Issue #4848 · vesoft-inc/nebula · GitHub

3 个赞

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。