聊聊图数据库和图数据库的小知识 Vol.02

2010 年先后，对于社交媒体网络研究的兴起带动了图计算的大规模应用。 2000 年先后热门的是 信息检索 和 分析 ，主要是 Google 的带动，以及 Amazon 的 e-commerce 所用的协同过滤推荐，当时 collaborative filtering也被认为是 information retrieval 的一个细分领域，包括 Google 的 PageRank 也是在信息检索领域研究较多。后来才是 Twitter，Facebook 的崛起带动了网络科学 network science的研究。 图理论和图算法不是新科学，很早就有，只是最近 20 年大数据，网络零售和社交网络的发展， big data、social networks、e-commerce 、IoT让图计算有了新的用武之地，并且硬件计算力的提升和分布式计算日益成熟的支持也使图在高效处理海量关联数据成为可能。

上文摘录了#聊聊图数据库和图数据库小知识# Vol.01 的【图数据库兴起的契机】，在本次第二期#聊聊图数据库和图数据库小知识#咱们将了解如下内容，若是有感兴趣的图数据库话题，欢迎添加 Nebula 小助手微信号：NebulaGraphbot 为好友进群来交流图数据库心得。

本文目录

• 图数据库和图数据库设计
  • 传统数据库经过设计良好的数据结构是否是能够实现图数据库的功能
  • 图数据库会出于什么考虑作存储计算分离
  • 数据量小，业务量小的状况下，是否单机部署图数据库性能也不错。
  • 图数据库 shared-storage 和 shared-nothing 的比较
  • 图数据库顶点和边输出及超级顶点输出优化
  • 如何处理图数据库中大数据量的点？
• Nebula Graph 实践细节
  • Nebula Graph 元数据（Meta Service）使用 etcd 吗？
  • Nebula Graph Cache 位于那一层
  • Nebula Graph 集群中的 Partition 多大
  • 如何理解 Nebula Graph Partition

☺️ 图数据库和图数据库设计

在这个部分，咱们会摘录一些图数据库设计通用的设计思路，或者已有图数据库的实践思考。

🤖 传统数据库经过设计良好的数据结构是否是能够实现图数据库的功能

图数据库相对传统数据库优化点在于，数据模型。传统数据库是一个关系型，是一种表结构作 Join，但存储结构代表了很难支持多度拓展，好比一度好友，两度好友，一度还支持，使用一个 Select 和 Join 就可完成，可是二度查询开销成本较大，更别提多度 Join 查询开销更大。图数据库的存储结构为面向图存储，更利于查询多度关系。特别的，有些图上特有的操做，用关系型数据库比较难实现和表达，好比最短路径、子图、匹配特定规则的路径这些。

🚀 图数据库会出于什么考虑作存储计算分离

存储与计算分离主要出于如下四方面的考虑：

1. 存储和计算资源能够独立扩展，使资源利用更充分，达到缩减成本的目的。
2. 更容易利用异构机型。
3. 解耦计算节点，计算资源能够更大程度地作到线性扩展。基于以前的项目经历，存储计算不分离的分布式架构，计算能力的水平扩展会比较不方便。举个例子，在好友关系这种场景——基于好友关系查询再作一些排序和计算，在某个节点查询执行过程当中须要去其余节点获取数据，或者将某个子计算交给其余节点，若是执行过程当中须要的数据存储在本地，相较存储计算分离效率可能会高；但当涉及到和其余节点通讯问题时，为了扩容计算资源而增长的机器会使得计算过程当中的网络开销相应增长，抵消了至关一部分的计算能力。若是存储计算分离，计算和存储一对一，不存在节点越多网络通信开销越大的问题。
4. Nebula Graph在存储层提供基于图的查询接口，但不具有运算能力，方便对接外部的批量计算，好比 Spark，能够将图存储层看成为图索引存储，直接批量扫描、遍历图自行计算，这样操做更灵活。存储层支持作一些简单的过滤计算，好比找寻 18 岁好友等过滤操做。

🎨 数据量小，业务量小的状况下，是否单机部署图数据库性能也不错。

单机按分布式架构部署，有必定网络开销由于通过网卡，因此性能还行。必定要分布式架构部署的缘由在于强一致、多副本的业务需求，你也能够按照业务需求部署单副本。

🎏 图数据库 Shared-storage 和 Shared-nothing 的比较

【提问】对于图数据库来讲，是否是 shared-storage 相比 shared-nothing 方式更好呢。由于图的节点间是高度关联的，shared-nothing 方式将这种联系拆掉了。对于多步遍历等操做来讲，须要跨节点。并且因为第二步开始的不肯定性，要不要跨节点好像无法提早经过执行计划进行优化。

【回复】交流群群友 W：errr，单个 storage 能不能放下那么多数据，特别数据量增长了会是个比较麻烦的问题。另外第二步虽然是随机的，可是取第二步数据的时候能够从多台机器并发

【回复】交流群群友 W：主要的云厂商，好比 AWS 的共享存储能够到 64 T，存储应该够，并且这种方式存储内部有多副本。顺便提一句：AWS 的 Neptune 的底层存储用的也是 Aurora 的那个存储。网络这块的优化，可参考阿里云的 Polarstore，基本上网络已经不是什么问题了。

此外，“第二步虽然是随机的，可是取第二步数据的时候能够从多台机器并发吧”这个却是，Nebula 有个 storage server 能够作这个事情，但逻辑上彷佛这个应该是 query engine 应该干的。

