Redis Mathematical Commands

[00:00:00]
>> One of the cool things that Redis can do is, it can do some math for you. So let's say we're tracking all the visits to our website. So I'm gonna say set visits to 0, because no one's visited our website yet. There's another command, so when I say command, these SET, GET, all those kinda things, again, I'm capitalizing it for your benefit, you don't have to.

[00:00:24]
You can also say set like that, and it works. Let's say someone visits our website, we can issue a command. We don't have to say GET visits, then do another SET. We can just say INCR, like this, visits. And there you go, that just increments it. And we can do it again, and again, and again, and again, and again, right?

[00:00:48]
So there's some amount of math that Redis can do for you. You can also do decrement visits, and lo and behold, it will decrement as well. Let's say we're writing an American football tracker. You can say SET score, and let's say SET score:seahawks, cuz I'm a Seattle Seahawks fan, obviously.

[00:01:20]
Their score is 0, and we'll say SET score:broncos to be 0, right, cuz that's how the game starts. And then later in the game, you wanna say increment by INCRBY. Then we'll say score:seahawks, 6, right? So this will actually go through and increment the Seahawks' score by 6.

[00:01:50]
Then if they score their extra point, you can say by 1, and lo and behold, there's 7, right? So INCRBY allows you to not only just add something, but you can actually specify how much you wanna add by. There's also DECRBY, and you can put score:broncos, cuz no one likes the Broncos, right, 3, so now their score's -3.

[00:02:12]
That's not possible, but in my fabricated reality, their score is -3, and that's what DECRBY does. It allows you to do the same thing, just by decreasing. You can do multiple sets and multiple gets, so I'm gonna say MSET score:seahawks 43 score:broncos 8. If we were just setting the end of the game scores, that's how you would do that.

[00:02:42]
And then again, we can do MGET score:seahawks score:broncos. The first one we get back is 43, the second one that we get back is 8. This one is decidedly easier than the other ones, that's kinda why I saved it to the end, for when your brains are all mushy from the other databases.

[00:03:00]
This one's like, this one's easy, we like this one. Another one it's useful is EXISTS, right? So I can just say EXISTS score:seahawks. And it's gonna say 1, yep, that definitely exists. If I went in here and queried for a Vikings score, I haven't set a Vikings score, so it's gonna say that one doesn't exist in my database.

[00:03:23]
The example I have here in my notes is, if you were doing a pathfinding algorithm, you could kind of use that as a way to, SET plane:0:0 for x, y. So I would say SET plane:0:0 true, or visited, something like that, right? And then later, if I try to go back to that same area, I could just say hey, have I visited this place before, plane:0:0, and it'll say yes.

[00:03:53]
Have I visited this area, no, and then I could know that I could go there, right? That's an example of how you could use EXISTS. If you wanna delete things, you can say SET greeting hello. EXISTS greeting, DEL greeting, and then if I asked EXISTS greeting again, it's gonna say no.

[00:04:15]
So that's what that delete does, it just deletes something out of your cache. And honestly, I just showed you, get and set are 90%, we're up to 96% of how you would use Redis. But let's go into the advanced stuff cuz why not, it's kinda fun. When would you use Redis as opposed to just keeping something in memory on your app server?

[00:04:40]
In general, when I'm writing Node servers, and PHP servers, and Ruby servers, I want my endpoints to be stateless, right? So that in between my first call and my second call, I'm not maintaining any state. The reason why that's really helpful is because, when I then scale out my app server to be ten app servers, you don't know which one they're gonna hit next.

[00:05:00]
So if I have to maintain state for a user across API calls, then I can just set it in Redis. And they're all gonna be reading from the same Redis even if it's different app servers. If you have just one app server running your entire app, go ahead and keep it in memory.

[00:05:17]
I can't see why you would use Redis, right, unless you have a lot of stuff that you need to store because you don't wanna take up all of your memory. But when you have two app servers, that becomes a big problem.