- nebula 版本：2.0GA
字符串索引只能256个字节，这样不能满足需求的，如果大字段场景怎么办？
请问这是ES的限制还是nebula的限制。可以修改ES的template吗，将value的类型改为text吗
2.请问以下template和nebula中的schema是怎么对应的呢
- 限制字符串的长度，是Nebula的限制。 如果你的数据超过256字符，可以按照如下操作：
字符串索引的最大长度为256字节，如果需要为超过256字节的数据创建索引，请逆序存储数据。
参考文档 全文索引限制 - Nebula Graph Database 内核手册 - 这个template 中settings 是对ES分片和副本数的配置，mappings是对nebula在es上建立的索引的配置，其中包括tag_id、column_id、value， 后面配置的是他们的数据类型。在这个template中不需要修改的。
是基于什么考虑限制长度呢，如果value的长度超过256，进行逆序存储是什么操作？
256的限制主要是因为性能考虑，同时也是es docid的长度所限。
超过256的话，tag存在数据时，create index 会报错吗。我看代码，nebula的属性value 对应的是es的mapping 中的value字段的，虽然value的type是keyword 但是可以不限制256。 不太明白你说的doc id限制 是指哪的限制。
如果属性的value超过了256的话 要怎么逆序存储数据，有相关操作说明吗。因为我这边的业务场景是很多tag的属性都是长文本
如果prop的长度超过256，是不会报错的，在同步到es时会被截断。
如果我需要去掉此限制，请问应该怎么操作呢
这个需求目前还不支持，类似mysql一样，索引单列的最大长度是255个字符。
文档上写需要逆序存储是要怎么操作呢
es的docid 确实有长度限制，但是value没有限制，nebula的属性即使超过256个字节还是可以同步到es才对，是否可以将这个256的限制做成可配置，将用户根据自己的业务场景来选择同步过程。如果将template的value的type改为text是否更好呢？
超过256是因为性能的考虑，请问当时你们测试的时，如果value超过256，性能会有很大的下降吗，具体的数据可以提供参考一下吗
es本身支持大文本的索引查询，如果利用了text分词后，超过256个字节会不会更好
可以的，类型为text或keyword，这个取决于用户的需求。
但是listener的同步过程会截断nebula的prop的长度，当用户设置为text后意义不大，这个截断是不是可以结合业务场景来配置呢。
这样的话，需要在上层业务中做一个截断预处理的工作，如何截断，从哪里截断需要根据实际业务来判断，最终的目的是保留小于256的字符串。
但据我的经验，这个预处理的业务不是那么好写的，比外部单独搭建一套es集群，专门做长字段字符计算的工作量和难度还要大。
嗯，我觉得可配置的话，应该在这个代码里不限制同步数据时，往es插入数据的长度。
因为ES本身可以支持大文本 分词索引的。
