Graph DATABASE_NEO4J underlying storage structure analysis (7)

Storage of 3.7 Relationship

The following is the file corresponding to the relationship data store in neo4j graph DB:

Neostore.relationshipgroupstore.db

Neostore.relationshipgroupstore.db.id

Neostore.relationshipstore.db

Neostore.relationshipstore.db.id

Neostore.relationshiptypestore.db

Neostore.relationshiptypestore.db.id

Neostore.relationshiptypestore.db.names

Neostore.relationshiptypestore.db.names.id

neo4j, relationship is stored by Relationshipstore, Relationshipgroupstore, Relationshiptypetokenstore and Stringpropertystore 4 types of store mates to complete. Among them, Relationshipstore is the most important storage structure of relationship; When a node's relationship reaches a certain threshold, the relationship is grouped (group), and Relationshipgroupstore is used to save the relational grouping data ; Relationshiptypetokenstore and Stringpropertystore mates are used to store the type of relationship.

The string description value of the type of the relationship is present in a dynamicstore such as Stringpropertystore, if the length exceeds a block, the block is stored and its 1th block in the Stringpropertystore BLOCK_ID is saved to the name_id field in the corresponding record of the Relationshiptypetokenstore type file.

Arraypropertystore storage format See < 3.3.2 Dynamicstore type, the following describes Relationshiptypetokenstore respectively, File storage format for Relationshipstore and Relationshipstore.

3.7.1 Relationshiptypetokenstore's primary file storage format

The corresponding storage file for class Relationshiptypetokenstore is neostore.relationshiptypestore.db, and its corresponding storage format is as follows: a length of record_size=5 Bytes The record array and a string descriptor of "Relationshiptypestore v0." A.2 "(File type description type_descriptor and neo4j all_stores_version) constitute. When accessed, it can be accessed by token_id as the subscript for the array.

The record is composed of 1Byte In_use and 4Bytes name_id.

3.7.2 Relationshipstore File storage format

Class Relationshiptypetokenstore corresponding to the storage file is neostore.relationshipstore.db, its file storage format is as follows, the whole file is there is a record_size=34bytes A fixed-length array and a string descriptor of "Relationshipstore v0." A.2 "(file type describes the all_stores_version composition of Type_descriptor and neo4j). When accessed, it can be accessed by node_id as the subscript for the array.

1234567891011

</PRE> Code class= "CPP Plain" >< div > //record header size  //Directed|in_use (Byte) + First_node (int) +second_node (int) +rel_type (int) +  //first_prev_rel_id (int ) +first_next_rel_id+second_prev_rel_id (int) +  //Second_next_rel_id+next_ prop_id (int) +first-in-chain-markers (1)  public static final int record_size = 34;</ div > <PRE>

The meanings of each field in the relationship record are described below:

• In_use (1 byte): 1th Byte, divided into 3 sections.

[PPPP,NNNX]
[, X] in use flag
[, NNN] first node high order bits
[PPPP,] next prop high order bits
The 1th bit indicates whether the record is in use;
The 2nd to 4th bit represents the high 3 bits of the First_node node_id;
The 5th to 8th bit represents the high 4 bits of next_prop_id's property_id

• First_node (4 Bytes): The 2nd to 5th byte is the lower 32 bits of node_id of relationship From_node. Add the 2nd to 4th bit of the inuse byte as a high 3-bit, constituting a complete 35-bit node_id.
• Second_node (4 Bytes): The 6th to 9th Byte is the lower 32 bits of node_id of relationship To_node. Add Rel_type's 29th to 31st bit as a high 3 bit, constituting a complete 35-bit node_id.
• Rel_type (4 Bytes): 10th to 13th byte, divided into 6 parts;

[xxx,   ][   ,   ][   ,   ] [    ,   ] Second node high order bits,     0x70000000//[    , xxx][   ,   ][   ,   ][    ,   ] First prev rel high order bits,  0xe000000//[   ,   X][xx&nbs P ,   ][   ,   ][   ,   ] First next rel High order bits,  0x1c00000//[   ,   ][  xx,x  ][    ,   ][   ,   ] Second prev rel high order bits, 0x380000//[ & nbsp; ,   ][   , xxx][   ,   ][    ,   ] Second next rel high order bits, 0x70000

[,] [,][xxxx,xxxx][xxxx,xxxx] Type

1. The 29th to 31st Place is the second_node of the node_id high 3 bits;
2. The 26th to 28th Place is the first_next_rel_id of the relationship_id high 3 bits;
3. The 23rd to 25th Place is the first_next_rel_id of the relationship_id high 3 bits;
4. The 20th to 22nd place is the second_prev_rel_id of the relationship_id high 3 bits;
5. The 17th to 19th place is the second_next_rel_id of the relationship_id high 3 bits;
6. The 1th to 16th place represents relationshiptype;

• FIRST_PREV_REL_ID (4 Bytes): The 14th to 17th byte is the lower 32 bits of relationship of relationship_id in front of this relationship, From_node. Add Rel_type's 26th to 28th bit as a high 3 bit, constituting a complete 35-bit relationship_id.
• FIRST_NEXT_REL_ID (4 Bytes): The 18th to 21st byte is the lower 32 bits of relationship of relationship_id in front of this relationship, From_node. Add Rel_type's 23rd to 25th bit as a high 3 bit, constituting a complete 35-bit relationship_id.
• SECOND_PREV_REL_ID (4 Bytes): The 22nd to 25th byte is the lower 32 bits of relationship of relationship_id in front of this relationship, From_node. Add Rel_type's 20th to 22nd bit as a high 3 bit, constituting a complete 35-bit relationship_id.
• SECOND_NEXT_REL_ID (4 Bytes): The 26th to 29th byte is the lower 32 bits of relationship of relationship_id in front of this relationship, From_node. Add Rel_type's 17th to 19th bit as a high 3 bit, constituting a complete 35-bit relationship_id.
• NEXT_PROP_ID (4 Bytes): The 30th to 33rd Byte is the lower 32 bits of property_id of the 1th property of this relationship. Add In_use's 5th to 8th bit as a high 3 bit, constituting a complete 36-bit property_id.
• First-in-chain-markers (1 bytes): Currently only used 1th and 2nd place, the role of the author has not yet figured out.

