Hacker News Reader

Comment by jwr | Hacker News Reader

I used to like Redis, because of its simplicity. But these days it is growing so complex, with so many distributed algorithms being implemented, that I'd much rather use FoundationDB, which at least has the benefit of being extensively tested (in fact it was written test-first) and provides a full distributed database with transactions.

I think there would be value in a "simple Redis": a well-maintained tool for a certain class of problems which do not require a distributed database.

View on HN

Redis is still very simple and most features are orthogonal and completely isolated. Don't trust my words, check yourself, if you count the lines of code with "cloc" in Redis unstable, it is composed of 64890 lines of code. In any other system this amount of code is used, maybe, for the query parser. A single developer can still read the Redis source code in a few days and understand how it works and modify any part alone.

EDIT: I also want to stress on a fact, that at the same time in the newer releases there was a simplification attempt. For instance the Lua scripting side effects problem are going to be removed completely by simplifying how the replication of Lua scripts is performed. Redis 5 is already like that, but the dead code was not yet removed for safety. Redis 6 will completely remove many parts of code. So there is not just the stress on adding, but also on refactoring. ACLs themselves allowed to refactor authentication in separated functions inside acl.c to lower the overall complexity.

I'm surely not speaking for a minority when I say I couldn't disagree more with the parent comment.

Redis is the most simple, rock-solid piece of software I have ever had the pleasure of using. I find the comparison with FoundationDB jarring.

Don't let the negative comments like that sway your mindset; I think your choices are spot on and the proof is in the pudding.

To be honest, the top level comment in this chain reads a bit like an attempt at a plug for FoundationDB than a legitimate criticism of Redis. You could s/Redis/<literally any other DB>/g

I can second that. It's been a few years since I actually did this, but within about two working days worth of reading, I had consumed and understood a good chunk of the code and overall control flow. I was able to make some reasonably invasive changes within a few hours each after that (initially adding "msg/trigger on expire" and check-and-set operations on hashes, then a bit later a change to memory management that was a few percent of global speedup, and a partial COW implementation for strings). Admittedly, I have fair amount of experience working on interpreters in C, which is pretty close to what plain Redis does, just simpler and hidden behind http.

A quick glance suggests that this would still be similarly possible today. Redis is by no means perfect, but it deserves it's reputation for being accessible!

PS: Thanks for the mention of the Lua side effects changes. I'll be curious to read up about your solutions to those puzzles.

65,000 lines of code? I'm not a developer but that seems impressive.

Impressively small or large? It's tiny compared to most storage products/databases.

I would say that's mostly due to that when it gets down to brass tacks, Redis (ignoring the orchestration in Cluster) really is a fairly simple interpreter with simple memory management (largely delegated to the malloc implementation) that glues together a fair number of nice data structure/algorithm implementations that have little codependence. That last point is really, really important in it's developer accessibility. (antirez called this modularity elsewhere I think.) It also helps keep code size down.

Definitely small for something so powerful.

Has redis broken any of the "simple" features? I don't use it that intensively, but always got the impression that most new things are optional and easily ignored.

This is actually what I love about redis. They added clustering, obviously a massive feature, in 3-4 and you could totally ignore it if you wanted to, while still receiving the stability and speed increases without changing much of anything.

Exactly, the same with ACLs and RESP3. With ACLs a lot of design work was done in order to make sure that is impossible to understand the difference if you don't know about ACLs. The old "requirepass" now sets the password for the default user, and the default user ships with the exact default of what connections could do before. Backward compatibility and the ability to ignore any part of Redis you don't use are one of my main goals.

If new features are implemented as 'composable' algorithms, meaning that they:

a) can be used, optionally

b) can be composed with each other into new data processing (eg filtering/aggregation) models

c) did not reduce, significantly complicate, or create many 'exception rules', to otherwise a coherent model

Then those are good additions, in my view.

Also, I personally found, useful about Redis is its protocol. It is a very useful and poweful paradigm when different systems by different authors/companies implement same protocol. It reduces cognitive overload on users (programmers) and helps to continue building their domain expertise, rather than constantly re-learing APIs of tools or libraries.

So work on RESP3, in my view, is very welcomed.

I think it is sad that downvoting is used to stifle non-popular opinions. It makes people with potentially interesting (or at least non-mainstream) views less likely to participate. I do not mind people disagreeing, but the downvote is used to "bury" comments, and as a result some people will never see them.

Think about it: if you downvote anything you disagree with, eventually all you will see is opinions that you agree with. I don't know about you, but that is not what I expect from HN.

Reply on news.ycombinator.com