跳转至

准备编译、安装和运行 NebulaGraph 的环境

本文介绍编译、安装 NebulaGraph 的要求和建议,以及如何预估集群运行所需的资源。

关于存储硬件

NebulaGraph 是针对 NVMe SSD 进行设计和实现的,所有默认参数都是基于 SSD 设备进行调优,要求极高的 IOPS 和极低的 Latency。

  • 不建议使用 HDD;因为其 IOPS 性能差,随机寻道延迟高。
  • 不要使用远端存储设备(如 NAS 或 SAN),不要外接基于 HDFS 或者 Ceph 的虚拟硬盘。
  • 不建议配置独立磁盘冗余阵列(RAID)。NebulaGraph本身提供了多副本机制,如果配置 RAID,会造成资源浪费。
  • 使用本地 SSD 设备;或 AWS Provisioned IOPS SSD 或等价云产品。

关于 CPU 架构

从 3.0.2 开始,NebulaGraph 在 Docker Hub 上的 Docker 支持 ARM64 架构。社区用户可以在 ARM macOS 的 Docker Desktop 上或者 ARM Linux Server 上运行容器化的 NebulaGraph 。

Caution

不建议在 Windows 上使用 Docker Desktop,因为 Windows 上的 Docker Desktop 性能较差。详情请参见 #12401

编译源码要求

硬件要求

单个机器的硬件要求如下。

类型 要求
CPU 架构 x86_64
内存 4 GB
硬盘 10 GB,SSD

操作系统要求

当前仅支持在 Linux 系统中编译 NebulaGraph,建议使用内核版本为4.15及以上版本的 Linux 系统。

Note

在内核版本低于要求的 Linux 系统中安装 NebulaGraph 可使用 RPM、DEB 或者 TAR 文件。

软件要求

软件版本需要如下表所示,如果版本不符合要求,请按照安装编译所需软件中的步骤进行操作。

软件名称 版本 备注
glibc 2.17 及以上 执行命令ldd --version检查版本。
make 任意稳定版本 -
m4 任意稳定版本 -
git 任意稳定版本 -
wget 任意稳定版本 -
unzip 任意稳定版本 -
xz 任意稳定版本 -
readline-devel 任意稳定版本 -
ncurses-devel 任意稳定版本 -
zlib-devel 任意稳定版本 -
g++ 8.5.0 及以上 执行命令g++ -v检查版本。
cmake 3.14.0 及以上 执行命令cmake --version检查版本。
curl 任意稳定版本 -
redhat-lsb-core 任意稳定版本 -
libstdc++-static 任意稳定版本 仅在 CentOS 8+、RedHat 8+、Fedora 中需要。
libasan 任意稳定版本 仅在 CentOS 8+、RedHat 8+、Fedora 中需要。
bzip2 任意稳定版本 -

其他第三方软件将在安装(cmake)阶段自动下载并安装到build目录中。

安装编译所需软件

如果部分依赖软件缺失或者版本不满足要求,根据如下步骤手动安装。可根据实际情况删减命令中要安装的软件、跳过无需执行的步骤。

  1. 安装依赖包。

    • CentOS、RedHat、Fedora 用户请执行如下命令:

      $ yum update
      $ yum install -y make \
                       m4 \
                       git \
                       wget \
                       unzip \
                       xz \
                       readline-devel \
                       ncurses-devel \
                       zlib-devel \
                       gcc \
                       gcc-c++ \
                       cmake \
                       curl \
                       redhat-lsb-core \
                       bzip2
      //  CentOS 8+、RedHat 8+、Fedora 需要安装 libstdc++-static  libasan。
      $ yum install -y libstdc++-static libasan
      
    • Debian 和 Ubuntu 用户请执行如下命令:

      $ apt-get update
      $ apt-get install -y make \
                           m4 \
                           git \
                           wget \
                           unzip \
                           xz-utils \
                           curl \
                           lsb-core \
                           build-essential \
                           libreadline-dev \
                           ncurses-dev \
                           cmake \
                           bzip2
      
  2. 检查主机上的 G++ 和 CMake 版本是否正确。版本信息请参见软件要求

    $ g++ --version
    $ cmake --version
    

    如果版本正确,则软件依赖已准备完毕,忽略后续步骤;如果不正确,根据不符合版本要求的软件执行后续步骤。

  3. 如果 CMake 或 g++ 版本不符合要求,访问官网以获取符合需要的版本。

测试环境要求

硬件要求

单个机器的硬件要求如下。

