The MariaDB Foundation values our partnerships with our sponsors. Our partnership with IONOS allows us to get insight into how MariaDB Server is used and the direction it should take. As well as generally improving MariaDB Server in many different ways.
IONOS story
At CloudFest 2023, one of the first meetings we had was with Stefan Erkeling from IONOS. It was a very good meeting and it was great to see how much IONOS values our partnership. Stefan indicated in the meeting that there was a performance issue they were hitting and some advice was needed.
Later on at the conference, Stefan introduced me to Babak Vahedipour, who is a Senior VP Engineering at IONOS. Babak was able to give more detail on the problem. Essentially, they have thousands of customers on one MariaDB Server, each with their own database on the server. When an application runs a SELECT query on INFORMATION_SCHEMA.TABLES or similar without a WHERE condition on SCHEMA_NAME, the server will scan for all FRM files for all databases. This can be an expensive operation, and is unnecessary for them because the application only needs to know about its own tables.
For hosting providers, the applications run on them cannot typically be modified by them. This is something that needs to be solved at the database server side. Their initial solution was to solve this by a proxy to re-write the query, but Babak wondered if a plugin to MariaDB was possible instead, eliminating the need for a proxy. He asked if I could give his team pointers on where to look to do this.
The solution
Unfortunately, solving this problem was not possible to do in a clean way in a plugin. But it did give us some ideas on how to solve this problem for IONOS and other hosting providers that may be hitting similar issues.
I discussed this problem with Monty and we came up with a couple of solutions. The first is something that could be implemented quickly. A system variable that when set, only showed results from INFORMATION_SCHEMA tables for the current working database unless a WHERE condition for a database is provided, the default for this being ‘off’ so that it doesn’t change normal behaviour. This acts as a stop gap until people can use the second solution. The patch for this is currently up for code review with the intention of landing in MariaDB 11.2. I informed Babak of this and his team is also testing it.
The first solution (the INFORMATION_SCHEMA patch) is not a permanent, fully generic one. But catalogs are. And that is a feature, the development of which many similar MariaDB users share an interest in. In short, this is a way of isolating users and databases by customer within a single MariaDB server. A customer can only authenticate their users and see their databases. We discuss this in more detail in a blog post about the feature. There is also an outline of the feature in the MariaDB Knowledge Base.
As with the first solution, this is off by default, so does not affect anyone who does not want to use the feature. This is currently in-development and companies such as IONOS are going to be providing feedback on the development and implementation of the feature so that we can make sure it is the right fit for their use cases.
Driven by you
Sponsorship of the MariaDB Foundation is a great way to improve the continuity of MariaDB Server and help shape the future of it to suit your needs better. If you are interesting in becoming a sponsor of the MariaDB Foundation please take a look at our sponsorship page.