Nebula 架构剖析系列(一)图数据库的存储设计

发布网友发布时间：2024-09-27 09:33

共1个回答

热心网友时间：2024-10-04 13:10

昨天我们讨论了图数据库 Nebula Graph 的整体架构，今天我们来研究下它的存储设计。在讨论某个数据库时，存储 ( Storage ) 和计算 ( Query Engine ) 通常是讨论的热点，也是爱好者们了解某个数据库不可或缺的部分。每个数据库都有其独有的存储、计算方式，今天就和图图来学习下图数据库 Nebula Graph 的存储部分。

Nebula 的 Storage 包含两个部分，一是 meta 相关的存储，我们称之为Meta Service ，另一个是 data 相关的存储，我们称之为 Storage Service。这两个服务是两个独立的进程，数据也完全隔离，当然部署也是分别部署，不过两者整体架构相差不大，本文最后会提到这点。如果没有特殊说明，本文中 Storage Service 代指 data 的存储服务。接下来，大家就随我一起看一下 Storage Service 的整个架构。 Let's go~

图一 storage service 架构图

如图1 所示，Storage Service 共有三层，最底层是 Store Engine，它是一个单机版 local store engine，提供了对本地数据的get / put / scan / delete 操作，相关的接口放在 KVStore / KVEngine.h 文件里面，用户完全可以根据自己的需求定制开发相关 local store plugin，目前 Nebula 提供了基于 RocksDB 实现的 Store Engine。

在 local store engine 之上，便是我们的 Consensus 层，实现了 Multi Group Raft，每一个 Partition 都对应了一组 Raft Group，这里的 Partition 便是我们的数据分片。目前 Nebula 的分片策略采用了静态 Hash 的方式，具体按照什么方式进行 Hash，在下一个章节 schema 里会提及。用户在创建 SPACE 时需指定 Partition 数，Partition 数量一旦设置便不可更改，一般来讲，Partition 数目要能满足业务将来的扩容需求。

在 Consensus 层上面也就是 Storage Service 的最上层，便是我们的 Storage interfaces，这一层定义了一系列和图相关的 API。这些 API 请求会在这一层被翻译成一组针对相应 Partition 的 kv 操作。正是这一层的存在，使得我们的存储服务变成了真正的图存储，否则，Storage Service 只是一个 kv 存储罢了。而 Nebula 没把 kv 作为一个服务单独提出，其最主要的原因便是图查询过程中会涉及到大量计算，这些计算往往需要使用图的 schema，而 kv 层是没有数据 schema 概念，这样设计会比较容易实现计算下推。

...