1–10 of 74 posts
Why do you think that is? Are there possibly other projects out there that I'm not familiar with?
- https://github.com/DataManagementLab/ScaleStore - "A Fast and Cost-Efficient Storage Engine using DRAM, NVMe, and RDMA"
- https://github.com/unum-cloud/udisk (https://github.com/unum-cloud/ustore) - "The fastest ACID-transactional persisted Key-Value store designed for NVMe block-devices with GPU-acceleration and SPDK to bypass the Linux kernel."
- https://github.com/capsuleman/ssd-nvme-database - "Columnar database on SSD NVMe"
Given however, that most of the world has shifted to VMs, I don't think KV storage is accessible for that reason alone because the disks are often split out to multiple users. So the overall demand for this would be low.
I mean, using a merkle tree or something like that to make sense of the underlying data.
Naive question: are there really expected gains to address natively an NVMe disk wrt using a regular key-value database on a filesystem ?
But that's about it. And the latency is still worse than in-memory solutions.
Between that and the non-trivial effort needed to make this work in any sort of cloud setup (be it self-hosted k8s or AWS), it's a hard sell. If I really need latency above all, AWS gives me instances with 24TB RAM, and if I don't… why not just use existing kv-stores and accept the couple of ns extra latency?
Otherwise though…you have the file system. Is that not enough?
Naive question: are there really expected gains to address natively an NVMe disk wrt using a regular key-value database on a filesystem ?
I’m also curious if different and more performant data structures can leveraged; if so, there may be downstream improvements for garbage collection, retrieval, and request parallelism.