Feat movable tree

[Leeeon233]

Movable Tree

I implemented the highly-available movable tree crdt made by M. Kleppmann, et al [paper], to support the tree-structure data model. This tree structure supports the following operations:

• Create a node.
• Moving a node to be a descendant of another node.
• Delete a node.
• Attach the metadata to the node.
• Check out any version.

Concept

I model the tree using a flat structure (HashMap<TreeID, Option<TreeID>>) and two additional defined specific root nodes, DELETED_TREE_ROOT and UNEXIST_TREE_ROOT so that all operations of the movable tree can be modeled by a move action.

• TreeID: the unique id of a tree node, its fields are the same as ID so we can get the associated metadata container by TreeID and Map ContainerType.
• DELETED_TREE_ROOT: The root of all deleted nodes. The delete action can be modeled as move the node to DELETED_TREE_ROOT.
• UNEXIST_TREE_ROOT: The root of all non-existent nodes. When we create a node and then check out the previous vision, we need to delete it from the state instead of moving it to DELETED_TREE_ROOT.
• None parent id: The parent of a root node is None.

Conflicts

Conflicts may occur when we receive updates from other peers, such as Peer A moving node a as the successor of node b, but Peer B does the opposite.

Generally speaking, our method of resolving conflicts is to arrange all operations in a unique order(Lamport and PeerID) and apply them one by one. If the operation causes a circular reference, mark the operation as uneffected(do not apply this operation and ignore its impact). After all operations are applied, it is the final state.

Specifically, when a new update is received, we will retreat the operation from back to front until the version is the LCA version. Then arrange these operations and new operations and apply them by the method mentioned above.

Performance

Profile by M2 Max.

	time
1000 nodes move 10^5 times randomly	58 ms
1000 nodes checkout 10^3 times randomly	53 ms	move 1000 times first
300 depth tree random checkout 10^3 times	158 ms	The new node is a child node of the previous node

Note:

When making changes to a movable tree, we need to check whether the new operation will cause a cycle, so the deeper the tree, the more time-consuming it is to traverse it.

Demo

An online movable-tree-based todo app can be found here.

TODO

• more API for tree
• remove deleted field from get_value() of tree state
  • we need to retain the deleted field to check consistency when checking out the version before deleting the node.
  • Or we could use a specific node to represent that all nodes don't exist instead of moving directly to the DELETE_ROOT
• cache all deleted nodes of the tree state to accelerate the filtering of existing nodes.

Breaking Change

• Encoding Format
  • add a field for caching TreeIDs