社区动态

Pick of the Week'22 |第 3 周看点:Nebula Explorer 新增 3D 查看模式

每周看点

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

年味渐浓的一周,不知道这周你过得如何呢 🌞 出门在外记得做好防护 😷

本周看点

Nebula GitHub star 破 7k

GitHub Star 破 7k

在本周 Nebula 主仓 GitHub star 突破 7k 大关,目前 star 7051 👏👏

和 Nebula 一起交流图计算 & nebula-algorithm

图计算一直是社区热门的话题,论坛也常有小伙伴问及图算法相关问题。这次 Nebula 技术团队的两位图计算研发同学将在直播中同你交流问题。如果你有什么问题想问,记得公众号回复「提问」向两位研发同学提问,或者回复「图计算」查看活动详情。

图计算

产品动态

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

Nebula Explorer 3D Demo Show

社区问答

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

主题分享

本周分享的主题是【单副本多机器的快照问题】,由社区用户 sworduo 提出,Nebula 研发解答。

sworduo 提问:假如我有一个 space,单副本 10 个 partition 分布在 3 台机器上,这时候 create snapshot 后,show snapshots 显示快照在三台机器上都有,但是实际上是不是每个机器上快照的内容都不相同?

如果是 3 副本,5 机器,创建快照。一个机器上有 partition 2 3 4 的快照,另一个机器有 3 4 5 的快照,如果我想把所有 partition 的快照集中在一起,但是每个 partition 的快照只有一个,有什么办法可以做到吗?

然而我看了 checkpoints 和 data 目录,在数据层面似乎没有记录本机有哪些 partition 的情况,这种情况下,是不是只能按照原来的拓扑结构进行恢复?

Nebula:首先解释一下你的几个问题:

  1. “但是实际上是不是每个机器上快照的内容都不相同?”

是的,对于 space 做一次快照后,所有的分片的快照分散在 partition 所在机器上本地,而没有收束到一个物理位置。

  1. “partition 的快照集中在一起,但是每个 partition 的快照只有一个,有什么办法可以做到吗?“

现在暂时没有办法,我们在做 br,能将所有 partition 快照集中在一起。但仍然是 partition 有几个副本,快照就会存储几个冗余,也即完全的物理克隆,然后收束到一块。

  1. “然而我看了 checkpoints 和 data 目录,在数据层面似乎没有记录本机有哪些 partition 的情况,这种情况下,是不是只能按照原来的拓扑结构进行恢复?”

是的,你理解的很对。现在恢复最大的问题就是只能按照原来的拓扑结构进行恢复。这种做法的优势在于备份和恢复速度很快,劣势在于受限于之前集群物理拓扑。

关于如何更好的备份,我们也在探讨。近期会出一个 br 工具,但是仍然是按照物理拓扑直接备份的。如果你有更好的 idea,在兼顾大数据量备份恢复速度的同时,能做到逻辑备份,欢迎来社区贡献。

追问:如果是副本数量=机器数量的情况,比如 3 副本 3 机器,是不是只需要保存一台机器上的快照就行了,因为一台机器上就含有所有的分片数据。

现在的结构我觉得快照冗余是不可避免的,因为 RocksDB 层面就没有把分区区分开来。如果想避免冗余,就得让 RocksDB 那里区分 partition,这样就可以做到每个分片只保存一份,然后根据 show hosts 的信息进行恢复。但是如果要在数据层面区分 partition,似乎就得一个 partition 启动一个 RocksDB 才行,这样看起来不太好。

另外你们有实验过 create snapshots 的速度吗,假如一个 space 有几百 g 甚至几个 T 的数据,这个命令一般耗时多少?我试过 4G 的 space,耗时 1s 多,但是不敢在线上测试。怕阻塞时间太长了影响服务。”

Nebula:回复如下:

  1. “是不是只需要保存一台机器上的快照就行了。”

