1- Multi: yes, I'm planning to support it in the next releases.
2- Consistency: Yep, also there will be test cases soon.
3- Performance: at first, nothing will be faster than RAM, so don't expect that an on-disk store is faster than an in-memory store, but that doesn't mean that on-disk stores are very slow, I selected two storage engines called bolt and badger, badger is the default because it follows RocksDB design and rocksdb. for redix server compared to redis server, redix doesn't use an eventloop, but each connection runs in its own light-weight thread, so there no possibilities that you run a command and block the server itself, another note is: the underlying implementation of internal datatypes makes redix faster in some cases especially when you try to load large datasets, you will notice that redix has very low response time than redis, that means, in a highly loaded environment you find redix performance better than redis especially with the coming version because redix will lower the memory usage more and more.
Every day I improve it more and more, and thanks for the issues creator on the repo, they're helping me too in organizing my thoughts.
> for redix server compared to redis server, redix doesn't use an eventloop, but each connection runs in its own light-weight thread, so there no possibilities that you run a command and block the server itself,
How does this jive with the “happens-before” transactional guarantees of Redis? Since it’s single threaded it’s easy to reason about the order of operations. Once an operation begins subsequent ones can assume the full impact of the changes.
In Redix, if a “big write” happens to a key in one connection/thread, what does a different reader see for the value of that key if they issue a read after the write begins but before it completes? The old value or a wait followed by the new value?
2- Consistency: Yep, also there will be test cases soon. 3- Performance: at first, nothing will be faster than RAM, so don't expect that an on-disk store is faster than an in-memory store, but that doesn't mean that on-disk stores are very slow, I selected two storage engines called bolt and badger, badger is the default because it follows RocksDB design and rocksdb. for redix server compared to redis server, redix doesn't use an eventloop, but each connection runs in its own light-weight thread, so there no possibilities that you run a command and block the server itself, another note is: the underlying implementation of internal datatypes makes redix faster in some cases especially when you try to load large datasets, you will notice that redix has very low response time than redis, that means, in a highly loaded environment you find redix performance better than redis especially with the coming version because redix will lower the memory usage more and more. Every day I improve it more and more, and thanks for the issues creator on the repo, they're helping me too in organizing my thoughts.