重庆建设医院官方网站,十大永久免费crm,手机商城系统,怎样网站备案表本文整理自 NebulaGraph PD 方扬在「NebulaGraph x KubeBlocks」meetup 上的演讲#xff0c;主要包括以下内容#xff1a;
NebulaGraph 3.x 发展历程NebulaGraph 最佳实践 建模篇导入篇查询篇
NebulaGraph 3.x 的发展历程
NebulaGraph 自 2019 年 5 月开源发布第一个 alp…
本文整理自 NebulaGraph PD 方扬在「NebulaGraph x KubeBlocks」meetup 上的演讲主要包括以下内容
NebulaGraph 3.x 发展历程NebulaGraph 最佳实践 建模篇导入篇查询篇
NebulaGraph 3.x 的发展历程
NebulaGraph 自 2019 年 5 月开源发布第一个 alpha 版本以来陆陆续续发布了 2.0 GA到现在 v3.6.0已经是 v3.x 版本中比较后期的版本了。从 3.x 开始基本上保持了三个月一个季度发一个 y 版本的节奏从 v3.1 到 v3.2到现在的 v3.6。演讲时 v3.6 尚未发布所以没有相关内容展示 而这几个版本主要是在完备性、性能稳定性以及易用性上的优化。从 NebulaGraph 作为一款图数据库的产品定位上来说核心应用场景是 TP 场景而对 TP 型数据库产品来说有几个特性是非常重要的
稳定数据库作为底层的基础设施许多业务是基于数据库运行的是在线的系统因此稳定性是一个非常重要的特性。在 NebulaGraph v3.4 版本包括最新版本的 v3.6 版本中系统的稳定性得到了非常大的提升和改善性能因为 NebulaGraph 定位是一个 TP 的数据库产品因此性能包括高吞吐量是至关重要的易用一个好的产品要如何让用户更好地用起来降低用户的学习成本也是需要考虑到的
针对这些特性我们在 v3.x 这 5 个版本中做了这些尝试
稳定性
在 v3.x 开始NebulaGraph 引入 fuzzer极大提升测试效率。fuzzer 可基于 nGQLNebulaGraph 的查询语言的语法进行灵活组合生成人为不能拟定的查询语句由此让测试更加完善从而提高了稳定性。
此外版本新特性部分还新增 Memory Tracker。图数据库不同于其他数据库数据一直处于持续地遍历、迭代中因为即便是数据量不大的情况下数据的迭代会导致它的结果异常大这就造成了内存的管理压力。在 v3.4 版本中NebulaGraph 引入了 Memory Tracker 机制从论坛的用户反馈上可以看得出来相关的 OOM 问题大幅度减少了。这里可以阅读下《内存管理实践之 Memory Tracker》
性能提升
图的经典查询一般包括 K 跳K-hop、子图和路径查询。K 跳就是从一个点出发比如说从我出发去找寻我好友一跳的好友两跳这种查询可能社交或者反欺诈的场景中使用会比较多。此外就是子图比如说我现在从一个点出发找到他的周围的关联的一群人以及这一群人关联的另外一群人这时候就可能会用到子图的功能。还有就是路径查询像是企业和企业之间的关联关系之类的就比较适合用路径来找寻二者的关联。在 v3.x 中这几个图的经典查询性能都有大幅度的提升的具体大家可以看论坛的性能报告自测和他测报告合集
上面提到过内存管理的难点除了 Memory Tracker 机制之外属性裁剪能提升内存的利用率在 NebulaGraph 中如果查询不需要用到某个属性就会将其裁剪掉从而提升内存利用率。
易用性
NebulaGraph 在 v2.x 开始支持 openCypher一开始是比较基础的 openCypher 语法在 v3.x 开始NebulaGrpah 做了一个语法完善像是 OPTIONAL MATCH、多 MATCH 等语法支持全面覆盖了国际图基准测试之一的 LDBC-SNB 支持的图查询。
此外在 v3.5 开始支持了 UDF 功能这个功能是由社区用户 zhaojunnan 提供支持的它可以用来帮助实现一些内核暂时不支持的功能。这里就不详细展开 UDF 的说明了具体大家可以看《NebulaGraph UDF 功能的设计与背后的思考》
最后一点是全文索引优化这个在后面章节会详细讲述。
NebulaGraph 的最佳实践
在这个部分主要分为建模、数据导入、查询等三大内容。
数据建模
数据膨胀
这是社区用户在交流群里反馈的一个问题
数据导入之后占用硬盘空间极大60 MB 的文件导入之后Storage 占用了 3.5 GStorage 服务占用内存很高 并发量大的时候会出现 ConnectionPool 不够的情况3 跳查询本来就很慢么我看官方的 Benchmark 数据规模大的时候会慢但是当前我们数据量也不是很大
目前的数据情况点 594,952边 798,826。同时边和点均建了 1 个索引 所以它有什么问题呢 在图数据库 NebulaGraph 中有个概念叫做 SpaceSpace里有一个概念是 VID typeVID 是 NebulaGraph 中非常关键、重要的概念所有的数据字段都是通过 VID 来进行唯一索引类似主键的概念。比如上图的中间部分点结构和边结构可以看到结构中都有 VID用来进行字段查询边结构还分起点 srcId 和终点 dstId就是上图的两处 VertexID。
如上图所示这个 Space 中配置的 VID 类型是 String而 NebulaGraph 支持的 VID 类型有两种一种是 INT数值类型像手机号之类的可以用 INT 来存储一种是 String比如说人名之类的当然你要用 String 来存储像是身份证号之类的数值信息也可以。但是用 VID 的查询效率从经验看是 INT 类型是远高于用 String 作为 VID 类型的。
回到上面的这个例子一开始用户创建 VID 时直接选取了 FIXED_STRING 类型设定为了 256 位的定长 String。但是这里会导致一个问题
594,952点数256 VID 大小* (1 1) 798,826边数* 256VID 大小 * (2 2 2 2) 1.80 GB
上面的例子是数据存储的大小计算过程点的数量乘以定长的长度这里是 256再乘以占据的字节大小以及边的数量乘以对应 VID 的长度再乘以对应边 VID 占据的空间大小算出来是 1.8 GB。由此我们可以想到一个事情是不是可以精简下 VID 的定长长度设置一个合理的数值比如说是 32那它空间占据量就是
594,952点数32VID 大小* (1 1) 798,826边数* 32VID 大小* (2 2 2 2) 0.23 GB
修改 VID 的定长长度之后整个空间使用量就是之前的 1/8还是非常可观的一个磁盘容量优化。如果是更多的点和边数据量的话缩减的磁盘空间会更客观。由此我们有个建议VID 的定长长度尽可能短同理属性类型设置亦如是。
超级节点 图数据库实践中超级节点是一个比较常遇到的性能问题。那么什么是超级节点稠密点呢图论给出的解释是一个点有着超级多的相邻边相邻边就是出边从这个点指向另外一个点或者是入边某个点指向这个点。像是社交网络中 KOL、网红大V 之类的人或是证券市场的热门股票交通网络中的枢纽站、银行系统中的四大行、互联网中的高流量站点或者是电商平台的爆款商品等等都是整个关系网络中的超级节点。一旦查询中有超级节点查询速率就会变得异常的缓慢甚至有时候内存都耗尽了查询结果还没跑出来。
下面就来讲讲现阶段你要用 NebulaGraph 可以如何解决或是绕开超级节点 要在建模环节规避掉超级节点的问题“拆点”是可行的方式之一。如上图左侧所示在未优化建模之前A 通过 transfer 边关系连接到 B1、B2如果 A 频繁的转账势必会导致它成为一个超级节点。这时候你可以将 A 拆分成 A1 和 A2按照某种约定的方式比如说转账的日期或者是由单一客户拆分成对公客户、对私客户从而达到拆点、避开超级节点形成的目的。不过这里会涉及到一个 VID 变更的问题将 A 拆分成 A1 和 A2会导致对应的 VID 发生变化当然你可以命名 A1 为 A0721A2 为 A0722加上日期数字来标识它们。
相对应拆点还有拆/合边的方式。在两个点之间有许多同一类型的边比如说转账关系这时候可以根据业务的逻辑来进行判断比如取最短边、最新边、最大边、最小边等在一些不需要明细的场景里只体现关系出来这样就能提升查询效率。除了合并之外拆边也是一种方式如上图右侧所示两个点之前有非常多的关系它们都是交易类型可能有一部分是发红包有一部分是转账这时候你就可以按照拆点的逻辑将边进行拆解。
此外还有截断NebulaGraph 有个配置参数是 max_edge_returned_per_vertex用来应对多邻边的超级节点问题。比如我现在 max_edge_returned_per_vertex 设置成 1,000那系统从点 A 出发遍历 1,000 个点之后就不再遍历了便将结果返回给系统。这里会存在一个问题加入 A 和 B1 之间存在 1 千多条边A 和 B2 存在 3 条边按照这种遍历 1,000 条边之后就不再遍历的设定可能返回结果中 A 和 B2 的关系边就不会返回了因为这个遍历返回是随机的。
其他的话同相关的社区用户交流我发现在许多业务场景中超级节点并没有太大的实际业务价值。这里就要提下“超级节点的检测”比如通过度中心性算法DegreeCentrality计算出出入度大小这个图算法 nebula-algorithm 和 nebula-analytics 都支持。当这个算法跑完之后得到的二维表就能告诉你哪些是超级节点提早让用户知道哪些点会影响查询效率。
此外假如现在你有一个已知的超级节点且不方便处理那查询的时候就要尽量避免逆向查询即从这个超级节点出发查询其他节点。
数据导入 社区用户经常遇到的还有一类问题数据导入慢的问题。一般新的社区用户都会问你们的导入性能如何这时候我们一般会说导入性能老牛逼了而且我们是直接用 INSERT 方式导入的速度贼快之前遇到最快的是 600MB/s。
这时候用户一般会反问为什么我测试出来导入速度没有官方说的那么快。 这里就展开说说如何提升你的数据导入性能。
熟悉 NebulaGraph 的小伙伴都知道它的底层存储是基于 RocksDB 实现的而 RocksDB 有 wal_ttl 这么一个配置项如果你的导入数据量非常大对应的 wal 日志也会相对应的变大。因此建议在进行数据导入时将 wal_ttl 时间设短一点以防止膨胀的 wal 日志过度地占用磁盘可以得到及时的清理。此外就是 Compaction 相关的配置项主要是 max_subcompactions 和 max_background_jobs 这两个参数项一般建议将其设置为 CPU 核数的一半。而这个一半的参数建议主要来源于用户的反馈以及一些经验数据不同的场景还是需要不同的配置HDD 和 SSD 的配置也有所不同大家可以后面看着情况进行调试。
除了配置参数之外在做数据导入之前建议大家执行下 SHOW HOSTS 操作查看 leader 是否分布均匀NebulaGraph 会将数据分为若干个 partition每个 partition 会随机分布在节点上理想状态自然是 partition 的 leader 是均匀地分布在各个节点的。假如 leader 分布不均的话可以执行 BALANCE LEADER 操作确保其均匀分布。
在工具配置方面可能就是数据导入的重头戏了配置你的数据导入工具参数
配置项 concurrency表示导入工具连接多少个 graphd查询节点一般设置为导入工具 nebula-importer 所在机器的 CPU 核数manager.batch虽然 NebulaGraph 支持你通过 INSERT 来一个个点插入到数据库中但是这个有些低效。因此设立了 batch 字段用来将一批数据导入到数据库中默认参数设置是 128不过这里要根据你自身的数据特性来进行优化。假如你的属性值很多那么建议将 batch 调小反之将 batch 值调大即可。整个 batch 的大小建议小于 4MBmanager.readerConcurrency 是数据读取的并发数即从数据源读取数据的并发数。默认参数是 50一般建议设置为 30-50 即可manager.importerConcurrency数据读取之后会根据一定的规则拼接成 batch 块这里就涉及到这个参数项。manager.importerConcurrency 指的是生成待执行的 nGQL 语句的协程数一般来说它会设置成 manager.readerConcurrency 字段的 10 倍默认值是 512
软件说完了来说下硬件方面的配置。NebulaGrpah 优先推荐使用 SSD当然 HDD 也是可以的不过性能相对会差点。此外在 data_path 下多配置几块盘每个路径配置一个盘这个也是之前的实践经验总结出来的。而机器和机器之间推荐使用万兆网卡。最后一点是nebula-importer 之类的导入工具有条件的话尽量单独部署和集群隔离开不然的话在一台机器人会存在资源抢占的问题。
软硬件都说完了剩下就是数据本身的问题。图数据库的定位是关系分析同此无关的事情例如全文搜索ES 擅长的场景要看情况是否将该部分数据放入到 NebulaGraph 中。由于 NebulaGraph 进行数据导入时不存在导入的先后顺序即点和边一起混合导入这样设计的好处是数据无需做预处理坏处是数据导入之后可能会产生悬挂边不利于后续的查询。最后要留意起点或终点为空的数据或者是异常数据这些数据在异常处理时很容易一不小心形成超级节点。
查询指南
下面来讲讲如何搞定 NebulaGraph 的查询篇。这里是一些 tips
MATCH 性能比 GO 略慢但 MATCH 是我们优化的重点。如果没有强性能需求的话推荐还是尽量使用 MATCH表达能加丰富之外它同将要出炉的 ISO GQL图查询语言是匹配的慎用函数无法下推在 NebulaGraph 中并没有将函数下推到 storage。因此像 src(edge)、dst(edge)、rank(edge)、properties($$) 之类的函数性能都不如 edge_.src、edge._dst、edge._rank、$$.tag.prop 这些下推到 storage 的表达遇到聚合且需要取属性的情况先聚合再取属性因为取属性耗时较长MATCH 如果只是最后需要返回 count那么对于 count 的变量最好采用 count(id(v)) 类似的形式这样会应用到属性裁剪减少内存消耗能不带路径尽量不要带路径带路径需要进行路径构造属性裁剪会失效此外还会增加很多额外的内存开销。
总的来说减少模糊、增加确定越早越好。
内存保护试试 Memory Tracker
在 v3.4 版本中引入的一个大功能是Memory Tracker用来保护内存防止内存占用过大导致的 OOM 问题。 预留内存memory_tracker_untracked_reserved_memory_mb默认 50 MB。Memory Tracker 机制会管理通过 new/delete 申请内存但进程除了通过此种方式申请内存外还可能存在其他方式占用的内存比如通过调用底层的 malloc/free 申请这些内存通过此 flag 控制在计算时会扣除此部分未被 track 的内存所以这里预留了 50 MB内存比例memory_tracker_limit_ratio就是实际可用内存的比例占用多少的情况下会限制它再申请使用内存。一般默认是 0.8就是这个内存占用小于 0.8 的情况下是可以随意使用内存的当系统内存占用超过 80% 时系统便会拒绝掉新的查询语句 数值范围(0,1]默认 0.8 且为开启状态。大多数的用户的 storage 和 graph 节点都存在混部情况这时候就会建议调低 memory_tracker_limit_ratio顺便说一句这个参数项是支持在线调整的数值配置成 2则会对其进行动态调整这个动态分配的内存占用比例可能会不大精准数值配置成 3则关闭 Memory Tracker 功能
此外你如果要调试 Memory Tracker 的话可以开启 memory_tracker_detail_log 来获得调试日志这个参数项默认是关闭的。
经测试Memory Tracker 对性能有 1% 左右的影响但是对于上层为平台类产品或者交互式分析类产品强烈建议打开。为什么呢因为上层的业务同学不大了解 NebulaGrpah 运行机制的情况下容易将服务打满导致内存爆炸因此开启这个功能之后至少能保证系统的稳定运行。
最后如果动态申请内存时返回报错 GRAPH_MEMORY_EXCEEDED/STORAGE_MEMORY_EXCEEDED 说明这个内存已经不够用这条查询语句将不会执行被杀掉。
语句调试得用 PROFILE
在任意一条 nGQL 查询语句前面加入 PROFILE并能得到这条语句的执行计划。 上图一条语句的整个生命周期Planner 是执行计划Execution Plan生成器它会根据 Validator 校验过、语义合法的查询语法树生成可供执行器Executor执行的未经优化的执行计划而该执行计划会在之后交由 Optimizer 生成一个优化的执行计划并最终交给 Executor 执行。执行计划由一系列节点PlanNode组成。而下图则是一些常见的算子上图每一个 Plan 节点对应了一个算子
算子介绍GetNeighbor根据指定的 vid 从存储层获取起始点和边的属性Traverse仅用于 MATCH 匹配 ()-[e:0..n]-() 模式获取拓展过程中的起始点和边的属性AppendVertices供 MATCH 使用同算子 Traverse 配合获取点的属性GetEdge获取边的属性GetVertices获取点的属性FETCH PROP 或者 GO 语句中。ScanEdge全表扫描边例如 MATCH ()-[e]-() RETURN e LIMIT 3 ScanVertices全表扫描点例如 MATCH (v) return v LIMIT 3IndexScanMATCH 语句中找到起始点的索引查询TagIndexPrefixScanLOOKUP 语句中前缀扫描 LOOKUP ON player where player.name Steve Nash YIELD player.nameTagIndexRangeScanLOOKUP 语句中范围扫描 LOOKUP ON player where player.name S YIELD player.nameTagIndexFullScanLOOKUP 语句中全扫描 LOOKUP ON player YIELD player.nameFilter按条件过滤例如 WHERE 语句Project获取上一步算子的列Dedup去重LeftJoin合并结果LIMIT限制输出行数
下面这个是一个例子我们可以结合例子讲解下。一般来说 PROFILE 会生成一个执行计划同 EXPLAIN 生成执行计划不同PROFILE 生成的执行计划中会有相对应的执行时间在里面比如说下面这张图 一般来说我们看执行计划不只是看上下的调用关系还需要去看里面的具体执行细节
execTimegraphd 的处理时间totalTimegraphd 算子起到到算子退出时间total_rpc_timegraphd 调用 storage client 发出请求到接收到请求时间execstoraged 的处理时间同上面的 graphd 处理时间的 execTimetotalstorage client 接收到 graphd 请求到 storage client 发送请求的时间即 storaged 本身的处理时间加上序列化和反序列化的时间
除了查看时间之外我们还要查看 row 就能看到 graphd 和 storaged 的具体通信量大小。上图有 3 个 Partition每个 Partition 返回 1 个 limit 1总共就 3 条数据。
此外还得查看执行计划中是否包含计算下推 上面两条查询语句的差异上面提到过就是将函数改成其他调用方式将 properties(edge).degree 改为 follow.degree很明显地看到计算下推了。
某个功能不支持array
因为产品规划的问题NebulaGraph 可能有些功能没法直接支持。比如用户反馈的 当前属性仅支持基本类型 long、string来构建索引。是否可以支持多值比如long[]、string[] 来构建索引 的确目前不支持 array有什么曲线救国的法子这里提供一些方法仅供参考
把数组放到 string 里进行查询时将数据读取出来进行解析虽然有点不优雅但是能解决问题转化成 bitmap将不同的类型组成 bitmap虽然导致代码会复杂点但可以获得比较快的过滤边上的 array 转换成两点之间的平行边相当于一条边就是一个属性可以方便地进行属性过滤当然它会带了额外的边数量增加问题点上的 array 转化成自环边弊端第 3 种方式会产生大量自己指向自己的平行边把属性作为 tag比如我现在有个商品它在北京、上海、杭州都有仓库这时候可以将这个货点变成一个 tag 属性从而方便地对其进行查询。这里需要注意的是这个方式容易产生超级节点这里就需要注意避免超级节点的产生。
功能更强了 UDF
用户自定义函数User-defined FunctionUDF用户可以在 nGQL 中调用函数。与从 nGQL 中调用的内置函数一样UDF 的逻辑通常扩展或增强了 nGQL 的功能使其具有 nGQL 没有或不擅长处理的功能。UDF 被定义后可以重复使用。
这里简述下 UDF 的使用过程 准备编译环境 下载源码https://docs.nebula-graph.com.cn/3.5.0/4.deployment-and-installation/1.resource-preparations/ 进入到 NebulaGraph 代码仓库创建 UDF 相关源码文件。当前有两个示意文件 standard_deviation.cpp / standard_deviation.h 可以参考 编译 UDF
g -c -I ../src/ -I ../build/third-party/install/include/ -fPIC standard_deviation.cpp -o standard_deviation.o
g -shared -o standard_deviation.so standard_deviation.o加载 UDF 至 graphd 服务
编辑 graphd 服务配置文件打开 /usr/local/nebula/etc/nebula-graphd.conf 文件添加或修改以下配置项
# UDF C
--enable_udftrue
# UDF .so
--udf_path/home/foobar/dev/nebula/udf/重启 graphd
udo /usr/local/nebula/scripts/nebula.service restart graphd连接到 graphd 后验证
GO 1 TO 2 STEPS FROM “player100” OVER follow YIELD properties(edge).degree AS d | yield collect($-.d) AS d | yield standard_deviation($-.d)不过目前 UDF 有些问题
so 包位置只支持扫描本地也就是如果你是分布式集群的话每个机器上都得有个包函数只在 graphd 层无法下推到存储暂不支持 Java性能考虑未来版本会支持
待解决的问题
这里罗列下未来的产品可优化点
全文索引v3.4 之前的全文索引功能都不太好用约束比较多且有些 bug。v3.4 版本做了精简和优化更加稳定。但实际上v3.4 及之前的全文索引功能准确讲并不是真正意义的全文索引主要是支持前缀搜索、通配符搜索、正则表达式搜索和模糊搜索等。并不支持分词、以及查询的分数v3.6 版本即将发布做了全文索引的优化重新设计了全文索引功能可以更好的支持 Neo4j 替换。不过与原有的全文索引不兼容需要重建索引关于悬挂边的产生设计理念不隐式的对数据进行变更导致删除点的时候不隐式删除边当然由此会带来悬挂边和孤儿点的问题后面这块会考虑进行相关的优化事务的支持大多数人对 NebulaGraph 的事务需求来源于他认为 NebulaGraph 是一款 TP 产品TP 产品是一定具备事务性的这并非是业务场景的需求。当然事务这块撇开这种某款产品必须具备的特性之外这点一些生产链路上面事务还是一个强需求因此在后续的开发中也会新增事务特性。
其他问题交流
下面问题整理自本次分享的 QA 部分
Q上文提到 VID 的设定是越短越好。短的 VID 会带来什么后果么
方扬VID 理论上是越短越好没有任何的副作用。不过它的设定是在满足你既有的业务需求不要出现重复的 VID 情况下尽可能的短即可
Q截断的话是对返回的数据量做限制这个返回的话是有序的么
训焘目前数据的返回是 random随即返回的随机根据你的 range 来返回一些数据量。 谢谢你读完本文 (///▽///)
如果你想尝鲜图数据库 NebulaGraph记得去 GitHub 下载、使用、(з)-☆ star 它 - GitHub和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能留下「你的名片」一起玩耍呀~
