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

Redis 8.8: New array data structure, rate limiter, performance improvements

redis.io

Post reply on HN
Print view View original

81–90 of 118 posts

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#81

Post by 9dev »

tossandthrow wrote: post #65
9dev wrote: post #42

Earlier quoted context omitted.

Sure the data is lost. A session commonly holds arbitrary state, and even if it’s just the login information. This is ridiculous.

Obviously these are application decisions. You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it. We use redis as infrastructure. To route events and as a cache. For us redis could go down and we would merely see a degradation of our service with no data loss. I recommend using redis like that. And then use a database that supports transactions for real…

This discussion is a bit weird. We started off from, Redis should have better availability guarantees. Specifically to avoid the degradation of service you described.

But that requires running on multiple instances, which in turn requires to share the data across all replicas.

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#82

Post by WJW »

jchw wrote: post #68
0x457 wrote: post #67

Earlier quoted context omitted.

Well, if you have a single instance than using language libraries and structures will be better in most cases. If you use multiple nodes, then you probably want your redis lifecycle not be tied to application lifecycle.

I am not aware of an in-process alternative similar to what Redis offers.

Well the most basic redis replacement would be just a global hashmap to replace GET and SET, possibly with a background thread to periodically delete expired keys. But obviously that stops working as soon as you get a second node.

The entire value of redis IMO is that is ISN'T inside your normal application, but rather some shared storage that all nodes can use to coordinate and that survives deploys, but that provides more ergonomic data structures than SQL databases. Caches are only one type of such shared data, but things like feature flags, circuit breakers and rate limiters are also super common (and super useful).

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#83

Post by echelon »

9dev wrote: post #57
echelon wrote: post #51

Earlier quoted context omitted.

> it's still lacking in two areas This is entirely different than what Redis is and tries to solve. Sqlite is embedded. It's not a distributed SQL. Redis is a distributed data structure store and concurrency primitive. These are worlds apart. > HA story is so much more complicated than it should be It is precisely as complicated as it needs to be. You don't want data loss. If you're in the business of high available…

What kind of an answer is that? This software is perfect the way it is, you’re just to inept to hold it right? A high availability protocol should not leak into the client. It should be able to discover other nodes. It should not land in broken states so easily. It should not limit the number of writers. It should not error during failover. Are these hard problems? Yes. Should we just accept that things are hard beca…

High availability and abstraction complexity are orthogonal.

Redis is a low-level concurrency primitive, and it made certain choices in dealing with CAP.

It might be single-threaded, but it can easily absorb 100,000+ requests per second.

I've built systems that handle billions of dollars of online payments flow, active-active, with six nines of uptime reliability on top of Redis. It does what it says on the tin, and it doesn't need to be everything for everybody. This is a hard domain and you're going to have to deal with different problems and tradeoffs.

If you want something higher level, there are other systems to reach for.

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#84

Post by wkrp »

jchw wrote: post #80
s_trumpet wrote: post #72

Earlier quoted context omitted.

Mnesia, if you’re using Erlang or Elixir.

Unfortunately I have never really used Erlang outside of deploying RabbitMQ. I mostly use Go, Rust, Python, sometimes C/C++. However, Mnesia seems like it is quite a bit more of a complete distributed database engine than Redis. To me the nicest thing about Redis is just the convenience of what it offers: very fast data structures, serialized, optimized (at least by default) for cases where speed is more important th…

Really it would be more like Nebulex/Cachex which provide a really nice caching interface across ETS (what Mnesia is built off of) or other data stores.

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#85

Post by 9dev »

tossandthrow wrote: post #74
n_e wrote: post #73

Earlier quoted context omitted.

> The app would look up in both databases. If it exists in any, there would be a session. And if you find the session with differing values in both databases, how do you know which one is up-to-date? You need an algorithm to pick which data is right, such as electing a master instance. And that brings us back to the original discussion: to manage sessions (unlike caches) in a highly available way, you need to setup H…

Yes, you are pointing out exactly how HA is difficult. There is a whole slew of downstream things you need to take into consideration.

