Samsung Announces Standards-Compliant Key-Value SSD Prototype
Samsung has announced a new prototype key-value SSD that is compatible with the first industry standard API for key-value storage devices. Earlier this year, the Object Drives working group of Storage Networking Industry Association (SNIA) published version 1.0 of the Key Value Storage API Specification. Samsung has added support for this new API to their ongoing key-value SSD project.
Most hard drives and SSDs expose their storage capacity through a block storage interface, where the drive stores blocks of a fixed size (typically 512 bytes or 4kB) and they are identified by Logical Block Addresses that are usually 48 or 64 bits. Key-value drives extend that model so that a drive can support variable-sized keys instead of fixed-sized LBAs, and variable-sized values instead of fixed 512B or 4kB blocks. This allows a key-value drive to be used more or less as a drop-in replacement for software key-value databases like RocksDB, and as a backend for applications built atop key-value databases.
Key-value SSDs have the potential to offload significant work from a server's CPUs when used to replace a software-based key-value database. More importantly, moving the key-value interface into the SSD itself means it can be tightly integrated with the SSD's flash translation layer, cutting out the overhead of emulating a block storage device and layering a variable-sized storage system on top of that. This means key-value SSDs can operate with much lower write amplification and higher performance than software key-value databases, with only one layer of garbage collection in the stack instead of one in the SSD and one in the database.
(Score: 4, Insightful) by Anonymous Coward on Friday September 06 2019, @02:12AM (4 children)
Got nothing to add, except to note that it's a good fucking summary, others should emulate this post.
(Score: 2) by acid andy on Friday September 06 2019, @03:17PM (3 children)
It would have been better if it was finished off with one of Phoenix666's witticisms.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by DannyB on Friday September 06 2019, @04:01PM (2 children)
It seems to be missing a department.
What doesn't kill me makes me weaker for next time.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @04:05PM (1 child)
Also, it's posted by janrinok, so...
(Score: 3, Interesting) by DannyB on Friday September 06 2019, @04:55PM
<no-sarcasm>
I did notice who it was posted by. But the post seemed entirely reasonable.
All of the posts seem to be missing a department.
</no-sarcasm>
Perhaps there is some hack or malware that has stolen all of the departments and holding them for ransom?
What doesn't kill me makes me weaker for next time.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @06:30AM (5 children)
My first thought was wondering why you'd want that to be your address unit, as opposed to the sector. But then I remembered the Flash Transition Layer. Modern solid-state drives don't actually store the data where they say they do because with sector-based file systems (which is most of them), that would quickly murder the life of the SSD in certain areas and cause other problems. So, it makes sense to have this and other specialized drive firmware in the future do the heavy work for you because they already have to translate the requests for data behind the scenes to what they use internally.
(Score: 2, Interesting) by shrewdsheep on Friday September 06 2019, @07:27AM (1 child)
LBA has always been an abstraction (spare sectors, physical structure etc). Even in the Head/Cylinder/Sector-days this addressing got abstracted because outer cylinders could hold more sectors than inner ones (software compatibility through hardware changes).
Maybe such drives can also be efficient files systems with the key being the inode and the value the file content. A minimal software layer would be needed to handle folders and meta-data therein. Such a file system would not have any file count limitation as keys can just become larger when needed.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @07:59AM
Yeah, I know about ZBR, and CHS 1023/255/63 limits, and internal controllers mapping before any of that was even a concern. But, this could be a good file system support underneath. Just map directly like you suggest. Heck, I know many pieces of software that already store files like this in databases. I'll have to give the specification a good read and watch the mailing lists and give LWN a search in a few months.
(Score: 2) by canopic jug on Friday September 06 2019, @08:46AM (2 children)
I'm wondering if these could be accessed more directly by key-value database systems like M/MUMPS/YottaDB.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @08:29PM
Don't see why not. Many database and NoSQL systems already have raw partition support, since many times they'd be the only file on the file system anyway. Makes sense to similarly extend to this sort of store, especially since this has native partition support.
(Score: 2) by Common Joe on Saturday September 07 2019, @10:07AM
I haven't used a nosql database before, but I don't think so. There's no security built into the API at all. If you use this hard drive directly for a database, it would be just for one database. As soon as you want a second, you run the risk of one database seeing the other database's data. And don't think about having two hard drives for one database. The set of keys would not be shared between hard drives, so the database could have duplicate keys -- one key name on one hard drive and the same key name in the second hard drive.
Check out the API specs. It's pretty bare bones. You'll get a good idea just by skimming the table of contents at the top.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @07:45AM (2 children)
Finally, someone understood the simple fact so-called SSD is not a block device, but a funny memory.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @10:23AM
Don't make me laugh.
(Score: 2) by DannyB on Friday September 06 2019, @04:03PM
Humor is subjective.
It would be even funnier if an SSD device offered a SQL / DDL interface.
What doesn't kill me makes me weaker for next time.
(Score: 2) by DannyB on Friday September 06 2019, @04:59PM (6 children)
<no-sarcasm>
How about an SSD that offers a SQL / DDL interface?
How about an SSD that offers a file server style API ? (eg, you don't know, don't care what underlying file system is used within the SSD, the interface to it is more like NFS or CIFS or some such)
I thought it important here to use no-sarcasm tags. Why doesn't SN offer such useful tags?
</no-sarcasm>
As long as they keep the SSD from having too much vibration.
What about nvme with similar interfaces?
What doesn't kill me makes me weaker for next time.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @08:23PM (1 child)
SQL / DDL would be too complex for something like a disk. Last thing I want is my unaudited and maybe never updated disk controller software parsing something as complex as SQL. Same with the file-server API, hardware should be as dumb as possible. Adding something like NFS, CIFS or whatever adds complexity with no benefit.
But to your last point, drives are already K-V stores if you think about it. They take a value in, like LBA or CHS, and spit out a value. It is just in this case, they can have arbitrary-sized values instead of being fixed at the sector and having the top layer do it. The SSD already has to map the request to the flash block, so this isn't that much more of a complication compared to that.
Other benefits I've noticed is that this supports partitions out of the box through key groups. It specifies APIs that work alongside SATA, SCSI, and NVMe protocols. And, as a transition, you can use these drives with "sectors" as the keys instead of the key-value calls.
(Score: 2) by DannyB on Sunday September 08 2019, @09:21PM
It is too complex for a disk. But not too complex for a computer plus a disk.
The case of a key-value store must actually be a computer plus a disk. Because keys and values can be arbitrary values of arbitrary length.
What doesn't kill me makes me weaker for next time.
(Score: 2) by acid andy on Saturday September 07 2019, @11:33AM (3 children)
<sarcasm>
<no-sarcasm>
Because nesting them within sarcasm tags would be such a delightfully useful feature, giving rise to prose utterly devoid of ambiguity.
</no-sarcasm>
</sarcasm>
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by DannyB on Sunday September 08 2019, @09:19PM (2 children)
But they're not nested.
Your first pair is this . . .
<sarcasm>
<no-sarcasm>
Your second pair is malformed by having the slash in each tag.
What doesn't kill me makes me weaker for next time.
(Score: 2) by acid andy on Monday September 09 2019, @01:10PM (1 child)
You've lost me, sorry. It's valid markup. Was it a joke I didn't get?
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by DannyB on Monday September 09 2019, @01:25PM
Yes, a joke.
Sarcasm, then No-Sarcasm considered a matched pair. One turns on sarcasm mode, the other turns it off. Obviously not how you actually write tags.
What doesn't kill me makes me weaker for next time.
(Score: 1) by jon3k on Saturday September 07 2019, @01:21PM
Seagate has been working on a key/value disk as well, but they also added an ARM SoC to the disk and connected it directly to ethernet. It's called Seagate Kinetic [crn.com] but I haven't heard much about it in a couple years.
(Score: 2) by Muad'Dave on Monday September 09 2019, @02:06PM
... my data stored with the SHA-256 hash as the key? Very nice for de-duping and other uses.