WEBVTT 00:00.000 --> 00:10.000 So I'm going to talk about Ronda B and real-time AI. 00:10.000 --> 00:14.000 So first of all, what is real-time AI? 00:14.000 --> 00:18.000 Well, in this case, it's personalized recommendation systems, 00:18.000 --> 00:22.000 such as you will find, in, for example, Spotify when you do a search. 00:22.000 --> 00:28.000 This use case that we're going to try here is salando when you go into buy some clothes. 00:29.000 --> 00:32.000 And so what's the traditional solution for that? 00:32.000 --> 00:35.000 The traditional solution is to use a key value store. 00:35.000 --> 00:41.000 So because you want real-time low latency in high throughput, 00:41.000 --> 00:44.000 and it's very often that you want to batch things. 00:44.000 --> 00:49.000 You want to have a lot of small operations that you want to have batch together. 00:49.000 --> 00:53.000 But the thing is what I'm going to talk about today is how Ronda B, 00:53.000 --> 00:56.000 once more than that when you do real-time AI, 00:56.000 --> 01:03.000 you also want to have projections to make sure you don't have to fetch 500 elements at the same time. 01:03.000 --> 01:08.000 You also have data models where you do traditional link joins, 01:08.000 --> 01:12.000 which a link join is basically where you do a primary key look up on the first table, 01:12.000 --> 01:16.000 and then a foreign key, foreign key, foreign key, foreign key. 01:16.000 --> 01:21.000 That's the link join, very easy to do with my scale. 01:21.000 --> 01:31.000 And we also have instead of storing all events in a single row, for example, radius. 01:31.000 --> 01:36.000 You can store them in multiple rows, and then we have this batch scan operation. 01:36.000 --> 01:41.000 So it's all about sort of doing things that you could do with SQL, 01:41.000 --> 01:48.000 but you don't want to do SQL because SQL means that you could also run a query that takes forever and ever. 01:48.000 --> 01:54.000 And that will not meet your low latency because that query will affect all the other queries. 01:54.000 --> 02:02.000 So it's very important to have sort of an interface that gives you low latency all the time. 02:02.000 --> 02:08.000 And we also have feature freshness, so if event comes in and you want to aggregate, 02:08.000 --> 02:13.000 you can of course do the aggregation on the offline system, 02:13.000 --> 02:16.000 but that means that your feature freshness will be less. 02:16.000 --> 02:21.000 So that means that your AI will work on old data. 02:21.000 --> 02:24.000 So that's why we also done push down aggregation. 02:24.000 --> 02:28.000 So you can also do aggregation on the latest and the latest data. 02:28.000 --> 02:34.000 And then of course you want to do high availability to avoid the need of caching solutions. 02:34.000 --> 02:38.000 So rendezvous is the platform of the Hopstwick feature store. 02:38.000 --> 02:43.000 And if you look at this slide, this is how Saland was started out. 02:43.000 --> 02:46.000 They had DynamoDB and Redis. 02:46.000 --> 02:53.000 And in the Redis server and in DynamoDB, they collected 500 events in one single row. 02:53.000 --> 03:01.000 So that meant that every time they had to update, they had to update a row with 500 elements in it. 03:01.000 --> 03:07.000 And then they had to do all the filtering and the transformations in the API. 03:07.000 --> 03:12.000 So with RunDB, you can insert events one by one. 03:12.000 --> 03:15.000 So when they come in, you do it. 03:15.000 --> 03:22.000 And then you do the sort of aggregation and you do the scanning batch scanning in the runDB itself. 03:22.000 --> 03:26.000 So it's sort of an SQL database runDB, 03:26.000 --> 03:30.000 but we use it in a very specialized way. 03:30.000 --> 03:36.000 And this is just how it looks in the architecture of the box. 03:36.000 --> 03:44.000 And so here we see that we can do push down aggregation so that you get the most feature freshness. 03:44.000 --> 03:47.000 And finally, runDB versions. 03:47.000 --> 03:50.000 We have been working on runDB for the last five years. 03:50.000 --> 03:54.000 It relieves the first version in April 2021. 03:54.000 --> 03:57.000 And it's now in development. 03:57.000 --> 04:00.000 We have 25 10 where we have a rest API scanning interface. 04:00.000 --> 04:02.000 We have increased the size of. 04:02.000 --> 04:05.000 So there's a lot of things going. 04:05.000 --> 04:06.000 A final thing. 04:06.000 --> 04:10.000 We did 100 million key value lookups using rest API. 04:10.000 --> 04:15.000 So that is something you can go look how it was done if you want. 04:15.000 --> 04:22.000 And finally, with Claude, you can go five to ten times faster in your programming. 04:22.000 --> 04:25.000 So that's a good advice. 04:25.000 --> 04:26.000 Okay, that's it. 04:26.000 --> 04:27.000 Thanks. 04:27.000 --> 04:37.000 Thank you.