MariaDB, the Backward Compatible Branch of MySQL(R) Database Server

MariaDB, the Backward Compatible Branch of MySQL(R) Database Server


>> WIDENIUS: I created a feature of MySQL a long
time ago. I even have a TechTalk here in Google about six or seven years ago. At that time,
it was a small room. So nowadays, after the Sun and because of the uncertainty about MySQL
we decided to create MariaDB, a version of MySQL that it will be guaranteed always be
free and available without commercial features and be able to work very close with the community
to ensure that. In fact, all our employees spend 40% of their time working with customers,
40% with the community and 20% kind of a free project that is–that they can decide on that
is good for them, future of the project. That’s–they took actually that idea from Google. And we
give it a [INDISTINCT] to how we make our living is that we make–we continue developing
MariaDB for customers. We also give support for both MySQL and MariaDB. Okay. Let’s go
to the more interesting things. So what is MariaDB? It’s a branch of MySQL with extra
features. And we call it a branch instead of a fork because we are 100% compatible with
MySQL. So we are drove with a replacement but with a lot of extensions. And we are compatible
on the library level and on the user level. Internally, we are doing a lot of changes,
enhancements, working both with the community and with the customers to do that. And there’s
a lot of patches out there that never have been into MySQL. From Google, from Facebook,
from others and we are–have the–last year working on getting those in and there are
still a lot of works. So we hope to that by the end of this year we should have all the
major patches in it. So we are–and that’s the difference with Drizzle, Drizzle doesn’t
care about backward compatibility. They are looking for at what can they do and innovate
and do something different. But that also means that if you have a MySQL installation
you can never easily go to Drizzle. It’s just too different. And it is also unclear when
the Drizzle will be stable enough to be use in production and it’s more a kind of a project
where you can do much more things. So we are an open development model, all our main list
server, regarding development, are on launchpad. And we’re actually working with people. And
they have–before we started there were a couple of other forks of MySQL that was not
happy with whom MySQL was going. Those are people in those forks and they’re working
on MariaDB and we expect them to–in the future, be totally dependent on this one and base
their changes, if ever needed, two hours–one hour. And current state, so we released MariaDB
5.1.42, our first stable release in February. And as this MySQL 5.1 has been stable along
time, so why did it take us a long time to do a stable release? The major thing with
MySQL that even if the server is open, the bill system, the [INDISTINCT], and the infrastructure
to do packages is not. And it took us a long time to recreate that. And everything we have
done is available for free and for every–and in the different projects. For example, we
are using Buildbot for the build system. All the changes we have done is contributed back
to Buildbot and they have accepted it and all the instructions how to duplicate everything
we have done. They are documented and you can find that in our Wiki. So before MySQL
used to say you can work at MySQL anywhere. No. You can work on MySQL anywhere. So we
change kind of that. We also made MariaDB 5.2.0 out as beta. And that has the changes
that we didn’t have time to add to 5.1. But basically 5.2 should be relatively stable
already because we had taken things that has been into production. Actually some Google
patches are in there. In fact, over years–and we expect that should be stable at least within
two or three months. And one big contrast from us on Oracle is that we actually do,
say forward-looking statements that we expect to keep. So what’s the difference between
5.1 and MySQL today? We have lots of extra storage engines, we have been using XtraDB
instead of InnoDB. XtraDB is made by Percona. Its base on the InnoDB plug-in plus Google
patches plus work from Percona. It basically gives you the performance of the next version
of MySQL in a stable release today. And with the stable release, another problem we had
with 5.1 was that when we started to put 5.1 into our test systems and running it with
many machines, we noticed a lot of random failures in all the test script that exist
from MySQL. So we spent basically half a year removing all compiler warnings and making
all these tests reproducible and ensuring that no week–even if test fails, we know
that there is actually a bug because we have no random failures anymore. And many of these
random failures were actually fatal bugs in MySQL that we have fixed. Some of those we
have contributed back to Sun and Oracle. Some of them we have not because Sun and especially
Oracle has not been responsive at all. We have been contributing patches to them. And
if they are not going to work with the community, why should the community work with them? So
slow query log extends statistics. So we added lots of more information about slow queries.
Microsecond precision in processlist, so you can do exactly, with much higher proficiency
how long a query has been running. So we have a–actually this is a nice slide. This shows
from where the different features are coming. And we actually go through all of these features
in detail so if you need to know more. The red are different storage engines that will
upstreams. And the green parts are things that we got from third parties from–both
from Percona and OurDelta. Some of those may even come from µROM. The blue one is developed
by us. And then we had pulling a lot of things from MySQL three years that Sun and Oracle
has abandoned. The best thing with what’s happened lately is that MySQL was–has been
working that 6.0 for three years at least. It’s been announced on every conference. It’s
coming. It’s coming. Though it’s crapped and a lot have occurred that is there including
the backup. We never come in to MySQL place. And as all–the full-optimizer team is now
working for me. They thought that they didn’t want to abandon all this work that has–they
spent years on doing, so most of that is backported to a MariaDB version. Most of that are actually
in 5.3. But the thread pool support, and the collation, and the Maria storage engines is
already in 5.1. We wanted to add as little as to 5.1 as possible, so we would know that
as soon as they go through all the test systems, everything is stable, we would have a stable
release. We haven’t got any notable bugs at all since we released this a couple of months
ago. So we are feeling quite fine about it. So we first look in at the XtraDB storage
engines. As I said, this is made by Percona which is one of the biggest support companies,
or actually the most active one outside of Oracle. And they have been doing a great job.
And most of those people actually come in from MySQL. So they know what they’re doing.
So the improvements from multi-cpu, I think that most of the patches comes from Google.
Some of those actually have been developed by Percona. Much more diagnostic. They have–it’s
a way to save the buffers. So if you want to take the MySQL down and have a very fast
warm start, you can do that. They have better index statistics and a lot of stuffs. And
then the slow query log. So we took Percona’s patches, optimized it, to make it notables,
faster, and had to take less code. That’s something what we do. So when we take a patch
from community, we don’t just take and apply it. We actually spent a lot of time to see
that how does it fit our infrastructure? How can we optimize it? How can we make it smaller?
Because many people out there doesn’t know the MySQL code very well. And we can usually
reduce it to–usually we can reduce it to two-third, sometimes half and get about 50%
more performance. And that’s something what we do when we work with the community. We
don’t only take patches, we actually optimize it. And if it’s in MariaDB, we actually take
responsibility of keeping them up-to-date. So with–by adding information to the CNF
file, which is basic option from MySQLD, you can tell exactly what you want to have in
the slow query log. And we should have an example about that. So with MySQLD, you just–you
get some limited information about the queries that takes a long time. And in the slide below,
you can see in red, more information about the query. If it was in the query cache, which
actually is pretty important, if you’re using it and how the join optimizer use the query,
because otherwise, you don’t know that what’s the reason for the slowness. And if you want
to ever do any debugging especially on a place where you don’t know anything about, this
is extremely useful information. And we also added micro precision as you can see at the
last column here. So you get more information about the query because the normal time is
not good enough. And this was added last because we want to be compatible with MySQL. If you
would have changed the time to microseconds that could probably have caused some problems
with the–for some people, so we take extreme measures with the releases to ensure that
we don’t do anything that could potentially crash. Of course when we add more things to
the information schemas, there’s always a small chance of something. But we also try
to add options to have a more compatible mode. So table elimination–this is the–for the
5.1, the major new feature that we have. It’s basically–this was–a customer asked this
for do–because they have a new paradigm in some new software packages that day. Basically,
we only have one table, they create a view of all tables in the systems and then they
just select things from the view which makes them queries against the database extremely
easy because you don’t need to know anything about the database. You just select the columns
you want. Of course, it’s a hell for the optimizer and especially with MySQL because it suddenly
has to do a join of 4 to 50 tables which we are actually not using those. And Oracle and
SQL server had an optimization that they ultimately detect things like that this is a table that
is not used and removes that from the query. So a customer asked us, “Can you do that?”
and we added that. So within [INDISTINCT] we only have 20 employees. We have all the
original core developers who knows the MySQL code are now working for us. So we can basically
do any changes everywhere. It basically covers all code in the server and most of the storage
engines. We don’t have that much knowledge about InnoDB, but that’s why we have a close
relationship with Percona to ensure that that’s done. And here is–lots of three or four slides
about table elimination, how it works in more detail. I will just skip those, we only have
45 minutes and–but the slides will be available so you can see basically here how it works
and in which cases it will be able to remove tables. And we are working on extending this
even more. So you can–and the main thing is that you can go, in many cases, down to
“index only” scan for tables that are not used that MySQL couldn’t do before. And of
course, these are only in MariaDB so. And we have–we don’t expect MySQL to ever pick
us up. We know that Drizzle has had some interest in this patch and we have worked with the
Drizzle people. So that if they find something interesting in MariaDB, they tell us and we
tell them here’s the code, here’s the patch, patch works, so we give it to them so they
can use it. And we are also monitoring what they are doing and they are telling us that
“Hey, this is a really, really cool feature.” And as long as it still keeps us on a user
level to be compatible with MySQL then we are looking at including it. So we have a
good relationship in working. We are also extending MariaDB to have much more plug-ins.
And that case, in some sense, going in the direction for Drizzle but backward compatible,
but we also spend much more time to do interfaces that–personally, I see that one of the problem
with Drizzle is that they are forcing interfaces or plug-ins when it doesn’t make a sense for
the current interfaces. But they’re not changing it because they just–there have too many–there
have many developers, but they don’t have many who has great knowledge of all the code
and how it works together. So we spend a lot of time to do it in the interfaces correctly.
And of course when we have done something, we tell Drizzle how we do as we have done
it, so they can see that do they want to use their implementation or ours.
>>[INDISTINCT]>>WIDENIUS: I actually have a slide for that,
yes. So PBXT, how many knows about PBXT here? One, so, it’s actually one of the problem
within the MySQL ecosystem. We have great technology, we have a–we are using things
like PBXT that has been around for three years is actually in some cases much better that
the DB but because MySQL never told anybody about those and pushes those out with the
information out, nobody knows about it. That’s also one of the problem we have faced here
with MariaDB to tell people that “Hey, We exist. We are better. And here’s something
that you can do to make your application better.” So PBXT is a little bit like in a DB in a
sense that it’s–transactional it has multi-version in. But the development is how are they structured,
how they do things is totally different in the sense that the only bright things sequentially.
So if you’re running on disks you get much better performance on a search. [INDISTINCT]
better than InnoDB can do. And theoretically, DB always be able to do the insert and deletes
and updates better. But of course you have–then have different performance in other cases.
But as far as we’ve seen, PBXT has a possibility to become great contender, if not winner,
in the race of storage engine for MySQL. And we have a close relationship with those. It’s
included in MariaDB. So in MariaDB, we take the approach that we want all the storage
in vendors and developers that’s been neglected by MySQL to be included in MariaDB so that
we can easily use it. And we add storage engines also very late even in a stable or beta releases
as long as the storage engine doesn’t change the Maria carrier at all. Because if you don’t
use it, it has no impact at all but if you use it, they had, of course, are bound by
the quality of the engines. And we have extended show engines to show which engines are of
least quality. But we need to get technology out and not just keep it away from people.
And here are some more information about PBXT. And you can just almost as fast as I say them–read
those. And the interesting thing with the PBXT is also that you can do replication now
of MySQL through the logs in PBXT, which means that you can have a normal overhead for replication
goes down to one-fourth or one-fifth. So you can get faster replication if you’re only
using PBXT. And we are looking at the–say that can we use that in general in for MariaDB
to get that faster, to get replication faster for those. And the difference–what are the
difference of PBXT? First is that this is community developed, all the derivative maps
and everything that’s happened is available. You can go to–you can communicate with the
developers on the MariaDB the developers list. You can contact–of course, you can contact
them directly also, and the–so you know what happen and you can work with them. And if
there’s a bug, you know when and if it will be fixed because they will tell you. It’s
not like a black hole that is a [INDISTINCT] InnoDB for years. They have also done a lot
of study of SSD’s and they are optimizing its fork for that. Some of the upcoming features
are in-memory tables because they–the design is very suitable to also keep things in memory,
and the PBXT guys are looking at them. The backup that Oracle has just abandoned in 6.0,
and as far as we know will never happen in any community version of MySQL. We are looking
at working on to ensure that that will happen in MariaDB. It was something that came out
from MySQL conference lately where as far as I know nobody we have attended. So the
Maria Storage engine. This actually has been a great source of confusion because when I
went out from Sun almost one year and two months ago, we were working in internal–Maria
storage engine that was meant to replace in a DB. And when I went out from Sun, I took
some of the MariaDB team with me. And they were told that “Okay, we will go out. We will
work with Sun to ensure that there will always be an InnoDB replacement. And then a couple
months later, Oracle suddenly bought Sun and the reason for doing MariaDB was not as important
as before. We’re still going to complete it. But know we see it’s much more important to
ensure that there is a free version of MySQL than a free version of InnoDB. And that’s
why our development in the last year has been almost 100 % on MariaDB. And then we kind
of got into the confusion that we thought that, okay, we need to change the name of
MySQL because we don’t want to conflict the Oracle’s trademark. And then we thought MariaDB
kind of [INDISTINCT] name because we have been working on the Maria Storage engines
for years. But of course, people find it–was confused. So, what is Maria? Is it the engine
or the server? And that’s why we launched at the User Conference a contest to rename
the engine to something different and we will announce that as soon as we have looked at
the results when we come home from here, whenever we are able to fly out from US. That’s the
different issue. So with Maria, the engine, we have–it’s a “Crash-safe MyISAM” so that
we do the replay things on a Crash-safe that is based to MyISAM code with a lot of work
and development. And we are very close to adding transactions than we had. Normally,
we would’ve been able to have completed it a long time ago but because of the focus of
our MariaDB, we haven’t–what we did [INDISTINCT] group commit to get to much highest speed
for it. And we use it internally for temporary tables when the HEAP table is not big enough
because normally in MySQL, if HEAP tables for temporary–HEAP gets too big, we switch
to MyISAM table. The program in MyISAM table is that all the records are always stored
on disk. And for each record fits over–fits, we actually do a disk create. Operating this
system is of course cache that. So with the Maria Storage engine, they actually cache
the records in memory. So this–in practice, this means that MariaDB should be faster than
MySQL for any complex queries maybe actually have to hit disk in normal cases. So the thread
pooling support, this was something that we did for our costumers–I did for our costumers
four years ago. It was added to 6.0 but I wanted to have it in 5.1, but back four years
ago, they said that 5.1 will be out in a couple of months so we can’t do anything with it.
Of course it took three years almost of 5.1 out after that. And I always thought it was
a shame that we never got this nice feature in. So, this was one of the first thing that
I backport it to MariaDB from 6.0. So normally, you have one process per thread per–sorry,
one thread per connection in MySQL. And then it works reasonably well. But if you want
to have a couple of hundred thousand connections to MySQL, it doesn’t work or you also had
the problem if you have lots of running queries at the same time, you get a lot of context
switches, which is not good. So, the idea with this one is say that you tell how many
threads you want to have running the queries at the same time. And then we take one thread–one
query at a time. And when we have N threads running, we don’t take more queries until
one of those are finished. And that worked very good for the costumer. The problem was
that if you have 10 running queries and you have put this up to 10, you can’t anymore
login to the MySQL server and see what’s happening because all your thread are occupied. And
I fixed that by allowing you to use both models at the same time so you can have–depending
on the port or how you connect, you can either say that “Does this connection use the thread
pool or the one thread per connection?” So you get the best of both worlds. So I would
say that if you–you know that you have a lot of short running, selects running–at
the same time you put those into thread pool and statistics queries and then you have something
that you need it know, this has to be executed. You have to put them into one thread per connection.
We add a new collation. So what’s–why is–what’s the big deal with the collation? The thing
was that Croatian collation is actually pretty different from other collation in MySQL and
they will only support in upcoming 5.5 or 6.0 for this one. So and the–we got connected
on the IRC by some people in Croatia say that they are going to decide here on University
of Government Level, I don’t remember just now that which database that we should use?
And there’s no free database that support the queries and collations. So if you don’t
get a solution for this in some weeks, they probably have to go to Oracle or some other
database, commercial database just for the whole infrastructure of Croatia. And the one
thing that was missing was this one. So we implement this in about three days for them
and they were happy. So that’s kind of how we try to work with the community. If somebody
is in crisis, we help. And that was–and we did get some help from people at that time
within Sun to get this done. But they couldn’t add that into the 5.1 because they have strict
rules for what can be done in the stable release. This product is safe but it just doesn’t work.
It has always been hard. Not always but the last eight years, it had been incredibly hard
to get any changes done in MySQL. And that was one of the reason Drizzle was created.
Brian Acker was so fed out that he couldn’t get his own changes that his [INDISTINCT]
critical into the MySQL Server just because somebody had told him that, “Hey, we’ll–we’ll
do a release soon, you can’t do anything, even if everybody didn’t know that the release
is still away–years away.” And that was why Drizzle was created, a frustration for getting
anything done. We are fixing that. We don’t want anybody to be frustrated. If you give
us the facts, we will always–there’s always somebody at [INDISTINCT] version where we
can add the facts, if it makes sense for the light of the community. So we have no–if
5.1 is closed, so there, we can only do bugfixes, 5.2 is in beta we can do a little more flexibility
to there but not new features. But if you notice that if something is missing for making
this feature useful, we can still do it, and everything else goes into 5.3. Of course,
we only that stable features two and three. So with the FederatedX, this is from Patrick
Galbraith, he was the one who wrote the original Federated engine in MySQL. Federated engine
allows you from one MySQL server connect to another server and fetch information. And
when he quit MySQL, MySQL stopped all development of Federated, and people–paying customer
reported bugs. MySQL said, “Oh, this is not the supported feature anymore”, even if the
customer had depended on it. And instead of working with Patrick Galbraith–actually,
we wanted to work with Sun. They’re just deprecated engine. And we noticed there was lots of customer
user depending on it. So we actually have worked with Patrick taking in the newest version
that he has been keeping up-to-date, putting into MariaDB, put it into the test system
have helped him actually to fix some issues with it. And that’s just a bit of Federated
engine that exist in MySQL server. So, 10 minutes. Okay, I always take it a great pride
in working with people and not–and uses in community, and ensure that their needs are
satisfied. I really hate the fact when you say something is deprecated just for your
own convenience when you know that other people are using it. It’s also one of the reasons
I’m working on MariaDB. I would hate that the oldest 20 years and more I’ve spent to
the server I will be just wasted because the Oracle will close the development. And I don’t
want that to happen. I would–I feel bad about everybody, every single person who is using
MySQL depending on it then suddenly they couldn’t use it anymore. That’s why we are doing this.
And my–the other people in my team feel the same. We won’t be able to contribute. We want
to make people happy. That’s why we’re working up open source. So, compatibility, we are
dropping replacement. Libraries are 100% the same, you can connect with the MySQL library
to MariaDB, and vice versa. It just works. And we have people just on IRC just say that
“Tried it, no issues.” Of course, you get more features with us, so there’s–not necessary
that you can go back easily without the dump, of course. If you use a Croatian Collation
or use PBXT, you have to do a dump back. But we are basically the big brother of MySQL.
And we are ensuring we are compatible. So for each of list we do, we have to pull in
the latest changes for MySQL, test those in a beta test system that MySQL has. Usually
we help to fix a lot of things. And then we do other list. And MySQL–MariaDB 5.1 is compatible
with MySQL 5.1, whenever MySQL 5.5 is released, we take the latest MariaDB version and make
that compatible with 5.5. So we will always be ahead. And they close source features that
Oracle is now developing. We will do our best to try to replicate those in MariaDB. So infrastructure,
I already told about that that no infrastructure is free. We have removed mutexes. We have
better test suite. We have removed compiler warnings. So in my belief is that MariaDB
is a stable version of MySQL. We know that there’s fatal bugs that they haven’t fixed
and they know that we have the stable test system that MySQL doesn’t have. So in 5.2,
we have virtual columns userstat–userstatsv2. That’s basically index and table statistics
that [INDISTINCT] Google. I think that you have those in your built. We have partitioned
a key cache that basically–one of the biggest problem with MyISAM for performance point
of view is that they have a global mutex on the key cache that actually has stopped us
for performing in a heavy multi-core environment [INDISTINCT]. That’s now fixed. And we are
adding new engines from the community to it. That’s it. So, this is basic with the virtual
columns patch where we–you can basically have a column that is calculated. You can
even–if you index it, they actually materialize it, but you will not have to maintain the
cells. Just some–you can do the same thing with trigger. These are just much more elegant
and if it’s not materialized yet, it’s faster and easier. And what will happen beyond 5.2?
We have our development team, the optimizer team especially, had backported a lot of the
works–work of the optimizer that have worked the last three years at Sun. So MySQL 5.3,
the work is almost complete. We are not only backporting, we have greatly enhanced it.
And what my optimizer team says it basically we have taken a five years leap forwards in
how the optimizer works in MySQL. So in the 5.3, subqueries, after four months, join a
better–because we see improvements of 10 to 100 times for a more complex queries. And
maybe we should–the guys actually wanted this–ask to do a beta or the user conference.
But the thing is they already just made 5.2 beta a couple of weeks ago. [INDISTINCT] have
two betas. So 5.3 is almost ready but we will keep up–it up for a couple of months to see
that all the additional features like, dynamic column so you can have different rows, can
have different number of columns. We also add the HEAP tables with varchar and blob
support. We want that to get that into 5.3. And then after the summer, we will basically
do a beta. And we will have a phone home feature which basically you can opt–it will be turned
off by default, but we can–you can basically turn it on, so we can get statistics off.
MariaDB uses specifically which feature are you used. Because one of the biggest problems
in developing database is to know “What features are people using?”, “Where should we put resources?”
So we really want to know what people are used production so we know that, “Oh, PBXT
is heavily used,” then we can add more resources for that one. And of course, all the statistics
we collect, we will have them publicly available. But of course not so you can track individuals.
We will basically also mash things so we can’t even track those. But we will–we want to
show people how MariaDB, and in some sense MySQL is used. And we are working with community
so. And there is still a room for things in 5.3. If people work with us, you can still
get it in, otherwise it gets in 5.4. And if you noticed, we are doing three releases this
year. We will expect that very soon we will do one release basically a year. But there’s
just so much interest in getting things in that we are all well with good patches and
we want to have this patch out as soon as possible. So, that was almost 10 minutes.
So questions, sir? Yes.>>Are any support embedded in server library
[INDISTINCT]?>>WIDENIUS: It’s part of out test suite and
so that means that for each push, we do a full test on, I think 17 platforms. We hope
to expand those to 20, 30, over time. And embedded is part of it. So it’s supported.
>>[INDISTINCT]>>WIDENIUS: Oh, sorry. The question was “Will
we support the embedded server?” And actually, the embedded server is something that has
been greatly forgotten within MySQL. And I think that is a great piece of work and it’s
just sad that it’s not as used because it can you give a 2 times improvements or 10
times improvements if you are in short queries by embedding things into your server. Yes?
>>What is the largest database that, you know, you know that you guys use, MariaDB
or MySQL?>>WIDENIUS: We did a release–the question
was, “What’s the largest database that we know of that is used of our Maria DB? We just
released it with. And as a MySQL, we don’t require people to register or download. So
we don’t know. We only know that there are lots of people have downloaded some 20,000
or 30,000 and we haven’t got a single complaint. Okay, we got one complaint but that was some
[INDISTINCT] couple of minutes.>> So my question is, some users with large database,
they do some sharding on at–outside of MySQL [INDISTINCT] full instances of MySQL server.
>>WIDENIUS: Yup.>>Because they have table that they divide
into those servers. Is there any effort to [INDISTINCT] at MariaDB [INDISTINCT] will
just be only one database [INDISTINCT]?>>WIDENIUS: So, in the 5.1 MySQL into–do
you use partitioning? Of course, we are based on 5.1 so we have that too. They have added
some more extensions to that in 5.5. And when 5.5 is RC, we also have that in MariaDB. The
problem with that, is that is not really taking care of at an optimizer level especially there
is no work going on as far as I know that you can do parallel query on the different
partitioners. But it’s more a question that if you have a query that will be used to partition
as a key, we can find the correct partition. There’s not much work on doing that within
MariaDB itself. Although they have–we are working with storage engine like a Cal point
and the SQL DB that does that on the storage engine level automatically. And they claim
that they have tremendous performance improvements for doing that. So, I mean, we are trying
to do–we are trying to handle the upper level and let the stories be handled at the lower
level, that’s much better than adding partition of the upper level. Yup.
>>[INDISTINCT] did not [INDISTINCT] decision in the [INDISTINCT] chapter in the documentation
of the fact that the transactions [INDISTINCT] needed and then [INDISTINCT] support [INDISTINCT].
>>WIDENIUS: So, yeah. So, if you look at what was originally said in the-okay, sorry.
The question was that, originally, in the manual ten years ago, we had a big statement
that if they don’t have transactions, you don’t them and no–somebody can say that we
did 180 degrees turn. If you’re going to look at the old documentation, we said that that
for many applications you can overcome transactions. You don’t need them in many applications.
An atomic operation is enough. With atomic operation basically means that if you get
to crash, you don’t lose data, it’s still atomic. MySQL didn’t have atomic transaction
although we already plan it to do a crash safe MyISAM. So basically having it into a
transaction but you can–you basically use commit. So the big argument back then was
you would really need rollback as a command in your applications. And I never had to use
rollback ever as a command for rolling back, because if you call your things properly,
you can avoid rollbacks. Back then we–of course, we also joined position in and explain
where we are usable. We also said that, of course, that there are things that–the quiet
transactions. When you ask question about, what’s the importance of transactions? And
Heikki Tuuri the author of innoDB came to me, that was about 10 years, and said that
they are having a great transaction of database and they want to have it. I said, “Of course,
they want to have it.” Because maybe–MySQL, they can only satisfy maybe 70% of their needs
back then, the transactions, because I support 95% of the needs. So it’s just a classification
of where do you go and where you want to do it or the way you want to do it. There’s still
a lot of people who are using MyISAM and only MyISAM just because it satisfied their needs
and the extra-performance they get from it is worth it. But, of course, they had to see
that what can you afford to lose? If you can’t afford to lose anything, then you had to–you
had to use atomic operations like MyISAM–Maria is now supported today. It doesn’t have transactions
but it’s atomic, so you’ll never lose anything. That’s how they might control back, which
is not transaction. And many of them known SQL databases, they don’t have transactions.
They have–because you can’t combine things into many instances. But they do have many
of those atomic, so you don’t get the half thing written somewhere. So, that’s where
you get to crash, your database is destroyed. More things. So in that case, if you have
questions, we are–our development is totally open, you can find all developers on the Maria
channel at free node. We don’t have any internal channels, so you can see that we are discussing.
There all our communications regarding development is on the Maria development list on launchpad,
you can participate. We are doing things, what you would expect from an open source
project. To be able to commit you need to show that you are clever enough, you don’t–you
are not causing any bugs and you can understand that we need to do reviews before you commit.
But we do have committers outside of our company doing commits to MariaDB, we expect that to
be bigger but we want to ensure that everything is properly reviewed before it’s pushed. But
then, we have an active developed pricelist that people who are more unsure can just post
the facts in us to be included and if it makes sense to be include it. If not, we tell why
and then we discuss our work. So that’s what you expect from open source project, and we
are working 100% that’s like that. So MariaDB is not a project of [INDISTINCT] maybe, be
it just the driver and enabler with it. Anybody can participate. Anybody can become a driver,
we are open. So, thank you.

Danny Hutson

7 thoughts on “MariaDB, the Backward Compatible Branch of MySQL(R) Database Server

  1. Hmm. I always called it "my ess que ell". Now I learn "my skwell". Naw. I keep on calling it what I always called it.

  2. Funny. I came here looking for how to pronounce MariaDB (as someone else is pronouncing it "Marie aye dee bee"). Now, I'm totally confused.

Leave a Reply

Your email address will not be published. Required fields are marked *