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.
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).
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.
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!
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.
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
> 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.
This was available for a long time as an extension as part of Redis Stack, but most hosted Redis providers don't make extensions available (I'm assuming due to nuances in Redis's not-quite-open licensing).
If cloud providers which include Redis are now going to include this, it opens up a lot of potential for my use case.
When do you want to store your time series data in Redis and not a database like TimescaleDB or Clickhouse which is optimized for storage on disk and analytics queries?
No, like yes they pissed a lot of people off and some people did migrate. But a large majority of "enterprise" customers didn't, it's just too much effort for a service you are paying for anyway.
I dunno, MongoDB is as if it's gone, due to a license change in 2018. So asking if redis should be thought of the same as MongoDB is a legitimate question.
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.
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).
If your application can't survive the Redis server being wiped without issues, you're using Redis wrong.
Rarely seen Redis viewed as a database, even if that has been their push for the last few years.
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.
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
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!
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.
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
You'd be surprised how many engineers make these kinda decisions.
> 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.
The inclusion of Redis timeseries is huge!
This was available for a long time as an extension as part of Redis Stack, but most hosted Redis providers don't make extensions available (I'm assuming due to nuances in Redis's not-quite-open licensing).
If cloud providers which include Redis are now going to include this, it opens up a lot of potential for my use case.
When do you want to store your time series data in Redis and not a database like TimescaleDB or Clickhouse which is optimized for storage on disk and analytics queries?
Likely when it's small enough to keep in RAM and you want to do some sort of on-the fly aggregation/correlation.
Then you can usually just store it in the memory of your application. No need to complicate your stack by running another service.
Isn't this just RocksDB?
I thought people stopped using Redis and moved on to a fork because of licensing issues. Is this true?
No, like yes they pissed a lot of people off and some people did migrate. But a large majority of "enterprise" customers didn't, it's just too much effort for a service you are paying for anyway.
I dunno, MongoDB is as if it's gone, due to a license change in 2018. So asking if redis should be thought of the same as MongoDB is a legitimate question.