存储结构
参考:
《图数据库(第二版)》
https://www.jianshu.com/p/94c1166eb400
https://blog.csdn.net/sinat_32336967/article/details/103348528
更新日期:2022-8-18
Neo4j版本:4.4
类型 | ID长度(bit) | 数量 | 数量(10进制) | 源码位置 | 存储区域 |
---|---|---|---|---|---|
点 | 35 | 235 | 34,359,738,368 | NodeRecordFormat.java | neostore.nodestore.db |
边 | 35 | 235 | 34,359,738,368 | RelationshipRecordFormat.java | neostore.relationshipstore.db |
属性 | 36 | 236 | 68,719,476,736 | PropertyRecordFormat.java | neostore.propertystore.db |
边类型 | 16 | 216 | 65,536 | ||
属性类型 | 4 | 24 | 16 | ||
属性键ID | 24 | 224 | 16,777,216 | neostore.propertystore.db.index | |
属性值ID | 字符串区neostore.propertystore.db.strings or 数组区 neostore.propertystore.db.arrays |
源码位置前缀为
community/record-storage-engine/src/main/java/org/neo4j/kernel/impl/store/format/standard/
ID都是物理地址,所以效率高
对于之前有删除的,
点结构
名称 | 长度 | 解释 |
---|---|---|
InUse | 1 | 是否在使用 |
nextRelId | 4 | 第一个关系 的ID |
nextPropId | 4 | 第一个属性 的ID |
labels | 5 | 第一个标签 的ID |
extra | 1 | 额外的,记录是否是supernode |
inUse
前四位:nextPropId
的高位
再后面三位:nextRelId
的高位
最后一位:才真正保存 是否在使用
即
nextPropId
其实有 36位;4+48
nextRelId
其实有 35位;3+48
边结构
名称 | 长度 | 解释 |
---|---|---|
InUse | 1 | 是否在使用 |
firstNode | 4 | 开始点 的ID |
secondNode | 4 | 结束点 的ID |
relationshipType | 4 | 边类型 |
firstPrevRelId | 4 | 开始点的上一个关系 的ID |
firstNextRelId | 4 | 开始点的下一个关系 的ID |
secondPrevRelId | 4 | 结束点的上一个关系 的ID |
secondNextRelId | 4 | 结束点的下一个关系 的ID |
nextPropId | 4 | 第一个属性 的ID |
firstInChainMarker | 1 | 关系链的第一个标识,是否为关系链的第一条边(包括 开始点,结束点) |
InUse
前四位为:属性ID 的高位
再三位:开始点ID 的高位
relationshipType
第一位:无用
再三位:结束点ID 的高位
前12位:4*3位,分给 各个4关系 作为高位使用
后16位:真正的关系类型ID
属性结构
名称 | 长度 | 解释 |
---|---|---|
InUse | 1 | 是否在使用 |
nextPropId | 4 | 上一个属性的ID |
PrevPropId | 4 | 下一个属性的ID |
propBlock | 32 | 属性值 ID |
propBlock比较复杂,可以看这里理解一下
可以存1-4个属性,可能有内联
InUse
前四位为 下一个属性ID 的高位
前四位为 上一个属性ID 的高位
inUse被完全占用,
inUse的判断逻辑(源码):第一个属性的类型不为0
Docker/Neo4j
https://zhuanlan.zhihu.com/p/389388077
https://blog.csdn.net/AnNanDu/article/details/125019447
dbms.connector.bolt.listen_address=0.0.0.0:7687