nebulagraph存储什么数据(nebula graph)

本期，边肖将给大家带来一些关于图数据库星云图中访问控制实现原理的信息。文章内容丰富，从专业角度进行分析和描述。希望你看完这篇文章能有所收获。

数据库权限管理大家都很熟悉。但是，如何管理好数据库权限呢？本文将详细介绍星云图的用户管理和权限管理。

数据库权限管理已经为大家所熟悉。Bulagraph本身是一个高性能的海量图形数据库，数据库的安全性是数据库设计中最重要的问题。目前星云图已经支持基于角色的权限控制功能。本文将详细介绍星云图的用户管理和权限管理。

Nebula Graph 架构体系

从上图可以看出，星云图的主要架构分为三个部分：计算层、存储层和元服务。控制台、应用编程接口和网络服务统称为客户端应用编程接口。账户数据和权限数据将存储在元引擎中。当查询引擎启动时，元客户端将被初始化，查询引擎将通过元客户端与元服务通信。

当用户通过客户端API连接到查询引擎时，查询引擎将通过元客户端查询元引擎的用户数据，并确定连接帐户是否存在以及密码是否正确。验证通过后，连接成功创建，用户可以通过这个连接进行数据操作。用户通过客户端API发送操作指令后，查询引擎首先解析指令识别操作类型，并根据操作类型、用户角色等信息判断权限。如果权限无效，它将直接阻止查询引擎中的操作，并向客户端应用编程接口返回错误消息。在整个权限检查过程中，星云图缓存了元数据，这将在后面的章节中介绍。

00-1010在介绍函数之前，我们需要先描述一下星云图的逻辑结构：星云图是一个支持多图空间(spaces)的图数据库，其中Schema和数据是独立管理的，空间是相互独立的。此外，星云图还为集群的全局管理提供了一系列高级命令。下面将详细描述集群和空间的操作命令。

因此，星云图的权限管理将基于图空间（Space）,角色（Role）和操作（Operation）.三个维度，具体描述请参考以下章节。

功能描述

星云图提供了GOD、ADMIN、DBA、USER、GUEST五种操作角色，基本涵盖了所有数据安全控制场景。一个登陆账户（Account）可以在不同的 Space 中拥有不同角色，但一个 Account 在同一个 Space 中只能拥有一种角色.角色解释：

GOD:相当于Linux操作系统中的root用户，拥有最高的管理权限. Bulagraph集群会在初始化时默认创建一个GOD的Account角色，命名为root。

管理员：空间的高级管理员，拥有但对整个集群则没有管理权限.空间的所有管理权限

数据库管理员：数据库管理员，可以在其权限范围内管理空间，例如修改和查询模式/数据。admin和ADMIN的区别是

DBA 不能对某个 Account 进行授权操作，但 ADMIN 可以.

用户：普通数据库使用角色。可读写 Data，可读 Schema 但没有写权限.

顾客：访客角色，对权限内 Space

的 Schema 和 Data 有只读权限。

详细权限列表如下图所示：

注 : Special Operation 为特殊操作，例如 SHOW SPACE，每个角色都可以执行，但其执行结果只显示 Account 权限内的结果。

数据库操作权限细分

基于上边的角色列表，不同的角色拥有不同的操作许可，详细如下：

控制逻辑

Nebula Graph 的用户管理和权限管理和大多数数据库的控制相似，基于 meta server，对图空间（Space）、角色（Role）、操作（Operation）三个层面进行权限管理，当 Client 连接 Nebula Graph Server 的时候，Nebula Graph Server 首先会验证登陆账户（Account）是否存在，并验证密码是否有效。

登录成功后，Nebula Graph Server 会为此连接初始 Session ID，并将 Session ID、用户信息、权限信息和 Space 信息一起加载到 Session 结构中。后续的每次操作将基于 Session 结构中的信息进行权限判断。直到用户主动退出连接或 session timeout，Session 销毁。另外，Meta Client 对权限信息进行了缓存，并根据设置的时间频率进行缓存同步，有效降低了用户连接的过程的时间耗费。

