对于3.1.0 版本（其实版本号对于这个问题影响不大吧）。
NebulaGraph的底层存储是KV的，从字面理解NebulaGraph应该是一个非原生图存储吧。
但是NebulaGraph做到了“同一个点的所有 Tag、出边和入边信息都会存储到同一个分片，这种方式极大地提升了查询效率”，这个分片是物理分片吧。
也就是通过查询物理分片，就知道一个点的所有邻接点了，因此做到了免索引邻接，于是NebulaGraph可以被称作图原生存储，图原生处理（免索引邻接），也就是原生图数据库
整个问题是这么理解吗？我是一个产品，在写从产品角度应该理解的图存储技术资料。请教各位大神
Index Free Adjacency，就是原生(Native)图吧，从这一点来看，nebula就是原生图数据库
neo4j当年提出这个技术概念的时候，大致的要求是说，从一个点怎么找到它的一个邻边。
它认为如果你用数据库来放图结构，那你必须要建立一个图结构（某一边列）的索引，而索引可能是一个B+树。如果你用文档型的数据库，也可以构造一个边索引。这样就不是它所说意义上的原生：只要你是通过一个辅助的索引结构，还不是主结构来直接得到邻边
另外，原生和是否分片是没有关系的，neo4j 3.x 自己就没有分片。当然4.x之后又构造了一个神奇的指鹿为马的技术名词 “原生图分片”。
对于他们创造技术名词的能力，我一直是很佩服的。
JanusGraph虽然依赖底层的KV存储，不是原生图存储，但是因为在逻辑上直接存储了每个节点的邻接表，所以应该是从主结构就可以得到一个点的所有临边，所以也算做到了免邻接索引，但是并不是原生图存储。
从NebulaGraph的文档看底层以KV存储边集列表，如果不把同一个点的边集列表放在一个分片，那就没办法快速的找到一个点的所有邻边了吧。
所以进一步的，是不是可以理解
1、只要在物理层面按照图的数据结构进行存储，能够通过主结构找到一个点的所有邻边，就是原生图存储。天然支持免索引邻接。
2、在物理层面依赖其他存储，在逻辑层面按照图的数据结构进行组织，能够通过主结构找到一个点的所有邻边，虽然不是原生图存储，但是也是免索引邻接的。
3、所以我们没变要区分免索引邻接，因为只要按照除边集列表外的图数据结构（邻接表等其他变形的链表）都可以从主结构上找到一个点的所有邻边。
大体是的。
10年前，当neo4j要提出这个技术名词的时候，它的对象是用RDBMS来进行图建模的竞品(比如Oracle Graph，或者OrientDB)。翻5年前的资料，可以找到很多如果把图结构 cast 成一个表（或者文档）结构。
在那个时候，图这个细分领域，并没有那么多以图为主要产品形态的玩家。参与者都是附带一个图功能而已。
所以说到JanusGraph, 点和所有的邻边存储在一起(比如HBase），并没有啥特别大的问题。当然Hbase->HDFS的CRUD性能问题，是另外一个话题。
再严格来说，kv系统寻找两个key之间的关系，也是需要一定的数据结构的。难道链表就一定比 skiplist或者tree高贵？
用索引结构的问题还是性能上的，同时维护两个数据结构，是会有图遍历和修改的性能问题的，这个是对用户影响最大的。
对于造名词嘛。。。。这个学不了
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。
浙ICP备20010487号