如何运维多集群数据库?58 同城 NebulaGraph Database 运维实践

简介: 随着 58 同城内部图数据库 NebulaGraph 应用的场景越来越多,集群数量与日俱增,如何高效地管理多个数据库集群便成了首要解决的问题,而本文所实践的部分运维内容同样也适用于其他数据库运维。

58 同城基于 NebulaGraph 一键部署运维架构的实践

图计算业务背景介绍

我们为什么选择 NebulaGraph?

在公司各个业务线中,有不少部门都有着关系分析等图探索场景,随着业务发展,相关的需求越来越多。大量需求使用多模数据库来实现,开发成本和管理成本相对较高。

随着图数据库的发展,相关系统应用越来越成熟,于是引入专业图数据库来满足这部分业务需求的事务也提上日程。接下来要考虑的问题就是图数据库选型了。

首先,NebulaGraph 有大量互联网大厂应用案例,说明 NebulaGraph 可以应对海量数据的图探索场景。另外,目前 NebulaGraph 在 DB-Engines 在图数据库领域排名 14,而且增长势头强劲。排名靠前的图数据库,部分不开源或者单机版开源,场景受限。

图计算业务背景介绍

NebulaGraph 实际测试表现如何

在导入性能上,数据量小的时候 NebulaGraph 的导入效率稍慢于 neo4j,但在大数据量的时候 NebulaGraph 的导入明显优于其他两款图数据库。在 3 种查询场景下,NebulaGraph 的效率都明显高于 neo4j,与 HugeGraph 相比也有一定的优势。

图计算业务背景介绍

适用场景有哪些

公司有多种线上业务,工程复杂度和架构复杂度都较高,各个业务部门都需要专门的图数据库来实现对实体关系数据的处理和探索。

通过图数据库实现对任务依赖的运行时间进行监控,及时获取延迟任务、销售激励平台任务血缘关系处理、分析应用内部的类/方法级调用关系、业务风险数据分析、记录企业高管、法人、股东关系,用于签单业务等场景。

资源申请和集群管理方式

为了更好的管理和维护,图数据库在运维部门集中运维管理。用户按需在工单平台中提交申请即可,工单中填写详细的资源需求数据和性能需求指标,由运维同学统一审核交付集群资源。

公司目前服务器环境是自建机房,采用高配物理机,单机多实例混部数据库服务。为了实现规模化管理和维护,需要提前制定好实例标准和规则。

集群规模

得益于 NebulaGraph 良好的图计算能力,我们已经持续交付集群接近 20 套,目前还有业务部门在持续申请相关集群服务资源。

NebulaGraph 规范和架构设计

由于需要满足大量业务需求,未来会有大量的集群需要交付和维护。为了高效管理和运维规模化的集群,需要提前规划和制定规范。

版本规范

目前使用版本为 2.0.1

路径规范

  • 程序路径为 /opt/soft/nebula201,该路径下有 bin、scripts、share 等,作为公共的服务依赖路径,从服务路径中抽离出来

同样,升级为 3.X 版本,只需要将程序路径抽离出来作为公共的服务依赖路径即可。

  • 服务路径为 /work/nebulagraph+graph 端口,该路径下有 data、etc、logs、pids

端口规范

  1. 集群之间端口递增 5,因为 storage 副本需要端口通信,通常是 storage 端口 -1,例如两套集群 graph 端口分别是 60000 和 60005;
  2. 每种服务端口和 http、http2 端口之间步长为 10000,例如 graph 端口是 60000,ws_http_port 就是 50000,ws_h2_port 就是 40000;
  3. 三种服务端口之间相差 1000,例如 graph 端口是 60000,meta 端口就是 61000,storage 端口就是 62000;

    • 60000 graph 端口;50000 ws_http_port;40000 ws_h2_port
    • 61000 meta 端口;51000 ws_http_port;41000 ws_h2_port
    • 62000 storage 端口;52000 ws_http_port;42000 ws_h2_port

运维规范

第一,创建 space 需用 ngdb_ 左前缀,分片默认是节点数的 2 倍,副本数默认为 2,参考 CREATE SPACE ngdb_demo (partition_num=6,replica_factor=2,charset=utf8,collate=utf8_bin,vid_type=FIXED_STRING(128),atomic_edge=false) ON default;
第二,授予业务账号 DBA 角色:GRANT ROLE DBA ON ngdb_demo TO demo_wr;
第三,搭建一套 NebulaGraph 集群后,将内置账号 root 的密码重置,之后将 /work/nebulagraph+graph 端口 路径打包生成 rpm,作为标准安装包

