What fascinates me most is not the protocol itself, but the potential to add a thin scripting layer (similar to Redis' EVAL or the newer modules API) to enable complex logic with atomic transactions and high QPS.
In the past, we relied heavily on using EVAL[SHA] with 200+ loc Lua scripts in order to implement high throughput, atomic transactions for realtime systems. We also used the JSON & Redis Query Language (previous named "full-text search") to build a more maintainable & strongly consistent system than using raw key-values and manually building secondary indexes.
We’ve since migrated to a native FoundationDB and SQLite hybrid setup, but this approach would have been really helpful for early-stage prototyping with a higher performance ceiling (thanks to FDB sharding) than a single-node Redis with AOF.
Related: Redis Cluster is a world of pain when handling clustering keys and cross-node queries and orchestration. DragonflyDB is chasing after the market of companies considering sharding Redis because of performance issues by providing better single-node performance. There's probably an alternative approach that could work by using an architecture like this.
One thing I wish redis had is the ability to extend itself beyond its memory capacity. So if I run out of memory, just move some stuff to disk. Or if I'm using persisted redis, just free up some memory.
Redis on Flash [1] is one of the key ways Redis gets people on their enterprise plan (esp before the SSPL relicense). I've spoken with their enterprise team before; it's ungodly expensive, even compared to AWS MemoryDB (wish I had the numbers on hand).
The awesome thing about Redis is that it's less a "cache" and more a set of fast network-shared, generic data structures. To have that then also be transactional and durable would be really handy sometimes.
What fascinates me most is not the protocol itself, but the potential to add a thin scripting layer (similar to Redis' EVAL or the newer modules API) to enable complex logic with atomic transactions and high QPS.
In the past, we relied heavily on using EVAL[SHA] with 200+ loc Lua scripts in order to implement high throughput, atomic transactions for realtime systems. We also used the JSON & Redis Query Language (previous named "full-text search") to build a more maintainable & strongly consistent system than using raw key-values and manually building secondary indexes.
We’ve since migrated to a native FoundationDB and SQLite hybrid setup, but this approach would have been really helpful for early-stage prototyping with a higher performance ceiling (thanks to FDB sharding) than a single-node Redis with AOF.
Related: Redis Cluster is a world of pain when handling clustering keys and cross-node queries and orchestration. DragonflyDB is chasing after the market of companies considering sharding Redis because of performance issues by providing better single-node performance. There's probably an alternative approach that could work by using an architecture like this.
One thing I wish redis had is the ability to extend itself beyond its memory capacity. So if I run out of memory, just move some stuff to disk. Or if I'm using persisted redis, just free up some memory.
Maybe this is it.
Redis on Flash [1] is one of the key ways Redis gets people on their enterprise plan (esp before the SSPL relicense). I've spoken with their enterprise team before; it's ungodly expensive, even compared to AWS MemoryDB (wish I had the numbers on hand).
[1] https://redis.io/resources/building-large-databases-redis-en...
The awesome thing about Redis is that it's less a "cache" and more a set of fast network-shared, generic data structures. To have that then also be transactional and durable would be really handy sometimes.
If only it wasn't Java.. but it looks very cool anyway.
Damnit this has been in my ideas list for a long time
Oh it’s in Java we’re good
There's a version written in Go, though clearly just a hobbyist project: https://forums.foundationdb.org/t/introducing-the-redis-prot...