
Samsung Announces Key-Value SSD Prototype - nikhizzle
https://www.anandtech.com/show/14839/samsung-announces-standardscompliant-keyvalue-ssd-prototype
======
skissane
IBM mainframes had key-indexed hard disks back in the 1960s – CKD (and later
ECKD). Each disk sector could have a key field at the start, and rather than
addressing disk sectors by physical location, you could tell the hard disk
"give me the data of sector with key 1234", and it would go search for that
sector and return it to you. (I think, you still had to tell it what disk
track to search on, and it just did a sequential scan of the disk track...)

A lot more primitive than this, of course, but funny how old ideas eventually
become new again.

~~~
kev009
It's also interesting that nobody implements CKD on storage devices. This
complexity runs on a massive POWER AIX box in IBM's storage systems, or in a
similar commodity powerhouse running UNIX or an RTOS in similar arrays of the
past couple decades.

You have a comparatively weak CPU (think ARM Cortex M series) on an SSD and
drive companies have been notoriously bad at firmware development.

Frankly, I don't trust Samsung to implement a file system. I prefer to not
even use their enterprise flash based on past trauma, but those are usually
harder fails than the subtle fuckups they can pull off in an opaque FS.

~~~
ClumsyPilot
You already are using a translation layer in the SSD, most SSDs have wear
levelling, error correction, compression, etc. What your OS things it's
writing to disk is very different to what ends up stored in the flash chips. I
think your are fighting yesterday's war.

~~~
theamk
That is exactly the reason I am using ZFS for important data -- one should not
really trust the storage devices to be fully reliable.

Is is a real pity that so few filesystems systems have integrated data
checksumming -- I'd love to use something other than ZFS for this.

------
ocdtrekkie
This continues the trend we see in processors, that in a post-Moore's law
environment, rather than trying to push physical limits for performance
improvements, we're branching out into hardware optimized for specific
purposes. Very neat to see it on the storage side, and something I don't think
anyone could fathom back in the spinning disk days.

~~~
jerf
I think it's happening somewhat in the software space, where we pursue speed
improvements by penetrating through sometimes literally decades of accumulated
cruft layers to build something more modern. It is ironically harder precisely
because it's easier; we've got a lot more software layers because it's so much
easier to add another one. Wayland is probably one big example of it, but I
often have this feeling in my Go code, too, where instead of a framework on
top of a framework on top of a very framework-y core language like Python, we
more-or-less just get on with it, both at the level of the code I type, and in
the generated assembler as well. I imagine Rust programming feels much the
same way when working with Rust-native libraries, I just don't have direct
experience.

It's not all Electron apps out there.

Also, when I call something "accumulated cruft", it's not just vague "bloat"
concerns I'm referring to; you have the problems of several layers of leaky
abstractions, and those leaky abstractions may well date from an era of
radically different hardware. It's true this can cause "bloat", but it causes
other problems, too.

~~~
the_duke
QUIC/Http3 could be another software example of this.

There is too much cruft in the TCP/IP + HTTP stacks, so the solution is to
implement a new protocol on top of the lowest abstraction that can be
practically used (IP+UDP) in user space; at least until kernels implement it.

I will delegate judging if this is a good idea to more knowledgeable parties
though.

~~~
ocdtrekkie
Isn't QUIC/HTTP3 the opposite? It's moving up the layers of abstraction, by
moving something that would previously have been managed at layer 4 up to a
higher layer.

Running everything that used to be done in the network layer up to the
application layer and putting everything on top of HTTPS is the opposite of
what the parent is advocating for.

~~~
jerf
If we consider it relative to HTTP1 just to heighten the contrast, it takes
the layers of: TCP connection management and negotiation, plain text framing
protocols, protocols too limited to deal with the greatly-increased use of or
need for multiple streams at once, SSL layering its own negotiation in, rather
hacky stories around websockets/SSE (which are usually used as text protocols
framed inside of text protocols framed inside of text protocols... not really
the best setup), and probably a couple of other things. All of these things
were designed for a different era at the very least, and often designed
independent of each other. HTTP3 slices through the whole thing and creates
nearly an entire protocol stack for its needs, using only the minimum it needs
from IP to work over the internet at all.

