3 ms·
> The interface is for random access. I'm not sure where you are getting this idea. How keys are organized would be up to the device, and devices could support
by the_duke 7y ago
> The interface is for random access.
I'm not sure where you are getting this idea. How keys are organized would be up to the device, and devices could support multiple schemes. Clustering keys in a sorted order and fast in-order iteration seems like an essential requirement.
Just scanning over the specification [1], I see an iterator interface for key groups (6.4) and a setting for ordering (5.4.3)
Edit: just to clarify, I agree that this would in no way obsolete databases. But software DBs could utilize key/value disks internally.
[1] https://www.snia.org/sites/default/files/technical_work/KVSAPI/Key%20Value%20Storage%20API%20v1.0.pdf https://www.snia.org/sites/default/files/technical_work/KVSA...
- zokier 7y agoSee slide 43 here https://www.snia.org/sites/default/files/SDC/2017/presentations/Object_ObjectDriveStorage/Ki_Yang_Seok_Key_Value_SSD_Explained_Concept_Device_System_and_Standard.pdf https://www.snia.org/sites/default/files/SDC/2017/presentati...
- the_duke 7y agoVery interesting presentation. Slide 43 is for write performance though. RocksDB does a lot of clever things with writes, like delayed and batched flushing with a WAL for recovery. Would be interesting how that benchmark was written. Other slides with read benchmarks show very significant performance improvements. But comparing directly to a software DB seems inappropriate to me anyway. We can't expect (and definitely wouldn't want) a hard disk to offer something as complex as RocksDB/LLDB/etc. I would rather imagine that the software DBs start taking advantage of key/value disks internally.
- aledalgrande 7y agoIs that basically like having B-trees on the keys? I guess you would need also an API to retrieve multiple values at once, like `MGET` in Redis.