NebulaGraph 规范和架构设计

服务请求直接通过 DNS 和网关服务到 Graph,方便计算和存储服务直接交互,由于是通过 DNS 访问,不对外暴露 Meta 节点信息,可以更灵活的运维,较少服务绑定 Meta 节点 ip 带来的运维代价。

这种架构限制了 Java 等驱动的访问,需要用其他驱动替代。

第四,基础集群套餐是 3 个 Graph 节点、3 个 Meta 节点、3 个 Storage 节点,在保证高可用的同时也能保证足够的处理能力。

基础集群分布在 3 台物理机上,存储和计算不需要过多的网络交互。

NebulaGraph 规范和架构设计

集群部署自动化实现

为了能够一键部署服务,集中式管理服务,我们需要借助远程管理工具 Ansible,能帮我们做到快速部署。依据三种角色服务的端口规范,生成 Ansible 的配置文件。

集群部署自动化实现

  • 由于将版本信息写到了配置文件中,在兼容多版本场景下,只需要在 bootstrap.yml 文件中增加相应判断即可,主程序兼容多版本成本非常有限。

部署实例时,根据 graph 角色分发文件,也可以每个节点单独分发文件。

  • 依据三种角色,分别分发配置文件到目的路径下,并且按照文件命名规则生成最终配置文件。
more bootstrap.yml
- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init elasticsearch file on data
      command: cp -r /opt/soft/nebulagraph201 {{ nebula_home }}
- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init config graphfile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201graph dest="{{ nebula_etc }}nggraphd.conf" owner=root group=root mode=0755
- hosts: meta
  become: yes
  remote_user: root
  tasks:
    - name: init config metafile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201meta dest="{{ nebula_etc }}ngmetad.conf" owner=root group=root mode=0755
- hosts: storage
  become: yes
  remote_user: root
  tasks:
    - name: init config storagefile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201storage dest="{{ nebula_etc }}ngstoraged.conf" owner=root group=root mode=0755

配置文件的分发最为关键,有较多变量需要处理,这些变量需要提前在 Ansible 的配置文件中定义,nebulagraphd 路径规范和服务端口需要使用 graphport、meta_server_addrs 需要用到 for 循环语法实现。

more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{ graphport }}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{ graphport }}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{ graphport }}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{ graph_h1_port }}
--ws_h2_port={{ graph_h2_port }}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password

同样,nebulametad 服务配置文件路径规范和服务端口需要使用 metahport、meta_server_addrs 需要用到 for 循环语法实现。

more templates/201meta 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{graphport}}/pids/nebula-metad.pid
########## logging ##########
--log_dir=/work/nebulagraph{{graphport}}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=metad-stdout.log
--stderr_log_file=metad-stderr.log
--stderrthreshold=2

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--port={{metaport}}
--ws_ip={{inventory_hostname}}
--ws_http_port={{meta_h1_port}}
--ws_h2_port={{meta_h2_port}}
########## storage ##########
--data_path=/work/nebulagraph{{graphport}}/data/meta

########## Misc #########
--default_parts_num=100
--default_replica_factor=1
--heartbeat_interval_secs=10
--timezone_name=CST-8

同样,nebulastoraged 服务配置文件路径规范和服务端口需要使用 storageport、meta_server_addrs 需要用到 for 循环语法实现。

more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{ graphport }}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{ graphport }}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{ graphport }}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{ graph_h1_port }}
--ws_h2_port={{ graph_h2_port }}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password

需要部署新集群时,需要按照规则和目的服务器信息生成 Ansible 的配置文件,然后调用 ansible-playbook,按照 bootstrap.yml 定义的行为执行即可。

集群部署自动化实现

部署完毕之后,需要按照服务角色依次启动 start.yml 的脚本文件提前定义好三种服务的启动命令和配置文件。

集群部署自动化实现

调用 ansible-playbook,根据 start.yml 的脚本文件依次执行三种服务的启动命令即可。

集群部署自动化实现

可视化图探索平台

有赖于将目标 host 前置于 Web 平台的设置,我们只需要对多个项目的开发提供一套公共的 Web 平台即可,减少了 NebulaGraph 集群的组件数量,有别于 ELK 的标准架构。

可视化图探索平台

开发可以通过 NebulaGraph Studio 实现可视化管理数据,轻松实现数据导入和导出,便于用户探索数据关系。直接呈现出点边关系,使探索图数据之间的关系更为直观。

