JanusGraph 数据模型

JanusGraph以邻接列表格式存储图形，这意味着图形存储为顶点及其邻接列表的集合。顶点的邻接列表包含顶点的所有关联边（和属性）。

通过以邻接列表格式存储图形，JanusGraph确保将顶点的所有关联边和属性紧凑地存储在存储后端，从而加快遍历。缺点是每个边必须存储两次—一次用于边的每个端点。

此外，JanusGraph按排序键定义的顺序和边标签的排序顺序维护每个顶点的邻接列表。排序顺序可以使用以顶点为中心的索引高效地检索相邻列表的子集。

JanusGraph在支持Bigtable数据模型的任何存储后端中存储图形的邻接列表表示。

Bigtable Data Model

在Bigtable数据模型下，每个表都是行的集合。每一行都由一个键唯一地标识。每一行由任意（大，但有限）个单元格组成。单元格由列和值组成。单元格由给定行中的列唯一标识。Bigtable模型中的行称为“宽行”，因为它们支持大量的单元格，而这些单元格的列不必像关系数据库中所要求的那样预先定义。

JanusGraph对Bigtable数据模型有一个额外的要求：单元格必须按其列排序，列范围指定的单元格子集必须可以有效地检索（例如，通过使用索引结构、跳过列表或二进制搜索）。

另外，一个特定的Bigtable实现可以保持行按其键的顺序排序。JanusGraph可以利用这样的密钥顺序来有效地划分图，从而为非常大的图提供更好的加载和遍历性能。然而，这不是一个要求。

JanusGraph Data Layout

JanusGraph在底层存储后端将每个相邻列表存储为一行。（64位）顶点id（JanusGraph唯一分配给每个顶点）是指向包含顶点邻接列表的行的键。每个边和属性都存储为行中的单个单元格，这样可以进行有效的插入和删除。因此，特定存储后端中每行允许的最大单元格数也是JanusGraph对此后端可以支持的最大顶点度。

如果存储后端支持键顺序，则相邻列表将按顶点id排序，JanusGraph可以分配顶点id，从而有效地对图进行分区。ID的分配使得经常同时访问的顶点具有绝对差异很小的ID。

Individual Edge Layout

每个边和属性作为一个单元存储在其相邻顶点的行中。它们被序列化，以便列的字节顺序与边缘标签的排序键一致。可变id编码方案和压缩对象序列化用于保持每个边缘/单元的存储空间尽可能小。

考虑在上面图形的顶部行中可视化的单个边缘的存储布局。深蓝色框表示用可变长度编码方案编码的数字，以减少它们所消耗的字节数。红色框表示一个或多个属性值（即对象），这些值是用关联属性键中引用的压缩元数据序列化的。灰色框表示未压缩的属性值（即序列化对象）。

边的序列化表示从边标签的唯一id（由JanusGraph指定）开始。这通常是一个很小的数字，并通过变量id编码进行了很好的压缩。此id的最后一位是偏移量，用于存储这是传入边还是传出边。接下来，存储包含排序键的属性值。排序键是用边标签定义的，因此排序键对象元数据可以引用到边标签。然后，存储相邻顶点的id。JanusGraph不存储实际的顶点id，而是存储与拥有此邻接列表的顶点id的差异。很可能差异比绝对id小，因此压缩效果更好。顶点id后跟此边的id。每个边由JanusGraph分配一个唯一的id。这将结束边单元格的列值。边缘单元格的值包含边缘的签名属性（由标签的签名密钥定义）的压缩序列化以及以未压缩序列化方式添加到边缘的任何其他属性。

属性的序列化表示更简单，只在列中包含属性的键id。属性id和属性值存储在值中。但是，如果属性键定义为list（），则属性id也存储在列中。