| | 1 | |
| | 2 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
| | 3 | <html> |
| | 4 | <head> |
| | 5 | <link type="text/css" rel="stylesheet" href="style.css" /> |
| | 6 | </head> |
| | 7 | <body> |
| | 8 | <div id="page"> |
| | 9 | |
| | 10 | <div id='header'> |
| | 11 | <a href="index.html"> |
| | 12 | <img style="border:none" alt="Redis Documentation" src="redis.png"> |
| | 13 | </a> |
| | 14 | </div> |
| | 15 | |
| | 16 | <div id="pagecontent"> |
| | 17 | <div class="index"> |
| | 18 | <!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. --> |
| | 19 | <b>Comparisons: Contents</b><br> <a href="#Memcached">Memcached</a><br> <a href="#Tokyo Cabinet / Toyo Tyrant">Tokyo Cabinet / Toyo Tyrant</a> |
| | 20 | </div> |
| | 21 | |
| | 22 | <h1 class="wikiname">Comparisons</h1> |
| | 23 | |
| | 24 | <div class="summary"> |
| | 25 | |
| | 26 | </div> |
| | 27 | |
| | 28 | <div class="narrow"> |
| | 29 | if your are asking yourself how is Redis different fom other key-value stores here you will find it compared to some of the most popular contendors (all great software) in this category. <h2><a name="Memcached">Memcached</a></h2><ul><li> Memcached is not persistent, it just holds everything in memory without saving since its main goal is to be used as a cache, while Redis is <a href="Persistence.html">persistent</a>.</li></ul> |
| | 30 | <ul><li> Like memcached Redis uses a key-value model, but while keys can just be strings, values in Redis can be <a href="Lists.html">Lists</a>, <a href="Sets.html">Sets</a> or <a href="SortedSets.html">SortedSets</a> and complex operations like intersections, set/get n-th element of lists, pop/push of elements, can be performed against sets and lists.</li></ul> |
| | 31 | <h2><a name="Tokyo Cabinet / Toyo Tyrant">Tokyo Cabinet / Toyo Tyrant</a></h2>Redis and Tokyo Cabinet can be used for the same applications, but actually they are <i>very different</i> beasts. If you read Twitter messages of people involved in scalable things both products are reported to work well, but surely there are times where one or the other can be the best choice.<br/><br/><ul><li> Tokyo Cabinet writes synchronously on disk, Redis takes the whole dataset on memory and writes on disk asynchronously. Tokyo Cabinet is safer and probably a better idea if your dataset is going to be bigger than RAM, but Redis is faster (note that Redis supports master-slave replication that is trivial to setup, so you are safe anyway if you want a setup where data can't be lost even after a disaster). </li></ul> |
| | 32 | <ul><li> Redis supports higher level operations and data structures. Tokyo Cabinet supports a kind of database that is able to organize data into rows with named fields (in a way very similar to Berkeley DB) but can't do things like server side List and Set operations Redis is able to do: pushing or popping from Lists in an atomic way, in O(1) time complexity, server side Set intersections, Sorting of schema free data in complex ways (By the way TC supports sorting in the table-based database format). Redis on the other hand does not support the abstraction of tables with fields, the idea is that you can build this stuff in software easily if you really need a table-alike approach. </li></ul> |
| | 33 | <ul><li> Tokyo Cabinet does not implement a networking layer. You have to use a networking layer called Tokyo Tyrant that interfaces to Tokyo Cabinet so you can talk to Tokyo Cabinet in a client-server fashion. In Redis the networking support is built-in inside the server, and is basically the only interface between the external world and the dataset. </li></ul> |
| | 34 | <ul><li> Redis is reported to be much faster, especially if you plan to access Tokyo Cabinet via Tokyo Tyrant. Here I can only say that with Redis you can expect 100,000 operations/seconds with a normal Linux box and 50 concurrent clients. You should test Redis, Tokyo, and the other alternatives with your specific work load to get a feeling about performances for your application. </li></ul> |
| | 35 | <ul><li> Redis is not an on-disk DB engine like Tokyo: the latter can be used as a fast DB engine in your C project without the networking overhead just linking to the library. Still in many scalable applications you need multiple servers talking with multiple clients, so the client-server model is almost always needed, this is why in Redis this is built-in. </li></ul> |
| | 36 | </div> |
| | 37 | |
| | 38 | </div> |
| | 39 | </div> |
| | 40 | </body> |
| | 41 | </html> |
| | 42 | |
projects / redis.git / blame_incremental