原文： http://*.com/questions/7888880/what-is-redis-and-what-do-i-use-it-for
Redis = Remote Dictionary Service
TL;DR: If you can map a use case to Redis and discover you aren't at risk of running out of RAM by using Redis there is a good chance you should probably use Redis.
It's a "NoSQL" key-value data store. More precisely, it is a data structure server.
Not like MongoDB (which is a disk-based document store), though MongoDB could be used for similar key/value use cases.
The closest analog is probably to think of Redis as Memcached, but with built-in persistence (snapshotting or journaling to disk) and more datatypes.
Those two additions may seem pretty minor, but they are what make Redis pretty incredible. Persistence to disk means you can use Redis as a real database instead of just a volatile cache. The data won't disappear when you restart, like with memcached.
The additional data types are probably even more important. Key
values can be simple strings, like you'll find in memcached, but they
can also be more complex types like Hashes, Lists (ordered collection,
makes a great queue), Sets (unordered collection of non-repeating
values), or Sorted Sets (ordered/ranked collection of non-repeating
values).
This is only the tip of the Redis iceberg, as there are other
powerful features like built-in pub/sub, transactions (with optimistic
locking), and Lua scripting.
The entire data set, like memcached, is stored in-memory so it is
extremely fast (like memcached)... often even faster than memcached.
Redis had virtual memory, where rarely used values would be swapped out
to disk, so only the keys had to fit into memory, but this has been
deprecated. Going forward the use cases for Redis are those where its
possible (and desirable) for the entire data set to fit into memory.
Redis is a fantastic choice if you want a highly scalable data store
shared by multiple processes, multiple applications, or multiple
servers. As just an inter-process communication mechanism it is tough to
beat. The fact that you can communicate cross-platform, cross-server,
or cross-application just as easily makes it a pretty great choice for
many many use cases. Its speed also makes it great as a caching layer.
Update 4/1/2015: Redis 3.0 (stable) was released today. This version of Redis brings cluster support, which makes it much easier to scale Redis.
@acidzombie24 Its possible you could use Redis in-place-of MySQL but it really depends on the use case. If your data set could grow to 20GB or you need to use some business analytic tools, you need to make heavy use of joins, etc. then it might not make sense. It's really hard to make a blanket statement except to say that there are certainly cases where Redis would be appropriate in place of MySQL.
@KO. Just like Redis offers features which memcached doesn't, RDBMS offers many many features which Redis does not. Redis should be FAR faster than any RDBMS, but it also can't do as much. If you can map your RDBMS use case to Redis then it might be worth taking a look, but if you can't don't force it. Best tool for the job and all that. A No-SQL store that has a better chance of replacing your RDBMS is MongoDB, but even that needs to be evaluated carefully and you should go with the best fit, which may be an RDBMS
A very thought-provoking thread here. Being an old dog, it was quite a thunder-clap when I realized the reason most data is now persisted to DBs is simply because a whole generation of programmers have grown up with cheap, ubiquitous DBs and they don't KNOW any other way of persisting data. No clue what qsort() & bsearch() are capable of for example. RE: joins with Redix, if people knew how simple it is to do joins in memory they'd be shocked. The data value you join on simply becomes a token that is replaced by the data the FK indexes. It's ~ string replacement problem
DBs are wonderful, and very flexible, but horribly expensive in terms of resources, and very slow. Slow, not because the internals aren't fast, but because they have a large fixed cost which is realized as a lot of latency. As an example, my employer has an ENUM server with 45 ms latency - good by industry standards. I am writing a CPS throttle with .067 microsecond latency. Not even in the same ballpark. Likewise, bsearch() against a pointer array, the result of a ptr qsort(), and fetching data from SSDs, is thousands of times faster than any DB - even in-memory ones like ours.
With respect to Redix only holding indexes in memory, with SSDs, I hope this option is still available. The latest generation of SSD focused RAIDs by Adaptec (ASR-8885 RAID) and LSI perform at 12Gbps - spectacular for 256 -2k byte random I/Os a data structure server would be fetching. The reason so many alternative to SQL, like NoSQL, are showing up, is because SQL is the problem. Too much parsing, too much data conversion, metadata driving the very internals of your database, and too much conversion again on the backend. With data structures you have the answer before the SQL gets to the NIC
|
109 down vote
|
What it can be use for? Few examples from http://highscalability.com/blog/2011/7/6/11-common-web-use-cases-solved-in-redis.html:
|
Yet another one: A very simple, but useful tool for programmers. A build-counter server. Eg. your application version may be 1.2.7 (build #473). It's very easy to add a new build number for your project, and your build-script can easily request a new (unique) number.
Oh, and it's awfully easy to use this for making two scripts that run on two different platforms communicate with eachother. For instance one of those Cortex-A based TV-boxes can send data back and forth to my desktop computer - so I'm using it like a FIFO.