4 ms·

This sort of makes me sad. Redis has strayed from what its original goal/purpose was. I’ve been using it since it was in beta. Simple, clear, fast. The compa

This sort of makes me sad. Redis has strayed from what its original goal/purpose was. I’ve been using it since it was in beta. Simple, clear, fast. The company I’m working for now keeps trying to add more and more functionality using Redis, that doesn’t belong in Redis, and then complains about Redis scaling issues.

ivolimmen 2y ago
This is what I see everywhere. Something is a success and then everybody starts using it wrong. Like Elastic search as database, people use it for searching and then start using it as primary database. Mostly pushed by management BTW not always the software engineer.
- darkstar_16 2y ago
  You'd be surprised how many engineers make these kinda decisions.
- addisonj 2y ago
  That does not match my experience. Engineers learn a new tool, that tool is successful in solving a problem. Whether it is recency bias, incorrect pattern matching, or simply laziness, the tool is used again but with reduced success. Repeat that process a few more times (sometimes in different organizations) and now the tool is way outside the domain, ill-fit to the task at hand, and a huge pain. That often happens with engineers who pushed that tool getting promoted a few times and building their career on said tool, which is where I have seen this being pushed down, but I think it is important that in most cases are still engineers
- MortyWaves 2y ago
  I worked somewhere where a team, that can only be described as a clown team, decided to use Elastic as the “database” for the entire login/auth microservice, that other teams depended on. It was so slow and terrible.
reissbaker 2y ago
What do you think doesn't belong in Redis? I've always viewed Redis as basically "generic datastructures in a database" — as opposed to say, Memcached, which is a very simple in-memory-only key/value store (that has always been much faster than Redis). It's hard for me to point to specific features and say: that doesn't belong in Redis! Because Redis has generally felt (to me) like a grab bag of data structures + algorithms, that are meant to be fairly low-latency but not maximally so, where your dataset has to fit in RAM (but is regularly flushed to disk so you avoid cold start issues).
- lucianbr 2y ago
  Generic data structures in memory, grab bag of structures and algorithms... sounds more like a programming language or library than an external tool. C++ STL for example would fit these descriptions perfectly. Doing everything is a recipe for bloat. In a database, in a distributed cache, in a programming language, in anything.
  - bittermandel 2y ago
    Don't think the argument is "everything", just the things that can be done within the protocol. There's really not much bloat being added considering the "limitations": https://redis.io/docs/latest/develop/reference/protocol-spec https://redis.io/docs/latest/develop/reference/protocol-spec I think it wouldn't be unfair to compare it to Golang, which has in my opinion a quite unbloated stdlib which allows you do almost anything without external libraries!
- ChocolateGod 2y ago
  If your application can't survive the Redis server being wiped without issues, you're using Redis wrong.
  - reissbaker 2y ago
    Why not just use Memcached, then? Memcached is much better as an ephemeral cache than Redis — Redis is single-threaded. The point of Redis is all of its extra features: if you're limiting yourself to Memcached-style usage, IMO you're using Redis wrong and should just use Memcached.
cbg0 2y ago
> The company I’m working for now keeps trying to add more and more functionality using Redis, that doesn’t belong in Redis, and then complains about Redis scaling issues. This doesn't sound like a Redis issue, you're just not using the right tool for the job.
- marklubi 2y ago
  Totally agree. It's definitely not the right tool for what they're doing, but some of the engineers don't seem to know better, or understand, the point of being able to run scripts on Redis. Lots of Lua scripting and calculations being done on Redis that has nothing to do with the data that's local to Redis. It's infuriating.
antirez 2y ago
I may be biased, but I think this announcement is actually a very good sign for Redis, since it shows that the focus is back to the community edition, that is, the source tree you can just download from GitHub (and I believe this is an effect of the license change: it is possible for the company to work on the public tree without competitors to cut&paste the code in SAAS services). There are few things that are interesting for me about this discussion related to complexity and use cases outside the scope. 1. You can still download Redis and type "make" and it builds without dependencies whatsoever like in the past, and that's it. 2. Then you run it and use just the subset of Redis that you like. The additional features are not imposed to the user, nor they impact the rest of the user experience. This is, actually, a lot like how it used to be when I handled the project: I added Pub/Sub, Lua scripting, geo indexing, streams, all stuff that, at first, people felt like they were out of scope, and yet many shown to be among the best features. Now it is perfectly clear that Pub/Sub belonged to Redis very well, for instance. 3. This release has improvements to the foundations, in terms of latency, for example. This means that even if you just use your small subset, you can benefit from the continued developments. Sometimes systems take the bad path of becoming less efficient over time. So I understand the sentiment but I still see Redis remaining quite lean, at least for the version 8 that I just downloaded and I am inspecting right now.

