图数据库是知识图谱系统的核心。在实际的应用中，为什么要做图数据库选型，图数据库选型应该怎么做？
蚂蚁集团图数据库负责人洪春涛，在知识分享社区Datafun的演讲中，对这些问题进行了分析和解答。以下是演讲原文整理。
1、为什么要做图数据库选型
图数据库是知识图谱系统的核心。在典型的知识图谱系统中，数据会在知识抽取、整理和推理之后，被存放到图数据库中，然后图数据库会支撑知识图谱的查询、更新、推断等任务。因此图数据的选型决定了图谱系统的规模、性能、稳定性，对整个图谱系统应用非常重要。
目前行业内图数据库类型非常多，常见的有Neo4j、JanusGraph，以及蚂蚁集团研发的图数据库TuGraph等，整体数量在几十种左右。但他们之间的差异非常大，比如查询语言上Neo4j用的是Cypher，JanusGraph用的是Gremlin。
图数据库的图模型也有很大差异。图数据库目前大部分以属性图为主，也有另外一类是RDF图，这两种图数据库从数据抽象上不一样，其它很多特性，比如有没有用户权限，有没有多图、有没有超图，这些特征也都非常不一样。
使用图数据主要的问题在于，它不像关系型数据库是一个标准的关系代数的抽象，上面有标准的SQL语言。目前图数据库没有完全标准化下来，所以对于很多用户造成了很大的困扰，在选图数据库的时候，不知道应该怎么选。
另外一个主要的问题是，图数据库现在很多应用场景其实是偏探索类的，在具体场景当中，会用到哪些算法，需要哪些特性，用户事先并不知道，因此更难选择图数据库的类型。
那么我们该如何做图数据库系统选型呢？
图数据库系统的选型，一个非常重要的工具就是基准测试程序，英文叫Benchmark，它会模拟真实的场景对系统进行测试，是比较标准的测试程序。
以TPC-C为例，这是个很标准的对关系型数据库进行测试的基准测试程序，它模拟的是连锁商店对数据库的使用，会在数据库建订单管理系统、库存管理系统、物流管理。这个程序本身会规定事务性应该支持到什么地步，应该有多并发，每一个查询的延迟应该有什么样的要求。如果一个关系数据库能够正确地通过TPC-C这个测试，并且得到一个值，那么对用户来说，就可以大致估计在正常的真实的情况下，它的功能，性能大致如何，进一步估计在真实场景下的功能性、稳定性等。
所以Benchmark可以指导我们对数据库系统的设计，同时它对加速整个行业的发展是很重要的。
2、我们需要什么样的基准测试程序
一个好的Benchmark有以下特性。
首先要贴合实际，它选择的场景必须是比较符合实际情况的。比如说TPC-C要模拟一个商店的管理系统，那么这个数据特征、操作特征就必须跟商店差不多，以做库存管理、订单管理为例，这些查询有多少读、有多少写，它们之间的混合比例，都需要符合实际。
性能特征上，要满足一定的延迟要求。读写比例并发有一定的要求，比如同时会有多少用户在这上面用，它的延迟要求是多少，必须要求查询应该是在几十毫秒，都是有一定的要求。查询跑出来的时间如果太长，肯定不符合正常的需求。
另外它必须具备可扩展性。实际测试中，商店大小是有差异的，如果说一个Benchmark只规定了一种数据大小，那就很难让用户感觉到在自己的场景下面会是什么情况。比如说用户要开一个商店，希望选一个数据库，但Benchmark的测试数据可能只限制了1GB数据，而实际用户的数据有1TB，那这个Benchmark就没有参考价值，所以大部分好的Benchmark都具备可扩展性，想测1GB、100GB、1TB甚至10TB都有办法去实现。
还有一点是标准必须要严谨，这是非常重要的。图数据测试，不能用TPC-C的数据来随意完成，比如只测读不测写，测试的时候把其中所有的写操作都去掉，跑出来一个结果看似很高，实际上却没有意义，因为并不符合实际的测试标准。所以这个标准本身必须要很严谨，它必须有审计规则，要有对数据的验证。
现在图数据库常用的几个测试程序，一个是Twitter，即把Twitter公布的数据集拿来跑K跳，从一个点出发去找K度的邻居，以及去跑图算法，这种测试的方法有很大的问题。一是推特本身的图非常有限，不具有可扩展性。图上面的点和边是没有属性，这其实是不符合真实情况的。另外它是一个社交图，跟其他很多常用的金融图等都不太一样，所以只能作为一个简单的参考。致命的是它只有读没有写，测试的时候就没法去测它的写操作，或者要测写操作也只能加几条边加几个点，这是非常不严谨的。
部分厂商在选型时会加一些自己的测试，比如说希望能够测一些读写混合，然后就从自己的数据里选一些示例数据，做读写的操作。这个做法实际上不符合标准，如果很明确地知道在一个场景下面要用什么数据，然后做什么操作，那么做这个测试是可以的。但是绝大多数情况下，我们并不知道以后会用在哪些场景下，它测试的时候只能测非常有限的几个场景，但是以后可能还要增加很多其他的业务，有可能这个数据以后也会增长。
所以这些只能作为简单的参考，它不具扩展性，也不具有严谨的效果。
这也是为什么我们想要去做Benchmark这件事情。
3、 金融图数据库benchmark怎么做
LDBC(The Linked Data Benchmark Council)是全球知名的非盈利性技术协会，目前有三个Benchmark，一个是基于语义网络的RDF图，一个是图分析，另外就是社交网络的图SNB。
目前国际上做得比较标准的图数据库测试程序是LDBC的SNB的测试。SNB测试是模拟社交网站对于图数据库的应用场景，按照社交网站的数据特性生成数据，它允许生成各种各样大小的数据，同时操作上有读写混合，读也有各种丰富的语义，有一个非常标准的文档，也有第三方审计。
SNB测试模拟的是社交的场景，里面有14类的点20类的边，点跟边上面会有一些属性，可以设置数据规模小的数据是SF1，大概生成出来是1GB的数据，大可以SF100，SF300，SF1000，SF30000都有。
从操作上它有两类，一类是Interactive，即模拟在线的查询，它上面有七种简单的读，14类复杂的读。有八种写的操作，实际测试的时候，会要求把这些读写混合的并发的发到这个图数据库上面。另外一类是BI的Workload。BI的查询里边，它是复杂的只读查询，就比上面这个复杂读还要更复杂，基本上是全局扫描的类似OLAP的应用。它的写是批量写，所以这个跟上面的Interactive是很不一样的。
在一些验证上面，它会要求读写混合，会有正确性的验证，这些读写做完了以后，需要验一下目前这个数据库的正确性，然后有事务隔离性的要求，重要的是它有延迟的要求，每一个查询规定大概只有千分之一的请求是可以超时的，如果延迟超过100毫秒的查询超过千分之一。那么这个比例太高了，这个数据库就是不通过的。
SNB模拟的是一个社交网站的数据，里边有人的节点，有论坛的节点，论坛里边有很多帖子，然后大家可以去转载这些帖子，同时这个人会有各种各样的资料，有他的公司、大学、城市，通过边会把这些信息连起来，在上面去做查询。是一个比较典型的图查询。
我们发现在蚂蚁自己的应用场景下面，有很多跟SNB不一样的地方，因此决定跟LDBC一起做一个金融图的Benchmark。金融Benchmark跟SNB的主要差别是什么呢？
首先是场景上的差别，SNB是一个社交场景，我们是金融风控等不同类型的场景，从数据上就会有比较大的差别。社交网络的图，有它的特殊性，首先它往往会有很多大点，比如一个微博大V账号，会有很多关注，它就是个大点；然后它里面的点，平均出度会比较高，如每个微博账号，平均会有300个左右的关注。这些特性导致社交图跟其它图都不一样，相对而言金融图相对出度会小一些。
SNB上面的模型点跟点之间是没有重复边的，但是金融图里边就非常多重边的情况，比如说两个人之间会经常转账，那么他们之间就会有非常多的重边出现。金融图的查询跟计算区别也很大，且查询对于延迟的要求更高一些。如果20毫秒之内返回不回来，那么整个用户体验就会很糟糕。
SNB里边读跟写是分开的。在金融图里读写是有可能在同一个Query里边的。我们会找很多的环状的结构三角的结构，这些都是跟SNB不一样的地方。所以这也是促使我们去做金融图Benchmark的一个主要动力。
目前我们的金融图Benchmark还在设计阶段，主要是在线查询，对延迟要求比较高。另外我们会设计负载的波峰波谷，因为一般来说半夜流量比较小；我们会对数据有TTL，会对过期的数据进行清理。比如说一般系统里边放三个月的数据，超过三个月就自动回收掉了。
以下是一个比较简单的又读又写的Query的示例。
除此之外，我们还会做一些反欺诈的、反套现的操作，这也是金融场景中经常需要解决的问题。我们会把金融图数据库Benchmark当做一个标准来做。
结语
综合以上，我们认为图数据库是图谱应用系统的核心，所以它的选型很重要，而Benchmark作为选型有力的工具非常重要。Benchmark如果做得好，它可以成为一种事实标准，指导系统的设计。我们也倡议更多的人来跟我们一起参与Benchmark的开发以及制定，推进图数据库系统的标准化，共建行业生态。
