开源之夏 2024 在 NebulaGraph 社区正如火如荼地进行，为了帮助同学们更好地了解每个项目，我们组织了导师面对面 的线上交流会议。在此之前，我们先对每位同学的意向项目做了统计，并提前和导师们沟通好时间来安排一场线上会议，导师们会为大家详细的讲解项目的技术和产出要求，并针对同学们的疑惑给出答复。
本次导师面对面第一期的主角我们请到了的小红鸡-刘导。刘导的项目（基于图数据库 nebula 增加对 List / Set 类型的支持）报名人数位居五个项目的第一（竞争相当激烈），在进行沟通后刘导也很爽快地答应了在 5 月 25 日的晚上开启线上答疑会议。在此之前，我们先回顾一下今天要讨论的项目。
项目回顾
项目名称：基于图数据库 nebula 增加对 List / Set 类型的支持
内容简述：NebulaGraph 是一款开源的分布式图数据库，目前支持的数据类型有基础的数值、布尔、字符串、时间、地理空间、类型转换等多种数据类型。但 List / Set 这两个重要的基础数据类型，在 nebula 最新版中，缺少了对它们的支持。大部分场景下，只要用到 List 数据类型，只能转化为多属性，或者平行边来实现，结果会带来使用上的各种不变。转换为多属性会导致属性的定义冗长，以及属性的频繁变更；转化为平行边会导致数据的冗余，以及一些超级节点的问题。
产出要求：支持 List/Set 类型的 DDL、DML和 DQL
Part1：自我介绍
本次参会的人员有小红鸡刘导，社区运营 Hera，东南大学小晖，华中科技大学小浩，香港中文大学小丰以及西安电子科技大学小洋。按照惯例，为了让大家先熟络起来，我们进行了自我介绍环节。
Hera：先自我介绍一下，我是 NebulaGraph 社区的运营 Hera。首先感谢这么多同学报名参加我们的项目。因为目前还处于申报的阶段，我们就想着老师如果方便的话，就组织一个答疑会，让同学们深度的了解一下每个项目具体要做什么，有什么价值。然后如果可以的话，也请大家也认识一下彼此，每位同学简短的介绍一下自己，也可以分享一下之前是否有参与过开源的项目。
小晖：老师好，各位同学们好，我是东南大学的小晖。参加此次活动的原因，是因为之前就想要学习跟了解图数据库的内容。我之前处理过一个大数据招聘平台的设计。读了研之后，也是跟着老师的要求，在做一个大平台的后端数据库，后面偶然间接触到 NebulaGraph。目前也还是在学习的一个过程中，后面就是看是否有机会能再跟老师还有其他同学继续交流学习，谢谢。
Hera：好的，谢谢你，看来你对数据库的后端开发，以及我们的产品是有一定了解的，那我们请下一位小浩同学自我介绍下吧。
小浩：大家好，我是来自华中科技大学的小浩。我自己实验室有做数据库相关的内容，之前也是参加过数据库大赛，是关于数据库内核的功能性内容。复赛做的也是有关数据库内核的一些东西。我自己对这块还是比较感兴趣的，所以看到 NebulaGraph 这边有数据库内核开发的项目，想来学习一下。
Hera：好的，谢谢小浩同学的分享，我们有请下一位小丰同学。
小丰：各位晚上好，我目前是研究生在读，之前在学校里上过一门课，是关于图数据库的，那节课的最后我正好做了一个图数据库的性能测试汇报。然后当时就逐渐对图数据库产生了兴趣，后面尝试去了解一些东西，就正好有机会接触到了我们 NebulaGraph 并想尝试贡献一点代码，目前就是这样。
Hera：非常棒，希望以后小丰同学能产出有关 NebulaGraph 的测试内容的话，可以分享到我们社区哈。接下来我们请到小洋同学。
小洋：大家好，我是西安的科技大学的小洋，现阶段我可能还是一位初学者。对图数据库做过一些基本的了解，也主动去学了很多有关内核开发的知识。我的话其实对这块很感兴趣，所以说想找一个途径来加入开源社区并尝试接触一些开源项目。
Hera：非常欢迎你，也谢谢各位同学的介绍！我们这次项目的导师是小红鸡刘老师。他是我们社区一位非常优秀的贡献者，之前对我们的产品和社区都做了很多的贡献，也很感谢他愿意以一个 Mentor 的角色投身到开源之夏的活动中。我们社区这次一共给出了五个项目，说实话可能都不是非常的简单，在我的理解里，特别是今天要讨论的项目，它需要对数据库内核要有一定的了解。接下去的内容就让刘老师来介绍一下吧，也可以顺带让他同学们认识一下你。
小红鸡：好的，我先自我介绍一下。同学们可以直接叫我的网名小红鸡，目前在一个项目组里负责对 NebulaGraph 做一些扩展开发。我平时会基于社区版做一些优化和性能的开发，闲暇之余也会和社区成员们互相交流，在力所能及范围内做出些贡献，这是我个人的一个基本情况。我接触 NebulaGraph 有两年左右了，两年前开始做的，期间断断续续，基本上都在做和这块相关的。我们项目组包括我个人做的东西可能更偏底层一点，一个传统分类图数据库上层的话有很多上层的算法或者上层的一些组件。我这边还是偏底层内核跟存储数据这一块，所以这个项目和我也是比较相关的。这种新增的数据存储，从上层的 Graph 层开始，从计算层开始到底层的存储，链路是挺长的，因此这个项目还是比较复杂的，有不小的难度和挑战性。
Hera ：谢谢刘导的介绍，这个项目确实会比较难，但也是一个非常好的机会。因为通过这一次的开发，同学们对图数据库会有一个比较清晰的认知。你会看到一些源代码，然后更清晰的了解存储到计算之间的各种关联逻辑。大家如果对底层技术感兴趣的话，也会有挺大帮助的。
Part2：难点答疑
进行了自我介绍后，会议的氛围也逐渐活跃了起来，导师和同学们对彼此也都有了一个基本印象，接下去就正式进入了会议的重点环节-答疑 timing，不妨看看学生们都有哪些“存货“吧。
1.东南大学-小晖
小晖 ：老师您好，我最近在认真的学习图数据库的用户画像和底层的一个逻辑代码，之前也根据自己的学习过程，在社区发布了一篇学习记录的博客，然后我现在学习追踪的是之前 v3.6.0 版本的代码，其中也找到了 List 和 Set 部分的代码。我看这两个部分内容上有很多相似的地方，它们都有用哈希函数来计算哈希值，所以我在想是否要做基于哈希的一个查找和比较？
小红鸡 ：这个你可以看它的数据链接，每个数据链接都有都定义了一个哈希函数。然后像底层数组是比较像的。它们都集中用了叠加机的原理，所以它都是直接迭代过去之后做一个哈希计算，上层的查找和匹配操作都会用到哈希函数。
小晖 ：还有就是项目的后半部分说用 List/Set 这个数据类型的时候会有一些问题，比如会带来使用上的不便，很多属性也导致属性定义太长，以及属性频繁变更和超级节点这些问题。针对其中多属性的定义修改的问题，我想的是能否把它拆成多个接口，去做一个多态并行继承。但我也不是很确定类似方法的可行性，还是想问问老师有没有具体解决这些问题的思路。
小红鸡 ：我大概理解你的意思，我们之前想定义 List/Set 这些属性的话。由于没有数据类型，我们采取了一些折中的方法，通过平行边的多属性去存储。然后我们现在有一个 List/Set 的这种属性，就可以直接指定一种属性。指定一种属性的话，在序列化和在网络传输上面，我们可以节省存储或者传输的字节数。然后有关性能方面的优化，我想的可能是更上层一点的优化。从计算层到存储层，我们定义两种属性跟定义一种属性，在做序列化和做 RPC 的时候，调一次函数跟调两次函数，这个区别就比较大了。包括做一次序列化跟做两次序列化，这个区别也是比较大。因此我想的是在更上层去减少这些动作。
小晖 ：好的，我还想再请教一下老师，我想要继续去搜索相关的一些代码功能，比如我之前是想查找关于超级节点的部分的解决方案。我当时设想的是能不能细化标签来减少遍历时的数据，但是我实际查找的时候并没有找到相关有用的内容。我不知道后面继续学习的话，老师您有什么建议可以帮助我去进一步的追踪一些代码，或者说查找功能？
小红鸡 ：超级节点这个问题可能我需要跟你一起学习，这一直是业界比较广泛被讨论的问题，所以这一块我也在学。我这边的学习方法比较倾向于去找一些优秀的案例，看在这些案例中有没有一些比较合适的方法去值得我借鉴。所以关于这一块我也没有一个很好的建议。当然各位同学，我们也可以一起学习，在这方面可以相互交流。
小晖 ：还有最后一个问题，就是如果我想要精确的查找一些功能，我该去怎么尝试追踪一些代码和函数呢？因为我在之前学习和追踪的过程中，都是通过日志去找到他们对应的调用函数然后一个一个查的，不知道老师您这边是如何去解决的，通俗易懂点讲的就是您是如何去看这个代码的。
小红鸡 ：我明白你的意思，其实就是一个功能对应的底层函数是哪些。这个问题在我以前刚开始接触一个新项目时也会遇到。从一个使用者的角度，我会从入口开始，首先找它的 RPC 接口。比如我们在调取 nebula 之后肯定会有一个对外的一个 RPC 接口，我们首先要找到它，然后再找它去调用的是哪些函数，从入口开始一层一层往往下走。这是一种方法，另外一种方法就是自己要清晰的知道目前使用的这个功能，比如说我想查找 List 或者查找 Set。那我就从底层开始找 Set 的存储或者 List 的存储，从下往下找，这也是一个方法。
小晖：谢谢老师，我这边暂时没有问题了。
Hera：谢谢刘导，小辉同学提的问题也很专业。超级节点这个问题确实是业界的一个热门话题，我们以前做产品的时候，内部也是有讨论如何去处理这个问题。社区论坛里面有很多相关的讨论帖，可以建议同学们搜索一下这方面的内容。其次还有关于学习的方面，我们有源码解读系列，对小晖同学刚才说的想找相关功能的对应文件还是有帮助的，所以同学们也可以去参考一下。接下去我们请小浩同学提问吧。
2.华中科技大学-小浩
小浩 ：你好刘老师，我想问一下，我们想要支持 List/Set，这是否会有很多种存储方案？因为 List/Set 不是静态的 Fix Size，它是会动态增长的，那我们是不是有一些可以使用的存储方案？
小红鸡 ：对，确实可以用到很多存储方案。不过关于这部分的详细设计我还没写。你可以关注一下 NebulaGraph 之前使用的数据，它的底层存储都是一个 String Buffer，Buffer 其实也是一个可扩展案例。String 本身也是动态的，你可以传一个参数，也可以传一个短的 String，因此可以参照 String 的存储方案。我在我的团队里也实现过 List 的存储，我是把 List 序列化成一个 Buffer 存储在底层。其实跟 String 的存储是一样的，只是多了一层序列化，重点就在于你怎么减少这个序列化的性能开销。
小浩 ：因为我是在想 List 和 Set 存储成 String 的方式也可以，但是存进去之后，再想把它拿出来用会非常麻烦，而且还要重新转换里面的 Value。所以这个 String 可能首先就要多存一点信息。其次就是我觉得如果存成 String 的话，操作难度会有点高。
小红鸡 ：对这是一个问题，关于这个问题我们需要先搞清楚是否要在中间层去转，这里我也得跟社区的开发对接一下，就是说我们存储到底层之后，取出来是直接拿到上层的客户端去用，还是说需要在中间的 Storage 层去解，或者在 Graph 层去做一个计算。如果有一些场景不需要的话，可以直接把取出来的序列化完整数据，传到上层的客户端再去解，这也是一个优化方式吧。如果需要在中间层把数据解出来使用，我们可以选择比较高效的解方式，我不知道同学们有没有用过 FlatBuffers， 它是一个不需要拷贝的操作，具体思路是用指针偏移的方式去读。像这种方式对读会非常的友好。当然可能还有其他的方式，我们可以后面再讨论。
小浩：好的老师，我这里差不多也结束了。
Hera：好谢谢小浩同学，下一位小丰同学可以说下你的问题。
3.香港中文大学-小丰
小丰 ：老师你好，我看了下源码，发现其中点和边的 Properties 已经抽象成 Value 类了。它的 Data Types 里面也已经有 List 和 Set。我想问第一个问题就是我看文档里，不查表的话，它好像已经有 List 和 Set 的语法了。文档里有实际的查询结果，但我没跑过。所以我想问它现在是完全不支持，需要从头实现吗？
小红鸡：你说的是查询结果，查询结果是可以返回 List 和 Set 的。关于这个查询结果，我们是通过函数然后在计算层得出了这样一个 List 和 Set 的结果返回给上层的。不过这个项目针对的是存储层，就是在存储的时候，我们目前还不支持对 List 和 Set 这种类型去进行存储和查询。
小丰 ：我明白了，那后续的话就是在 KP Store 还有 Storage，这两个模块还需要再大改一下吗？
小红鸡 ：是的,这部分是需要有修改的。
小丰：好的我明白了谢谢老师。
Hera ：好的谢谢小浩同学的提问，请最后的小洋同学提问吧。
4.西安电子科技大学-小洋
小洋 ：老师好，我是最近才开始看这个源码，现在也有类似刚才那位同学的疑惑。就是我看了源码里对 List 和 Set 内容的描述后，不太理解的是对这个项目而言，我们需要对存储做一些什么吗？是支持一下在分布式，一致性上的问题，还是一些性能上的优化？
小红鸡 ：首先你说的分布式和一次性，其实这些 NebulaGraph 的底层都已经做好了，它底层是通过 Raft 协议去做我们的支撑和一次性同步。我们要做的是让 List 和 Set 这些类型能查询，后续可能还要需要多做一些性能上的一些优化。就像刚刚小浩说的如果序列化成 String 去存储的话，在读的时候就会有性能上的开销。那就需要想办法用更好的方法去存储，然后再读取，最终实现性能优化，首先我们要能实现这个功能，其次再去关注性能。
小洋 ：好的我理解了，非常感谢老师。
Hera ：谢谢小洋同学的提问，也感谢每位同学能在会议上畅所欲言，同时也相信在经过了刘导的解答之后，同学们对这个项目也有了一个更清晰的认知。最后感谢刘导今天的耐心解答！
Part3：会议总结
经过长达半小时的讨论，老师和同学们的思维在一次次碰撞中产生了许多火花。对于此次会议及同学们在接下去如何更好的完成这个开发项目，现给出了以下几点总结：
-
查找并学习有关超级节点问题的优化方案 （详情戳这里
超级节点指南） -
研究如何在存储方案中减少序列化的性能开销 （可参考这个案例
关于 nebula 的存储设计） -
实现源码中提到的存储层支持 List 和 Set 数据类型的功能（可在我们公众号内输入关键词“源码解读”查看相关合集哦）
End
以上就是关于这次会议的全部内容，想要来交流图数据库技术？或者是对开源之夏项目感兴趣？关注公众号后发送“技术群”或“开源之夏”，NebulaGraph 小客服拉你进群~