【回复】交流群群友 W：“网络这块的优化，可参考阿里云的 polarstore，基本上网络已经不是什么问题了。” 网络这问题，部署环境的网络不必定可控，毕竟机房质量良莠不齐，固然云厂商本身的机房会好不少。

【回复】交流群群友 W：这个确实。因此开源的创业公司走 shared-nothing，云厂商走 shared-storage，也算是都利用了各自的优点

【回复】交流群群友 S：其实，shared-storage 能够被当作是一个存储空间极大的单机版，并非一个分布式系统

【回复】交流群群友 W：嗯嗯。不过 Neptune 那种跟单机版的区别在于计算那部分是可扩展的，一写多读，甚至 Aurora 已经作到了多写。不过就像前面所说的，开源的东西基于那种需定制的高大上存储来作不现实。想了下拿 AWS 的存储作对比不大合适，存储内部跨网络访问的开销仍是一个问题，拿 Polarstore 这种 RDMA 互联更能说明。可能 2 种方案都差很少，本质上都是可否减小跨网络访问的开销。

📈 图数据库顶点和边输出及超级顶点输出优化

【提问】请教一个问题。Nebula 的顶点和出边是连续存放的。那么在查询语句进行 IO 读取时，是顶点和出边会一块儿读出来呢，仍是根据查询语句的不一样而不一样？

【回复】交流群群友 W：会一个 block 一块儿读出来

【回复】交流群群友 W：恩恩。对于 supernode 这种状况，有没有作什么优化？Titian/Janusgraph 有一个节点全部边的局部索引，Neo4j 应该有在 object cache 中对一个节点的边按照类型组织

【回复】交流群群友 S：Nebula 也是用 index 来解决这个问题

【回复】交流群群友 W：Neo4j 的 relationship group 是落在存储上的，请教下，Nebula 的这种 index 和 Janusgraph 的 vertex centric 索引相似麽，仍是指存储格式里面的 ranking 字段啊

【回复】交流群群友 S：相似于 Janusgraph 的索引，可是咱们的设计更 general，支持 multi-column 的索引

【回复】交流群群友 W：ranking 字段其实给客户用的，通常能够拿来放时间戳，版本号之类的。

💌 如何处理图数据库中大数据量的点？

【提问】：Nebula 的存储模型中属性和边信息一块儿存储在顶点上，针对大顶点问题有好的解决方案吗？属性和关系多状况下，针对这种实体的查询该怎么处理，好比：好比美国最有名的特产，中国最高的人，浙江大学年龄最大的校友

【回复】交流群群友 W：若是能够排序，那分数能够放在 key 上，这样其实也不用 scan 太多了，ranking 字段就能够放这个。要否则还有个办法是容许遍历的过程当中截断或者采样，否则很容易爆炸的。

【回复】交流群群友 B：在作实时图数据库的数据模型设计时，尽可能避免大出入度的节点。若是避免不了，那至少避免此类节点再日后的 traversal。若是仍是避免不了，那别期望这样的查询会有好的性能

【回复】交流群群友 H：单纯的大点若是不从它开始 traversal，其实问题也不大。load 的 unbalance 都是有办法解决的。数据的 unbalance 由于分 part 存储，在分配 part 到 host 时可加入 part 数据量的权重，而 load 的 unbalance，对于读，可经过拓展只读副本 + cache 解决，写的话，可作 group commit，client 也能够作本地 cache。

【回复】交流群群友 B：图数据库的一个查询的性能最终取决于 physical block reads 的数量。不一样方案会致使最后 block reads 不同，性能会有差异。任何一种方案不可能对全部查询都是优化的，最终每每就是 tradeoff。主要看你大部分实际的 query pattern 和数据分布式如何，该数据库实现是否有优化。拆边和不拆边，各有其优缺点。

🤗 Nebula Graph 实践细节

在这个部分咱们会摘录一些开源的分布式图数据库 Nebula Graph 在实践过程当中遇到的问题，或者用户使用图数据库 Nebula Graph 中遇到的问题。

📝 Nebula Graph 元数据（Meta Service）使用 etcd 吗？

不是。Meta Service的架构其实和 Storage Service 架构相似，是个独立服务。

🔍 Nebula Graph Cache 位于哪一层

A：KV 那层。目前只有针对顶点的 Cache，顶点的访问具备随机性，若是没有 Cache，性能较差。Query Plan 那层如今尚未。

🔖 如何理解 Nebula Graph Partition

partition 是个逻辑概念，主要目的是为了一个 partition 内的数据能够一块儿迁移到另一台机器。partition 数量是由建立图空间时指定的 partition_num 确立。而单副本 partition 的分布规则以下

经过算子：partID%engine_size，而多副本的状况，原理相似，follower 在另外两个机器上。

📚 Nebula Graph 集群中的 Partition 多大

A：部署集群时须要设置 Partition 数，好比 1000 个 Partition。插入某个点时，会针对这个点的id作 Hash，找寻对应的 Partition 和对应 Leader。PartitionID 计算公式 = VertexID % num_Partition

单个 Partition 的大小，取决于总数据量和 Partition 个数；Partition 的个数的选择取决于集群中最大可能的机器节点数，Partition 数目越大，每一个 Partition 数据量越小，机器间数据量不均匀发生的几率也就越小。

最后，这里是开源的分布式图数据库 Nebula Graph 的 GitHub 地址：https://github.com/vesoft-inc/nebula， 欢迎给咱们提 issue~~

推荐阅读

• #聊聊图数据库和图数据库小知识# Vol.01