[Improvement] Graph server edgeCache invalidate strategy
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- java
- Domain
- databases, performance
Research direction
Start with the linked discussion and CachedGraphTransactionTest#testEdgeCacheClearWhenUpdateVertex to understand the current edgeCache invalidation behavior and queryId examples. Inspect the existing graph server cache logic, then confirm the intended vertex and edge invalidation strategy with maintainers. Done means an agreed, tested strategy is implemented without assuming an unresolved approach for edge changes.
Written by the indexing model from the issue text.
Description
Discussed in https://github.com/apache/incubator-hugegraph/discussions/2720
Originally posted by haohao0103 January 7, 2025
According to the current logic, the edgeCache invalidation mechanism is triggered by any vertex addition, update, or deletion, as well as any edge addition, update, or deletion, resulting in the clearing of the entire edge cache. As shown in the image, my expectation is to handle edgeCache invalidation differently based on the type of vertex change. From what I understand, the edgeCache's cache key is the queryId, such as:
Query * from EDGE where [OWNER_VERTEX == 2, DIRECTION == OUT OR DIRECTION == IN]
Query * from EDGE where [OWNER_VERTEX == 1, DIRECTION == OUT OR DIRECTION == IN]
This data is sourced from CachedGraphTransactionTest#testEdgeCacheClearWhenUpdateVertex.
The queryId in edgeCache is related to the vertex ID and not to the vertex's properties. Therefore, vertex addition or update operations should not trigger edgeCache invalidation. Is this understanding correct?
For vertex deletion operations, only the edgeCache entries corresponding to the relevant queryId should be cleared, rather than clearing the entire edge cache. This requires designing a data structure to maintain the mapping between vertices and their associated queryIds.
For edge change operations, I do not yet have a clear approach and will temporarily maintain the original design.
I welcome any guidance, suggestions, or feedback on this approach. Thank you in advance for your input!
- Dominant language
- Java
- Stars
- 3.2k
- Forks
- 637
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 23
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/hugegraph
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 64/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 28/100
All issues in apache/hugegraph
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
apache/cloudstack#14222 ·
-
[BUG]茶杯方块在取茶时会引发崩溃 Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
1.0.0-alpha2 Type/Improvement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
wso2/dpdp-accelerator#272 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
area/frontend
Difficulty 2/5 1-3 hours Newbie friendliness 65/100