关于NebulaGraph原生图存储、原生图处理特性的问题

对于3.1.0 版本(其实版本号对于这个问题影响不大吧)。
NebulaGraph的底层存储是KV的,从字面理解NebulaGraph应该是一个非原生图存储吧。

但是NebulaGraph做到了“同一个点的所有 Tag、出边和入边信息都会存储到同一个分片,这种方式极大地提升了查询效率”,这个分片是物理分片吧。
也就是通过查询物理分片,就知道一个点的所有邻接点了,因此做到了免索引邻接,于是NebulaGraph可以被称作图原生存储,图原生处理(免索引邻接),也就是原生图数据库

整个问题是这么理解吗?我是一个产品,在写从产品角度应该理解的图存储技术资料。请教各位大神

3 个赞

Index Free Adjacency,就是原生(Native)图吧,从这一点来看,nebula就是原生图数据库

1 个赞

neo4j当年提出这个技术概念的时候,大致的要求是说,从一个点怎么找到它的一个邻边。
它认为如果你用数据库来放图结构,那你必须要建立一个图结构(某一边列)的索引,而索引可能是一个B+树。如果你用文档型的数据库,也可以构造一个边索引。这样就不是它所说意义上的原生:只要你是通过一个辅助的索引结构,还不是主结构来直接得到邻边
另外,原生和是否分片是没有关系的,neo4j 3.x 自己就没有分片。当然4.x之后又构造了一个神奇的指鹿为马的技术名词 “原生图分片”。
对于他们创造技术名词的能力,我一直是很佩服的。

2 个赞

JanusGraph虽然依赖底层的KV存储,不是原生图存储,但是因为在逻辑上直接存储了每个节点的邻接表,所以应该是从主结构就可以得到一个点的所有临边,所以也算做到了免邻接索引,但是并不是原生图存储。

从NebulaGraph的文档看底层以KV存储边集列表,如果不把同一个点的边集列表放在一个分片,那就没办法快速的找到一个点的所有邻边了吧。
所以进一步的,是不是可以理解
1、只要在物理层面按照图的数据结构进行存储,能够通过主结构找到一个点的所有邻边,就是原生图存储。天然支持免索引邻接。
2、在物理层面依赖其他存储,在逻辑层面按照图的数据结构进行组织,能够通过主结构找到一个点的所有邻边,虽然不是原生图存储,但是也是免索引邻接的。
3、所以我们没变要区分免索引邻接,因为只要按照除边集列表外的图数据结构(邻接表等其他变形的链表)都可以从主结构上找到一个点的所有邻边。

1 个赞

大体是的。

10年前,当neo4j要提出这个技术名词的时候,它的对象是用RDBMS来进行图建模的竞品(比如Oracle Graph,或者OrientDB)。翻5年前的资料,可以找到很多如果把图结构 cast 成一个表(或者文档)结构。

在那个时候,图这个细分领域,并没有那么多以图为主要产品形态的玩家。参与者都是附带一个图功能而已。

所以说到JanusGraph, 点和所有的邻边存储在一起(比如HBase),并没有啥特别大的问题。当然Hbase->HDFS的CRUD性能问题,是另外一个话题。

再严格来说,kv系统寻找两个key之间的关系,也是需要一定的数据结构的。难道链表就一定比 skiplist或者tree高贵?

用索引结构的问题还是性能上的,同时维护两个数据结构,是会有图遍历和修改的性能问题的,这个是对用户影响最大的。
对于造名词嘛。。。。这个学不了

4 个赞

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。

浙ICP备20010487号