nebula-graph2.0,有四个使用问题咨询下

nebula 版本:2.0 GA
部署方式(分布式 / 单机 / Docker / DBaaS):单机
硬件信息
磁盘( 推荐使用 SSD)
CPU、内存信息 8核64G

问题1:请问LOOKUP + limit 2.0GA版本是不是没有做数据下推,优化性能?
问题2 :请问全文索引的256字符限制,当索引字符个数大于256,有没有办法规避或者解决?
问题3:请问不能同时为多个属性创建全文索引,这个意思是不能建多个全文索引,还是一个全文索引不能包含多个属性?
问题4:同一个语句是不是支持多个属性进行模糊查询+精确查询,能不能用管道符链接?

  1. 暂时还没有,刚提上日程
  2. 256主要是ES那边的DocId会所限制,超过就截断
  3. 是指不能建立两个字段的联合索引,即一个全文索引只能包含一个属性
  4. 目前不支持,暂时也还不支持管道符

截断的问题可以参考这个

1 个赞

多谢解答

ES的DocId有所限制,超过256就存在截断机制。
但ES组件本身,Value值不存在限制,不应该将Vaule也截断,且ES的id可以自定义生成,与Vaule无关。 目前graph 2.0的此截断ES的Value动作,是否有待商榷!

看截断这个帖子,实际上没有解决我们的问题。我们的场景就是有很长的value需要做全文索引。docId应该是对应参数值,value设置成text类型是否能解决这个问题?

cc @critical27 @bright-starry-sky

这个问题,额,设计可能有问题,我是不太支持这个方案。现在在docId和value里都存了需要做全文索引的那个字段的值,比如要索引的是“张三”,给es的请求里大概就是

POST nebula_spacename_tag/_doc/partId_tagId_propertyname_张三 {
    "schema_id": ...,
    "column_id":...,
    "value": 张三
}

所以在docId里和body里存了两份,也就是为啥我们限制了docId的长度。

按这个方案呢,全文索引查出来的结果,再用lookup在nebula里查,然后返回对应结果。
另一个方案是docId里只存vid,那全文索引查出来的结果,就需要用fetch在nebula里查。

1 个赞

为什么要在docid保存了字段的值,而不是字段的名?

为了保持doc的唯一性,有两种设计方案,一种是docId中存TagId_VId 或 srcId_edgeType_Rank_dstID; 另一种是tagId_ColName_values; 两种方案各有利弊,目前使用的是后者。
因为elasticsearch中docId的长度限制,以上两种方案都不可避免的会遇到这个问题(vid是fixed_string的时候),另外考虑到因为全文索引是基于nebula原生索引的,目前nebula原生的索引为fixed_string的时候,其长度也有限制。综合考虑后,其全文索引的字段长度被设计为小于256。

既然既有利弊,是否可以做成配置,业务自己选择

暂时没有可配置的这个计划,欢迎贡献PR。

@critical27 请问第一个问题排上日程,具体会在哪个版本落地? 3.0 ?

暂定下个大版本,半年一个大版本

1 个赞

浙ICP备20010487号