about graph database
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 查询开销更大。图数据库的存储结构为面向图存储，更利于查询多度关系。特别的，有些图上特有的操作，用关系型数据库比较难实现和表达，比如最短路径、子图、匹配特定规则的路径这些。
🚀 图数据库会出于什么考虑做存储计算分离
存储与计算分离主要出于以下四方面的考虑：
- 存储和计算资源可以独立扩展，使资源利用更充分，达到缩减成本的目的。
- 更容易利用异构机型。
- 解耦计算节点，计算资源可以更大程度地做到线性扩展。基于之前的项目经历，存储计算不分离的分布式架构，计算能力的水平扩展会比较不方便。举个例子，在好友关系这种场景——基于好友关系查询再做一些排序和计算，在某个节点查询执行过程中需要去其他节点获取数据，或者将某个子计算交给其他节点，如果执行过程中需要的数据存储在本地，相较存储计算分离效率可能会高；但当涉及到和其他节点通信问题时，为了扩容计算资源而增加的机器会使得计算过程中的网络开销相应增加，抵消了相当一部分的计算能力。如果存储计算分离，计算和存储一对一，不存在节点越多网络通讯开销越大的问题。
- 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，基本上网络已经不是什么问题了。
关注公众号
网友评论