support dual encoding in LTRIM

[redis.git] / doc / Comparisons.html

diff --git a/doc/Comparisons.html b/doc/Comparisons.html
index 25e6699efad9c0d46651cc40bec0b6ec6daa8a02..14c253a43e7de22c2ed098d6613df67919be6bc9 100644 (file)
--- a/doc/Comparisons.html
+++ b/doc/Comparisons.html
@@ -26,8 +26,8 @@
                 </div>
 
                 <div class="narrow">
                 </div>
 
                 <div class="narrow">

-                    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>
-<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="OrderedSets.html">OrderedSets</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>
+                    &iuml;&raquo;&iquest;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>
+<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>

 <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>
 <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>
 <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>
 <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>
 <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>
 <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>