Redis TODO and Roadmap
+----------------------
-VERSION 2.0 TODO
+VERSION 2.2 TODO (Optimizations and latency)
+============================================
+
+* Lower the CPU usage.
+* Lower the RAM usage everywhere possible.
+* Specially encoded Sets (like Hashes).
+* Implement an UDP interface for low-latency operations.
+* What about a special coding that is about storing the "rdb" serialized format instead of the actual value? This can be used when we have LRU in order to super-compress data into memory, for data not accessed frequetly. It's a VM-alike strategy but fully in memory, may reduce the space to hold some dataset in an impressive way. Trivial to implement.
+* Another idea: LRU does not need to be super precise right? Maybe it's a good idea to just put into the skiplist implementing the LRU just the pointer to the key without evne incr/decr business, nor the need to remove the pointer when the key is deleted. There is to think more about that.
+
+VERSION 2.x TODO
================
* BRPOPLPUSH
-* List ops like L/RPUSH L/RPOP should return the new list length.
* Save dataset / fsync() on SIGTERM
-* MULTI/EXEC should support the "EXEC FSYNC" form?
-* BLPOP & C. tests (write a non blocking Tcl client as first step)
-* Once ZRANK is implemented, change the implementation of ZCOUNT to use the augmented skiplist in order to be much faster.
-* Write doc for ZCOUNT, and for open / closed intervals of sorted sets range operations.
+* Change the implementation of ZCOUNT to use the augmented skiplist in order to be much faster.
-Virtual Memory sub-TODO:
-* Check if the page selection algorithm is working well
-* Divide swappability of objects by refcount
+Virtual Memory optimizations:
* Use multiple open FDs against the VM file, one for thread.
-* vm-min-age <seconds> option
-* Make sure objects loaded from the VM are specially encoded when possible.
-* Check what happens performance-wise if instead to create threads again and again the same threads are reused forever. Note: this requires a way to disable this clients in the child, but waiting for empty new jobs queue can be enough.
-* Sets of integers are slow to load, for a number of reasons. Fix it. (use slow_sets.rdb file for debugging). (p.s. this was now partially fixed).
-* On EXEC try to block the client until relevant keys are loaded.
-
-* Hashes (GET/SET/DEL/INCRBY/EXISTS/FIELDS/LEN/MSET/MGET). Special encoding for hashes with less than N elements.
-* Write documentation for APPEND
+* Check what happens performance-wise if instead of creating threads again and again the same threads are reused forever. Note: this requires a way to disable this clients in the child, but waiting for empty new jobs queue can be enough.
* Implement LEN, PEEK, POKE, SETBIT, GETBIT
-VERSION 2.2 TODO (Fault tolerant sharding)
-===========================================
-
-* Redis-cluster, a fast intermediate layer (proxy) that implements consistent hashing and fault tollerant nodes handling.
-
-Interesting readings about this:
-
- - http://ayende.com/Blog/archive/2009/04/06/designing-rhino-dht-a-fault-tolerant-dynamically-distributed-hash.aspx
-
-VERSION 2.4 TODO (Optimizations and latency)
-============================================
-
-* Lower the CPU usage.
-* Lower the RAM usage everywhere possible.
-* Use epool and alike to rewrite ae.c for Linux and other platforms suppporting fater-than-select() mutiplexing APIs.
-* Implement an UDP interface for low-latency GET/SET operations.
-
OTHER IMPORTANT THINGS THAT WILL BE ADDED BUT I'M NOT SURE WHEN
===============================================================
* Pattern-matching replication.
* Add an option to relax the delete-expiring-keys-on-write semantic *denying* replication and AOF when this is on? Can be handy sometimes, when using Redis for non persistent state, but can create problems. For instance should rename and move also "move" the timeouts? How does this affect other commands?
* Multiple BY in SORT.
+
+KNOWN BUGS
+==========
+
+* LRANGE and other commands are using 32 bit integers for ranges, and overflows are not detected. So LRANGE mylist 0 23498204823094823904823904 will have random effects.
projects / redis.git / blobdiff