ivolimmen 2y ago

This is what I see everywhere. Something is a success and then everybody starts using it wrong. Like Elastic search as database, people use it for searching and then start using it as primary database. Mostly pushed by management BTW not always the software engineer.

darkstar_16 2y ago
You'd be surprised how many engineers make these kinda decisions.
addisonj 2y ago
That does not match my experience. Engineers learn a new tool, that tool is successful in solving a problem. Whether it is recency bias, incorrect pattern matching, or simply laziness, the tool is used again but with reduced success. Repeat that process a few more times (sometimes in different organizations) and now the tool is way outside the domain, ill-fit to the task at hand, and a huge pain. That often happens with engineers who pushed that tool getting promoted a few times and building their career on said tool, which is where I have seen this being pushed down, but I think it is important that in most cases are still engineers
MortyWaves 2y ago
I worked somewhere where a team, that can only be described as a clown team, decided to use Elastic as the “database” for the entire login/auth microservice, that other teams depended on. It was so slow and terrible.

reissbaker 2y ago

What do you think doesn't belong in Redis? I've always viewed Redis as basically "generic datastructures in a database" — as opposed to say, Memcached, which is a very simple in-memory-only key/value store (that has always been much faster than Redis). It's hard for me to point to specific features and say: that doesn't belong in Redis! Because Redis has generally felt (to me) like a grab bag of data structures + algorithms, that are meant to be fairly low-latency but not maximally so, where your dataset has to fit in RAM (but is regularly flushed to disk so you avoid cold start issues).

lucianbr 2y ago
Generic data structures in memory, grab bag of structures and algorithms... sounds more like a programming language or library than an external tool. C++ STL for example would fit these descriptions perfectly. Doing everything is a recipe for bloat. In a database, in a distributed cache, in a programming language, in anything.
- bittermandel 2y ago
  Don't think the argument is "everything", just the things that can be done within the protocol. There's really not much bloat being added considering the "limitations": https://redis.io/docs/latest/develop/reference/protocol-spec https://redis.io/docs/latest/develop/reference/protocol-spec I think it wouldn't be unfair to compare it to Golang, which has in my opinion a quite unbloated stdlib which allows you do almost anything without external libraries!
ChocolateGod 2y ago
If your application can't survive the Redis server being wiped without issues, you're using Redis wrong.
- reissbaker 2y ago
  Why not just use Memcached, then? Memcached is much better as an ephemeral cache than Redis — Redis is single-threaded. The point of Redis is all of its extra features: if you're limiting yourself to Memcached-style usage, IMO you're using Redis wrong and should just use Memcached.

cbg0 2y ago

> The company I’m working for now keeps trying to add more and more functionality using Redis, that doesn’t belong in Redis, and then complains about Redis scaling issues. This doesn't sound like a Redis issue, you're just not using the right tool for the job.

marklubi 2y ago
Totally agree. It's definitely not the right tool for what they're doing, but some of the engineers don't seem to know better, or understand, the point of being able to run scripts on Redis. Lots of Lua scripting and calculations being done on Redis that has nothing to do with the data that's local to Redis. It's infuriating.

antirez 2y ago

I may be biased, but I think this announcement is actually a very good sign for Redis, since it shows that the focus is back to the community edition, that is, the source tree you can just download from GitHub (and I believe this is an effect of the license change: it is possible for the company to work on the public tree without competitors to cut&paste the code in SAAS services). There are few things that are interesting for me about this discussion related to complexity and use cases outside the scope. 1. You can still download Redis and type "make" and it builds without dependencies whatsoever like in the past, and that's it. 2. Then you run it and use just the subset of Redis that you like. The additional features are not imposed to the user, nor they impact the rest of the user experience. This is, actually, a lot like how it used to be when I handled the project: I added Pub/Sub, Lua scripting, geo indexing, streams, all stuff that, at first, people felt like they were out of scope, and yet many shown to be among the best features. Now it is perfectly clear that Pub/Sub belonged to Redis very well, for instance. 3. This release has improvements to the foundations, in terms of latency, for example. This means that even if you just use your small subset, you can benefit from the continued developments. Sometimes systems take the bad path of becoming less efficient over time. So I understand the sentiment but I still see Redis remaining quite lean, at least for the version 8 that I just downloaded and I am inspecting right now.