既然暴露了，那就来吧~
大家好，我是新来的产品经理MuYi，在各种群里和帖子里看到大家有各种抱怨，开个帖子，欢迎大家来吐槽。
吐槽归吐槽，为了方便整理，也定个规矩：
吐槽规则：
吐槽时，请描述：
，我先来一个 
产品：Database
版本：3.2.0
问题：DML 可以更灵活，要么能支持 Cypher DML，要么我们的 UPDATE/UPSERT 可以支持管道，https://github.com/vesoft-inc/nebula/issues/2938
路径搜索能不能优化下，性能被neo4j暴打 
搬运一下群里的抱怨~
正常我创建了schema和概念，一定要等20s再去用
异步创建schema,我也觉得非常扯，很难用
产品：Database
版本：3.2.0
问题：schema的创建更新无法实时生效，需要等待2个心跳周期的延时后才能使用，很影响用户体验
提了issue：https://github.com/vesoft-inc/nebula/issues/4462
偶尔在一个match的无向查询语句里，交换起点和终点，查出来的东西竟然不一样，这种明显的bug也没回复
产品：Database
版本：3.2.0
问题：考虑引入 CLEAR TAG <TAG_NAME> 语义，解决 v3 之后 DROP TAG 单 TAG 点不再删除 vertex 的缺失 https://github.com/vesoft-inc/nebula/issues/4455 。
schema实时生效我们也做了一下，简单思路就是如果这个schema在metaclient找不到，就去metad找一下。大多数情况下都能正常工作，少部分奇怪场景会有些问题，比如反复删除创建同名schema，比如删除新建同名space然后创建schema，不过都是缓存不一致的问题，改改就好了。主要一个问题是，当删除schema后，按照同样的逻辑，storaged在压缩数据时，发现schema不存在会去metad找，由于数据量很大，所以metad和storaged的cpu会飙升，后来我们强制压缩时只在本地缓存检查这个schema存不存在，假装解决了这个问题 
产品：Database
版本：3.2.0
问题：集成相关图计算框架，比如graphscope
match和lookup语句如果没有给字段创建索引就用不了，这相当于数据这块用户必须根据vid去过滤，我如果知道vid的值，那我还有match干什么，这不是死循环？创建索引导入性能就极差，那就相当于根本不支持根据自字段查询整条数据，这随便放在拿着数据库设计里，都算是个很致命的问题吧。。。性能测试对比了半天，性能确实可以，回头看原来设计就挺尴尬的，发现根本用不了nebula，太难用了。。。
别的就不说了，希望官方能重视一下文档吧，对于一些会影响执行的限制，如果不在文档里显式说明或者更新，线上遇到了真的是会做噩梦。
比如上次发现的 connection 会话有上限，还有最近遇到的单次提交最多512条语句，一个是文档过时（旧文档里是可以设置不过时），一个是没有（关于 session 的提交限制是没有相关内容的）
+1
希望官方文档里能给一个docker swarm的集群部署说明，
目前v3只有一个单机版的docker-compose.yml部署方式
这个swarm的分支 docker-stack.yaml文件是2020年7月提交的，使用的v1版本，
现在新版本是v3.1.0了 区别应该挺大的，咱们官方可以更新一下吗？
方便快速部署 测试性能等。
我回头去 PR 更新一下（或者你有时间来一个PR到这个分支哈，照着单机版的改一下就行），我们其实是不鼓励大家使用 swarm 而是用 k8s(nebula operator)满足生产的容器部署的
感谢 
！！
我们也是刚接触这个，因为需要离线环境部署，swarm安装相对于k8s依赖更少一些。
目前主要是希望能快速部署，是测试一下功能、性能。
metad找到又能怎么样呢？ graphd还是需要等待不确定的时间，无法解决动态建space+schema的场景
没错
