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

The End of the Redis Adventure

antirez.com

Post reply on HN
Print view View original

181–190 of 308 posts

Re: The End of the Redis Adventure

#181

Post by normalnorm »

1_player wrote: post #130
cat199 wrote: post #124

Earlier quoted context omitted.

this is IMHO no different the real world - a 'good' despot/monarch/etc can be a good leader, but this is highly dependent on the situation (read: leader), and leadership transition process is always a risky one. Democracies/Republics work well so long as the community has a generally shared vision, but can be hampered when there is too much dissent, but generally avoid the succession problem

OT: Indeed, a good dictatorship is better than any democracy, but it doesn't work in practice because for every Augustus there's 10 Caligula. Democracy is just the least worse political system.

Democracy is more of a principle (is just means that legitimacy of government comes from some aggregate choice of the governed), than a political system. Radically different political systems can be classified as democracies, all the way from direct vote (self-organized communes, also Switzerland) to complex federations with layers of indirect representation, such as the USA or the EU -- with a lot of other interesting alternatives such as sortition.

Re: The End of the Redis Adventure

#182

Post by neop1x »

wokwokwok wrote: post #35
JamesSwift wrote: post #21

Dang. I say this frequently both online and when discussing system design with newer devs, but will repeat here: of all the production issues I've debugged, the culprit has has never been redis. In fact, redis has been a critical piece of achieving cost-effective scaling. It is one of only two pieces of software (along with postgres) that I blindly recommend without any caveats. From following along here and on your…

Redis is simple. Good. Has a nice api. Has good libraries. Single threadsed. Extremely hard to scale. Impossibly difficult to cluster in containers because it uses hard coded ips to address nodes. Performs poorly with large payloads. Doesn't run on windows properly. Is extremely expensive as a hosted service (orders of magnitude in some cases, eg. azure). You'll love it until you don't. The scaling and clustering sto…

I think you are using it wrong. It is not meant to be run in a K8S cluster woth dynamic IPs in multiple instances. You are supposed to deploy VM mesh of fixed IPs as database store. Moreover, it is design-dependent. You can live with just multiple master-slave pairs and have your data implicitly sharded by something, e.g. by user country or continent. It's sad that some people still think "perfect db" exists: partition-tolerant, high-available, durable, horizontal-scalable, low-latency, acid-compiant, open-source database dosn't exist and never will (see the CAP theorem, see the broken guarantees found by Jepsen[1]). Live with it and design your architecture appropriately.

[1] https://jepsen.io/

Re: The End of the Redis Adventure

#184

Post by WJW »

antirez wrote: post #78

Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.

Thank you for Redis and some of the other stuff too! I had great fun reading through the small string compression code and learned a lot! Hope you have many decades of happy hacking ahead of you.

Re: The End of the Redis Adventure

#185

Post by jffhn »

eric_b wrote: post #50

So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively. T…

>Saying no is one of the most important jobs of a project maintainer. It's a thankless task that upsets a lot of people. But it's critical for a project to stay successful and achieve the leader's vision.

