Graph database_neo4j 底层存储结构分析(6)

3.6  Node 数据存储

neo4j 中, Node 的存储是由 NodeStore 和 ArrayPropertyStore 2中类型配合来完成的. node 的label 内容是存在ArrayPropertyStore这样的DynamicStore 中，如果长度超过一个block ，则分block存储，并将其在ArrayPropertyStore中的第1个block 的 block_id 保存到 NodeStore类型文件相应record 的labels字段中。

下面是neo4j graph db 中，Node数据存储对应的文件：

neostore.nodestore.db

neostore.nodestore.db.id

neostore.nodestore.db.labels

neostore.nodestore.db.labels.id

ArrayPropertyStore的存储格式见< 3.3.2 DynamicStore 类型>，下面介绍一下 NodeStore 的文件存储格式。

3.6.1   NodeStore的主文件存储格式

NodeStore的主文件是neostore.nodestore.db， 其文件存储格式示意图如下，整个文件是有一个 RECORD_SIZE=15Bytes  的定长数组和一个字符串描述符“NodeStore v0.A.2”(文件类型描述TYPE_DESCRIPTOR和 neo4j 的 ALL_STORES_VERSION) 构成。访问时，可以通过 node_id 作为数组的下标进行访问。


1

2

3

4

5

&lt;div&gt;

// in_use(byte)+next_rel_id(int)+next_prop_id(int)+labels(5)+extra(byte)

public static final int RECORD_SIZE = 15;

下面介绍一下 node record 中每个字段的含义：

  • n  inUse(1 Byte):第1字节,共分成3部分

// [pppp,rrrx]

// [    ,   x] in use bit

// [    ,rrr  ] higher bits for rel id

// [pppp,    ] higher bits for prop id

long inUseByte = buffer.get();

    1. 第1 bit 表示 record 是否在 use;
    2. 第2~4 bit 表示 node 的第1个 relationship_id 的 高3位；
    3. 第 5~8 bit表示 node 的第1个property_id 的 高4位
  • next_rel_id(4 Bytes) : 第2~5字节是node 的第1个 relationship_id 的 低32位. 加上inUse 字节的第 2~4 bit作为高3位，构成一个完整的35位relationship_id。
  • next_prop_id(4 Bytes) : 第6~9字节是node 的第1个 property_id 的 低32位. 加上inUse 字节的第 5~8 bit作为高4位，构成一个完整的36 位 property_id。
  • labels(5 Bytes) : 第10~14字节是node 的label field。
  • extra(1 Byte) : 第15字节是 extra , 目前只用到第 1 bit ，表示该node 是否 dense, 缺省的配置是 该 node 的 relationshiop 的数量超过 50 个，这表示是 dense.

3.3.2   NodeStore.java

neo4j 中与neostore.nodestore.db文件相对应的类是NodeStore,负责NodeRecord在neostore.nodestore.db文件中的读写。

下面看一下 NodeStore.java 中 getRecord 成员函数，可以帮助理解 Node Record 的存储格式。


1

