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

41–50 of 104 posts

Re: Redis explained

#41

Post by LewisVerstappen »

btilly wrote: post #27

I think a few more concrete use cases would help. First, a key limitation that every architect should pay attention. Redis reaches the limits of what you can do in well-written single-threaded C. One of those limits is that you really, really , *really* don't want to go outside of RAM. Think about what is stored, and be sure not to waste space. (It is surprisingly easy to leak memory.) Second, another use case. Repli…

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

Re: Redis explained

#42

Post by CSDude »

topspin wrote: post #36

I am thinking of using Redis as a lightweight queuing mechanism. An event source will MULTI a small amount of metadata as a hash and append a list. Event sinks will BLPOP the list and retrieve and delete the metadata key. One requirement is the events survive power loss. Is there anything inherently wrong with this? Gotchas? A mockup I've done works great so far.

There used to be disque by antirez, which died. https://github.com/antirez/disque

Re: Redis explained

#43

Post by itake »

koolba wrote: post #30
btilly wrote: post #27

I think a few more concrete use cases would help. First, a key limitation that every architect should pay attention. Redis reaches the limits of what you can do in well-written single-threaded C. One of those limits is that you really, really , *really* don't want to go outside of RAM. Think about what is stored, and be sure not to waste space. (It is surprisingly easy to leak memory.) Second, another use case. Repli…

> One of those limits is that you really, really, really don't want to go outside of RAM. Think about what is stored, and be sure not to waste space. (It is surprisingly easy to leak memory.) 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…

> You can have massive amounts of RAM these days.

True, but I am finding that balancing CPU and RAM can be tricky. Slapping 128GB on a 1-core machine means you quickly have CPU limitations.

Re: Redis explained

#44

Post by topspin »

CSDude wrote: post #42
topspin wrote: post #36

I am thinking of using Redis as a lightweight queuing mechanism. An event source will MULTI a small amount of metadata as a hash and append a list. Event sinks will BLPOP the list and retrieve and delete the metadata key. One requirement is the events survive power loss. Is there anything inherently wrong with this? Gotchas? A mockup I've done works great so far.

There used to be disque by antirez, which died. https://github.com/antirez/disque

See my other reply where the disque author talks about exactly that.

Re: Redis explained

#45

Post by stjohnswarts »

googletron wrote: post #21
_gmnw wrote: post #4

Really love this style of writing. Pairing the diagrams/illustrations with the easy to grok copy is really helpful for folks like myself who have been mainly focused on the front-end. What tool do you use for your diagramming, is it all hand-drawn?

Its hand drawn with some fonts for the titles.

This is what I do for my presentations (on a wacom of course). I have gotten grief over it, but I work faster and get less distracted by the eccentricacies of powerpoint and figma. My handwriting is abysmal so I will do that in a "handwriting font" to sort of look hand drawn. Even if I have to convert them later for some big wig, at least I have my "rough draft". Plus it all feels a little more human.

Re: Redis explained

#46

Post by its_bbq »

I've been looking into tech stacks to make a collaborative editor and Redis CRDTs come up a lot. IIUC this requires a Redis db running in each users machine and they connect P2P with each other. Do I understand right? Anyone have good resources for this? I've also seen Riak come up as an alternative. Do they work similarly?

Re: Redis explained

#47

Post by tpmx »

mindcrime wrote: post #32
tpmx wrote: post #29

Earlier quoted context omitted.

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.

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. I think that falls into the "noticed through observation" bucket. I'm relatively sure that it is correct, as I've noticed that behavior myself. But, I have no official standing here and I could be totally wrong. But that sure s…

So you may have misunderstood your observations, just like I maybe did.

Re: Redis explained

#48

Post by remote-dev »

anton96 wrote: post #34

Very interesting. This is leading me to think, using redis as the sole database is very tempting but the Ram requirement is making me think twice. Wouldn’t there be a database like redis that only stores the latest data into memory and keeps the rest in an AOF file ?

Not to make this an ad, but you can actually do better with Redis Enterprise using Redis on flash (part of the flexible and annual plans). It stores hot data in RAM and "warm" data in flash. Here is a good 68s video on the subject: https://www.youtube.com/watch?v=hFQnhPstqLM

Re: Redis explained

#49

Post by zo1 »

topspin wrote: post #36

I am thinking of using Redis as a lightweight queuing mechanism. An event source will MULTI a small amount of metadata as a hash and append a list. Event sinks will BLPOP the list and retrieve and delete the metadata key. One requirement is the events survive power loss. Is there anything inherently wrong with this? Gotchas? A mockup I've done works great so far.

RabbitMQ. It's so cheap and easy to startup a super performant queuing broker with docker these days. And the libraries are all there, async ready and with established patterns. Closest to zero code you can get for this. You'll likely end up reimplementing all those patterns and support around them using redis.

If you want something quick and easy and dirty, go with Redis. But switch to Rabbit when you start having to write a lot of handling and other code.

Re: Redis explained

#50

Post by mindcrime »

tpmx wrote: post #47
mindcrime wrote: post #32

Earlier quoted context omitted.

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. I think that falls into the "noticed through observation" bucket. I'm relatively sure that it is correct, as I've noticed that behavior myself. But, I have no official standing here and I could be totally wrong. But that sure s…

So you may have misunderstood your observations, just like I maybe did.

That's absolutely possible. This particular pattern has seemed pretty consistent over the years, but unless somebody from the HN admin crew chimes in, I guess we'll never be 100% sure.
Post reply on HN