anyone using Redis with NVMe?

[Hubbert Smith]

first, I am a noob on redis and key value. so, thanks in advance for tolerating my noob questions :o)

I do however have some modest understanding of storage hardware, storage protocols, storage systems performance and databases. but its modest understanding.

About NVMe - You may know that NVMe is an industry standard protocol to connect computers to SSDs (without all that ugly baggage of previous protocols designed for HDDs and SCSI tape drives).

NVMe design includes mapping of CPU cores to SSD channels, and NVMe handles queues for each core-SSD channel pair. Cool, yes?

NVMe sequential performance is typically 10x faster than disk drives and 5x faster than most non-NVMe SSDs. NVMe random performance is many times faster, but your mileage will vary (a lot).

About Redis+NVMe - I read in this group that Redis is single threaded. 

1) The idea I'd like to explore with the group  .... might NVMe (with really good IO queuing) pay off nicely when used with single threaded Redis?

2) Have any of you kind ladies and gentlemen already used Redis and NVMe together? if so, can you kindly point me to results or share results?

3) any group feedback on the theory of using NVMe CPU-to-SSD channel mapping? and might this idea pay off?

full disclosure - I work for Samsung. We contributed to the NVMe standard and we manufacture NVMe hardware product

my interest is developing a Redis+NVMe reference design, with compelling performance and publish the results

cheers

Hub...@hubbertsmith.com

[Stefano Fratini]

An even more humble contribution... and please correct me if I'm completely off the mark

The speed of Redis comes from being in memory only. Random memory access time is measured in tens of nano seconds not in milli seconds or hundreds of microseconds (typical of a modern SSD)

For example, on a typical production deployment with master/slave replication you may want to disable snapshotting (and any sort of logging to disk) on the master to make performance more predictable

CouchDB (where each and every read or write op hits the hard disk) or more traditional SQL engines sound like a better candidates to test the improvements brought forward by NVMe

Stefano

[Javier Guerra Giraldez]

On Sun, Jun 7, 2015 at 11:46 PM, Stefano Fratini <ma...@stefanofratini.it> wrote:
> CouchDB (where each and every read or write op hits the hard disk) or more
> traditional SQL engines sound like a better candidates to test the
> improvements brought forward by NVMe

AFAIUI, the NVMe improvements include not using a filesystem, or even
a block-device abstraction, but rather 'look' like nonvolatile memory
(which is what Flash is, after all). couchDB, or any other disk-based
application would indeed benefit from the greater speed, but the
bottleneck becomes the "disk emulation"

maybe a more impressive demo of NVMe (which is what the OP is after, i
guess) would be LMDB, which is a "mmap() and use storage as memory"
database. currently it suffers from bad locality (which is why
leveldb beats it on some write-heavy benchmarks), but maybe replacing
the mmap()'ing of a file with the corresponding NVMe primitive for
mmapping a chunk of the device could avoid the whole filesystem+block
device overhead, and exploit the nearly-random-access nature of good
Flash managers.

in the Redis case, it might be possible to simply map the NVMe device
as a huge chunk of memory and use it for Redis storage, making it
conceivable to simply turn off disk persistency and trust the
non-volatility of Flash. But, as you noted, it's still orders of
magnitude slower than main RAM. It would be better than the disaster
that it's currently to fall into virtual memory (even with fast SSDs),
but i doubt it would "feel" like normal, RAM-based Redis.


--
Javier