Pick of the Week'22 ｜第 7 周看点 NebulaGraph Cloud 海外上线

每周看点

每周五 Nebula 为你播报每周看点，每周看点由固定模块：产品动态、社区问答、推荐阅读，和随机模块：本周大事件构成。

2022 年的第一个长假过完了，开启了虎年的第一个工作周，这周你过得如何？听说本周看点 Nebula 小姐姐有礼相送~

本周看点

NebulaGraph Cloud 云服务上线海外市场

2022.02.10（昨日）NebulaGraph DBaas 产品 NebulaGraph Cloud 在 Azure Marketplace 正式上线~

NebulaGraph Cloud

NebulaGraph Cloud 支持在 Azure 云平台上一键部署 NebulaGraph，屏蔽了数据库部署、性能调优、运维等繁杂过程，可分钟级在云上创建图数据库，并快速进行扩展计算、存储数据等操作。

除了核心功能，云上使用 NebulaGraph 内核之外，NebulaGraph Cloud 包含了可视化图探索工具 Nebula Explorer、NebulaGraph Studio，以及集成了可视化集群监控工具 Nebula Dashboard。简而言之，NebulaGraph Cloud 借助丰富的可视化周边工具让你体验导入图数据集、执行 nGQL 语句查询、图探索和图分析、集群监控管理等一站式云端服务。

NebulaGraph Cloud 公测优惠

目前，NebulaGraph Cloud 提供多种配置，你可视情况选择机型和磁盘大小满足业务需求。（划重点）从即日起至 2022 年 3 月 31 日，购买 NebulaGraph Cloud 服务你可以享受到公测阶段的独有优惠：全面 3 折优惠，最低配置价格低为 $ 0.35 / 小时。

距离即用即启，用完即走的图数据库服务，你就差一个 NebulaGraph Cloud 了~

点击链接：订阅链接订阅服务享受本次公测的 3 折优惠价哟。

如果你对 Cloud 有任何咨询问题，欢迎邮件 inquiry@vesoft.com 邮箱。

Nebula 情人节活动上线

NebulaGraph Cloud 公测优惠

去年情人节，春节撞上情人节，社区的小伙伴在 Nebula 论坛打卡了自己对另一半的爱。这一次，陪伴再启程，Nebula 专属情人节礼物来袭，来论坛写下你对 TA 的爱意，Nebula 限量情人节礼物或在情人节当天到你手~

活动链接：https://discuss.nebula-graph.com.cn/t/topic/7463 。

产品动态

本周 Nebula 主要有这些产品动态：

新增属性裁剪的优化规则，支持只从 storage 读取必要的属性值，进而优化 MATCH 语句的性能，标签：内核，具体 pr 见：https://github.com/vesoft-inc/nebula/pull/3750
支持 3 种 Unique ID，标签：内核，具体 pr 参见：https://github.com/vesoft-inc/nebula/pull/3453

社区问答

Pick of the Week 每周会从官方论坛、知乎、微信群、微信公众号及开源中国等渠道精选问题同你分享。

主题分享

本周分享的主题是【Nebula 查询性能如何自测】，由社区用户 wuyou 提出，Nebula 研发解答。

wuyou 提问：由于目前在技术选型阶段，所以暂时没法提供具体的环境配置。不过应该会按照标准的配置来定，标准的意思是例如官方建议的多大的数据列用多少配置。目前估计数据量不大，可能只有千万级别的点。

问题一：目前有一些场景，要求自测一下 Nebula 大致的查询性能，但是很难构造符合业务场景的大数据量的点边关系，基本查询需求是使用 GO 语法查询多跳的血缘，然后是基于多个 VID 查询。

例如：go 1 to steps 6 from “vid1”,“vid2”… over edge yield xxxxxx

想了解一下这种查询千万级别的话性能会有瓶颈吗，瓶颈在哪些地方，就是想大致了解下。

问题二：有一些多跳的血缘查询，会带很多的查询条件，是否查询条件都必须设置索引，对性能有没有什么影响，除了 GO 有没有更好的实现方式的语法。

问题可能都过于语言话，所以希望能大致给点建议，目前确实有这些困扰。”

Nebula：技术选型的参考，官网的 blog 中应该有一些相关的文章：https://nebula-graph.com.cn/cases/ ，你可以先了解一下。

问题一：如果只是简单的多跳查询，GO 目前应该是最优的查询方案，GO 查询的主要开销应该都在 rpc，本身是没有太多的计算。

问题二：GO 查询是不依赖索引的，每次都是基于顶点的 ID 向外探索，如果查询需要依赖属性查找 VID 则需要建立索引，比如 LOOKUP 或者 MATCH。不清楚你这里描述的血缘的查询是否是说不同顶点之间是否有边，如果类似这种 pattern 的匹配，可以用 MATCH 表达。

追问：问题一：目前基础的血缘查询就是准备基于 go 1 to steps 6 from “vid1”,“vid2”… over edge yield xxxxxx 这种语句去查询，只是目前我们的场景下血缘只有上下游的关系，一个方向，使用 GO 的话由于是 walk 类型的路径，有重复的点边，需要逻辑进行去重操作。

问题二：也是想基于 GO 查询我这里的血缘场景是，基于某个 VID 查找其血缘，然后其血缘满足一定的条件停止查询，比如其血缘某个属性值等于、不等于、包含、不包含等等，甚至可能是一个正则表达式，我了解到 GO 语法的 WHERE 是不支持正则表达式的，所以我是不是只能选择 match optional 的语法查询，通过建立索引，但是索引太多的话会不会产生查询性能上的问题”

Nebula：