在 5 月末，NebulaGraph 社区针对开源之夏 2024 的活动开展了第一期导师面对面的线上项目答疑会议。同学们在会议上的踊跃发言和导师的耐心解答为枯燥的项目本身增添了许多色彩，也帮助同学们对自己的意向项目有了更清晰的认知。
本次导师面对面的主角我们请到了的 Milittle-米导。米导的项目（基于图数据库 nebula 的 LOOKUP 语法支持 UPDATE）作为 NebulaGraph 的内核开发任务在此前也受到了许多学生的关注。以下先让我们来回顾一下该项目的大致信息：
项目回顾
项目名称：基于图数据库 nebula 的 LOOK UP 语法支持 UPDATE
内容简述：作为一个数据库使用者，日常会遇到的一个需求是批量更新部分数据。如果更新已知的部分数据，直接用 UPDATE 语句便可。但是如果要更新满足特定条件的部分数据，目前查询条件数据的 LOOK UP 不支持将其查询结果传递给 UPDATE 做更新操作，用户只能繁琐地将数据查询出来之后，再做一次 UPDATE。所以希望通过支持 LOOK UP ｜ UPDATE 语法来减少不必要的二次处理工作。
产出要求：在 NebulaGraph 查询语句中，支持对 LOOK UP 的结果做 UPDATE 操作
自我介绍
参加此次线上答疑会议的成员有：社区运营 Kristain，项目导师 Milittle-米导，上海科技大学的小阳，中科院软件所的小松和来自复旦大学的小杰和小涛。和往期一样，为了让导师和同学们能先熟络起来，在会议的开始先有了自我介绍环节：
Kristain ：各位同学还有米导晚上好，我是 NebulaGraph 社区的运营 kristain。首先欢迎同学们申报 NebulaGraph 社区的项目，目前也已经进入了申请的尾声阶段，相信同学们对今天要讨论的项目已经有较为详细的了解。接下去的时间大家先来介绍一下自己吧，可以分享你们以往做过的开源项目或报名此次开源之夏的契机。
小阳：各位同学还有老师晚上好，我是来自上海科技大学的小阳。在很早的时候我就有了解过开源社区，同时也接触了图数据库及其相关的一些知识。我个人对开源社区的文化和一些开源项目是很感兴趣的，正好这次开源之夏能提供这样一次机会可以让我了解 NebulaGraph 社区的项目。我之前做过比较基础的 CMU15445，但对开源项目暂时还没有涉猎，以上就是我的一个情况，谢谢大家。
Kristain：好，谢谢小阳同学的分享。同学们可以大胆地介绍自己哈，包括后面的提问环节也一样，其实过往有没有开源经验不是最重要的，关键是要有勇于挑战自己的精神。大家能参与到这次活动中来，都是一次很好的尝试。接下去我们请小松同学来介绍一下自己吧。
小松：大家好，我是来自中科院研究所的小松，目前是研一在读，研究方向是图计算这块。了解开源之夏一方面是通过同学介绍，另一方面因为是我们软件所承办的活动，所以比较快的知晓了这次活动。我的研究方向是图计算方向，所以就想在此次活动中找一个和图数据库相关的项目。此前我也没有开源项目的经验，不过就像刚刚 kristain 说的那样，我觉得这是一次很好的尝试。现在我也在看不同社区的开源代码，了解不同项目的差异，希望通过这次会议能跟老师和同学们好好学习交流一下。
Kristain ：谢谢小松同学的发言，也欢迎同学们在之后能多多使用 NebulaGraph，大家一起互相交流和学习。接下去请小杰同学发言。
小杰：大家好，我是复旦大学大数据学院的小杰，我自己的研究领域也是图计算这一方面。我是比较早就关注到了开源之夏，包括在社群里面，以及运营的朋友圈里面也看到了，就想着来参与一下。我之前也做过 NebulaGraph 的代码优化，但可能没有在开源社区里面非常深入的去参与。然后也是想借此机会再了解一下 NebulaGraph 社区， 比如更底层的开发逻辑等方面。
Kristain ：谢谢小杰同学的分享，今后在用 NebulaGraph 的过程中遇到什么问题欢迎找我们讨论哈。最后我们请小涛同学发言吧。
小涛：大家好，我是小涛，是复旦大学大数据学院的研一学生。我目前研究领域也是在图计算这一方向。之前也参与过开发的任务，但是没有在开源社区做过贡献。想通过这次开源之夏能做一次完整的开发流程。就是这样，谢谢大家。
Kristain：欢迎小涛同学，也谢谢各位同学的发言。我们每位同学都很优秀，希望大家日后都能加入到 NebulaGraph 社区中一起交流和进步。今天项目的导师是 Milittle-米导，他是我们社区一位很出色的贡献者，对 NebulaGraph 语法运用的很熟练，在此前与我们有过多次合作和深入的交流。接下去的时间我们交给米导发言。
Milittle ：同学们好，我是 Milittle，你们可以不用叫我老师，我也是 90 后，大家年龄其实都相仿。我此前在公司的时候主要是用 NebulaGraph 来开发内研项目的，包括内核基础等方面。后来因为工作方向的变动就没继续了，但我本身对开源社区很感兴趣，包括 NebulaGraph 的内核代码有很多地方还是值得去学习的。关于这个项目，最开始的思路方向是由 NebulaGraph 的产品提出来的，刚好我对语法和代码结构这块了解比较深入，所以我觉得可以借这个机会再把这个项目深入开发一下，然后贡献给社区。这个项目其实不涉及纯功能性的算法优化，同学们首先需要了解 NebulaGraph 的 nGQL 结构和运作关系，其次需要明确 NebulaGraph 集群部署模式是怎么样的。在明确这两点之后，再把我们需要做的任务从流程中切入进去，然后顺理成章的完成这项开发任务。接下去同学们有什么问题，不妨大胆地提出来。
kristain ：感谢米导的介绍和对项目的详细讲解，接下去的问答时间，大家提问时不要有拘束，希望每位同学在今天的会议后都能有所收获和总结。
难点答疑
结束了自我介绍后，导师和同学们对彼此都有了一个基本印象，会议的氛围在此刻也变得慢慢活跃起来。接下去的答疑环节，来一起看看学生们都有哪些“存货“吧。
1.中科院研究所-小松
小松 ：那老师要不我先问吧，我的初步预想是项目的整体流程涉及到的操作是从解析到优化去做一个改动，那最终会进一步深入到执行层的 executor 吗？KV Store 的存储层也需要改动吗？
Milittle ：会深入到 executor 的，包括存储层也会有改动。你可以复用原有的代码，因为我们目前提供的两个语法只是用管道符串起来的，并没有提供一个新的语义。对于现存的 nGQL 的解析来说，还有 NebulaGraph 中 Graph 那一层的 executor，以及存储层的各种 executor，就相当于你前面的 LOOK UP 这一层已经实现过了，已经有现成的结构代码可以供你知道能查出来什么东西。但是对于查出来的一些点而言，以前是没有串下一个 executor 的操作的。所以这个项目在 Graph 层肯定要做从 LOOK UP 的 executor 通过管道符串起来到 UPDATE 的操作，这些都是作为开发者需要去做的。然后存储层可能是不需要重新做的，这个还是要根据后续我们把这个项目拆解出来以后看以哪种方式是最合适的。
小松 ：好的老师，我还有一个问题。像我和另外一位同学了解 NebulaGraph比较晚，那后续 NebulaGraph 在社区发布的一些其他任务，比如在 GitHub 上发的一些 issue 也会在社区群里同步吗？我还是想有机会多参与参与以后社区发布的活动。
Milittle ：完全可以的。官方会发布一些比较好上手的一些 issue，比如流程里面的一些 bug 或者是解决校验逻辑不合理的任务。你可以先把我刚才说的三个服务端的代码稍微理解下，然后去浏览 issue 的具体描述，主要是想解决什么问题。比如说你在用 NebulaGraph 时候给社区提了一个 Bug，这个Bug 会在你进行某一步操作后触发。那么你就可以通过你之前熟悉的代码，再根据它的描述，找到它对应的源码，这就说明你对内核已经有一定的了解了。了解以后你可以把 issue 认领，然后在下面评论。大家都肯定很乐意把这个 issue 分配给你。其实我刚开始对 NebulaGraph 也没有很深入的了解，我就是浏览官方的 nGQL 语法，然后把源码 download 下来，再通过看一些源码的解析，比如社区发的一些文章，看完之后自己捋清一条代码线，然后不断的深入。这样的话你就会从简单的 issue 开始，然后把代码修复以后，不断地往源码里深入，就会产生一个良性的循环。NebulaGraph 的代码是我看过 C++ 的开源代码里，对于想要学习项目结构的开发者来说是一个不错的典范。如果你想要要写一个 C++ 工程，它会是一个非常好的例子。
小松 ：好的谢谢老师，我这边暂时没问题了。
Kristain：谢谢小松同学的提问，确实如刚刚米导讲的，我们会不定期发布一些 issue 在社群供开发者们去探讨并解决，随着对源码的不断深入你们也会对 NebulaGraph 有一个更深刻的认知。此外，同学们也可以留意平时社群里其他用户提出的一些问题，有能力的话也可以尝试解答别人的疑惑，这也是对自己的一种提升。接下去的三位同学谁想先提问呢。
2.复旦大学-小涛
小涛 ：米老师你好，我的问题是为什么 NebulaGraph 没有支持 LOOK UP 接到 UPDATE 这个管道符的操作。我之前也没有深入看过有关 UPDATE 这部分的代码，但按照我的理解，要实现这部分的功能好像并没有太多的难点在这里吧。
Milittle ：你的理解和我的理解是一致的。首先我是觉得要实现 LOOK UP 支持 UPDATE 的功能，可能会出现性能问题。因为你之前有接触过 NebulaGraph，你在用 LOOK UP 查出管道符喂给 GO 查多跳的时候，会产生很大的性能开销。因为 LOOK UP 查出来的点是不可控的，比如你基于属性做查询得到的结果会很泛化，它在不同数据集上的表现会不一致。实际情况也有可能是社区人力有限，没有排期去解决这个问题，当然这只是我的猜测。不过这个项目相较于其他内核项目而言，确实不会太复杂，在开发难度上不会太难。
小涛 ：谢谢老师我明白了。
Kristain：谢谢小涛的提问，能站在出题者的角度去思考问题本身，这对大家的全局分析能力和解决问题的能力都有很大的帮助。请接下去的两位同学继续发言。
3.复旦大学-小杰
小杰 ：老师你好，对于上个话题我还想再追问一点， LOOK UP 支持 UPDATE 和 UPDATE WHEN 有什么区别吗？UPDATE 本身也是支持过滤条件的语法吧。
Milittle：确实是支持过滤的这点没错，UPDATE 本身就是一个单纯的语法。但是我印象里好像 UPDATE 的支持条件应该没有 LOOK UP 支持的条件来的多。
小涛 ：对我刚看了一下手册，LOOK UP 支持的过滤条件比 UPDATE WHEN 支持的要更多一些。
Milittle ：是的，这两部分内容是不完全一致的。不过根据我去年开源之夏的经验来看，具体的实现过程会与我们现在讨论的内容有所出入，这个需要我们后续把项目拆解出来再分析讨论。还有一点要补充的是，对于 UPDATE VERTEX 的语法来说，不光是 WHEN 条件有疑问，它的 VID 是没办法用前面查出来的 ID 的。所以对于这个项目的实现价值来说，我们是想让 LOOK UP 查出来的点，能在后面的 UPDATE VERTEX 中应用。
小杰：好的我明白了。但我刚刚就在想，如果说要追求效率的话，是不是连 Graph 层都可以不过，直接在 Storage 层里面把它做完就好。我的意思是 LOOK UP 和 UPDATE 这两个语句，我把要 UPDATE 的内容直接传到 Storage 层里面，这样我就不需要 VID 返回 Graph 层，再让 Graph 层去调用一个 UPDATE 算子。像这样直接在 Storage 层里面做好像也可以吧？
Milittle ：完全可以，你可以在优化规则里面设计一个这样的 rule。从性能角度来说，如果能在 Storage 层闭环地实现这个操作是最好的。这相当于你不仅在 NebulaGraph 做了功能的部分，又把性能直接下推到了 Storage 层。 LOOK UP 语句的查询最终在 Storage 层的时候，所有的 Partition 都是会去查的，因为在我设定的条件下，每个 Partition 上能查出点和边的数量是未知的。所有的 Part 都会去落这个条件，落完条件以后，这上面的点和边就会根据 Partition 的分片来走，它整体是固定下来的。这样在你查询以后的这个 Storage 节点，把本地的这些 VID 所需要更新的信息在 Storage 层做完就可以了，最后再返回给 Graph 层，这样就是一个完整的流程。但是我建议最好做成一个通用的规则，比如你设定这个 rule 来匹配这个语法的时候，它就能进入我们的压缩 executor，你把多个 executor 压成一个 executor 就可以了。这个方法是可行的，你提的非常好。
Kristain：感谢小杰能提出自己构思好的 idea，项目开发的同时也是一个不断创新不断试错的过程，同学们如果有更好的想法或者方案都可以大胆地去尝试。最后请小阳送上你的问题吧。
4.上海科技大学-小阳
小阳 ：老师你好，我看它语法的意思是目前只支持单点语法的修改吗？之前是如何支持批量操作的？
Milittle ：可能是通过了客户端的多次调用，这是可以实现批量操作的，不过效率比较低。就像我刚才说了，LOOK UP 第一时间查出来，如果能在内核里面直接处理好，比在外面用客户端去调用要省力很多。
小阳 ：那为什么要实现的是只有基于 LOOK UP 支持 UPDATE，是因为 LOOK UP 基于索引会更快吗？
Milittle：可以这么讲，所有的查询语句其实都可以这样去实现，你完全可以让其他的查询语句都支持这样的功能。但需要考虑的是，你做的不仅仅是一个功能，还要是能实际生产可用的，它要能经得住考验。你要想象在大数据的场景下，比如现在有几千万个点，这几千万个点都比较集中，而且属性也是一样的，你如何确保扛得住这种语法对内核数据库的一个冲击？所以很多数据库实际上不是没法实现某些功能，而是实现了以后在实际情况中用不成，这是我们需要思考的问题。
小阳： 谢谢老师，我理解了。
Kristain：感谢四位同学的提问，大家的问题都很有深度和针对性。完成好开发任务的关键就在于找准切入点和选择切实可行的方案。希望同学们能根据今天的会议反馈再去完善一下项目申请书，最后也再次感谢米导今天的耐心解答！
会议总结
长达四十多分钟的会议最终迎来了尾声，同学们的精彩提问和老师的悉心解答褪去了这个项目的一层层外衣。为了学生能够在日后更好地完成这项开发任务，现给出了以下几点总结：
-
继续深入了解 NebulaGraph 中的 LOOK UP 和 UPDATE 管道服务的操作（可参考《读 NebulaGraph 源码 ｜ 查询语句 LOOKUP 的一生》一文）
-
确认 UPDATE VERTEX 的语法解析器中的语法配置（可参考手册中 nGQL指南-点语句-UPDATE VERTEX 板块）
-
思考 LOOK UP 实现 UPDATE 功能在实际应用中的价值