本文由美团 NLP 团队高辰、赵登昌撰写
首发于 Nebula Graph 官方论坛: https://discuss.nebula-graph.com.cn/t/topic/1377
## 1. 前言
近年来,深度学习和知识图谱技术发展迅速,相比于深度学习的“黑盒子”,知识图谱具有很强的可解释性,在搜索推荐、智能助理、金融风控等场景中有着广泛的应用。美团基于积累的海量业务数据,结合使用场景进行充分地挖掘关联,逐步建立起包括美食图谱、旅游图谱、商品图谱在内的近十个领域知识图谱,并在多业务场景落地,助力本地生活服务的智能化。
为了高效存储并检索图谱数据,相比传统关系型数据库,选择图数据库作为存储引擎,在多跳查询上具有明显的性能优势。当前业界知名的图数据库产品有数十款,选型一款能够满足美团实际业务需求的图数据库产品,是建设图存储和图学习平台的基础。我们结合业务现状,制定了选型的基本条件:
我们试用了 DB-Engines 网站上排名前 30 的图数据库产品,发现多数知名的图数据库开源版本只支持单节点,不能横向扩展存储,无法满足大规模图谱数据的存储需求,例如:Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。经过调研比较,最终纳入评测范围的产品为:NebulaGraph(原阿里巴巴团队创业开发)、Dgraph(原 Google 团队创业开发)、HugeGraph(百度团队开发)。
## 2. 测试概要
### 2.1 硬件配置
### 2.2 部署方案
Metad 负责管理集群元数据,Graphd 负责执行查询,Storaged 负责数据分片存储。存储后端采用 RocksDB。
实例 1 | 实例 2 | 实例 3 |
---|---|---|
Metad | Metad | Metad |
Graphd | Graphd | Graphd |
Storaged[ RocksDB ] | Storaged[ RocksDB ] | Storaged[ RocksDB ] |
Zero 负责管理集群元数据,Alpha 负责执行查询和存储。存储后端为 Dgraph 自有实现。
实例 1 | 实例 2 | 实例 3 |
---|---|---|
Zero | Zero | Zero |
Alpha | Alpha | Alpha |
HugeServer 负责管理集群元数据和查询。HugeGraph 虽然支持 RocksDB 后端,但不支持 RocksDB 后端的集群部署,因此存储后端采用 HBase。
实例1 | 实例2 | 实例3 |
---|---|---|
HugeServer[ HBase ] | HugeServer[ HBase ] | HugeServer[ HBase ] |
JournalNode | JournalNode | JournalNode |
DataNode | DataNode | DataNode |
NodeManager | NodeManager | NodeManager |
RegionServer | RegionServer | RegionServer |
ZooKeeper | ZooKeeper | ZooKeeper |
NameNode | NameNode[ Backup ] | - |
- | ResourceManager | ResourceManager[ Backup ] |
HBase Master | HBase Master[ Backup ] | - |
## 3. 评测数据集
## 4. 测试结果
### 4.1 批量数据导入
#### 4.1.1 测试说明
批量导入的步骤为: Hive 仓库底层 csv 文件 -> 图数据库支持的中间文件 -> 图数据库
。各图数据库具体导入方式如下:
#### 4.1.2 测试结果
#### 4.1.3 数据分析
### 4.2 实时数据写入
#### 4.2.1 测试说明
INSERT VERTEX t_rich_node (creation_date, first_name, last_name, gender, birthday, location_ip, browser_used) VALUES ${mid}:('2012-07-18T01:16:17.119+0000', 'Rodrigo', 'Silva', 'female', '1984-10-11', '84.194.222.86', 'Firefox')
{
set {
<${mid}> "2012-07-18T01:16:17.119+0000" .
<${mid}> "Rodrigo" .
<${mid}> "Silva" .
<${mid}> "female" .
<${mid}> "1984-10-11" .
<${mid}> "84.194.222.86" .
<${mid}> "Firefox" .
}
}
g.addVertex(T.label, "t_rich_node", T.id, ${mid}, "creation_date", "2012-07-18T01:16:17.119+0000", "first_name", "Rodrigo", "last_name", "Silva", "gender", "female", "birthday", "1984-10-11", "location_ip", "84.194.222.86", "browser_used", "Firefox")
INSERT EDGE t_edge () VALUES ${mid1}->${mid2}:();
{
set {
<${mid1}> <${mid2}> .
}
}
g.V(${mid1}).as('src').V(${mid2}).addE('t_edge').from('src')
#### 4.2.2 测试结果
#### 4.2.3 数据分析
### 4.3 数据查询
#### 4.3.1 测试说明
GO ${n} STEPS FROM ${mid} OVER person_knows_person
{
q(func:uid(${mid})) {
uid
person_knows_person { #${n}跳数 = 嵌套层数
uid
}
}
}
g.V(${mid}).out().id() #${n}跳数 = out()链长度
GO ${n} STEPS FROM ${mid} OVER person_knows_person YIELDperson_knows_person.creation_date, $$.person.first_name, $$.person.last_name, $$.person.gender, $$.person.birthday, $$.person.location_ip, $$.person.browser_used
{
q(func:uid(${mid})) {
uid first_name last_name gender birthday location_ip browser_used
person_knows_person { #${n}跳数 = 嵌套层数
uid first_name last_name gender birthday location_ip browser_used
}
}
}
g.V(${mid}).out() #${n}跳数 = out()链长度
GO FROM ${mid1} OVER person_knows_person INTERSECT GO FROM ${mid2} OVER person_knows_person
{
var(func: uid(${mid1})) {
person_knows_person {
M1 as uid
}
}
var(func: uid(${mid2})) {
person_knows_person {
M2 as uid
}
}
in_common(func: uid(M1)) @filter(uid(M2)){
uid
}
}
g.V(${mid1}).out().id().aggregate('x').V(${mid2}).out().id().where(within('x')).dedup()
#### 4.3.2 测试结果
单个返回节点的属性平均大小为 200 Bytes。
本项未测试最大吞吐量。
#### 4.3.3 数据分析
## 5. 结论
参与测试的图数据库中,Nebula 的批量导入可用性、导入速度、实时数据写入性能、数据多跳查询性能均优于竞品,因此我们最终选择了 Nebula 作为图存储引擎。
## 6. 参考资料
本次性能测试系美团 NLP 团队高辰、赵登昌撰写,如果你对本文有任意疑问,欢迎来原贴和作者交流: https://discuss.nebula-graph.com.cn/t/topic/1377
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论