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.
Moving the abstraction to hardware level gets rid of the multi-layer indirections that maps the key-value pairs to actual physical page. It replaces 3 layers of mappings with 1 layer. That reduces CPU load caused by the multi-layer indirections of software KV stores.
You haven't eliminated them. You've just moved them into a dedicated co-processor.
Co-processors are cheap when they're ubiquitous, like DMA. Co-processors are expensive when they're in custom hardware, like K-V stores. I'll get more performance/$ by using standard SSDs than you will by buying specialized hardware. And because the workload is IO dominated, we'll probably both get the same absolute performance from the same server (that differs only in storage devices).
You'll only recoup those CPU cycles back if you bin pack CPU heavy workloads next to IO heavy workloads, which is rarely desirable for storage services, because it adds a great deal of variance. But you just spent shit loads of money eliminating variance by going to SSD.
