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