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

问答 问题
, , ,
1

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

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

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

截断的问题可以参考这个

1 个赞
3

多谢解答

4

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

5

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

6

cc @critical27 @bright-starry-sky

7

这个问题，额，设计可能有问题，我是不太支持这个方案。现在在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 个赞
8

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

9

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

10

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

11

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

12

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

13

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

1 个赞