This weekend we’re hearing great news from Michael “Monty” Widenius – one of the Fathers of MySQL. Monty finally found a time to create his own blog with very descriptive name Monty Says. At the same time Monty finally announces Maria – the MyISAM successor storage engine he has been working for last few years. You can now get Maria from MySQL BitKeeper Server.
I’m really excited to see Monty speaking publicly again in the free form rather than in form of sanitized interviews and press releases we’ve seen during recent years.
I’m also excited to see Monty finally releasing his new brainchild and putting his personal commitment behind it: “NOTE: The opinions and promises stated in this FAQ is by the Maria development team and not promises by MySQL AB.” I guess this means Monty will now have more time to do coding and helping people with Maria problems – things he was also great with.
It is still unclear how Maria will be integrated with MySQL (what version, which conditions etc) but honestly I do not really care. I can trust code from Monty (when he will call it stable) and as soon as Pluggable Storage Engine API works well it should not require any official support to work well.
Monty has serious plans and long road map with Maria. Initial version has two main benefits compared to MyISAM – it has page cache for rows (meaning no OS calls will be required to fetch/modify row data) which can dramatically improve performance for certain on disk temporary tables (both implicit and explicit) and it will be (optionally) crash safe, meaning you will not have to deal with partially executed statements or check and repair tables in case of crash which can be showstoppers for many applications when MyISAM would be sufficient otherwise.
But this is only first version – further version to include full transactional storage engine with MVCC and row level locks functionally close to Innodb or Falcon. Though many internal architecture decisions are different from either.
What I also like about Maria is – it gets tools to check and repair tables from the very first versions as well as has tables movable between the nodes one by one. This functionality is may be not in line with serious traditional DBMS thinking when data in theory never is corrupted and database maintains consistency between tables so you should not be moving them around in binary format but it is often so convenient in practice.
I will not say anything about performance of Maria because performance is not the main goal of this release and Monty tells me there are a lot of things which are not optimized yet. Some of these will be quite soon others will be fixed in one of the next Maria versions.
We’ve been testing Maria for a few weeks now and should warn you it is still Alpha software – we’re finding bugs and Monty and team fix them promptly. The passion and speed of bug fixes however makes me think it will be stabilizing rapidly, and the best thing you can do to speed up this process is download maria and give it a try on your workload.
It is also worth to note number of links Monty mentions in his announcement still do not work – it takes time MySQL to update documentation and make worklog entries publicly visible, but at least we have the the sources available now.
In general MySQL seems to keep low profile about Maria (there was almost no mentions on conferences in articles etc even though it was in works for almost 2 years) I guess there are some marketing reasons for that – with Falcon being storage engine of focus for last couple of years MySQL probably does not want distractions. Not to mention showing there is at large extent similar storage engine in works would leave impression as there is a chance Falcon would fail and never deliver its promises (so there is backup) or turn not to be transactional storage engine of choice for future MySQL.
Again, Congratulations Monty, these are both great news !
UPDATE: I now see some binaries are made available, some Maria Documentation is also now available at MySQL Forge.
All very interesting. I understand the reasoning for not wanting to distract from Falcon, because I’m a little confused. In his announcement, Monty mentioned a small foot print as a design goal to help its adoption in desktop,embedded environments and default usage. Whereas Falcon’s goals mention things like increased memory utilization and greater multiprocessor performance. Is that an accurate representation, of the proposed utilization of each?
Monty mentions Maria should be operational on smaller footprint, similar to MyISAM, it however does not mean it should not scale with large amount of memory. Scaling up is also surely a goal.
With Falcon the point is it needs large amount of memory to function because for example it holds uncommitted changes in memory. Falcon does not have goal to scale down at extent Maria does.
It is however hard to tell which will be more efficient at large memory sizes and I would expect it to be workload specific in the end.