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

Redis explained

architecturenotes.co

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Redis explained

#71

Post by btilly »

jbboehr wrote: post #64
btilly wrote: post #33

Earlier quoted context omitted.

You can have massive amounts of RAM these days. You’re sooner to hit big-O limits from bad architectural decisions than run out of memory. If you do get to that point you likely have enough value in your usage to justify scaling out further and sharding. Absolute disagreement. It is very easily to accidentally leak a few hundred MB per week in a busy Redis system. The code will look and work fine...at first. It is co…

You can also "leak" rows in a traditional RDBMS or even a filesystem. Why is this particular notable for Redis?

A traditional RDBMs or filesystem is designed for high throughput and concurrency, even if some tasks are blocked on data. Additionally both have options to partition steadily growing things. If needed with old partitions being moved to tape backup while the server continues running.

Redis is a single threaded program acting against RAM whose philosophy is that it does things fast then moves to the next job. If it needs to access memory that got paged to disk, the whole server stops and waits to get it. Nobody can do anything.

Because Redis doesn't have to deal with locking and concurrency, it can run much faster on the same resources. But when concurrency is required, it is stuck because it doesn't have it.

Re: Redis explained

#72

Post by tpmx »

_gmnw wrote: post #7
tpmx wrote: post #3

Earlier quoted context omitted.

[Potentially inaccurate content removed by author]

The saltiness isn't a good look here. Especially seeing as he's not the poster. It's the HN algorithm which is probably due to the fact that other posts from his domain have done relatively well, plus the actual poster here has quite a bit of karma.

No post body was provided.

Re: Redis explained

#73

Post by ok123456 »

rfrey wrote: post #67

A question so noob I'm almost shy to ask it: The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?

Short lived processes/workers.

Re: Redis explained

#74

Post by radicalriddler »

rfrey wrote: post #67

A question so noob I'm almost shy to ask it: The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?

Redis persists on disk (well, it's optional), if you restart your server I'd assume that it'd be able to restore the disk data into memory, versus your applications memory, which would just be lost.

I'm not a Redis user, but that's based on what I've read

Re: Redis explained

#75

Post by anonymousDan »

btilly wrote: post #59
LewisVerstappen wrote: post #41

Earlier quoted context omitted.

> Replication in Redis is cheap. If your data is small and latency is a concern (eg happened to me with an adserver), then you can locate read-only Redis replicas everywhere. The speed of querying off of your local machine is not to be underestimated. Do you face any consistency issues with doing this?

No. Replication time was measured in hundredths of a second, and Redis operations are atomic. So all queries got a consistent view of the data, and the lag to update was very reasonable.

So in other words, potentially yes since there is some lag :)?

Re: Redis explained

#76

Post by manigandham »

tpmx wrote: post #29
mindcrime wrote: post #28

Earlier quoted context omitted.

There isn't a ton of documentation per-se about HN behavior. There is: https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newsfaq.html and a handful of posts by dang, sama, pg, etc. over the course of the years. most of the rest is what long-time users have just figured out through observation. There's a Git repo[1] out there that aggregates a lot of that stuff, but keep in mind that it…

Thanks, that's a good summary of what I've seen referenced throughout my years here. I can't find any reference to something like "combine the scores of new submissions of the same URL to the first submission's score" though. I guess that's either new information or incorrect.

You can try this yourself. Go to the ‘new’ page and submit an existing URL. You’ll be redirected to the existing post which will now have at least one more vote.

Re: Redis explained

#77

Post by tmpz22 »

jrm4 wrote: post #51

As someone who doesn't code for a living but teaches it to mostly novices, this helps (because before this I had no clue what it was except that it had something to do with databases.) Typically for my courses we just use some flavor of SQL and call it a day (and that kind of spoils us because of how declarative it tends to be) -- roughly, what's the "explain like I'm 10" use case for Redis over something else? From…

The traditional line of thinking is:

* you're building a web-ish application and need to store session data

* you don't want to go through the overhead of building a strongly typed relational table

* you know minimal operations stuff

* just use redis, its easy to deploy, easy to code for, and available on all major cloud platforms as a managed service

---

The problem is there are tradeoffs and session storage becomes a fundamental architectural decision once your application matures. So something you added as a once-off so you can get back to feature development is now a foundational pillar.

Re: Redis explained

#78

Post by piaste »

rfrey wrote: post #67

A question so noob I'm almost shy to ask it: The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?

Your application and runtime are probably tuned to act as servers, with short-lived requests and little or no persistent stage, and they may not play well with keeping a bunch of persistent data around forever.

I personally first reached for Redis when I needed to asynchronously process a bunch of JSON uploaded by clients via POST. I initially just stuck them in a ConcurrentQueue in memory, but no matter how much I fiddled with HostedServices and BackgroundWorkers and whatever the MS documentation recommended, the ASP.NET Core app would occasionally 'lose' that queue before it could be consumed (or the consuming loop would get stuck, with the same result).

You are also probably running your app on a pretty high-level language, with bytecode and reflection and all that nice stuff - if not even an interpreted language - while Redis is raw C code and will outperform your homebrew double-linked list or hash set.

Re: Redis explained

#79

Post by Havoc »

The white cube in the traditional usage example - what does that represent? App code? Or so that cache miss to db implemented in some standardized way?
Post reply on HN