共计 2721 个字符，预计需要花费 7 分钟才能阅读完成。
本文来自 NebulaGraph 的软件工程师文豪在美国费城加入 2022 年 SIGMOD 大会时的见闻。SIGMOD 是数据库畛域的顶级会议之一，是 CCF 数据库 / 数据挖掘 / 内容检索畛域 A 类会议。
NebulaGraph 作为国内惟一的开源图数据库厂商加入，并以展商身份在会上发表了《NebulaGraph: a nex t-generation of hyperscale graph database》演讲。
以下内容文豪将以第一人称开展叙述：
往年 SIGMOD’22 在费城 Philadelphia 举办，我有幸代表公司加入这次盛会。此次参会，我和学生、传授、厂商多有交换，一方面宣传了咱们的产品，另一方面也获取了许多贵重的倡议和意见。接下来，我将分享其中一些倡议，以及我整体的思考。
图学习和存储技术广受关注
首先是行业新趋势，本次会议大家关注的热点次要有两个。
第一，机器学习的比重进一步减少 ，尤其图学习（graph learning）可能成为新的热点。近年来，越来越多的零碎畛域的会议会专门开设机器学习的专区，次要是使用一些机器学习的办法来优化零碎或者算法。其中，有一个方向最近异军突起，就是图学习。简略来说，图学习就是在图上的机器学习。和其余用机器学习解决理论问题相似，图学习通过 embedding 的形式，从 graph 中提取出特征向量（feature vector），再用机器学习的办法解决图中那些艰难的问题，包含分类、子图匹配、链接预测（classfication，subgraph matching，link prediction）等。
从会议的偏向和 NSF (National Science Foundation) 的领导来看，这个趋势还会继续炽热。咱们也收到很多学生和传授对于是否反对图学习的询问。从图数据库供应商角度登程，图学习是 NebulaGraph 的利用之一。咱们不能仅仅满足于提供图数据库外围，还得为下层利用提供库、接口，甚至优化，来保障下层利用的顺利高效运行。从另一个角度登程，如果咱们的 NebulaGraph 能够帮忙学界在一些畛域，比方在图学习方面有所突破，对咱们公司、全行业倒退也是大有裨益的。
除了机器学习， 我认为另一个热点趋势就是内存 ，包含 in-memory database, persistent memory 等。目前非易失性存储（non volatile memory），或者叫持久性存储（persistent memory），通过学术界和工业界十多年的共同努力曾经越来越成熟。目前针对如何应用持久性存储的钻研也是十分炽热，简直所有零碎的顶会都有大量相干的文章。
具体到数据库畛域，就包含：如何设计内存数据库（in-memory database）、如何将持久性存储（persistent memory）和 SSD、DRAM 等混合应用，如何解决内存隔离（memory segregation）的问题。NebulaGraph 作为图数据库供应商，也应该踊跃拥抱新硬件带来的扭转，积极探索基于 persistent memory 的存储系统。
图的劣势与倒退方向
除了新趋势，我在会议中最大的播种和思考是对于图数据库（GDBMS）和关系型数据库（RDBMS）的比拟。会上有不少人表白「为什么不基于关系型数据库来实现 graph datababse」的疑虑。
因为关系型数据库通过多年优化，的确曾经武装到了牙齿。比方 Peter Boncz 传授（LDBC 创始人之一）在往年早些时候在 EDBT / ICDT 会议上做了个主题演讲——《The (Sorry) State of Graph Database Systems》，提出以后 GDBMS 跟 RDBMS 相比，在计算和存储层都还有很多中央须要进步，尤其是针对子图匹配（subgraph matching）这样的 AP 查问。他提出了针对子图匹配场景的性能基准测试（Benchmark）。在他的试验环境下，没有一款图数据库软件在「子图匹配」场景上的性能可能靠近 Hyper 和 Umbra 这两款关系型数据库（见上面图 1）。
图 1：在 Subgraph matching 上，GRDMS 不如一些非凡的 RDBMS，具体可看 Slides。
这个试验的设置诚然有值得探讨的中央，但 Peter 作为 LDBC 的创始人，他的外围目标天然不是贬斥图数据库，只是想借用子图匹配——这个图数据库优化得还不够好的一种查问场景，来激励各个图数据库厂商晋升本人的产品。
从更广的图景来看，咱们 NebulaGraph 作为图数据库厂商，必须把握图数据库和关系型数据库的区别和劣势：
- 一是图查问，尤其是 GQL 绝对于 SQL 的易用性和高效性。
- 二是易用性，Neo4J 的 CEO，Emil Eifrem 有个十分好的例子：对于一个 AP 零碎十分常见的查问，如果应用 SQL 须要 23 个
SELECT，21 个WHERE，11 个JOIN，9 个UNION，最初造成一个巨长无比的查问语句（query）。但如果应用图相干语句，只须要一个MATCH和一个WHERE。对于应用 SQL，很有可能是无奈实现工作或者极易出错，而对于后者应用图相干语句，则能够省下有数人力物力。
对于性能，除了在关联关系查问中，图数据库相较于关系型数据库的人造劣势，还须要在其余图相干的各种查问上（不止于上文提到的子图匹配 subraph matching）获得对于关系型数据库的劣势。这其实也是 Peter 提出子图查问这个检测基准对于咱们的外围启发。
对底层存储构造的思考
最初，咱们也取得了不少对于底层存储的倡议。NebulaGraph 目前底层存储应用的是基于 LSM Tree 的 RocksDB。但 LSM Tree 是否实用于图数据库的 workload，尤其是上云后，是否是性能最好、老本最低的抉择，始终是有争议的。可能的替代者有：
- Bε-tree File System，betrFS: https://www.betrfs.org/
- LiveGraph：https://marcoserafini.github.io/papers/LiveGraph.pdf
- B+ Tree: 在这方面，后续咱们也会继续跟进钻研
总之，这次 SIGMOD’22 之旅播种了许多。期待明年的 SIGMOD。西雅图见！
谢谢你读完本文 (///▽///)
要来近距离体验一把图数据库吗？当初能够用用 NebulaGraph Cloud 来搭建本人的图数据系统哟，快来节俭大量的部署安装时间来搞定业务吧~ NebulaGraph 阿里云计算巢现 30 天收费应用中，点击链接来用用图数据库吧~
想看源码的小伙伴能够返回 GitHub 浏览、应用、(^з^)-☆ star 它 -> GitHub；和其余的 NebulaGraph 用户一起交换图数据库技术和利用技能，留下「你的名片」一起游玩呢~