可视化图探索平台

以上是我们在规模化管理维护 NebulaGraph 集群过程中的一些经验,希望对大家有些帮助。


交流图数据库技术?加入 NebulaGraph 交流群请先填写下你的 NebulaGraph 名片,NebulaGraph 小助手会拉你进群~~

NebulaGraph 的开源地址:https://github.com/vesoft-inc/nebula 如果你觉得使用体验还不错的话,给我们的 GitHub 点个 ❤️ 鼓励下开源路上的我们呢~

相关实践学习
阿里云图数据库GDB入门与应用
图数据库(Graph Database,简称GDB)是一种支持Property Graph图模型、用于处理高度连接数据查询与存储的实时、可靠的在线数据库服务。它支持Apache TinkerPop Gremlin查询语言,可以帮您快速构建基于高度连接的数据集的应用程序。GDB非常适合社交网络、欺诈检测、推荐引擎、实时图谱、网络/IT运营这类高度互连数据集的场景。 GDB由阿里云自主研发,具备如下优势: 标准图查询语言:支持属性图,高度兼容Gremlin图查询语言。 高度优化的自研引擎:高度优化的自研图计算层和存储层,云盘多副本保障数据超高可靠,支持ACID事务。 服务高可用:支持高可用实例,节点故障迅速转移,保障业务连续性。 易运维:提供备份恢复、自动升级、监控告警、故障切换等丰富的运维功能,大幅降低运维成本。 产品主页:https://www.aliyun.com/product/gdb
目录
相关文章
|
4天前
|
存储 人工智能 NoSQL
AI大模型应用实践 八:如何通过RAG数据库实现大模型的私有化定制与优化
RAG技术通过融合外部知识库与大模型,实现知识动态更新与私有化定制,解决大模型知识固化、幻觉及数据安全难题。本文详解RAG原理、数据库选型(向量库、图库、知识图谱、混合架构)及应用场景,助力企业高效构建安全、可解释的智能系统。
|
22天前
|
数据采集 运维 数据可视化
AR 运维系统与 MES、EMA、IoT 系统的融合架构与实践
AR运维系统融合IoT、EMA、MES数据,构建“感知-分析-决策-执行”闭环。通过AR终端实现设备数据可视化,实时呈现温度、工单等信息,提升运维效率与生产可靠性。(238字)
|
2月前
|
存储 运维 安全
运维知识沉淀工具深度解析:从结构设计到落地实践全拆解
运维知识沉淀工具助力团队将零散经验结构化存储,实现问题处理路径标准化、知识复用化。通过标签、模板与自动化调取机制,让每次处理都留下可复用资产,提升团队协同效率与系统稳定性。
|
5月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
1月前
|
机器学习/深度学习 人工智能 运维
三重Reward驱动的运维智能体进化:多智能体、上下文工程与强化学习的融合实践
这篇文章系统性地阐述了 AI 原生时代下,面向技术风险领域的智能体系统(DeRisk)的架构设计、核心理念、关键技术演进路径与实践落地案例。
三重Reward驱动的运维智能体进化:多智能体、上下文工程与强化学习的融合实践
|
2月前
|
运维 NoSQL 容灾
告别运维噩梦:手把手教你将自建 MongoDB 平滑迁移至云数据库
程序员为何逃离自建MongoDB?扩容困难、运维复杂、高可用性差成痛点。阿里云MongoDB提供分钟级扩容、自动诊断与高可用保障,助力企业高效运维、降本增效,实现数据库“无感运维”。
|
3月前
|
运维 监控 负载均衡
高效运维实践:常见问题的应对策略与实践经验
本文探讨了运维工作中的五大核心挑战及应对策略,涵盖负载均衡优化、数据库性能提升、系统监控预警、容器化与微服务运维等方面,旨在帮助企业提升系统稳定性与运维效率。
|
4月前
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
3月前
|
运维 监控 安全
从实践到自动化:现代运维管理的转型与挑战
本文探讨了现代运维管理从传统人工模式向自动化转型的必要性与路径,分析了传统运维的痛点,如效率低、响应慢、依赖经验等问题,并介绍了自动化运维在提升效率、降低成本、增强系统稳定性与安全性方面的优势。结合技术工具与实践案例,文章展示了企业如何通过自动化实现运维升级,推动数字化转型,提升业务竞争力。
|
6月前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。

热门文章

最新文章