30亿数据的知识图谱如何解决“超级痛点”

微澜作为一款用于查询技术、行业、企业、科研机构、学科及其关系的知识图谱应用，具有十亿级实体以及百亿级关系。

而知识图谱作为一项系统性工程，很多场景需要向用户展示经过分页的一度关系，同时我们的数据中存在一些超级节点，但根据我们的业务场景，超级节点一定会是用户访问可能性最高的节点，所以这不能被简单归类到长尾问题上；又因为我们的用户量并不大，所以缓存必然不会经常被撞到，我们需要一套解决方案来使用户的查询延迟更小。

为了解决上述的业务痛点，微澜通过在知识图谱中引入 OceanBase社区版，突破了技术挑战，完美地在新闻资讯体系中搭建起了自己独有的体系优势，有效保证了信息的速度以及信息的可溯源与真实可靠。

超级节点引发的”超级痛点”

在微澜的知识图谱业务中，很多场景需要展示复杂的关系。

比如，某个机构在某领域的排名特别高，但在全局或者其他领域一般。在这种场景下，微澜必须显示排序属性，并且对于全局排序项，进行拟合标准化，使每个维度的数据方差都为1，均值都为0，以便用户进行局部排序，方便用户查询。

在技术上我们遇到了一个很严重的问题，我们选择图数据库作为知识图谱的数据载体，同时我们希望通过排序的方式展示用户查询到的前一千条结果，但是由于我们的知识图谱业务涉及到的数据极为庞杂，所以会出现很多邻接边超过十万的超级节点。

在知识图谱领域中，邻接边越多基本上就等同于此实体有越大的几率被搜索，当搜索此超级节点实体时，若需要展示排序后的结果，图数据库目前是不能胜任的（除非此图数据库已经全面做到了数据端的排序下推）。

一个十万邻接边的节点以 path 的方式进行一度查询需要近4秒，无法满足我们的业务需求。

空间换时间，知识图谱拥抱NewSQL

为了解决此问题，我们考虑加入其他数据库到我们的业务中，以空间换时间，通过数据冗余存储来实现业务延迟的降低。

微澜在知识图谱中加入 NewSQL ，把一度关系问题转化为传统 RDBMS 中的联合主键即可解决图数据库中海量数据排序下推的问题。

为什么是 NewSQL？

对于初创企业而言，在数据量极大但是并发量不大的情况下，NewSQL 不论是运维成本还是硬件成本都很低，我们的集群规模只有3台，但是总数据量却接近百亿，而且单表数据量极大，最大的一张表超过八亿数据，MySQL 之类的传统 rdbms 的分库分表方案对于我们运维人员很少的公司而言不友好。

传统的 DBMS 容错方案的重点是保障数据的更新不会丢失，而 NewSQL DBMS 除了这点以外，还能最小化停机时间，使其一直保持应用在线。这对于我们而言很重要，因为我们做的是商业场景，而且集群数量小，最小化停机时间对于我们来说非常重要。

性能PK，“30亿records”的选型之路

微澜有30亿的 records 数据，但没有复杂分库分表的运维能力。而 ScyllaDB 无法适应新业务的查询要求，所以微澜需要一个能实现传统 RDBMS 的 query 功能的数据库。

由于我们需要采用冗余存储的方式去以空间换时间，所以索引性能与索引形态是我们考虑的最关键的一点。

01

索引性能对比

目前市面上的分布式数据库中，从使用体验的角度看主流有两种形态：

以 TiDB、CockroachDB 等为代表的纯透明的用法

从表现上来看，该种类型的数据库所有表都是分布式表，并且不需要指定分区键，其核心逻辑是使用分布式事务来维护全局索引，并使用全局索引完全替代单机数据库中的二级索引。优点是其易用性决定了分布式数据库的使用下限，但性能上是有更高的成本代价。

以 OceanBase 等为代表的纯手动的用法

从表现上看，数据库在不指定分区键的情况下，是以单表的形式存在的，不具备扩展性；创建分布式表需要使用分区表语法。此类型的数据库也提供全局索引的能力。但与第一类不同，它们一般会将全局索引作为一个可选项，由用户手动指定与创建。此外，还会提供基于单机事务实现的本地索引。优点是手动创建能够提供最优的性能，但同时使用门槛会有所增加。

对于追求性能的业务来讲，第二种索引显然更适合我们。

除此之外，微澜需要进行周期性的大量写入，每两周就要淘汰掉30亿数据并且重写入等量数据，在这种情况下需要评估带索引的数据写入速度。

02

数据写入速度对比

CockroachDB 是 PG 型数据库，团队之前接触的比较少，对于单表的数据量支持一般，不符合业务需求。

TiKV 采用 Range 的方式分区，但微澜更需要 hash 的分区方式，因为微澜的业务更偏向于单点查询而非范围查询，写入速度比较慢，无法适应微澜周期性的大量写入的业务场景。

OceanBase 有优秀的写入能力，支持 hash 分区策略。对于单表大数据量的支撑强而有力，有良好的社区支持，支持 B tree 索引策略复合业务。对于 Paxos 的极致应用使得任务的并行粒度很细，可以把性能尽可能发挥出来。

经过测试，在有一个索引，数据量1亿左右的本地表中，OceanBase的写入速度整体比TiDB要好，而且TiDB在有索引的写入中比较容易造成oom，无法适应微澜周期性的大量写入的业务场景。

经过综合考虑，微澜最终选择使用 OceanBase社区版 。

全新CP，OceanBase 助力微澜突破技术挑战

在微澜的所有业务中，微澜选择使用 OceanBase 来存储图谱中所有的一度关系。查询性能相比之前的接近4秒，已经提升到100ms的水平，图数据库无法覆盖的海量关系查询排序已经被完美解决。

对比之前使用的 ScyllaDB ，作为 NewSQL 的 OceanBase ，自然比 NoSQL 数据库能实现很多扩展，覆盖更多的业务场景，比如多个条件的筛选并排序。现在微澜两周一次30亿 records 的数据更新已经在 OceanBase 上被验证了很多次，可以适配微澜的业务需求。

令人倍感惊喜的是，除了开发起来难度大大下降，和 MySQL Client 的兼容还有与MySQL 一致的 sql 语法，也让我们使用起 OceanBase社区版来如鱼得水。

来源：OceanBase 数据库星球