嬴图 | 图数据库的挑战是什么？

无论是什么数据库，如果不突出性能这个第一生产力，那么还有什么继续深入了解它的必要呢？图数据库尤其如此——因为图数据库解决的最主要的挑战就是传统数据库在面对深度数据间的关联关系时指数级性能下降、时耗增长的问题。

这里我们就不去赘述到底为什么需要图数据库—— 简而言之，它的出现与发展和不断向前迭代是企业IT信息化走向智能化的必然，也是从SQL到NoSQL再到Graph & Deep Data的必然。

然而，并非所有的图数据库都是类似的，目前我们已经看到了几个不同的阵营:

如果按照魔力四象限来区分的话，它们会如上图所示分布在各个象限中。显然，第一象限突出了2个特点：

1. 高性能；

2. 原生图支持。

有些厂家认为原生图是个噱头，这个恰恰说明这些厂家的开发人员对于原生图的概念的模糊——原生图隐含的意义是原生图存储，或者说是高性能存储引擎支持，也可以说是近邻无索引存储体系架构的搭建 ——试想，如果一个图计算引擎，它底层的存储还在依赖关系型数据库或者其它NoSQL数据库（例如JanusGraph)，那么你可以指望它有高并发、低延迟的能力吗？

回到性能，我们需要明确一点的是，很多系统都号称是毫秒级反应，听起来很快。但是笔者要指出的是现代CPU是在纳秒级工作的，毫秒已经是百万次纳秒操作了。况且，有些图数据库系统所宣称的毫秒级响应指的是最基础的操作（例如对顶点、边的搜索，或者最多1-hop类的路径或K邻操作），这种简单的操作，难道不应该在微妙级响应吗？

我们来看一下在真实的金融场景中，在生产环境下嬴图实时图数据库与其它系统的性能比较：

例如，1000次的点、边查询：

注意上图中所示的是1000次面向顶点、边的查询操作，嬴图的平均每次查询的时间在110-140微妙（~0.1毫秒）——约10倍快于Neo4j。

而，上图则展示了在进行1-3-5-10层（度）的K邻、路径查询，以及在带有过滤条件下的嬴图vs. Neo4j vs. ArangoDB的性能比较。注意在上图右侧在进行深度为5步的路径查询中，嬴图的平均时延为2ms，而其它系统则数千倍甚至万倍慢于嬴图!

以上的两个截图中的测试数据集分别为阿里妈妈的公开数据集（1亿边）以及全国工商数据（3亿点边规模及属性）。

下图则是图数据库公司都可能会遇到的Twitter数据集上的测试结果：

Twitter脱敏数据集有个特点是存在一些典型的超级节点，42M顶点，~15亿条边，存在一些出度超过100万的顶点（所谓的KOL大V）。Twitter数据集只是拓扑结构上分布不均匀，但是数据整体间关联度非常高——然而，它并没有任何点、边属性，因此面向Twitter的benchmark测试其实只能算上是一种暴力计算的能力，距离真实的工业化（金融行业）场景中的需求还有很大的差异（差距更为准确 ——大家可以理解为，当你的系统为了能更好的支持真实的业务场景时，例如数据、事物一致性的时候，你的系统可能不得不牺牲掉一些性能因素——这也就是为什么很多系统都是越做越慢——随着你的核心代码越来越臃肿，真正能保持性能极致的系统，少之又少）。

关于高并发系统，还有一个点很多人都没有get到，以为任何分布式系统都是高并发的，这个理解非常不准确。高并发主要有两点：

1. 在服务器端的高并发；
2. 在客户端的高并发。

怎么理解上面两句话呢？一个是你的系统可以支持多少用户同时访问你的图数据库（客户端），另外就是每个请求到达你的图数据库的服务器端的时候，你怎么实现的高并发 —— 这个地方最为tricky——比如一个5-hop的计算请求，高并发的服务器端会根据数据特征和请求特征来动态的匹配并行计算资源来以BFS（广度优先搜索）的方式，结合近邻无索引数据结构，以每个原子级操作为O（1）的算法复杂度，从原始顶点出发递归运算5层后返回所有距离出发顶点最短路径为5步的所有unique（去重）顶点集合—— 这个过程中如果实时观测CPU的利用率，可能会达到物理极限（如果不做任何并发规模限制的话）——在Twitter数据集上，这个特征会很容易体现出来，一个请求，例如顶点12的6-hop计算，16-core的单个CPU上可能可以达到3200%.……那么问题来了：除了嬴图，我们并没有发现任何其它系统可以有这种高密度并发的能力！这种能力不是说你的分布式集群里面有32台实例，然后每个实例只有1个线程跑起来，你就可以完成这个6-hop的操作的！32台机器*1线程每台机器的效率远远（指数级低于）低于1台机器上面32个线程的并发。因为图数据库的数据是高度关联的，当你暴力切割分图后，你在面对深度关联查询的时候的性能一定是极其糟糕的！

能做到单实例的高并发，再开始迭代演进到多实例的分布式系统的超高并发。而很多互联网厂家最喜欢的就是宣称自己的系统是如何水平分布式——然而到今天为止他们的系统既没有怎么高密度并发，也没有做到如何低延迟—— 这个问题的本质是所有高性能系统的底层一定是在存储与计算（还有网络层）做了很多工作，并且面对图数据集的特征做了很多性能优化与功能适配——这个的挑战和做过几年的秒杀抢单完全不是一码事儿。这个挑战是从底层就解决掉传统数据库的存储与计算逻辑—— SQL是面向存储的，而图数据库是面向计算的，把这两者混淆了之后，会走很多弯路。

图数据库还有很多内容值得探讨，希望大家多多交流。