Hello everybody, I'm Hesos Espino, I'm supporting the name of Maramos, and I'm going to talk
our experience running Maramos on Djugabai.
Well, I'm going to explain what it's Maramos for, as Maramos is an open source communication
platform, similar to the Slag or other communication platforms, it's specialized in mission
critical system system where you need to be online or wrong things happen, and we are
very focused on stability and security.
So why are these two with the database?
I think it's obvious from my previous definition of Maramos, but yeah, it aligns a lot with
the focus of Maramos, the potential for highest scalability is also very interesting from
this with the databases, geopartitioning for having different regions and things like that.
And why we decide to explore Djugabai?
Well, one of the main things is open source, so that's aligned with Maramos also.
It's highly compatible with Postgres, it's something that is important for us, because it's
our main database.
Half a very good metric, good administration, and half a cloud service that I can just use for testing
that.
I'm going to tell the story that is a conference three years ago and trying another database,
I'm not going to mention the database because it's not fair because it's for three years
ago, and I don't even know if that is still the case, but the problem was this.
I need all these changes, a lot of changes, a lot of files modified to get these running,
not getting great, it's just running.
And the results were really bad, the database was collapsing at 2000 users, Maramos is able
to scale up to 200,000 users, so 2000 users is like, it was really bad.
So I had a lot of back and forth with a support team from them, and we were able to get anywhere,
and modifying a specific SQL for them and thinking that, and we were able to get a decent
performance, what you can see there is the P99 performance that is four seconds for setting
queries, what is not acceptable at all.
So my lesson lens back then was, the three of the database are hard, it's not something
that you can use as a drop in replacement of both of us, and you need to design your queries
thinking about this with the databases.
Then I started running Maramos in Djugabai, because I meet Frank in a conference, and he said,
yeah, you should try Djugabai, and I say, okay, I was hesitant, but I tried, and these are the
changes that I need to do.
It's just small changes in the migration that were mostly related to things like
out-to-backing and things like that.
And actually, one of the changes I think today wouldn't be needed.
But anyway, the first try was very, very, but what's collapsing to sales and users?
And the performance was the grading over time, the most opposed we have was even worse,
and the P in 99 was growing, we're query plans all the time, and then I was talking with
Djugabai, people and say, just run and analyze, because it's something that I need to do when you
are using the Postgres Compatibility to have that working on, I don't know if they were working
on fixing that, but we need to do that back then.
And suddenly, boom, everything was working like a sham.
So, it was a great spring, everything, you can see the same kind of graph here from,
from Djugabai, and it's everything is going down and going flat,
where it's exactly what I was wanting.
So the database was working on 6,000 users, the performance was stable over time.
So that was a great experience.
We were using our low tests, and modern ones that we have for demonstrating performance.
And my lesson learned from Djugabai was, it can be a drop in replacement, so different lesson
learned for sure. It worked great without any changes, was working great without changes,
and while it requires analyze to get the right decisions when it's the right decision
from the query planning, basic analyze updates, the metadata, the statistical data from the database.
So, I will notice this, then, these open source, like, modern ones, so they Djugai people
went there and run the low test against their instances, and they tried to, to,
to, they five, low test were working well, and these are their results.
They actually, and I'm having an example of a Marmos, sorry, Djugabai cloud instance
that is bigger than the equivalent for Aurora, but in the price is kind of similar price,
and it's getting the same amount of top users, the same amount of users that you can run in that instance.
So, it was 70,000 users, 17,000 users, and the same for Aurora, similar price,
and was a really good average time and P99 time. The average time and the P99 time on Aurora
is lower than that, but the thing is, they are not paying for having a distributed database.
So, at the end of the day, what you have is a whole distributed database for the same price
that you have Aurora. I want to thank, so a mark from the Djugai team that did all this work,
they were working really hard for getting this work in, because running a low test in Marmos is not an
easy task to be honest. Some extra information here about the results,
some graphs about growing the number of users and the performance. At the bottom, at the bottom,
you see the store time, the time that is taking for getting the result from the database.
So, you see that when you approach the 17,000, it's start getting worse, but in general,
for 13,000, for example, it's working very well. The multiple test runs and everyone was
more or less consistent. So, this is my comparison with Postgres when I run the low test,
it's in general, it's similar in flat terms, it's getting flat at 13. But it's getting more
latencies. What is expected from the database, because you are doing more work, actually.
Same here, this is about CPU and there are some artifacts that make no sense, like the number of
goretings, but it's not very relevant. I think this is the important one.
Some conclusions, Marmos works on scales on Djugai, that's great. It's Djugai, it's very compatible
with Postgres. I was surprised by that. And Postgres, it's able to handle more with
left resources that is suspected. Djugai would have high latencies that is suspected.
At the end of the day, it's the price that you pay for having this with the database.
And that's it. Thank you.
Thank you, that was awesome. Thank you.