My software engineering instincts tell me this is all a bad idea and those
layers should be kept separate as they were, if indeed they weren't already
intermingled more than they should be (e.g., SSL & SNI; "why should SSL have
to know anything at all about how HTTP deals with host names?" say my
instincts). However, I intellectually realize that my software engineering
instincts are not calibrated for the size of the HTTP world, nor the amount of
resources that can be thrown at this problem. It's a great example of slicing
through many layers that make sense independently, but just never _quite_ went
together properly, to make something that's going to perform better without 30
years of mismatching layers stacked on top of each other.

(I'm not saying HTTP3 is perfect, only that it is a good example of someone at
least _trying_ to do what I was talking about.)

------
umvi
Maybe slightly off-topic but I've always struggled to understand the appeal of
key-value stores like Redis and DynamoDB. I tried using it once as a
substitute for shared memory in an embedded device, but you lose a lot of
information (like type) and it seems like you can't represent or query complex
data structures like nested structs without serializing it out to some data
format first and then storing _that_ in in the store (but at that point it's
starting to get slow/complex and you can't easily examine what's in the
database and so it's easier to keep using shared memory).

But clearly I'm missing something because everybody loves them and uses them.
Is this a technology I would only use when building websites at scale or
something?

~~~
oh-4-fucks-sake
I was in your camp for a long time until it clicked while attending an AWS
summit presentation by the head DynamoDB evangelist/wizard Rick Houlihan.

He said (paraphrasing) "a lot of people repeat this mantra that DynamoDB (and
by extension, NoSQL in general) is flexible--which couldn't be further than
the truth--it's not flexible, but it's extremely efficient."

He went on to elaborate that relational DBs are not going away, and if 1) your
data will never be huge and 2) you just can't predict the query patterns in
the future of your app--a relational DB is still the way to go.

However, if your data is both huge _and_ you can spend the up-front careful
planning of the queries you'll need to support _and_ can afford the risk of
future migration efforts that could be needed if your query needs outgrow your
model--then DynamoDB is a slam dunk.

If you fall into that category, then you'll need to spend the time learning
the "advanced patterns" of DynamoDB which include key overloading, adjacency-
list pattern, materialized graph pattern, and hierarchical key pattern--and
then compose those patterns into a custom "schema" (in the parlance of
relational DBs).

I'm building an app right now and it took me about 30 hours to collectively
enumerate the 40-odd queries I'll need to support and the 10 iterations of
overhauls of my design. But boy, was it worth it, because the DB is going to
easily be the cheapest m'fu __ __* component of my app. Compare that to
(taking an extreme alternative) paying for something like MS SQL server which
is colossal money sink. Even compared to open-source like Postgres, my setup
here will be probably < 1/10th the cost and if, for whatever reason, I see a
drop in traffic or I need to shut down for a period, my DB isn't metering for
compute--only storage.

In a drawn-out answer to your question of "would (I) only use (this) when
building websites at scale or something?" the answer is generally "yep,
probably".

~~~
reilly3000
Finely put!