and as you've just confirmed... there is a need for good HA support in Redis. Which was the entire premise of this thread.

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#86

Post by adamcharnock »

williamdclt wrote: post #77
adamcharnock wrote: post #49

Earlier quoted context omitted.

> One, it would be cool to be able to embed it, similar to sqlite, directly into applications. I've found myself wanting this on several occasions too. I.e. wanting all my rust backend processes (k8s pods) to have some minimal shared state, without having to spin up a Redis cluster. I've talked to Claude about it a couple of times, and it descends into something like, "you gotta use Raft or CRDTs, and pick 2 out of 3…

I don't know if that'll make you feel any better but yeah, you're indeed asking for the impossible! You need consensus between your nodes that store state _somehow_, either these nodes are Redis and it does that for you, or these nodes are your pods and you need to do consensus yourself (zookeeper might help, but you're definitely in "complicated stuff" territory). Spinning up an in-memory (no persistence) Redis clus…

Yeah, fair enough.

And yes, adding a Redis cluster is fine, it is just another moving part to manage. But given that the alternative is made out of unobtainium, I guess that is just the way of it :-)

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#87

Post by benatkin »

tapoxi wrote: post #7

Where did everyone end up on the Redis/Valkey split? Is there still a reason to use Redis after the license kerfuffle?

Valkey continues to be the real redis, released under a permissive open source license like redis originally was. The fork of redis known as redis because those that decided to fork it had the trademark at first wasn't under an OSI-certified open source license and now is under a non-permissive OSI-certified open source license.

I'm taking liberties with the concept of forking.

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#88

Post by atmosx »

9dev wrote: post #3

While I love Redis as a versatile tool for external data structures, it's still lacking in two areas IMHO: One, it would be cool to be able to embed it, similar to sqlite, directly into applications. Two, the HA story is so much more complicated than it should be. I totally acknowledge that concurrency and distributed computing is hard, but it should not require reading heaps of documentation and understanding two en…

> Two, the HA story is so much more complicated than it should be.

Really? I am curious, how would simplify it? It’s a very well defined problem and all the “solutions” are very complicated and with many strings attached. I have managed one or two systems that came in different modalities and you had to pick your poison and had to make sure the other engineering teams understand the trade offs. Some were more successful than others, but “easy” never crossed my mind.

Redis is single threaded and doesn’t concern itself with these things, directly, exactly because Antitez understood the trade offs and made all the right choices.

How would you improve the HA story without sacrificing ease of use and performance on a single thread?

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#89

Post by atmosx »

freakynit wrote: post #35
stingraycharles wrote: post #25

Earlier quoted context omitted.

It doesn’t seem like the right tool for the job, though. Aren’t your own programming language’s constructs much more well-defined / understood ?

Language's own native data-structures are generally much more capable and vast. 99%+ developers use only a very limited set of those capabilities. This approach packages those most used ones into a nice, consistent DSL. It's similar in effect to what busybox does to shell utilities, though the motives are different.

Doesn’t depend on the language? Actually I am thinking of the standard library… Python’s in kinda huge and some are hard (for me) to grasp. Golangs seem pretty simple.

Re: Redis 8.8: New array data structure, rate limiter, performance improvements

#90

Post by Xeoncross »

simonw wrote: post #50

> Rate limiting is one of the most common Redis use cases. Traditionally, users implemented rate limiters using server-side Lua scripts combined with client logic. In Redis 8.8, we introduce a window counter rate limiter (by @raffertyyu, together with the Redis team). I had a look for this and it turns out it's slightly mis-described there - it's not a window counter, it's a "GCRA (Generic Cell Rate Algorithm)" - a l…

I've never liked token buckets (vs sliding window counters) due to the extra work CPU cycles required to "fill" them. It seems like doing an atomic incr on a key based on a `time % 1 minute` or something would be more efficient and then let that key TTL expire X duration later. This results in zero work for rate limiters not in use and only a single push change -> resulting count for ones in use. Nothing but setting the TTL extra is required.

Thanks for the links, I'll checkout the Generic Cell Rate Algorithm!

Post reply on HN