SoylentNews is people
SoylentNews
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: 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.