------
elevenbits
Would be interesting if this evolves into a full filesystem implementation in
hardware (they talk about Object Drive but aren't focused on that yet). Some
interesting future possibilities:

\- A cross-platform filesystem that you could read/write from Windows, macOS,
Linux, iOS, Android etc. Imagine having a single disk that could boot any
computer operating system without having to manage partitions and boot
records!

\- Significantly improved filesystem performance as it's implemented in
hardware.

\- Better guarantees of write flushing (as SSD can include RAM + tiny battery)
that translate into higher level filesystem objects. You could say,
writeFile(key, data, flush_full, completion) and receive a callback when the
file is on disk. All independent of the OS or kernel version you're running
on.

\- Native async support is a huge win

Already the performance is looking insane. Would love to get away from the OS
dictating filesystem choice and performance.

~~~
joosters
_A cross-platform filesystem that you could read /write from Windows, macOS,
Linux, iOS, Android_

I wonder if that is possible to implement right now... It’s simple to adapt
something like a raspberry pi to become a usb device, pluggable into another
computer. It could emulate a USB drive, but depending upon the host computer’s
OS, it could present the raw drive data as a different file system,
fat/ntfs/ext4/whatever, and translate the host’s reads and writes back into
the appropriate reads and writes of an internal ‘universal’ filesystem.

You’d have to make compromises to cope with FS-specific features (like how to
translate users/groups onto a more basic FAT representation of the storage,
etc) but in principle it could work.

...except I’m not sure if a usb device can detect the OS of the system it is
plugged into?

~~~
Nursie
I think that's partly what MTP was supposed to be, without the os detection -
a way to present the files to a host OS without needing to expose the
underlying FS

------
jasonhansel
This is huge. It's been obvious for a long time that the standard block-device
abstraction isn't a great fit for SSDs. This development finally gives us a
better abstraction that will immensely improve performance of a wide variety
of applications (possibly even SQL databases).

~~~
BubRoss
Why isn't a block device a good fit for an SSD?

~~~
wtallis
NAND flash has _two_ inherent sizes: pages and erase blocks. NAND flash pages
are several times larger than the 4kB virtual memory pages that your OS
prefers to deal with, and erase blocks are a few orders of magnitude larger
than that. There's a lot of complexity involved in making it possible to do
512-byte or 4kB IO to NAND flash.

~~~
BubRoss
Block sizes can often be set to at least 65KB, does this not help the problem?

~~~
wtallis
It helps a bit, but keep in mind that just because your filesystem is doing
most of its allocation in 64kB chunks, doesn't mean it is issuing only 64kB
IOs to the drive itself.

~~~
sliken
Additionally it doesn't mean that your 64KB chunks aligned to your current
partition are also aligned with the 64KB boundary of the underlying block
device.

------
psanford
Interesting. I remember a short period where Seagate was really hyping their
own ethernet connected key/value hard drives back in 2015[1]. It seems like
that project died and this appears to be a completely different API (and not
ethernet based).

[1]:
[https://www.theregister.co.uk/2015/08/17/seagate_kinect_open...](https://www.theregister.co.uk/2015/08/17/seagate_kinect_open_thing/)

~~~
gitgudnubs
Network attached HDDs were killed by ethernet. In their infinite wisdom,
ethernet decided there was no need for speeds between 1GbE and 10GbE. They
finally caved to reality with 40GbE, 25GbE, and 50GbE. They eventually
ratified 2.5GbE, but it was too late for network drives.

The transfer rate of an HDD is well over 1Gbps.

~~~
oarsinsync
> In their infinite wisdom, ethernet decided there was no need for speeds
> between 1GbE and 10GbE. They finally caved to reality with 40GbE, 25GbE, and
> 50GbE.

I’m not sure that’s accurate. There were no intermediate steps to get to
10GbE, it was a straight jump from 1GbE and it was relatively easy.

To get to 40GbE, it involved running four lanes of 10GbE. To get to 100GbE, it
involved running four lanes of 25GbE. 50GbE is just two lanes of 25GbE.

We’ve gone from a single serialised stream to multiple parallel streams in
order to reach next order speeds. This is magnified when you start looking at
400GbE and 800GbE services that operate on 8 lanes (QSFP-DD or the confusingly
named OSFP).

~~~
jdnenej
10gbit networking gear is massively more expensive than 1gbit

~~~
amiga-workbench
Its finally beginning to fall in price, Microtik are doing relatively
inexpensive routers with 10gig SFP ports.

~~~
gitgudnubs
If I were going to sell a network attached spinning disk at scale, then I
would probably target 2.5GBASE-T. The problem there is that no routers support
it.

------
geophile
I don’t understand the comments saying that this obsoletes databases, or that
this is a good substrate for relational databases.

The interface is for random access. Quite a few database optimizations depend
on sequential access, I.e. accessing records in key order following a random
access. This is why B-trees are so important. Sequential access in key order
does not appear to be a possibility with this technology.

~~~
the_duke
> 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/KVSA...](https://www.snia.org/sites/default/files/technical_work/KVSAPI/Key%20Value%20Storage%20API%20v1.0.pdf)

~~~
zokier
See slide 43 here
[https://www.snia.org/sites/default/files/SDC/2017/presentati...](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)

~~~
the_duke
Very 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.

------
jandrewrogers
These have been built many times, and I have even been involved in the design
of one (that was ultimately scrapped). The value proposition of these products
is not what many people seem to be assuming, so I will elaborate. Under the
hood, most implementations are just mildly modified LevelDB/RocksDB/etc
running on an ARM processor.

In theory, there should be no performance advantages to embedding the storage
engine this way. But there is -- back to that in a moment. Not only will a
properly optimized storage engine run just as fast on the CPU but there are
performance advantages to doing so for applications like databases. If you are
designing a state-of-the-art storage engine for complex and high-performance
storage work, these devices are not for you, you can always do better with
bare storage.

The key phrase is "properly optimized". The I/O scheduling and management
underlying a typical popular KV storage engine is actually quite far from
properly optimized for modern storage hardware, with significantly adverse
consequences for performance and durability. The extent to which this is true
is significantly underestimated by many developers. From the perspective of
the storage manufacturers, more and more theoretical performance of their
product is being wasted because the most popular open source storage engines
are incapable of taking advantage of it as a matter of architecture. The kind
of architectural surgery required to address this is correctly seen as
something you can't upstream to the main open source code base.

The software in these devices is typically an open source storage engine where
they ripped out the I/O scheduler, storage management, and whatnot, replacing
it with one properly optimized to take advantage of the hardware. This could
be done in software but storage companies aren't in that business. Their hope
is that people will use these devices instead of LevelDB etc, with the promise
of superior performance that justifies higher cost.

In practice, these devices never seem to do well in the market. People that
are using the KV stores these are intended to replace are the kind of people
that do not have particularly performance-sensitive applications, and
therefore won't pay a premium. And it adds no value, and has some significant
disadvantages, for companies with serious storage engine implementation chops
or software storage-engines that _are_ well-optimized for this kind of
hardware.

tl;dr: These are like in-memory databases. A simple way to improve the
performance of applications instead of investing in hardcore software design
and implementation but providing no other value.

~~~
ntoshev
> The kind of architectural surgery required to address this is correctly seen
> as something you can't upstream to the main open source code base.

Why is this?

------
tenebrisalietum
What's the advantage of this over a simple hardware interface (which should be
really simple since I thought NVMe was basically just a PCIe node) that
directly exposes the flash and then let the application/filesystem/whatever
layer handle it?

~~~
duskwuff
Nobody wants to deal with raw flash. It's awful.

The error rate of raw flash is incredibly high -- it takes loads of error
correction to make it reliable, especially with modern MLC and QLC memories --
and the structure of flash erase blocks means that it doesn't support random-
access writes. A proper flash translation layer, implemented in hardware,
means that software can forget about all the strange features of flash and use
it as general-purpose block storage.

~~~
tenebrisalietum
I know how flash works. Linux, for example, supports all the "weirdness" of
flash with an MTD module which is low-resource enough for single-core sub 1GHz
routers with 16MB and 32MB of RAM to handle. I don't see how that is a burden
to a 32-core or higher amd64 architecture CPU in a database server whatsoever.

And SSDs already abstract that without adding a key-value store on top of it.

~~~
ClumsyPilot
I don't think my router's 16MB of flash are optimised for performance.
Additionally, i will need an implementation for windows, an implementation for
Linux, one for openBSD. Then there are many different kinds of flash memory on
the market, do you really want to debug why your OS is loosing data with a new
SSD that uses some weird flash memory?

------
chadash
Can someone tell me what the use case for this would be?

~~~
ricardobeat
You can see for yourself in the third paragraph. Streamlines key-value storage
and might replace database backends.

~~~
mruts
Why is this worth paying a premium for, though? Maybe a SQL SSD could get some
adoption, but a simple KV store? How would that ever be a bottleneck (they are
relatively easy to make blazing fast, unlike SQL) in your application? How
many people/corporations actually want something like this?

~~~
tantalor
> How would that ever be a bottleneck

Disk I/O is always the bottleneck.

~~~
rosser
Disk IO is far from the only bottleneck, or necessarily even the most common
one.

Source: My day job has been as a DBA for ~15 years.

------
ahupp
This is a cool idea, and I'm excited to see what kind of perf wins it
produces. It seems like the other solution would be to expose all the details
of the SSD to the OS: wear leveling, GC etc, and make that a driver concern.
Probably a lot harder to get right, but more debuggable and more opportunities
to tune for your specific workload.

~~~
wtallis
That's what the Open Channel SSD concept is. It's been getting a lot of
attention in the past few years, but it seems like many potential users still
balk at the idea of having that thin of an abstraction layer. The open-channel
stuff has been influencing the addition of other new features to the NVMe
protocol that expose most of the information an open-channel SSD would, but
don't break compatibility by requiring the host to use that information.

Several vendors are also supporting the Zoned Storage concept of making SSDs
that have similar IO constraints to shingled magnetic recording (SMR) hard
drives. Those constraints aren't a perfect match for the true characteristics
of NAND flash memory, but it does handle the problem of large erase blocks.

------
bvinc
I understand how it can achieve better performance by bypassing the file
system.

But I'd like to compare this to hypothetical key-value software that stores
its data directly on a partition (instead of in files). Isn't this essentially
the same thing? The only difference that I can see is that the software would
be much harder to update, and you can offload some CPU on to the processor on
the drive.

Am I looking at this correctly? I don't get why you would want this to be a
hardware device.

------
myself248
As someone on the periphery of comp-sci my whole life, I find myself
wondering, is this similar in concept to content-addressable memory?

~~~
goldenkey
No, because we are addressing it by key.

------
int0x80
How is this exposed to userspace? What interface?

~~~
mpsys
It is accessible directly to applications through the SNIA KVS API (and
Samsung has it's own API as well). There is no filesystem in the middle, if
you are using the KV-controller.

------
perspective1
On the one hand I think this is very cool. On the other, I think it's funny
that Redis can fit in my RAM and not on my SSD.

------
kissgyorgy
So now we will have yet another computer IN THE SSD too? Is this a good idea?
[https://boingboing.net/2018/11/12/cpus-in-your-
cpus.html](https://boingboing.net/2018/11/12/cpus-in-your-cpus.html)

~~~
wtallis
The most active area of R&D in the storage industry at the moment is stuff
falling under the umbrella term "computational storage". Everyone is looking
into ways to make SSDs smarter, and move some processing closer to the storage
where it can be done more efficiently or at least free up CPU time.

Some of the companies making enterprise SSD controller ASICs have decided to
throw in extra ARM Cortex-A53 or similar cores for the customer to put
software on, giving the application access to the data without a PCIe
bottleneck. Some companies are putting machine learning accelerators on the
SSD. Some are adding dedicated compression or crypto engines to transform data
at wire speed. Some are just putting an FPGA on the drive, or implementing the
controller on an FPGA and leaving leftover LUTs for the customer's use.

Almost any idea you can come up with about how to move storage hardware past
the hard drive-like block storage paradigm has been at least prototyped and
demoed at Flash Memory Summit.

~~~
DonHopkins
It's like NFS 3 (NeFS) in hardware! (NeWS for disks: A PostScript interpreter
in the kernel as a file system API.)

[https://www.donhopkins.com/home/nfs3_0.pdf](https://www.donhopkins.com/home/nfs3_0.pdf)

Network Extensible File System Protocol Specification (2/12/90)

Comments to: sun!nfs3 nfs3@SUN.COM

Sun Microsystems, Inc. 2550 Garcia Ave. Mountain View, CA 94043

1.0 Introduction

The Network Extensible File System protocol (NeFS) provides transparent remote
access to shared file systems over networks. The NeFS protocol is designed to
be machine, operating system, network architecture, and transport protocol
independent. This document is the draft specification for the protocol. It
will remain in draft form during a period of public review. Italicized
comments in the document are intended to present the rationale behind elements
of the design and to raise questions where there are doubts. Comments and
suggestions on this draft specification are most welcome.

[...]

Although it has features in common with NFS, NeFS is a radical departure from
NFS. The NFS protocol is built according to a Remote Procedure Call model
(RPC) where filesystem operations are mapped across the network as remote
procedure calls. The NeFS protocol abandons this model in favor of an
interpretive model in which the filesystem operations become operators in an
interpreted language. Clients send their requests to the server as programs to
be interpreted. Execution of the request by the server’s interpreter results
in the filesystem operations being invoked and results returned to the client.
Using the interpretive model, filesystem operations can be defined more
simply. Clients can build arbitrarily complex requests from these simple
operations.

------
eleitl
One of the comments to the article mentions
[https://en.wikipedia.org/wiki/Lightning_Memory-
Mapped_Databa...](https://en.wikipedia.org/wiki/Lightning_Memory-
Mapped_Database)

------
lucas_membrane
But who will be the first to use a Key-Value SSD to implement a file system?

~~~
wtallis
Samsung has already published a Ceph backend for their KV SSD, so you can use
CephFS to get a POSIX filesystem backed by these drives.

------
DonHopkins
How flexible are the limits on key and data size? I imagine a lot of apps
would need more than just 255 byte keys and 2MB values. Is there an efficient
way to virtually increase the value size, at least?

------
Androider
How would you do a backup of this KV store if it's not exposed as a filesystem
or block device? You wouldn't (it's for ephemeral caching?), or you'd just
walk the entire keyspace?

~~~
zzzcpan
There are iterators in the API I believe.

------
aspaceman
This is really cool! I find it very interesting that moving the key-value
store directly into the hardware could result in performance gains.

I suppose these wouldn't be as generally useful?

~~~
mpsys
SNIA KV stack gets rid of the filesystem, and the disk is directly accessible
by applications through the API. Hence, it won't be generally useful. The
target is a very specific segment of the SSD market.

------
cellular
They need to make write once ssd /usb drives. So you can backup photos and not
accidentally delete or be ransom-wared for them!

------
algaeontoast
This is incredibly interesting. Can't wait to see more application specific
NVME hardware come out!

------
lgats
What would a RAID-equivelant setup look like over this archetecture?

~~~
notyourday
RAID driver would use it as a retarded object store based block device.

The absolutely last thing that any fs designer would want is to outsource to
hardware vendor implementation of anything other than a basic operation. We
already saw this in hardware RAID which sucks donkey balls compared to
software RAID.

This is a pure value add play in a commodity market.

~~~
mpsys
KV-SSD replaces the filesystem with Abstract Device Interface(ADI), that sits
between the KV API exposed to the applications directly and the KV device
driver. According my understanding, although some modern filesystems combines
RAID and the file system, these are separate independent abstractions.
However, it would be interesting to explore how RAID will work with KV-SSDs.
You can take a look at a commercial implementation of Samsung's Mission Peak
system to benchmark KV-SSDs (I am not sure whether the following one is an
officially approved implementation or not) -
[https://www.broadberry.com/performance-storage-
servers/cyber...](https://www.broadberry.com/performance-storage-
servers/cyberstore-136nf1-nvme-ssd)

------
thinkmassive
How does the cost of these compare with existing SSDs?

~~~
wtallis
Same hardware, different firmware. Cost will be basically the same if the idea
catches on.

------
azurespace
A hello from the Samsung SSD developer :)

------
xzmmd
Eh, what a title. Wouldn't it be better if it said key-value ?

~~~
paulmd
Whining about titles is white-noise that contributes zero value to the
discussion, and it's absolutely rampant on HN.

~~~
the_duke
It definitely is not, because mods often change bad titles when it is pointed
out.

Which also just happened in this submission.

~~~
paulmd
The fact that the mods humor you doesn't make it not white noise, and in fact
it makes them part of the problem since it encourages it.

It is incredibly tedious to see people arguing about titles on every single
topic instead of actual discussion. On some topics with less discussion it is
literally the entirety of the discussion.

------
gitgudnubs
Ok.... I can just store the mapping of content key to blkid. Then I can load
the mapping into memory. Then I have a key value store on an SSD using cheap,
available hardware.

~~~
losteric
Obviously, key-value stores aren't a new thing... but pushing that abstraction
to hardware offers far better latency.

~~~
gitgudnubs
No it doesn't. The SSD lookup is measured in microseconds. The memory lookup
for the mapping to blkid is measured in nanoseconds.

Unless they're putting some expensive, power-hungry CAM in these devices,
they're doing exactly what I described above.

The only real advantages could be variably-sized values, and offloading CPU
cycles. But a map lookup isn't exactly expensive, especially for an I/O heavy
system. And variably-sized blocks aren't particularly relevant, since DBs are
pretty good at packing in data.

There's not much there to justify an unusual, expensive device that's far more
complicated than the alternative.

~~~
wtallis
> The SSD lookup is measured in microseconds. The memory lookup for the
> mapping to blkid is measured in nanoseconds.

Some people care about write performance, too.

~~~
gitgudnubs
It's the same in both cases.

You write a dirty mapping in memory. You persist the value, and you persist
the mapping. Then you flip the dirty bit.

------
pinewurst
I see these as pointless technology because you still have to deal with data
protection explicitly at a higher level. Given that, what does KV per drive
really get me?

~~~
zzzcpan
You'll get benchmarks that show higher numbers compared to non-KV SSDs and
Samsung may use them in its marketing. But yes, key-value APIs are not going
to make durability (and security) any easier. It's easier with lower level
APIs, i.e. raw flash or some primitive mapping around raw flash, not higher
level APIs.