Reminds me of Brian Goetz: "We have to say no to almost anything. If we didn't, things would pretty quickly degenerate to the point where the system collapses on its own weight (...) if we did this, which of these eighteen possible features might we foreclose on, and might we want to leave those possibilities open, at the cost of saying no to this thing here." (https://www.infoq.com/presentations/java-history-present-fut..., 24m+)

Re: The End of the Redis Adventure

#186

Post by erk__ »

ddevault wrote: post #154
sitkack wrote: post #93

Earlier quoted context omitted.

Does FreeBSD have a BDFL? We don't have enough data points to determine if what you are saying is correct. I have also seen lots of BDFL projects smoke out. Is the lesson that actual dictatorships only survive long term if 1) the dictator is a nice person and 2) they eventually get managed by an open democratic process? I think you are actually describing the two clocks problem. Lots of BDFL projects have their own C…

If you're comparing FreeBSD to Linux then I think that says a lot about the merits of BDFLs, really.

Did FreeBSD not have the discussion about this years ago? Though they did not have a single person, but a 20 person core team, which were cut down to a 9 person core team that is voted for every 2 years.

http://freebsd.dk/sagas/freebsd/#id1

Re: The End of the Redis Adventure

#187

Post by makapuf »

umvi wrote: post #155
eric_b wrote: post #50

So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively. T…

> The most important thing Antirez did, in my opinion, was to say "No" to things. This is hard. It makes you feel bad inside to tell people "No", especially when they open PR and clearly did a lot of work adding some feature.

Thats something a have regarding PR and code reviews: much frustration can be avoided by discussing what to do and how to do it before showing the work done (avoiding also infinite bikeshedding). Often code review talk about the strategy to do X and not the way to do X

Re: The End of the Redis Adventure

#188

Post by sidlls »

wokwokwok wrote: post #35
JamesSwift wrote: post #21

Dang. I say this frequently both online and when discussing system design with newer devs, but will repeat here: of all the production issues I've debugged, the culprit has has never been redis. In fact, redis has been a critical piece of achieving cost-effective scaling. It is one of only two pieces of software (along with postgres) that I blindly recommend without any caveats. From following along here and on your…

Redis is simple. Good. Has a nice api. Has good libraries. Single threadsed. Extremely hard to scale. Impossibly difficult to cluster in containers because it uses hard coded ips to address nodes. Performs poorly with large payloads. Doesn't run on windows properly. Is extremely expensive as a hosted service (orders of magnitude in some cases, eg. azure). You'll love it until you don't. The scaling and clustering sto…

Extremely hard to scale in what sense? A single redis server running on fairly commodity hardware can serve some pretty intense loads (10s of thousands of ops/sec). Once "scale" bigger than that is an issue, companies should already have in place the development staff that will ensure scaling up is done in a sane way, i.e., that have enough sense and/or experience to choose the correct tools for the job.

Redis is one such tool--its clustering "story" may not be ideal but even a small, minimal cluster will be more than sufficient for any use-case that a distributed memory cache is fit for at a scale that will cover 99% of business' needs.

Re: The End of the Redis Adventure

#189

Post by calpaterson »

nurettin wrote: post #175
calpaterson wrote: post #86

Earlier quoted context omitted.

> The most important thing Antirez did, in my opinion, was to say "No" to things. No to new features that didn't make sense. Redis has had tremendous mission creep over the years. It started of course mostly as a volatile cache but I've now seen it also used as a message bus (in three different ways: BLPOP, PUB/SUB and Streams), for service discovery and as a general purpose database - something that Redis Labs (in m…

> but I've now seen it also used as a message bus It works excellent as a message bus, though. And you can add HSET/HDEL to your list as the fourth way.

Strongly, strongly, disagree that Redis works well as a message bus.

Lots of reasons why but here is just one because I'm short on time: all of these (four) ways of doing a message bus with Redis offer either a work queue mode or publish/subscribe - but not both (perhaps excepting streams which I've forgotten some of the details of). I have yet to see many real world messaging scenarios where you don't end up using both.

A "proper" message bus needs to have topics, exchanges and queues - like Rabbit. 50% of that functionality is usually not 50% of the value but 10% or less (especially when you consider all the other things about Redis you need to think about - like how eviction is configured).

This is a bit typical of Redis: for any X, you can normally do X in Redis, but is it really a good idea to do X in Redis? IMO, usually no.

Re: The End of the Redis Adventure

#190

Post by pjscott »

When some software I was responsible for started melting down under a load 10x bigger than it could handle, I was able to fix it by doing an emergency rewrite of the data storage part using Redis with Lua scripting. This was back when that feature was still experimental, so I was using unstable tarballs in production -- and yet everything worked perfectly! The emergency was fixed in a single long day. It was a miracle.

Thanks for all the great things you've done with Redis! "Beautiful" describes it well.

Post reply on HN