QuestDB data durability without performance compromise on NV-DIMM memory
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 17.3k
- Forks
- 1.6k
- Avg merge
- 5d 10h
- Merged PRs (30d)
- 28
Description
Is your feature request related to a problem? Please describe.
QuestDB should support NV-DIMM memory as intermediate data buffer(WAL analogue) to avoid trade-off between frequently use of sync with performance degradation versus data lost possibility.
Describe the solution you'd like
Some operating systems already expose NV-DIMM memory through the file system. Examples are NTFS DAX mode and ext4 DAX. Memory-mapped files in these file systems bypass the page cache and provide a direct mapping of virtual memory to the physical memory on the device. [JEP 316]. PMDK has almost no overhead in compare with FS+DAX.
Describe alternatives you've considered
Current performance/durability state.
Additional context
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.
Research direction
The issue names no repository files, tests, or entry points. Start by locating QuestDB's current WAL and sync durability paths, then assess the proposed NV-DIMM or PMDK buffer against the stated performance and data-loss trade-off; the issue needs an agreed scope and validation criteria before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- databases, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100