I've been using Redis wrong this whole time...

Seriously. I've been wasting it's talents.

Redis happens to be one of my more favorite databases out there, but I often relegate it to the caching layer in my application stack. In this video, I decided to look at how to use redis as a database, rather than as a cache, and how that would work.

Join this channel to get access to perks:

My socials:

00:00 - Intro
00:46 - How did we get here
01:23 - Persistence
04:14 - Data Structures
05:02 - Tables
07:29 - Basic Index
08:17 - Columns
10:43 - Ordering
13:43 - Filtering
14:59 - Unique Constraints
16:13 - Transactions
18:51 - Drawbacks

[DesertRat]

I would truly appreciate a homelab setup from you, love your videos, God Speed!

[eduardornh]

Be aware that in AOF (Append Only File) persistence, Redis saves logs every second by default, not every write.

[jack]

You don’t need a cache if your database has enough memory. You don’t need a database if your cache has enough disk space. You don’t need any of them if you have no users.

[blank]

Perfect example for: Just because we can doesn't mean we should.

But content wise this video is top notch

[advanceringnewholder]

This made me appreciate SQL more. Look what they need to mimic a fraction of SQL power

[TheKnocKY]

So instead of using postgres I can use redis and recreate most of the SQL functionality myself, with less safety and more complexity and space for error...
I struggle to see why to use this in any real world setting. Even for side projects, if I wanna set something up quickly, I don't wanna have to have to create indexing etc myself before being able to develop the app. I'd also be interested how the performance actually plays out once you start parsing long JSONs, maybe it will still be faster, but it's something you didn't consider. Also if you eventually decide to switch to postgres that could be a really hard rewrite.

[IshanAditya]

Hey! Nice one! Online Engineering Lead at Ubisoft here... Sorted Sets in Redis are the go-to solution to do leaderboards in the game industry actually, but you're constantly optimizing to battle server costs since everything stays in memory, and larger leaderboards need machines with more memory, which happen to be more expensive.

But honestly, as soon as you want persistence and you enable AOF for every write operation, you'll start to run into performance issues on Redis too. There's no magic bullet in engineering - weigh the pros and cons for each use-case and then choose the tool.

[cat-.-]

Next video idea: most people scoff at the idea of using filesystem as a database, but did you know we can recreate Postgres with fs in c++ and achieve similar functionality and safety

[tim.martin]

Can confirm: you were using redis the right way at the start. Enjoyed watching this but wowzer, I can't imagine inheriting a project setup this way...

[ordinarygg]

Postgres Transactional speed > Redis Transactional speed. Also Redis is single thread write/read so you need compex cluster and one command could lock everything.
You used Redis correct, now you start using Redis not what is designed for. Seems like you doing bold claims without real usage in big systems those approaches.

[jtms]

In my past experiments with using redis as a primary store it tended to not scale well once the project grew to a certain level of use and complexity. I often use it as a primary store for specific slices of a given application's data persistence strategy when and where it provides advantages over a traditional RDB. Inserts when using a RDB tend to be expensive (especially if the table has a bunch of indices) so Redis can really shine in very write heavy areas of your app like messaging, sensor data capture, etc.

[rslakinski]

You missed a key point. During snapshot redis will fork the process and dump what is in that forked process to disk. This means you need 2x the ram to perform this action but also it’s a global db lock during the forking process. If you have a small dataset this generally fine but if you have a large db this process will cause large spikes in latency when the snapshot begins.

[Chzz]

It might be good to add that redis transactions are not nearly as powerful as SQL transactions.
You can resort to using LUA scripts to fix that but this is really annoying to maintain and to write proper tests for.

[codr]

So now I know that I *could* sort of replicate a relational-ish storage model in Redis by reimplementing abstractions that are already in place in any RDBMS by hand at a lower abstraction level. Which is indeed quite interesting. The question is: Why should I, instead of just using an RDBMS?

[johnholland]

You've been doing great. The content is presented at a reasonable speed, well at least for me. And the content its self has been very interesting and informative. Personally, I'm really interested to hear about your home lab, so please do an overview of it and maybe down the line a deep dive ;-) Thanks again, bud!

[BadDogeU]

Our company uses Redis as a runtime database for our live chat system, and it saves off transcripts into a real RDB at various checkpoints. The footprint in redis for all of that is 400MB, and we saved an immense amount of maintenance/development cost doing it this way..

[KuroKazeZX]

"redis is an open source..."
hmm, unfortunately this aged bad

[tom_marsden]

I think you've convinced me to stick with RDBMS + SQL as the primary database for my relational data 😁

[khanra]

This seems a terrible unsafe idea
Just use some SQL db that can be in-memory

[TheShorterboy]

Nice I like REDIS but there is a lot to manage and that is a lot of data sets, a normal DB lets me abstract this away with table index magic and in this case I might as well just use python/TCL/C++ with hahses, sets and arrays (though TCL will let me push raw commands in avoiding the need for an API) and write every transaction to a rotating log file with a threaded snapshot by time.