大数据四大阵营之OLTP阵营（中）

【书接上篇】*

（4）图数据库型NoSQL – 从Neo4J到嬴图

图数据库这一概念对于行外人士而言具有比较大的误导性，很多人乍一听会以为是图像处理数据库，而不会想到这里“图”是图论的“图”，也许当时命名这一类的数据库时用Topo Graph（可翻译为拓扑数据库）会更准确一些。
图：哥尼斯堡大桥问题。莱昂哈德·欧拉于1736年发表的《哥尼斯堡七座桥》被认为是图论史上的第一篇论文

图数据库的出现在NoSQL阵营中是较晚的，1990年代初互联网之父Tim B. Lee提出语义化网络（Semantic Web）的时候，对于整个互联网的数据层面的规划就是一张大的节点间相互关联的图。而之后的W3C推出的RDF（Resource Description Framework）标准是对WWW数据资源间的关系的一种描述，但是图数据库真正开始在商业中被应用是直到2011年前后Neo4J的推出，它是一种标注属性图，英文为Labeled Property Graph，简称LPG，而RDF类型的数据库则因为受到学术界的更多的采纳而侧重于解决学术界的问题（例如本体论等问题）。

Neo4J可以算作第一个工业级的商用化图数据库，它提出的不少理念及其产品化的实现是非常有价值的，例如：
· Index-Free Adjacency · Cypher
Index-Free Adjacency（无索引邻接），顾名思义是指图数据库中的数据是不需要索引的，这个对于传统的关系型数据库是个完全的颠覆！也就是说，可以做到IFA的数据库，那么它的数据存储和查询效率一定是实现了O(1) 或者远低于O(N)或O(LogN)，因此在图中的搜索、查询、计算的效率才会很高。
Cypher是Neo4J提出的一种类SQL的查询语言，图数据库中的查询是尤其特型的，例如查找图中一个顶点（节点）的朋友的朋友的朋友，这个对于关系型数据库意味着多次的表连接（join-table），这个操作是非常昂贵而且缓慢的（如果数据集恰好也较大），但是在图数据库中这个操作用Cypher表达可以非常直观，而且搜索运算的效率也要远高于关系型数据库（注：这类操作关系型数据库要比图数据库普遍慢几个数量级，例如1000倍甚至更多）。
(‘NodeA’) - [:FRIEND]-> ()-[:FRIEND]->() -[:FRIEND]->()
Cypher并不是图数据库领域唯一的查询语言，还有SPARQL，Gremini，这3者目前可以算作图数据库领域的三大标准，Gremini受到了Apache Tinkerpop3阵营的拥护，SPARQL顾名思义是从Spark阵营中演变而来的，Cypher因为Neo4J的推广而被Apache基金会接纳演变为OpenCypher，这3大阵营也许未来相当长一段时间会共存，毕竟图数据库的市场还远未饱和，而不同的解决方案也会适应不同的业务场景需求。
上面我们介绍了Neo4J的特点和出现的背景，我们再看一下它的工程实现的效果。Neo4J的核心引擎是Java实现的，也就是说在运行时它是跑在JVM（Java Virtual Machine）之上的，整个内存、堆的管理等一系列效率问题由此而生。笔者无意挑起关于Java性能问题的论战，但是有很多业界的场景和业务诉求，翻译成对底层技术的挑战就非常值得探讨：
· 高性能：在大图中如何做到纯实时计算或查询。一个基于批处理理念而生的系统如何能提供高性能（实时）的服务呢？Neo4J虽然宣称无索引邻接存储，但是它依然在很多地方需要通过构建磁盘索引来实现查询加速，它无法支持基于关系(边）的多属性过滤，它无法支持高密度并发计算，这些都是架构层面存在性能瓶颈的表现。
· 深度查询：在关联度较高的图当中如何实现实时的深度查询（>=5级的查询）。
· 高并发：这个问题和性能高度相关，从互联网产品的角度思考所有不能支持高并发的系统都是扩展性差的系统，而这在图数据库的领域是个很大的挑战。
· 系统稳定性：当在高压力、高复杂度查询、较高并发条件下，系统是否稳定？
· 系统资源消耗或性价比问题：基于Java的系统，因为GC等问题而导致对内存的需求庞大，并且难以控制。另一个方面是系统在运算时的真正的所需的时间、空间复杂度问题，Neo4J的每一次操作的（时间）复杂度为 O(LogN)，但是这个操作（iteration）只是每一次计算或查询请求中的1步，而每次计算的请求数量可能是N或N2甚至N3，如果从递归的角度看，Neo4J的计算时间复杂度经常达到O(N log N)、O(N** 2 log N)甚至O(N**3 logN)，这也解释了为什么它对于内存消耗之大和复杂操作时性能低下的问题了。

Neo4J在面对上面几个问题的时候受到了很大的挑战。当然，一部分原因是因为它有社区开源版本和企业级版本之分，而前者毫无疑问并没有（或者是有意而为之）去解决以上任何问题。这个问题也是开源社区都要去面对和思考的，一款优异的产品，特别是新产品，如果有明确的商业化的道路可以遵循，还有什么理由去打造一个开源的版本其性能与功能与商业版本无二呢？开源版本的稳定性一个是滞后于商业版本，另一个是需要极长的时间不断迭代才可能获得，MySQL今天如此稳定是用了20年的时间才得到的。反观后起之秀MongoDB，虽然它的用户群体在过去几年间快速的增长，也相当的庞大了，但它依然有很多陷阱，对于很多在成长中与其绑定的开发团队而言是极大的挑战，这个时候反而是商业化的版本更能解决团队当下甚至相当长一段时间之内的挑战。

当越来越多的企业与开发者在使用Neo4J类的基于批处理理念而构建的图数据库遇到问题的时候，他们就会转而寻找性能更优异的实时图数据库产品或解决方案。嬴图数据库就是在这样的背景下应运而生的。

嬴图数据库

**· 纯实时算力：**在大图当中依然可以做到毫秒级以内的实时计算能力。
**· 超深度图计算能力：**在复杂的大图当中支持超过30度的深度搜索、查询与计算。
**· 高并发系统：**嬴图支持高并发，能满足互联网级产品支持海量并发用户请求的需求，换句话说也能把很多之前的批处理请求转换为高并发请求以实时或近实时完成。
**· 高可扩展性：**线性可扩展的体系架构，它有两个维度，一个是数据存储量的线性扩展，另一个是并发处理效率的线性提升（处理时间线性缩减）。
**· **融合OLTP+OLAP：****简单而言实现了把批处理运算转换为在线实时的处理请求。
**· 计算复杂度：**通过数据结构和极致代码工程优化，在图上的大量操作，嬴图实现了最优的时间复杂度O(1)，在最复杂的查询条件下复杂度为O(log N)，而在空间复杂度上它稳定在O(2 * N)。

在NoSQL数据库的阵营中，图数据库所解决的最重要的问题是：深度数据间关联性挖掘的问题。例如如下这些行业场景与案例：

**· 流动性风险管理：**例如银行资债、资管场景中的各种流动性风险的实时、逐笔计量、下钻、穿透、追溯、模拟等等。
**· 智能营销管理：**例如在商业、零售银行中对于各种营销路径的智能化、量化、白盒化、实时化、传导化的推荐、分析、梳理。
**风控、反欺诈：**发现欺诈团体间的关联关系（环或链路）、发现已知黑户与新户间的潜在关联。
**· 反洗钱：**发现多个账户间的（深度）关联关系、资金流流向等。
**· 反黑、刑侦：**发现社区，多个（海量）账户间的潜在网络关系。
**· 知识图谱：**发现图谱中的节点的变动的影响范围，或定量查询任意节点间的关联。
**· 智能化网络管理：**发现任何节点的故障的网络化影响、智能定位故障节点。
**· 供应链管理与分析：**发现任意故障、延迟对于网络的整体影响或定向、定量影响。

以上多个反欺诈类型的场景中一个通用特点是利用图数据库来发现长链路或环，英文中称之为crime ring（犯罪环路或犯罪链条，可意译为欺诈链条，在银行业务中也常演变为像担保链、担保环的场景）这在风控的领域中是普遍的诉求，而用传统的关系型数据库、其它类型的NoSQL数据库或基于机器学习、深度学习或Spark类的大数据架构并不能有效解决这些问题，而图数据库几乎就是为此而生的。

还有一些场景的通性是要去发现传导效应、蝴蝶效应、涟漪效应，在网络中计算任意节点间的关联关系或者是某个节点或多个节点的影响力范畴、波及范围，这在审计、风控等领域中也是颇为常见的诉求。

以个人或企业的小微贷款中的征信过程为例，网络化分析是最有可能帮助贷款机构实现精准的客户判断，控制信用风险和进行信用管理的方案。而嬴图数据库的实时算力是在互联网时代对于实时性追求的最好的诠释。

·文/ 老孙（孙宇熙：云计算、大数据、高性能存储与计算系统架构专家 ）
·未完待续·