快手安全情报通过收集需求和前期调查,最终选择NebulaGraph作为图数据库,用于生产环境。选型时,对图数据库的主要需求在于数据写入和数据查询两个方面:数据写入方式:离线+联机,需要支持天级导入大量离线数据,每天新增上百亿级的写入数据,需要每日生成关联关系数据,需要支持小时级写入数据,Flink使用Kafka数据,在完成逻辑处理后,直接对图数据库进行实时写入,需要支持QPS到10W级,数据查询方式:毫秒级在线实时查询,需要支持QPS到5W量级。
属性筛选和点、边查询,多层次关联查询,局部基图数据分析能力,图最短路径算法等。总而言之,本文所选择的适合大数据体系结构的图数据库主要需要提供3个基本功能:实时和离线数据写入、在线图数据基本查询、基于图数据库的简单OLAP分析,其相应的定位是:在线、高并发、低延迟OLTP类图查询服务以及基于图数据库的简单OLAP类图查询服务。
根据上述确定的要求,在进行图库选择时,我们主要考虑以下几点:图库所能支持的数据量必须足够大,因为企业范围内的图数据往往会达到上百亿甚至上千亿,集群可线性扩展,因为需要能够在生产环境中连续运行的联机扩展机器。由于需要满足联机服务的性能要求,查询性能不会因图数据量的增加而受到影响,因此可以比较方便地与HDFS、Spark等大型数据平台打通,在此基础上可以在后期建立图计算平台。
高效:提供毫秒级读写,可扩展:可水平扩展,支持超大规模图存储,支持引擎架构:独立于存储计算,图数据模型:点(vertex),边(edge),以及点或边的属性(properties)建模,查询语言:nGQL,查询语言类SQL,易于学习,满足复杂的业务需求,提供了一个比较丰富和完善的数据导入导出工具,NebulaGraph作为开源图数据库产品,在开放源代码社区中表现得非常活跃。与JanusGraph和HugeGraph相比,NebulaGraph查询性能有了很大的提高,这是基于NebulaGraph的以上特性以及对我们的使用场景和需求的恰到好处的满足,所以最终选择NebulaGraph作为我们的产品环境的数据库。
还没有评论,来说两句吧...