由于目前在技术选型阶段，所以暂时没法提供具体的环境配置。不过应该会按照标准的配置来定，标准的意思是例如官方建议的多大的数据列用多少配置。目前估计数据量不大，可能只有千万级别的点。
问题一：
目前有一些场景，要求自测一下nebula 大致的查询性能，但是很难构造符合业务场景的大数据量的点边关系，基本查询需求是 使用go语法 查询多跳的血缘，然后是基于多个vid查询。
例如： go 1 to steps 6 from “vid1”,“vid2”… over edge yield xxxxxx
想了解一下这种查询千万级别的话性能会有瓶颈吗，瓶颈在哪些地方，就是想大致了解下。
问题二：
有一些多跳的血缘查询，会带很多的查询条件，是否查询条件都必须设置索引，对性能有没有什么影响，除了go有没有更好的实现方式的语法。
问题可能都过于语言话，所以希望能大致给点建议，目前确实有这些困扰。
技术选型的参考，官网的 blog 中应该有一些相关的文章，你可以先了解一下。
问题一：如果只是简单的多跳查询，go 目前应该是最优的查询方案，go 查询的主要开销应该都在 rpc，本身是没有太多的计算。
问题二：go 查询是不依赖索引的，每次都是基于顶点的 ID 向外探索，如果查询需要依赖属性查找 vid 则需要建立索引，比如 lookup 或者 match。不清楚你这里描述的血缘的查询是否是说不同顶点之间是否有边，如果类似这种 pattern 的匹配，可以用 match 表达。
问题一： 目前基础的血缘查询就是准备基于 go 1 to steps 6 from “vid1”,“vid2”… over edge yield xxxxxx 这种语句去查询，只是目前我们的场景下血缘只有上下游的关系，一个方向， 使用go的话由于是walk类型的路径，有重复的点边，需要逻辑进行去重操作。
问题二：也是想基于go 查询我这里的血缘， 场景是，基于某个vid 查找其血缘，然后其血缘满足一定的条件停止查询，比如其血缘某个属性值等于、不等于、包含、不包含等等，甚至可能是一个正则表达式，我了解到go语法的where是不支持正则表达式的，所以我是不是只能选择match optional的语法查询，通过建立索引，但是索引太多的话 会不会产生查询性能上的问题
重复的点边这个确实是的，如果想要返回的结果不重复，只有用 match 来表达路径了
go 中的过滤是可以使用正则表达式的
索引多不太会造成查询上的性能问题，会造成更新或者插入的性能问题。