Recommendations for kinds of hard drives for Redis persistence?

[Jan Algermissen]

Hi all,

I am new to Redis and have a question regarding Redis host configuration.

(Short intro: My name is Jan Algermissen, REST-head and freelance programmer/software architect)

I am developing a Web app and chose Redis as primary storage (the possible data loss is ok as it is replicated data).

The Web app is not under heavy load, there are just a couple of users. Mostly the app is extracting all the data from Redis and generating various output files (XML,CSV..)

I chose to put Redis and the app on the same box, put lots of memory in there and attach 4 hard drives, (2xRAID1). 1 RAID for the OS, Web app and file generation and the other RAID for Redis persistence.

My question is, which kinds of disks I should choose for Redis persistence? Will Redis benefit from SSDs as much as other DBs do? Or would it be ok to opt for slower, cheaper disks?

The data is actually changing very infrequently (couple of times an hour a few keys will be updated), so maybe I can even put the OS, the Web app and Redis persistence in a single RAID?

Jan

[Josiah Carlson]

What disks make sense will depend on your expected persistence method. With rarely updated data, it probably makes the most sense for you to use snapshots (which are configured with the 'save' configuration lines). If you are using snapshots, then standard spinning disks are fine, and unless your web app requires a lot of random disk I/Os, you could put it all on one drive.

That said, for anyone using AOF persistence, all of those reads/writes are sequential too, so spinning disks would work there too. About the only thing you get with SSDs is potentially better throughput (maybe not enough for it to matter with standard Redis), or if you had so much data that you overflowed main memory and wanted to use one of the Redis forks with on-disk key storage.

But if you have enough memory for your data, use RDB if you want snapshots that can be easily backed up. If you need better incremental persistence, use AOF (sync every second, NOT every write). And for both of them, using spinning disks is fine.

 - Josiah

Jan

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matt Palmer]

On Wed, Jul 24, 2013 at 04:47:20AM -0700, Jan Algermissen wrote:
> My question is, which kinds of disks I should choose for Redis persistence?
> Will Redis benefit from SSDs as much as other DBs do? Or would it be ok to
> opt for slower, cheaper disks?

Disk speed should rarely[1] have an impact on the interactive performance of
Redis. The only time it will even have an impact on operation is during
startup, when Redis needs to read all the data off disk and load it into
memory. If you're using a decent filesystem, and depending on what quality
of disks you're using, reading large chunks of data off disk may actually be
*faster* off spinning disk than SSD, because orbital rust is *really* good
at large-chunk sequential I/O.

Persisting data back to disk with RDB, or rewriting an AOF, is done in a
separate process, which should[2] never get in the way of serving clients.
Thus, even with the slowest disks in the world, all that'll happen is the
work takes longer to complete (and you might end up consuming more memory
than you would have otherwise).

- Matt

[1] AOF with fsync on or everysec will cause performance degradation, but if
you're comfortable with a bit of data loss you could easily go fsync no and
take the risk. Also, if you ever swap, then slower disks makes for slower
swap, but if you're swapping, you're already about up to your chest in the
performance swamp, SSDs just mean the alligators are a bit less hungry.

[2] Modulo slow forks on AWS, extra data in memory causing swapping, etc.