https://blog.dgraph.io/post/badger/

Titan: https://medium.com/@shafreeck/titan-a-distributed-redis-prot...

Tidis: https://github.com/yongman/tidis

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

I disagree that Badger plays such a big part in this project that it needs to be included in the title. Badger is only the storage component and it can be easily swapped out for an alternative.

Is the DB strongly consistent?

Are there performance gains compared to Redis due to multi-core?

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.

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?

- Backup: Copy the storage directory as it. - Restore: stop the server, move the previously backup data directly to redix storage.

It is very simple, but I may add commands that will help you with that operation.

Is there a suggested way to get a list of keys based on wildcard? I note that the infamous KEYS command is not listed as supported (and fair enough). Is there a suitable non-Redis backend command that can get this info?