JanusGraph / JanusGraph/janusgraph
Global db-cache invalidation on mutation
- Dominant language
- Java
- Stars
- 5.8k
- Forks
- 1.2k
- Avg merge
- 13h 53m
- Merged PRs (30d)
- 6
Description
Partially discussed in `Invalidation` topic here: https://lists.lfaidata.foundation/g/janusgraph-dev/topic/discussion_janusgraph/93326202
Currently we invalidate db-cache only in the next 3 scenarios:
1) Enough time passed (`cache.db-cache-time`).
2) Evicted due to cache size limitation (`cache.db-cache-time`).
3) Evicted on current JanusGraph instance only due to being mutated on the current JanusGraph instance.
I would propose adding a feature which adds a possibility to evict JanusGraph cache on all JanusGraph instances during mutation on any of the instances (something like `cache.db-cache-global-eviction = true`).
This would be a good feature for situations when there are no many writes but many reads. Of course, if there are too many writes this would pressure other JanusGraph nodes which isn't good but then this feature shouldn't be used in such use-cases.
I didn't think on how to implement this feature but I guess maybe reusing JanusGraph messaging mechanism could be a good start.
Contributor guide
Research direction
Start with the linked Invalidation discussion and inspect JanusGraph’s messaging mechanism as the proposed entry point; the issue names no specific files or tests. Done means a configurable option can evict the database cache across all JanusGraph instances after a mutation, with behavior suitable for the stated low-write, high-read use case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- databases, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100