类型 要求
CPU 架构 x86_64
CPU 核数 4
内存 8 GB
硬盘 100 GB,SSD

操作系统要求

当前仅支持在 Linux 系统中安装 NebulaGraph,建议在测试环境中使用内核版本为3.9及以上版本的 Linux 系统。

服务架构建议

进程 建议数量
metad(meta 数据服务进程) 1
storaged(存储服务进程) ≥1
graphd(查询引擎服务进程) ≥1

例如单机测试环境,用户可以在机器上部署 1 个 metad、1 个 storaged 和 1 个 graphd 进程。

对于更常见的测试环境,例如三台机器构成的集群,用户可以按照如下方案部署 NebulaGraph 。

机器名称 metad 进程数量 storaged 进程数量 graphd 进程数量
A 1 1 1
B - 1 1
C - 1 1

生产环境运行要求

硬件要求

单个机器的硬件要求如下。

类型 要求
CPU 架构 x86_64
CPU 核数 48
内存 256 GB
硬盘 2 * 1.6 TB,NVMe SSD

操作系统要求

当前仅支持在 Linux 系统中安装 NebulaGraph,建议在生产环境中使用内核版本为3.9及以上版本的 Linux 系统。

用户可以通过调整一些内核参数来提高 NebulaGraph 性能,详情请参见内核配置

服务架构建议

Danger

不要跨机房部署单个集群(企业版支持跨机房集群间同步)。

进程 数量
metad(meta 数据服务进程) 3
storaged(存储服务进程) ≥3
graphd(查询引擎服务进程) ≥3

有且仅有 3 个 metad 进程,每个 metad 进程会自动创建并维护 meta 数据的一个副本。

storaged 进程的数量不会影响图空间副本的数量。

用户可以在一台机器上部署多个不同进程,例如五台机器构成的集群,用户可以按照如下方案部署 NebulaGraph 。

机器名称 metad 进程数量 storaged 进程数量 graphd 进程数量
A 1 1 1
B 1 1 1
C 1 1 1
D - 1 1
E - 1 1

NebulaGraph 资源要求

用户可以预估一个 3 副本 NebulaGraph 集群所需的内存、硬盘空间和分区数量。

资源 单位 计算公式 说明
硬盘空间 Bytes 点和边的总数 * 属性的平均字节大小 * 7.5 * 120% 由于边存在存储放大现象,所以需要点和边的总数 * 属性的平均字节大小 * 7.5 的空间,详情请参见切边与存储放大
内存 Bytes [点和边的总数 * 16 + RocksDB 实例数量 * (write_buffer_size * max_write_buffer_number) + 块缓存大小] * 120% 点和边的总数 * 16 是 BloomFilter 需要占用的内存空间,write_buffer_sizemax_write_buffer_number是 RocksDB 内存相关参数,详情请参见 MemTable。块缓存大小请参见 Memory usage in RocksDB
分区数量 - 集群硬盘数量 * disk_partition_num_multiplier disk_partition_num_multiplier是一个用于衡量硬盘性能的整数,取值范围 2~20。建议在计算 SSD 硬盘的分区数量时使用 20 做参数值,HDD 硬盘使用 2。
  • 问题 1:为什么硬盘空间的预估公式中需要乘以 7.5?

    答:因为根据测试值,相比原始数据文件(csv),单副本所占用的空间约为之前的 2.5 倍;另外索引会另外占用硬盘空间,每个被索引的点或边占用 16 字节的内存,索引的占用硬盘空间可按经验估算为:被索引的点或边总数 * 50 字节。

  • 问题 2:为什么磁盘空间和内存都要乘以 120%?

    答:额外的 20% 用于缓冲。

  • 问题 3:如何获取 RocksDB 实例数量?

    答:对于社区版 NebulaGraph,每个图空间对应一个 RocksDB 实例,并且--data_path选项(etc目录下的nebula-storaged.conf文件中)中的每个目录对应一个 RocksDB 实例。即,RocksDB 实例数量 = 图空间总数 * 目录总数。

Note

用户可以在配置文件nebula-storaged.conf中添加--enable_partitioned_index_filter=true来降低 bloom 过滤器占用的内存大小,但是在某些随机寻道(random-seek)的情况下,可能会降低读取性能。

Caution

每个 RocksDB 实例即使还未写入任何数据时,仍会占用 70M 左右的磁盘空间。一个分区对应一个 RocksDB 实例,当分区设置特别多时,例如 100,图空间创建后即占用了大量磁盘空间。


最后更新: May 9, 2024