I started redix with redis protocol to make use of redis ecosystem out there. There is also a plan to make HA a native feature in redix with no external requirements, so I can keep redix a standalone DB server.
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?
So, mysql is a frontend to InnoDB?
Cockroach is a frontend to RocksDB?
Note:
Redix has a pluggable storage engine, the current engine is "badgerdb", the next is "bolt" and it is already integrated and I'll release it soon.
I would put it the other way around: InnoDB is a backend for MySQL. But an SQL database is far more complicated than a key-value store, and has a lot of "middle end" between the "talk to the client" front end and the "store stuff on disk" back end.
I'm not saying that RedixDB isn't interesting -- having a network front-end to Badger seems like it would extremely useful for most people who want to use Badger. It's just that I spent a while digging through the code trying to figure out where the back end was and what data structures you were using, only to discover that you didn't have a backend (or rather, you're using a pre-existing one).
Second that. It would help if you included on the website some info about the technical implementation. That would help instill confidence in the solution.
There is also Facebook's MyRocks which is MySQL frontend with RocksDB backend. It has lower write amplification than InnoDB, which is the main reason why it was created.