<br />&lt;div&gt;<br /><br />private NodeRecord getRecord( long id, PersistenceWindow window,<br /><br />RecordLoad load  )<br /><br />{<br /><br />Buffer buffer = window.getOffsettedBuffer( id );<br /><br />// [    ,   x] in use bit<br /><br />// [    ,xxx ] higher bits for rel id<br /><br />// [xxxx,    ] higher bits for prop id<br /><br />long inUseByte = buffer.get();<br /><br />boolean inUse = (inUseByte &amp; 0x1) == Record.IN_USE.intValue();<br /><br />if ( !inUse )<br /><br />{<br /><br />switch ( load )<br /><br />{<br /><br />case NORMAL:<br /><br />throw new InvalidRecordException( "NodeRecord[" + id + "] not in use" );<br /><br />case CHECK:<br /><br />return null;<br /><br />case FORCE:<br /><br />break;<br /><br />}<br /><br />}<br /><br />long nextRel = buffer.getUnsignedInt();<br /><br />long nextProp = buffer.getUnsignedInt();<br /><br />long relModifier = (inUseByte &amp; 0xEL) &lt;&lt; 31;<br /><br />long propModifier = (inUseByte &amp; 0xF0L) &lt;&lt; 28;<br /><br />long lsbLabels = buffer.getUnsignedInt();<br /><br />long hsbLabels = buffer.get() &amp; 0xFF; // so that a negative byte won‘t fill the "extended" bits with ones.<br /><br />long labels = lsbLabels | (hsbLabels &lt;&lt; 32);<br /><br />byte extra = buffer.get();<br /><br />boolean dense = (extra &amp; 0x1) &gt; 0;<br /><br />NodeRecord nodeRecord = new NodeRecord( id, dense, longFromIntAndMod( nextRel, relModifier ),<br /><br />longFromIntAndMod( nextProp, propModifier ) );<br /><br />nodeRecord.setInUse( inUse );<br /><br />nodeRecord.setLabelField( labels, Collections.&lt;DynamicRecord&gt;emptyList() );<br /><br />return nodeRecord;<br /><br />}<br /><br />

 
时间： 2024-10-12 18:12:05

Graph database_neo4j 底层存储结构分析(6)的相关文章

Graph database_neo4j 底层存储结构分析(7)

3.7  Relationship 的存储 下面是neo4j graph db 中,Relationship数据存储对应的文件: neostore.relationshipgroupstore.db neostore.relationshipgroupstore.db.id neostore.relationshipstore.db neostore.relationshipstore.db.id neostore.relationshiptypestore.db neostore.relati

Graph database_neo4j 底层存储结构分析(5)

3.5 Property 的存储 下面是neo4j graph db 中,Property数据存储对应的文件: neostore.propertystore.db neostore.propertystore.db.arrays neostore.propertystore.db.arrays.id neostore.propertystore.db.id neostore.propertystore.db.index neostore.propertystore.db.index.id neo

Graph database_neo4j 底层存储结构分析(1)

1       neo4j 中节点和关系的物理存储模型 1.1  neo4j存储模型 The node records contain only a pointer to their first property and their first relationship (in what is oftentermed the _relationship chain). From here, we can follow the (doubly) linked-list of relationshi

Graph database_neo4j 底层存储结构分析(8)

3.8  示例1:neo4j_exam 下面看一个简单的例子,然后看一下几个主要的存储文件,有助于理解<3–neo4j存储结构>描述的neo4j 的存储格式. 3.8.1    neo4j_exm 代码 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

Graph database_neo4j 底层存储结构分析(4)

3.3.2   DynamicStore 类型 3.3.2.1        AbstractDynamicStore 的存储格式 neo4j 中对于字符串等变长值的保存策略是用一组定长的 block 来保存,block之间用单向链表链接.类 AbstractDynamicStore 实现了该功能,下面是其注释说明. /** * An abstract representation of a dynamic store. The difference between a * normal Abs

Graph database_neo4j 底层存储结构分析(2)

3       neo4j存储结构 neo4j 中,主要有4类节点,属性,关系等文件是以数组作为核心存储结构:同时对节点,属性,关系等类型的每个数据项都会分配一个唯一的ID,在存储时以该ID 为数组的下标.这样,在访问时通过其ID作为下标,实现快速定位.所以在图遍历等操作时,可以实现 free-index. 3.1  neo4j 的 store 部分类图 3.1.1   CommonAbstractStore.java CommonAbstractStore 是所有 Store 类的基类,下面的

Graph database_neo4j 底层存储结构分析(3)

3.3  通用的Store 类型 3.3.1    id 类型 下面是 neo4j db 中,每种Store都有自己的ID文件(即后缀.id 文件),它们的格式都是一样的. [test00]$ls -lh target/neo4j-test00.db/ |grep .id -rw-r–r–9 04-11 13:28 neostore.id -rw-r–r–9 04-11 13:28 neostore.labeltokenstore.db.id -rw-r–r–9 04-11 13:28 neos

Docker底层存储结构

Docker底层存储结构 由于aufs并未并入内核,故而目前只有Ubuntu系统上能够使用aufs作为docker的存储引擎,而其他系统上使用lvm thin provisioning(overlayfs是一个和aufs类似的union filesystem,未来有可能进入内核,但目前还没有:Lvm snapshot are useful for doing e.g. backup of a snapshot, but regress badly in performance when you

Protobuf底层存储原理

参考官网, 序列化原理 底层二进制存储 message Test1 { optional int32 a = 1; } 并设置为a=150,序列化到一个文件中,查看文件,得到下面的二进制: 08 96 01 从底层存储的二进制值看出,Protobuf为什么这么快,节省内存了吧. 有以上的结果是因为 varints 这个特殊的东东.它可以让已个int数据类型的存储根据值的大小而自动改变存储的字节数. varint 中的每个字节,除了最后一个字节,都有最重要的位集--这表示还会有更多的字节.每个字节