如果都拷贝到一台机器上,得要求用户配置 ssh 免密,才能用 scp 之类的工具自动拷贝。但是如果存到对象存储等其他外存上,是可以做到的,只需要配置下对象存储的身份信息即可。这个年后会发布一款 br 工具,实现相关功能。

  1. “似乎就得一个 partition 启动一个 RocksDB 才行,这样看起来不太好。”

你说的很对~ 的确是首先得把同一个 space 中 partition 物理分开,才能做到去重。

  1. “这个命令一般耗时多少?”

这个实现上都是对 sst 和 wal 的硬链接,所以应该耗时不会太久。至于有没有测过不同量级数据的备份时间,这里可以给出一个大概上限:1T 左右的数据用时不会超过一分钟。当然用时和 partition 的数量(partition 多 sst 就多)、sst 的数量(每个做硬连接)、机器的数量(发 rpc到不同机器)呈正相关。

Nebula 进阶技能

本周的 Nebula 进阶技能分享一个稠密点处理,来源于文档:https://docs.nebula-graph.com.cn/2.6.1/8.service-tuning/super-node/

数据库端的常见办法

  1. 截断: 只访问一定阈值的边,超过该阈值的其他边则不返回。
  2. Compact:重新组织 RocksDB 中数据的排列方式,减少随机读,增加顺序读。

应用端的常见办法

根据业务意义,将一些超级顶点拆分:

  • 删除多条边,合并为一条
    • 例如,一个转账场景:(账户 A)-[转账]->(账户 B)。每次转账建模为一条 AB 之间的边,那么(账户 A)和(账户 B)之间会有着数万十次转账的场景。按日、周、或者月为粒度,合并陈旧的转账明细。也就是批量删除陈旧的边,改为少量的边“月总额”和“次数。而保留最近月的转账明细。
  • 拆分相同类型的边,变为多种不同类型的边
    • 例如,(机场)<-[depart]-(航班)场景,每个架次航班的离港,都建模为一条航班和机场之间的边。那么大型机场的离港航班会极多。根据不同的航空公司将 depart 这个 Edge type 拆分更细的 Edge type,如 depart_ceair,depart_csair 等。在查询(图遍历)时,指定离港的航空公司。
  • 切分顶点本身
    • 例如,对于(人)-[借款]->(银行)的借款网络,某大型银行 A 的借款次数和借款人会非常的多。可以将该大行节点 A 拆分为多个相关联的子节点A1、A2、A3,
      • (人 1)-[借款]->(银行 A1)、(人 2)-[借款]->(银行 A2)、(人 2)-[借款]->(银行 A3)
      • (银行 A1)-[属于]->(银行 A)、(银行 A2)-[属于]->(银行 A)、(银行 A3)-[属于]->(银行 A)
    • 这里的 A1、A2、A3 既可以是 A 真实的三个分行(例如北京、上海、浙江),也可以是三个按某种规则设立的虚拟分行,例如按借款金额划分 A1: 1-1000, A2: 1001-10000, A3: 10000+。这样,查询时对于 A 的任何操作,都转变为为对于 A1、A2、A3 的三次单独操作。

推荐阅读

星云·小剧场

为什么给图数据库取名 Nebula

Nebula 是星云的意思,很大嘛,也是漫威宇宙里面漂亮的星云小姐姐。对了,Nebula 的发音是:[ˈnɛbjələ]

本文星云图讲解–《超新星遗迹─延髓星云》

超新星遗迹─延髓星云

CTB-1 是大约 10,000 年前,仙后座方向一颗大质量恒星发生爆炸,所形成的超新星遗迹,因为形似延髓而有延髓星云的称号,而至如今在可见光波段,仍能见到扩张碎片云冲撞周遭星际气体所发出的光。

影像提供与版权:Russell Croman 作者与编辑:Robert Nemiroff (MTU) & Jerry Bonnell (UMCP)


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

关注公众号


Tag
Recommended for you
green iguana

技术分享

使用 nebula-spark-connector 3.6 版本搭建备集群实践
green iguana

技术分享

来自开发者的认可,NebulaGraph Star 突破 10,000 大关
green iguana

技术分享

多年 NLP 从业者对 LLM 和知识图谱的一些看法