郑荣凯：
北京深鉴智源科技有限公司架构师
负责数据挖掘/知识图谱业务的架构与落地
微澜作为一款用于查询技术、行业、企业、科研机构、学科及其关系的知识图谱应用，具有十亿级实体以及百亿级关系。
而知识图谱作为一项系统性工程，很多场景需要向用户展示经过分页的一度关系，同时我们的数据中存在一些超级节点，但根据我们的业务场景，超级节点一定会是用户访问可能性最高的节点，所以这不能被简单归类到长尾问题上；又因为我们的用户量并不大，所以缓存必然不会经常被撞到，我们需要一套解决方案来使用户的查询延迟更小。
为了解决上述的业务痛点，微澜通过在知识图谱中引入 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社区版 在知识图谱的用法，可以复制到类似的业务场景下吗？这种场景有什么突出的特点？
答：原生的存储数据的形式不具有排序功能。OceanBase社区版可以索引，做更多复杂的业务。