控制逻辑代码片段

Permission Check

bool PermissionCheck::permissionCheck(session::Session *session, Sentence* sentence) {
    auto kind = sentence->kind();
    switch (kind) {
        case Sentence::Kind::kUnknown : {
            return false;
        }
        case Sentence::Kind::kUse :
        case Sentence::Kind::kDescribeSpace : {
            /**
             * Use space and Describe space are special operations.
             * Permission checking needs to be done in their executor.
             * skip the check at here.
             */
            return true;
        }
        ...

Permission Check Entry

Status SequentialExecutor::prepare() {
    for (auto i = 0U; i < sentences_->sentences_.size(); i++) {
        auto *sentence = sentences_->sentences_[i].get();
        auto executor = makeExecutor(sentence);
        if (FLAGS_enable_authorize) {
            auto *session = executor->ectx()->rctx()->session();
            /**
             * Skip special operations check at here. they are :
             * kUse, kDescribeSpace, kRevoke and kGrant.
             */
            if (!PermissionCheck::permissionCheck(session, sentence)) {
                return Status::PermissionError("Permission denied");
            }
        }
   ...
}

示例

查看现有用户角色

(root@127.0.0.1:6999) [(none)]> SHOW USERS;
===========
| Account |
===========
| root    |
-----------
Got 1 rows (Time spent: 426.351/433.756 ms)

创建用户

(root@127.0.0.1:6999) [(none)]> CREATE USER user1 WITH PASSWORD "pwd1"
Execution succeeded (Time spent: 194.471/201.007 ms)
(root@127.0.0.1:6999) [(none)]> CREATE USER user2 WITH PASSWORD "pwd2"
Execution succeeded (Time spent: 33.627/40.084 ms)
# 查看现有用户角色
(root@127.0.0.1:6999) [(none)]> SHOW USERS;
===========
| Account |
===========
| root    |
-----------
| user1   |
-----------
| user2   |
-----------
Got 3 rows (Time spent: 24.415/32.173 ms)

为 Space 中的不同 Account 指定角色

# 创建图空间
(root@127.0.0.1:6999) [(none)]> CREATE SPACE user_space(partition_num=1, replica_factor=1)
Execution succeeded (Time spent: 218.846/225.075 ms)
(root@127.0.0.1:6999) [(none)]> GRANT DBA ON user_space TO user1
Execution succeeded (Time spent: 203.922/210.957 ms)
(root@127.0.0.1:6999) [(none)]> GRANT ADMIN ON user_space TO user2
Execution succeeded (Time spent: 36.384/49.296 ms)

查看特定 Space 的已有角色

(root@127.0.0.1:6999) [(none)]> SHOW ROLES IN user_space
=======================
| Account | Role Type |
=======================
| user1   | DBA       |
-----------------------
| user2   | ADMIN     |
-----------------------
Got 2 rows (Time spent: 18.637/29.91 ms)

取消特定 Space 的角色授权

(root@127.0.0.1:6999) [(none)]> REVOKE ROLE DBA ON user_space FROM user1
Execution succeeded (Time spent: 201.924/216.232 ms)
# 查看取消之后，user_space 现有角色
(root@127.0.0.1:6999) [(none)]> SHOW ROLES IN user_space
=======================
| Account | Role Type |
=======================
| user2   | ADMIN     |
-----------------------
Got 1 rows (Time spent: 16.645/32.784 ms)

删除某个 Account 角色

(root@127.0.0.1:6999) [(none)]> DROP USER user2
Execution succeeded (Time spent: 203.396/216.346 ms)
# 查看 user2 在 user_space 的角色
(root@127.0.0.1:6999) [(none)]> SHOW ROLES IN user_space
Empty set (Time spent: 20.614/34.905 ms)
# 查看数据库现有 account
(root@127.0.0.1:6999) [(none)]> SHOW USERS;
===========
| Account |
===========
| root    |
-----------
| user1   |
-----------
Got 2 rows (Time spent: 22.692/38.138 ms)

上述就是小编为大家分享的图数据库Nebula Graph访问控制实现原理是什么了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。