On MariaDB Enterprise Server. Q&A with Max Mether
Q1. You distinguish between “open source” and “enterprise open source,” what is the difference?
In this context, I mainly refer to the difference between an open source project and a product geared towards enterprise production usage. This is similar to Fedora vs RHEL.
Q2. What are the database features that most customers need to run in the most demanding production environments?
The features that we have added to MariaDB Enterprise Server stem from discussions with customers or direct customer requests. For example, MariaDB Enterprise Backup was a result of discussions we had with one of our customers with an extremely large deployment that was experiencing issues with backups. They had huge tables so taking backups took a really long time. At the same time, they needed to run DDL statements on the table.
This approach didn’t work in the past and would often lead to the backup failing. So we designed a more rigorous backup process with escalating lock phases that allow DDL to run simultaneously with the backup. Another good example is the audit logging feature, where many of our customers have very strict auditing requirements with large scaling needs, so they needed better ways of tuning the audit logs. With MariaDB’s new Enterprise Audit log, we address those problems.
Q3. What is the positioning of MariaDB in the database landscape?
MariaDB started off as a general purpose OLTP RDBMS. Although a high percentage of our usage was web-based, we’ve always been designed for general purpose usage. Now, we’re focused on large scale enterprise customers and have expanded to cover the newest additions to the ANSI specs (like CTEs, window functions, system versioning, etc.). With this we are able to cover an even wider spectrum of the OLTP use case. But what is really exciting is that our Storage Engine architecture allows us to more easily expand to totally different usage scenarios. We started with ColumnStore for analytics, are now expanding that to cover hybrid transactional and analytical workloads as well, Spider for sharding and MyRocks for write-scaling. In theory, the possibilities are endless. Basically “Adaptive Scaling,” as we call it, allows us to address use cases ranging from small mom and pop shops to large enterprises with multiple data centers and huge analytical and scaling requirements.
Q4. How is MariaDB expanding its market presence with the introduction of MariaDB Enterprise Server?
Open source projects can sometimes be a bit hard to follow and while that allows for a fast pace of innovation, enterprise customers ultimately care about things like greater security, stability and scalability. With MariaDB Enterprise Server we’re boiling it down to a server product with added QA, stability and robustness in addition to expanded enterprise features that deliver the peace of mind our enterprise customers expect.
Q5. Can you tell us about the QA process for MariaDB Enterprise Server?
MariaDB Enterprise Server goes through an extensive QA process where we allot more time to QA than in the past. We have also collaborated with our largest enterprise customers to include their tests directly into our QA process. This is a win-win situation as it reduces the need for our customers to conduct broader test themselves and at the same time increases the robustness of our tests. The end result is a win for all with a more stable product. For example by fixing bugs we sometimes (inadvertently) introduce regressions. By having more time dedicated to QA we hope to discover those regressions before they reach our customers.
Q6. How do you ensure the level of reliability and stability required in production environments?
We’ve worked closely with our customers to determine the types of features and requirements they need to confidently run a production database. That’s why we’ve added an extensive QA process and prioritized bug fixes in Enterprise Server to maintain reliability. We know that reliability and stability for some of our customers means it may take a while to upgrade to a more recent version of MariaDB. With MariaDB Enterprise Server we backport key enterprise features to earlier versions of MariaDB, providing long-term support.
Q7. MariaDB supports bi-temporal tables and broad instant schema changes. What are these features?
Temporal data is something we first added to MariaDB Server 10.3 with the addition of system versioning. System versioning basically means that when a row in a table is changed, the old “version” of the row is not really discarded but stored by the system and can then be viewed later. It is called “system” versioning as the versioning is done automatically by the system as a result of DML (INSERT, UPDATE, DELETE etc) queries being run. This allows a user with sufficient privileges to go back in time and look at how the rows looked in the past, allowing for things like comparisons etc.
However, one drawback with system versioning is that it is defined by when the actual queries are run. Many time related definitions (support contracts to take an example close to our own business) are defined by contracts and not by when the query is run in the database. Typically, a customer renews the support contract before the previous one runs out (or in some cases after the previous one runs out), but in both cases the validity period should be defined by the contract. “Application time” allows the user to define the validity period of a row independently of when it was changed in the database. A table that has both system versioning and application versioning is called “bi-temportal” and that’s what we added in the most recent 10.4 version.
Instant schema changes is a feature that we worked on in collaboration with some of our enterprise customers. Traditionally, in MariaDB, a schema change operation would require the whole table to be rebuilt with the new schema, even when there were no changes needed on the row level. We decided to dig a bit deeper and see if there was a better way of doing schema changes. For example, if you change the order of two columns, you don’t actually have to change the order on disk (as was previously done) just make sure that the end result is delivered in the order defined by the table definition. For adding a column it is the same thing. As the contents of this new column will be empty in all old rows, we don’t really have to go and allocate the space for the old rows at the time we edit the schema. Instead the schema (or table definition) is changed immediately and rows will only get the added space allocated when the rows are changed subsequently. Optimizations like these makes the ALTER TABLE statements be almost instantaneous where instead the actual change on the disk layer is delayed to when it is actually needed, if at all. For more information about this feature go here.
Q8. How do you define top-notch quality, comprehensive database security?
Security is something we have always prioritized at MariaDB. We have added things like data-at-rest encryption, TLS encrypted connections, secure password plugins, etc. We have worked with customers and prospects in industries where security requirements are very strict (like banking and health care) to ensure that we have all the necessary features. One thing we have recently discovered is that the defaults of the server matters quite a bit. For example, there used to be a passwordless root account on a freshly installed server. Now, this is not a problem as a freshly installed server contains no data. However, we have seen many cases where this security hole was never plugged and we have even seen cases where the whole application was relying on the root user account not having a password. Changing the defaults to more secure settings will ensure that customers don’t use non-secure features in production environments by mistake.
Q9. What are the database features that most customers need to run in the most demanding production environments?
In general, production environments need stability, security and scalability. There are many improvements that we have made lately due to an increased usage by larger enterprise customers. For example, we’ve made several improvements on data-at-rest encryption, mainly due to its extensive usage. Another really cool add-on for MariaDB Enterprise Server 10.4 is the Enterprise Backup feature. We have a customer with very large tables where a backup of an individual table can take several hours and a backup of the whole database even more.
At the same time they frequently run ALTER TABLE statements that can take even longer. Our previous backup solution didn’t allow this to happen simultaneously but would instead add locks and waits. However with tables this large, waiting on locks to be released is not an option. That is why the new MariaDB Enterprise Backup allows for ALTER TABLE statements simultaneously with the backup and only require a very short synchronous lock at the end of the backup. It was created specifically to solve this problem. This is an example of how we create database features to cater for our enterprise customers.
Qx. Anything else you wish to add?
The newly released MariaDB Enterprise Server is a huge milestone in the maturity of MariaDB as a product and MariaDB Corporation as a company. It also forms the foundation for MariaDB SkySQL, our upcoming database-as-a-service (DBaaS) offering, powered by Kubernetes to support hybrid cloud. I’m proud of the team having reached this accomplishment.
Max Mether, co-founder and VP of Product Management, is currently leading the efforts on MariaDB Server development. Prior to his current role, Max built up the Professional Services team at MariaDB from scratch. Max began his career consulting and training for prominent companies including MySQL and Sun Microsystems. He continues to train as a frequent speaker at LinuxFests, LinuxCons and other prominent conferences globally. Max earned his Master of Science (Eng) in Physics and Maths from Helsinki University of Technology. A native of Finland, and by-way of Paris, France, Max now resides in Atlanta, Georgia where he is an avid skier, rugby and hockey player.