Redis Cluster connecting to nodes via DNS instead of IP would vastly simplify deployment on K8s.
How do you solve this problem? Can you use headless K8S services for that?
Redis 4.0
121–130 of 184 posts
Re: Redis 4.0
#122Earlier quoted context omitted.
Memory fragmentation is largely related to the allocator you're using (ie: glibc malloc, jemalloc, tcmalloc) and previously it was up to the OS to manage this (ie: freeing up unused memory). Now with active memory defragmentation things are a bit more pleasant, specifically with high delete load actually freeing up unused memory in a timely manner without impacting performance too much. Previously, to fully recover u…
120GB on a single thread, yeah. Redis has been abused for quite some time but 120GB is way out of reasonable reach for current CPU arch if you use a single core only (even if you switch off hyper threading)
just randomly curious here - why? hash time gets absurd?
Re: Redis 4.0
#123Earlier quoted context omitted.
I'm fine with an argument based solely on its technical merits. But then you're going to lose out to things like backwards compatibility and the sheer force of momentum - everyone understands these terms. There are probably hundreds of ill-fitting terms in the tech world that now mean what we mean them to mean (lol). This one receives blowback not because it's technically unsound (which it might be), but because some…
For most projects it seems like a pretty easy change. You could add new keywords, alias the old methods/commands to them. You don't even have to deprecate them, just make the docs point to the newer terminology. What is easier having to have this conversation EVERY time the term gets used for the rest of eternity, or making the change once and being done with it?
>What is easier having to have this conversation EVERY time the term gets used for the rest of eternity, or making the change once and being done with it?
That's not very compelling. Just because certain people make a lot of noise doesn't mean we have to do what they want us to do.
>For most projects it seems like a pretty easy change. You could add new keywords, alias the old methods/commands to them. You don't even have to deprecate them, just make the docs point to the newer terminology.
...for every project that uses these terms across the entire industry. You know what's easier? Not making the change. There are two arguments:
1. The technical gain by changing these terms outweighs the drawbacks (legacy code, consensus/convention, etc.). I doubt there's much to gain here.
2. The technical aspect doesn't matter since it's offensive. I've already addressed this.
Re: Redis 4.0
#124Any news on when this will be on Azure Redis Cache ?
Re: Redis 4.0
#125Earlier quoted context omitted.
`bash` is also pretty evangelical ;) On a serious note, I've never actually understood where the term "hung" comes from in computing. Why is the process "hung" and not simply "stalled" or something else.
The real reason is because most of the concepts surrounding multi-process computing come from the telephone industry. The modern interpretation is that system operators need to feel like they have a big penis.
> The real reason is because most of the concepts surrounding multi-process computing come from the telephone industry.
ah
> The modern interpretation is that system operators need to feel like they have a big penis.
I actually didn't even think of it in that regard. I regard hung as in something that is hanging (dangling) from something else.
Re: Redis 4.0
#126It seems it even supports nearest search for lon/lat points by default... Quite nice since most RDMS don't even support it be default. Although I'm curious to know what algorithm it uses for nearest search, it doesn't talk about it in the doc. I don't really understand what redis should not be used for, I guess it's not for complex queries? Conventional RDMS really seem to belong to the hard disk drive age. So the di…
I adore redis, I use it for tons of stuff, but I still like to keep my single-point-of-truth for critical data in an ACID, transactional relational database.
I frequently denormalize that data INTO redis so I can answer certain classes of queries quickly. I'm also very happy with redis for caching, rate limiting, inter-process-communication, distributed locking and tons of other fun use-cases.
Re: Redis 4.0
#127Earlier quoted context omitted.
Antirez has talked about moving Disque to a Redis module, which should solve that problem neatly. I'd love to drop our RabbitMQ dependency and move queueing into Redis.
Why?
One less service to manage, plus RabbitMQ's options for dealing with network partitions are all terrible. If you want to run a RabbitMQ cluster, you don't have any option that avoids data loss.
Re: Redis 4.0
#128Earlier quoted context omitted.
The context of how I use the word "fuck" dramatically changes what it means. Whether you're offended by the word is entirely up to the listener as well.
Do you understand the phrase "technical correctness" or is that open to interpretation as well?
In this case, the "technical correctness" of your argument is up for debate.
Re: Redis 4.0
#129Redis Cluster connecting to nodes via DNS instead of IP would vastly simplify deployment on K8s.
How do you solve this problem? Can you use headless K8S services for that?
You can use a StatefulSet which gives a fixed hostname per pod. Then you can have a sidecar pod that monitors the cluster, discovers the IPs of all pods, and uses redis_trib to create and maintain the cluster. It's a hassle to make it robust though.
Re: Redis 4.0
#130Earlier quoted context omitted.
120GB on a single thread, yeah. Redis has been abused for quite some time but 120GB is way out of reasonable reach for current CPU arch if you use a single core only (even if you switch off hyper threading)
Call me a slowpoke, but I wasn't aware that Redis was single core!
It makes it great for storing distributed locks, semaphores, and thanks to Lua scripting it can store/update cache invalidation lists - eg https://github.com/Suor/django-cacheops