Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis 4.0

groups.google.com

Post reply on HN
Print view View original

111–120 of 184 posts

Re: Redis 4.0

#111

Post by notyourday »

numbsafari wrote: post #5

I really wish Redis wouldn't use the "master/slave" terminology. Primary/replica or even Master/replica are better terms. I know I'll probably get flamed for saying this, but it's a pox on a project that I otherwise very much love.

It is rather sad that most discussed part of the announcement of a pretty amazing piece of software that probably had multi-billion dollar effect on the computing is concentrated on the perceived offensive usage of the words "master" and "slave" by people who never experienced it or had contacts with anyone who had experienced it.

Re: Redis 4.0

#112

Post by FLUX-YOU »

ihsw2 wrote: post #17
StevePerkins wrote: post #13

"9) Active memory defragmentation. Redis is able to defragment the memory while online..." I'm so amazed that this is a thing.

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…

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

Is Redis managing this itself using simple calls to Jemalloc, or is Jemalloc doing it on its own because it has better algorithms than the OS?

Re: Redis 4.0

#113

Post by schneems »

Mouse47 wrote: post #108
schneems wrote: post #106

Earlier quoted context omitted.

I had it in there to emphasize how un-technically incorrect it is. Apparently people saw the word "offensive" and they didn't read the rest, so I took it out to add clarity. I forgot that HN doesn't provide a diff of edits, so went back and added a note in the comment that it was edited. Edit: Edited this note to mention I updated the previous note with an edit note.

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?

Re: Redis 4.0

#114

Post by scotu »

juliensab wrote: post #103
zedpm wrote: post #53

Earlier 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 dependency to take care of, I presume

Re: Redis 4.0

#115

Post by user5994461 »

xxs wrote: post #90
jackmott wrote: post #59

Earlier quoted context omitted.

It is one of those things where people say "Java can be faster than C/C++ because it can compact memory" and the C/C++ lady says "here, hold my beer"

To be fair only a compacting GC can do that

And the Java GC is NUMA aware. The C compiler is not.

Re: Redis 4.0

#116

Post by ixtli »

joshlemer wrote: post #68
RUG3Y wrote: post #66

Use of the term "man page" is misogynistic as well, IMO and should be changed.

Is this satire? "man" here is short for "manual".

it's an attempt to mock an old discussion about the use of "SLAVE" / "MASTER" terminology.

These threads fill with reactionaries who think marginalized people are just complaining about nothing or by reductionist leftists who think so-called "identity politics" detract from class struggle.

Edit: It's worth noting that antirez has, as is usual for him, dealt with this issue wonderfully by making a call without downplaying the importance of the problem.

Re: Redis 4.0

#118

Post by dijit »

jimktrains2 wrote: post #94
butabah wrote: post #92

Earlier quoted context omitted.

'Bash' is too violent as well. We should rename it to 'hug'.

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

Re: Redis 4.0

#119

Post by actuator »

Hates_ wrote: post #58

Anyone know when we might see this on AWS (Elasticache)?

I don't like the Elasticache offering of Redis at all. It is severely limited if you are not just using Redis as a cache. There is no way to scale up/down the size of the node without putting it down(this is possible if you run it on EC2 as well as you have access to commands related to replication that are not allowed on Elasticache). We have had master restarting instead of failing over to slave and in the process coming back with no data. Even the snapshot is only taken once in a day.

Re: Redis 4.0

#120

Post by iagooar »

xxs wrote: post #84
ihsw2 wrote: post #17

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

Call me a slowpoke, but I wasn't aware that Redis was single core!
Post reply on HN