3.7.2.1 Relationshipstore.java

The class corresponding to the Neostore.relationshipstore.db file is Relationshipstore, Responsible for reading and writing Relationshiprecord files from neostore.relationshipstore.db. Take a look at the Getrecord member function in Neostore.relationshipstore.db to help understand the storage format of the relationship Record.

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465 66676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109

</pre><div>private RelationshipRecord getRecord( long id, PersistenceWindow window,RecordLoad load ) {Buffer buffer = window.getOffsettedBuffer( id );// [    ,   x] in use flag// [    ,xxx ] first node high order bits// [xxxx,    ] next prop high order bitslong inUseByte = buffer.get();boolean inUse = (inUseByte & 0x1) == Record.IN_USE.intValue();if ( !inUse ){ switch ( load ){case NORMAL:throw new InvalidRecordException( "RelationshipRecord[" + id + "] not in use" );case CHECK:return null;}}long firstNode = buffer.getUnsignedInt();long firstNodeMod = (inUseByte & 0xEL) << 31;long secondNode = buffer.getUnsignedInt();// [ xxx,    ][    ,    ][    ,    ][    ,    ] second node high order bits,     0x70000000 // [    ,xxx ][    ,    ][    ,    ][    ,    ] first prev rel high order bits,  0xE000000// [    ,   x][xx  ,    ][    ,    ][    ,    ] first next rel high order bits,  0x1C00000// [    ,    ][  xx,x   ][    ,    ][    ,    ] second prev rel high order bits, 0x380000 // [    ,    ][    , xxx][    ,    ][    ,    ] second next rel high order bits, 0x70000// [    ,    ][    ,    ][xxxx,xxxx][xxxx,xxxx] typelong typeInt = buffer.getInt();long secondNodeMod = (typeInt & 0x70000000L) << 4;int type = (int)(typeInt & 0xFFFF); RelationshipRecord record = new RelationshipRecord( id,longFromIntAndMod( firstNode, firstNodeMod ),longFromIntAndMod( secondNode, secondNodeMod ), type );record.setInUse( inUse );long firstPrevRel = buffer.getUnsignedInt();long firstPrevRelMod = (typeInt & 0xE000000L) << 7;record.setFirstPrevRel( longFromIntAndMod( firstPrevRel, firstPrevRelMod ) ); long firstNextRel = buffer.getUnsignedInt();long firstNextRelMod = (typeInt & 0x1C00000L) << 10;record.setFirstNextRel( longFromIntAndMod( firstNextRel, firstNextRelMod ) );long secondPrevRel = buffer.getUnsignedInt();long secondPrevRelMod = (typeInt & 0x380000L) << 13;record.setSecondPrevRel( longFromIntAndMod( secondPrevRel, secondPrevRelMod ) ); long secondNextRel = buffer.getUnsignedInt();long secondNextRelMod = (typeInt & 0x70000L) << 16;record.setSecondNextRel( longFromIntAndMod( secondNextRel, secondNextRelMod ) );long nextProp = buffer.getUnsignedInt();long nextPropMod = (inUseByte & 0xF0L) << 28;byte extraByte = buffer.get();record.setFirstInFirstChain( (extraByte & 0x1) != 0 ); record.setFirstInSecondChain( (extraByte & 0x2) != 0 );record.setNextProp( longFromIntAndMod( nextProp, nextPropMod ) );return record;}

3.7.3 relationshipgroupstore type of storage format

When node's relationship number exceeds one threshold, neo4j groups the relationship to provide performance. The class used to implement this function in Neo4j is Relationshipgroupstore.

Its corresponding file storage format is as follows:

The entire file is a fixed-length array of record_size=20bytes and a string "Relationshipgroupstore v0. A.2 "(file type describes the all_stores_version composition of Type_descriptor and neo4j). When accessed, it can be accessed by using the ID as the subscript for the array. The record 4 Bytes with the array subscript 0 holds the threshold for relationship grouping.

The format of the Relationshipgroupstore record is as follows:

• InUse (1 byte): 1th Byte, divided into 4 parts

[, X] in use

[, XXX] high next ID bits

[XXX,] high firstout bits

Long inusebyte = Buffer.get ();

1. 1th bit: Indicates whether the record is in use;
2. 2nd to 4th bit: represents the high 3 bits of next;
3. 5th to 7th bit: Firstout High 3 bits
4. 8th bit: no use.

• Highbyte (1 byte): 1th Byte, divided into 4 parts

[, X] in use

[, XXX] high next ID bits

[XXX,] high firstout bits

Long inusebyte = Buffer.get ();

1. 1th bit: no use;
2. 2nd to 4th bit: Indicates the height of the Firstin 3 bits;
3. 5th to 7th bit: Firstloop High 3 bits
4. 8th bit: no use.

• Next:
• Firstout
• Firstin
• Firstloop

Graph DATABASE_NEO4J underlying storage structure analysis (7)