社区动态
NebulaGraph 开源三周年，你关心的 5 个问题都在这里
2019 年 5 月 15 日，NebulaGraph 图数据库在 GitHub 开源 alpha 版本。三年过去了，NebulaGraph 的开源社区茁壮成长，聚集了几千名社区成员和超百位社区代码贡献者，项目在 GitHub 上积累了超过 7400 个 star。
在过去的三年里，包括腾讯、美团、京东科技和快手在内的数百家海内外企业用户已经将 NebulaGraph 作为底层图数据库用到他们各自的行业解决方案或产品中。
另外，NebulaGraph 近期被 CSDN 选为 2021 年的 “年度开源项目”。英国投资公司 OXX.VC 也将 NebulaGraph 评选为 2021 年成长最快的开源公司，与 Airbyte、Supabase 等广受欢迎的开源项目并列。
在庆祝 NebulaGraph 开源三周年取得的成绩的同时，NebulaGraph 的创始人、技术负责人、和社区负责人也希望能将自己的开源经验分享给社区成员们，并回答一些社区成员最关心的问题。
NebulaGraph 是如何诞生的？
以下内容来自于 Sherman Ye，NebulaGraph 创始人
在过去 10 年里，我参与研发了数个以图为基础的查询和数据库系统，并创业打造了国内首个开源分布式图数据库 NebulaGraph。在这十年时间里，类似于 Facebook 和微信这样的社交网络的爆发让发掘数据之间的关系显得比任何时候都重要。而图数据库则是表示和理解这些关系最天然的工具，并将作为下一个十年最重要的数据库类型被广泛应用在金融、AI 和物联网等热门领域。
在充分了解行业对图数据库的需求，以及认识到现有图数据库产品的不足后，我在 2018 年开始投入研发 NebulaGraph。我们从写下 NebulaGraph 的第一行代码开始就认识到它必须是一款开源的、分布式的、支持线性扩容和性能高效的图数据库产品。
打造这样一款图数据库产品最先要解决的是可扩展性（Scalability）的问题。当时市面上已有的图数据库基本上要么是单机版，要么可扩展性不强。
要解决可扩展性的问题，就需要从整个技术架构上实现高效可扩展。因此，NebulaGraph 的技术架构有两个重要特征：Shared Nothing（SN）和存储计算分离。
SN 架构是相对于 Shared Everything 架构，一般指单个主机独立支配 CPU、内存和磁盘等硬件资源，但其数据并行处理能力差，可扩展性低。另外还有 Shared Disk 架构，各个处理单元私有 CPU 和内存，但各个节点共享磁盘。这种架构具有一定的可扩展性，可以通过增加节点的方式来提升数据并行处理能力，但磁盘的 I/O 性能就成了系统性能的瓶颈。
在一个 SN 架构中，各个处理单元都有私有的 CPU、内存和磁盘资源，不存在共享资源。SN 架构中的节点相互独立，各自处理自己的数据，各个处理单元之间通过协议通信。每个节点处理后的结果可以向上层架构汇总或在各节点之间传递。在 SN 架构的数据库中，各个节点具备共同的 Schema，因此只需要增加节点就能快速增加处理能力和容量。
NebulaGraph 的另一个架构特征是存储计算分离。在这种架构下，有状态的存储端只负责存储数据，不处理业务逻辑，而无状态的计算端只处理逻辑，不持久化处理数据。
做存储计算分离最大的好处就是每一个节点之间没有共享数据，这样在做扩容和扩展的时候成本会很低，因为存储节点之间没有依赖关系。存储计算分离之后存储层和计算层能够单独地做扩容，不需要一起来做。这样首先可以降低成本，其次是整个 scale out 的过程也更加敏捷。存储计算分离也使得我们的系统成了一个云原生的系统。云最大的特点就是它的资源是按需分配的，那么一个存储计算分离的数据库系统也能做到在存储端和计算端分别按需分配，分别做弹性扩容。
在过去几年的时间里，国内涌现了一批优秀的图数据库产品，也逐步建立了一个图数据库开发者生态。但国内图数据库的生态还处于非常早期的状态，目前围绕数据库的外围产品大多数都来自于海外，而图数据库也不为很多开发者所知。
但国内有海量的数据以及一流的业务场景，我相信随着图数据库的不断普及，加上开源社区的力量，很快国内就会出现一个良好且成熟的图数据库生态。
为什么 NebulaGraph 会选择开源？
以下内容来自于 于新林，NebulaGraph VP of Engineering
关于为什么选择开源这个问题，第一，我们公司成立在 2018 年 10 月份左右，那个时候感觉业界整个开源的势头越来越强，这是一个大的趋势；第二，因为我们是做图数据库的，图数据库是底层的 infrastructure 的产品，这种产品只要是商业模式找到了，其实开源是一个比较好的手段，它可以快速地让你接触到你的客户、接触到开发者，可以让客户和开发者给你提需求、提 Bug，甚至贡献代码，这样更适合产品的发展，进行快速迭代，所以当时我们选择了开源。
另外，开源也让 NebulaGraph 这款产品在与其他图数据产品的竞争中脱颖而出。因为 NebulaGraph 是一个开源的、完全自研的图数据库，所以可控性就高了很多，这里自研指的是我们跟社区共建产品；其次，因为可控性很高（自研），可以做很多极致的优化。Nebula 最大场景可以到千亿点和万亿边规模，现在有的客户已经达到这种规模，在这种海量高并发场景下采用 NebulaGraph 就很适合。
另外在这种高并发下，客户对于响应时间的要求比较严格。因为 NebulaGraph 是一个 OLTP 数据库，性能上，在海量高并发下可以实现毫秒级返回，这些都是我们目前感觉做的相对比较好的点，当然也有一些不足需要持续的优化和完善。
如何看待开源项目的商业化？
以下内容来自于 Sherman Ye， NebulaGraph 创始人
如何将开源产品商业化这个话题由来已久。从开源这个概念诞生开始，大家就一直在探索怎么能够把开源项目商业化。我认为开源项目的商业化经历了三个阶段的发展。第一阶段是类似于 Red Hat 这样的公司模式，为其开源项目提供商业服务。第二阶段是所谓的 open-core 模式，为开源项目提供付费的企业版。第三阶段就是最近流行起来的云原生的方式，提供基于开源项目的云服务。
对于 NebulaGraph 来说，我们现在处于第二阶段和第三阶段。首先，我们在做强做好 NebulaGraph 开源版本的同时，会提供一个在功能和性能方面更符合企业级要求的企业版，并提供一系列的企业级的服务，包括 SLA 的响应时间以及更及时的技术支持。其次，我们会通过上云的方式来实现商业化，为用户提供一种简洁、方便且平价的图数据库服务。对于中小企业来说，每个月花一笔不多的订阅费使用云上的图数据库其实是一种比较省心省力的投资。而对于大企业来说，如果他们的整个系统和架构都已经在云上的话，他们对开源项目的云服务的需求也是很大的。
因此，我认为云服务在未来几年里将会为开源项目的快速发展提供一块非常肥沃的土壤。
NebulaGraph 在构建社区上有什么经验分享？
以下内容来自于 刘昭，NebulaGraph 社区负责人
NebulaGraph 这个开源项目离不开我们社区里几百名外部成员的贡献。为开源项目贡献代码和时间本质上是一种劳动，但大多数开源项目贡献者其实并没有收获到实际的报酬。因此，我一直在思考为什么有人愿意贡献开源项目。
去年 COSCon 开源社区年会上，知名开源布道师 tison 分享了题为 Why Contributors Stay and Grow 的演讲，我深感共鸣。结合 NebulaGraph 社区运营的实践，我认为开源贡献者可以分为三类：因为公司使用开源项目而发生的代码回流、为了推动某项技术的开源爱好者，以及对社区产生归属感的成员。这三类人参与开源项目的动机各不相同，但他们都是一个健康的开源社区里不可或缺的一部分。
最常见的一类开源贡献者是他们所在的公司使用某款开源产品，他们作为该产品的使用者，在使用过程中遇到了问题或者发现有功能缺失，在自己 fork 的版本上做了修复和开发，最终将修改回源到上游开源社区，成为贡献者。
第二类开源贡献者因为认同某一项技术，出于个人学习和提升的目的，参与到开源项目的开发中。这些行为与直接的物质奖励和组织的绑定都无关，他们即使没有收到物质奖励或离开了使用这项开源项目的机构，仍可能保持贡献。这种模式下，贡献者从社区获得的价值是个人的成长和能力、声望的提升。
最后一类贡献者是因为对某个社区产生了价值认同和归属感，而愿意长期留在社区，跟社区一起成长，持续地做出贡献，这叫文化驱动。
开源社区是围绕着开源软件存在的，社区的终极目标是打造一款有价值的软件产品，并以此推动行业的发展。在实际维护 NebulaGraph 开源社区的过程中，我们发现第一类，也就是因为组织驱动的贡献者对项目的贡献最活跃和显著。因为他们是开源项目真正的使用者，有真实的业务场景，对项目的理解比较深刻，能提出来的代码贡献应该是最有意义的。
有很多人说开源其实是一个产品进行市场营销 （Marketing） 的一种方式，即通过开源的方式吸引到一批种子用户，然后再推出商业版本将用户转化为付费用户。但我认为社区和 Marketing 是有本质上不同的。
Marketing 有一个转化漏斗的概念，这个漏斗尝试将感兴趣的用户一步一步转化为最终的付费客户，而这个漏斗对用户的价值判断取决于他们是否能够最终沿着设定的路径被转化到漏斗的最底端。因此，在 Marketing 的体系里，只有被转化的那部分人有价值。
而社区允许各种用户的存在。在社区的话语体系里，每个类别的用户都有他 / 她的价值，比如代码贡献者、文档贡献者、布道者等。他们不需要被统一地转化成某一类角色，他们被允许以某一种角色停留在社区里，比如仅仅作为用户，或者仅仅作为一次性的代码贡献者。
目前有一个大家比较认同的社区模型，叫 Orbit 模型，比较清楚地展示了社区中各类角色跟项目之间的关系。在这个模型里，每一个开源社区都致力于构建一个“高引力社区”，意味着社区通过提供极致体验以吸引和留存所有类型的社区成员。
因此，无论是组织驱动的贡献者，抑或是自我驱动、文化驱动的参与者，本身在社区里都有存在的价值。
NebulaGraph 的下一步 roadmap 是什么？
以下内容来自于 于新林，NebulaGraph VP of Engineering
第一步，先把 NebulaGraph 上云，提供 DBaaS 服务，类似于 PaaS 服务，客户不用去考虑怎么样去搭建、部署、运维一个数据库，只要使用数据库的服务就好了。我们现在已经在和一些云厂商合作，把我们图数据库搬到云上来。实际上，最近我们已经宣布在微软的 Azure 上的 DBaaS 服务，主要面向海外市场。在国内，最近我们也会宣布在阿里云上的云服务，敬请期待。
第二步，我们其实后续也在加大 AP 这个领域的投入，现在已经有 AP 相关的服务，但是跟我们理想中的还有差距，之后通过加大对 AP 领域的投入，真正把 TP 和 AP 融合起来，做到 HTAP。
第三步，我们后续也希望能把图的计算和图的分析以 SaaS 化的服务形式搬上云，这样对一些客户来讲，就不需要去搭建一套图计算和图分析的平台，只需要用 SaaS 服务把数据上传，进行图计算和图分析便可得到结果，这样可实现按需付费，按照计算单元和时间付费，这是我们接下来的一些大的思考和规划。
交流图数据库技术？加入 Nebula 交流群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~
