共计 2072 个字符，预计需要花费 6 分钟才能阅读完成。
随着 2.0 各版本的陆续公布，Nebula Graph 迎来了一系列的改变，在存储方面，影响最大的改变就是 底层编码格局进行了批改。Nebula Graph 的底层存储是基于 KV 保留在 RocksDB 中，本文将介绍新老编码格局的差别，以及为什么要批改存储格局等一系列问题。
1.0 版本的格局
咱们先简略回顾下 1.0 版本的编码格局，不相熟的能够参考这篇博客《Nebula 架构分析系列（一）图数据库的存储设计》。因为在 1.0 版本中，点的 ID 只可能用整型来示意，所以底层所有 VertexID 都是以 int64 来保留的。
- 点的格局
- 边的格局
给定任何一个 VertexID，通过 hash，能够失去对应的 PartID，因而对于一个点和这个点的所有边（边用终点计算 hash），都会映射到同一个分片中。须要指出的是，在 1.0 版本中，点和边的第一个字节的 Type 是雷同的。也就是说，对于一个点而言，它的所有 tag 并没有在物理上间断保留，比方可能是如下保留的。对于这个 src 这个点的三个 tag（tag1 tag2 tag3)，实际上可能会被其余边隔开。
这个格局可能满足 1.0 绝大多数接口的须要，比方 fetch 和 go 都只须要指定对应前缀，就能获取对应数据。
2.0 版本的格局
在 GA 之前公布的版本，底层存储格局其实和 1.0 是基本相同的。如果 VertexID 是整型，和 1.0 格局完全一致。而如果 VertexID 类型反对 string，则从占用 8 个字节的 int64 改成了固定长度的 FIXED_STRING，长度须要用户在 create space 时候指定长度。对于有余的长度零碎主动应用 \0 补齐，而超过指定长度的 VertexID 会间接报错。
在 GA 版本中，咱们对底层存储格局进行了若干改变，因而这次版本升级时须要通过降级工具，将原有格局的数据转换为新格局的数据。如下是在 2.0 GA 版本中采纳的存储格局。
2.0 版本存储格局
- 点的格局
- 边的格局
和 1.0 存储格局比照
其中有几个比拟大的改变:
- VertexID 的长度如前文所说，从固定的 8 字节，批改为 n 个字节。VertexID 类型为整型时，n 为 8，VertexID 类型为 string 类型时，n 为指定长度。
- 点去掉了 1.0 的工夫戳。边将 1.0 工夫戳改为了一个字节的占位符。
- 对于点和边的第一个字节，不再应用同一个 Type，在物理上点和边进行了拆散。
这些改变次要是基于以下几点进行思考的：
VertexID 扭转次要是为了反对 string ID 同时兼容 1.0 版本 int ID。在 storage 中，把 VertexID 都解决为 bytes，只在返回后果时依据 space 的设置不同，返回相应类型的 VertexID。
为什么 string ID 要应用 FIXED_STRING ? 如果不应用固定长度，则无奈应用前缀进行扫描。通过长度有余补齐，使得所有点之间和边之间的各个前缀长度雷同，从而进行相应的前缀查问。
去掉工夫戳次要是因为保留多版本数据会影响性能，另外一段时间内临时不思考做 MVCC 的相干工作。
在边外面还保留一个字节的占位符，次要是留给 TOSS（transaction on storage side）应用。次要用于标识一条边的出边和入边是否残缺插入了，这里不具体介绍，后续会有其余文章进行详尽的剖析。
点和边拆散的益处次要是可能不便疾速拿某个点的所有 tag（在 Cypher 的
MATCH语句中大量应用）。如果按原先同一Type + VertexID前缀扫描，因为点边可能掺杂在一起，会极大影响性能。而 Type 拆散之后，按VertexType + VertexID前缀扫描，能够疾速获取所有 tag。在 1.0 版本中，因为没有取某个点的所有 tag 的需要，因而点和边能够按同一个前缀保留。不过在代码层面，还是有不小影响，例如 fetch 接口在 1.0 是按 VertexID 的前缀去扫描的，对于超级大点来说取 tag 性能比拟差。另外如果应用 storage 提供的 scan 接口，想要获取全图的所有点，理论是扫描了整个 RocksDB。
除了点和边的格局相干改变之外，索引的格局其实也有所扭转。
一方面是 2.0 反对 NULL 后，索引也须要可能示意对应的语义。另一方面是在 1.0 的版本中，对于索引中 string 的字段的解决，理论是按变长 string 解决。因而在 LOOKUP 语句中只有应用了带 string 字段的索引，就只能应用等值查问。而在 2.0 的版本中，索引的 string 字段和数据中的 VertexID 一样，应用固定长度的 FIXED_STRING，LOOKUP 语句中带 string 字段的索引可能应用范畴查问，例如 LOOKUP ON index1 WHERE col > "aaa"。无关索引局部的性能和批改，后续也会再有其余文章介绍。
以上，为本次 Nebula Storage 2.0 存储格局解说。
喜爱这篇文章？来来来，给咱们的 GitHub 点个 star 表激励啦~~ ????♂️????♀️ [手动跪谢]
交换图数据库技术？交个敌人，Nebula Graph 官网小助手微信：NebulaGraphbot 拉你进交换群~~
举荐浏览
- 《Nebula 架构分析系列（一）图数据库的存储设计》
