图数据库返回的数据的维度与多样性较传统数据库更加丰富，点（顶点）、线（路径）、面（子图）、体（异构多维数据），不一而足。但是所有的计算逻辑与数据结果应该是可以被验证的，例如查询逻辑、算法逻辑等等。结果正确性这一点目前为止很少被触及，也因此有很多图数据库与图计算产品的计算结果错误百出却依然浑水摸鱼。不解决正确性验证的问题，就会出现劣币驱逐良币的问题。
在图数据库的应用场景中，尤其是金融场景中，正确性验证更是尤为重要，一个小数点的错误，都可能会衍生系列的金融风险。从图上来说，例如在反欺诈、反洗钱场景中，账户 A 收到了一笔来自账户 B 的转账，这笔转账交易天然的应该被数据建模为一条由顶点（账户）B指向A的有向边。但是，在数据库底层，也需要构建一条A到B的反向边。这么做的原因是什么？如果没有存储一条从 A 至 B 的反向边，我们将无法从A出发追踪该笔（指向A的转账）交易，这显然是不能容忍的。
查询方式和查询代码逻辑错误同样也会对结果造成严重影响！明明应该用BFS（广度优先搜索）实现的查询或算法的却用DFS（深度优先搜索）实现，结果必然错误，最典型的就是K邻查询，有的互联网大厂图数据库（星图）因为没有能力对Twitter这类数据集中的超级节点通过BFS进行全量邻居处理，竟然改用DFS来实现——DFS的最大问题在于，它根本不是按照最短路径的方式的来进行遍历，因此会造成数据不去重、深度计算错误、结果错得离谱等诸多问题。再如，最短路径查询问题，任意两个顶点间可能存在多条最短路径，如果是转账网络、反洗钱网络、归因分析等查询，只计算一条路径显然是无法反映出全貌的！有的图数据库（例如ArangoDB）默认只返回1条最短路径，在Twitter数据集中，有些顶点间存在百万条以上的最短路径——不仅仅结果错误，计算复杂度也相差百万倍之巨！
一款图数据库，在POC与上线前不进行综合的正确性验证，你敢采购它？不要以为开源的就能算对了，没人给程序员开工资，谁给你费劲做正确性验证？目前我们看到的多款图数据库都存在各种各样的正确性错误的问题，总结有如下几个方面：
1. 数据建模方式错误（例如只进行单向边加载）；
2. 图查询逻辑与实现方式错误：K邻、路径等
3. 图算法实现方式错误：例如三角形计算，Neo4j只支持按照点来计算三角形个数，是一种典型的投机取巧，它不支持按照边来计算三角形个数；还有PageRank算法，必须是全量计算，且结果能排序，Neo4j居然允许算法调用是只进行部分计算，诸如此类的问题，不胜枚举。
4. 缓存结果，数据更新后，查询结果无法实时更新：有的图数据库，因为本身的算力、性能很糟糕，只能跑批来缓存结果，一旦数据集发生变化，再次查询也只是取缓存的结果，而没有能力实时返回更新后的结果。例如Twitter中某个顶点的3度邻居个数，如果该顶点与其某个三度邻居间建立条边，3度邻居结果必然改变，但是缓存的数据库结果必然不变，或者需要跑很久才能返回结果。这些猫腻都是在数据库正确性验证中不得不防的！
希望以上的分享对于大家有所帮助。
具体关于图计算（图数据库）如何进行结果正确性验证的链接如下，感兴趣的读者可以点击阅读： https://www.ultipa.cn/article/technical/graph_database_query_verification
