 All right, let's get started. So thank you, everybody, for coming. I am Vichen, too. I am a software engineer for the MariaDB Foundation. And today I'm going to talk to you about MariaDB. What it is we hope to accomplish and give you a preview of what is up to come in our next release. So a brief history about MariaDB. How many of you have heard of MariaDB before? OK. How many of you have heard of MySQL? I guess, pretty much, everybody. OK, so MariaDB is a fork of MySQL. The naming goes after Monty's daughter, Maria. This was the same for MySQL. His first daughter was called My, so MySQL. We had our first release in October 2009. And the reason for MariaDB's birth was to, as a response to Oracle's acquisition of MySQL, at that time it wasn't clear what the direction for MySQL will be. So we tried to maintain the spirit of MySQL, which was to keep development through the community. So all our work is done as a response to what the community needs and what the community asks of us. And due to this approach, we've now actually been accepted as the default MySQL variant in Debian 9. There may be questions about compatibility between previous MySQL version and MariaDB. If you have any concerns, we can discuss them now or after the presentation. I'll do my best to answer them. Another thing to note is that we do hold developer conferences. And if you want to give your input on what you think MariaDB should do forward, they are free to attend. Everybody is invited. The next one is in China. It is announced on marioDB.org, so you can look to see if you can attend. Okay, so let's just go through a brief history of all our versions. Each version tends to have one flagship feature or a theme, if you like. MariaDB 5.1 was the first version to guarantee that MariaDB is a free database. And then we've added progressively more complex features. Our most recent stable version is 10.2, which brings advanced creating features which other databases did have but MySQL and its ecosystem did not. We can... Examples are window functions and commentable expressions. If anyone is interested about this, I also have a talk prepared for this. You can give me feedback. If you'd be interested, I am more than happy to talk about them as well. And MariaDB 10.3 is now focused on compatibility. So we're trying to make it as easy as possible for people to migrate from other database systems to MariaDB. And in particular, we're talking about Oracle Database. So not MySQL, but the Oracle Database, which supports PL SQL programming language. So generally, we can say that migrating from MySQL to MariaDB is a relatively painless process, minus a few exceptions here and there. We've tried to play as nice as possible with whatever MySQL tries to throw at us. And we are generally compatible with almost all of their features. And we want to also tackle the proprietary database market. How can you convince people who are using proprietary databases to switch over to an open source one? Well, it's not easy to just tell them rewrite everything, make it work. Instead, why don't we try to provide as good of a compatibility as possible using the minimum amount of effort? So we believe that 20% of our work is needed to get about 80% of use cases working. And this is how we've guided our decision to support PL SQL. So I'm just going to go through most of the features, which are already in the alpha release of 10.3. If you have any questions, feel free to interrupt me at any point. So one of the interesting features is sequences. So you can create a sequence, which acts kind of like a table. And whenever you query a column in it, it will give you a number, which always increases. There's multiple parameters. You can make it loop around, make it skip elements in the sequence. This was something that a lot of people requested and it was implemented. It was actually not that complex to do. We also added support for intersect and accept. So you probably heard of union, which merges rows from two selects. Well, intersect and accept are the counterparts when it comes to set arithmetic. So intersect will give you rows that are in both selects, but not rows that are in just one of them. Whilst accept will give you all the rows from the first select that are not in the second select. Any questions so far? I'm not really sure how versed you are in the SQL language, so if there's something unclear, please interrupt me. We've also added support for the row data type, which acts like a structure from C or C++. You can declare it and it has members. Here we have a row with one integer column and one text column. And then you can access the members with the dot notation. You can also get the type of... You can create a row data type based on already existing tables. So here, for example, on the second example here, you can get the data type from the table row itself, or if you have a cursor, you can get the data type from the cursor. So it's very easy now to work with rows as opposed to just column values. You can also now declare cursors with parameters. So before this, you could select... You could create a cursor and then open it, but the way the cursor would go through the table would be fixed on how you've initially created it. But now you can actually have some sort of factory of cursors which have parameters. So here this cursor will go through this table, but it will only return the values between minimum and maximum. And these can be created using expressions as well. So this gives you a lot more flexibility when it comes to editing your application. If you have a lot of data in a table, it may make sense to split it up. An example from... I think booking is one of the largest corporations who make use of MariaDB. And they have a lot of bookings from all over the world. It makes sense for them to split the data by country, by continent. And this is what partition does. It splits your table into multiple tables each with certain rows which match a condition. We did not have this default case before. So you had to enumerate all the possible combinations. Now you just add the default here and it will catch everything else which was not caught in the previous rules. Here we have odd and even. And in case you allow null values, this goes into the third partition. Now whenever you do a transaction, you need to lock either rows from a table or the metadata from a table if you want to alter that table. If there are multiple transactions, they have to wait until the previous one finishes with its work. And you may not want to have it wait forever. So you can set a timeout. Previously, you could set this timeout with a session or global variable in the server. But you would have to always set it and unset it if you wanted to change this for certain queries. Well, now this is integrated into queries which require locking. So you can just specify this here and it will only affect that query. It's basically variable value per query. Now this one's interesting. This was actually contributed by a student I worked with last summer. So there may be functions that are in other databases that are not available in MariaDB implicitly. And you can use user-defined functions to simulate regular functions. Over the problem is with aggregate ones, it's hard to have them behave well when you have groupings and other modifiers added to them. You can now actually specify custom aggregates using regular SQL syntax. So the way you do this is you define the function with the aggregate keyword here. And you need to think about it in a couple of steps. So first, what should the function return once it finishes going through all the rows? This is covered here. So whenever we're finished with that group, we're going to return whatever is here. Now the logic in the function has to be in a loop because you need to go through multiple rows. And whenever you want the next row in that group, you have to call fetchGroupNextRow. So after this call here, the parameters which are here are going to be set to the next value in the group. So this allows you to define quite interesting functions. One which is very useful and is frequently requested is actually median. We have plans on supporting that natively, but right now this is an alternative on how you can get it to work. It is not currently available in the first alpha release, but it's coming up in the next one, which is probably in a couple of weeks at most. And now let's talk about Oracle compatibility. So this is the main focus on this release. We're trying to make MariaDB work with Oracle-style syntax. In order to enable this syntax, you have to set SQL mode equals Oracle. And then all sorts of syntax constructs from PLSQL are available in MariaDB. The reason why you need this mode here is that a few syntax constructs are incompatible with MariaDB syntax. So you cannot support both at the same time. It's either one or the other. For example, labels in MariaDB, they resemble C-style labels while Oracle has greater and lesser signs between the label. Also, Oracle needs a different order for out and in and in-out parameter types. This is supported in Oracle syntax. This is in Maria. Oracle also requires a mandatory as keyword when you're creating a function. MariaDB does not. If you do not specify the as keyword or is, it will return an error if the Oracle mode is activated. There is a correspondence for the exit statement, which Oracle allows. So if you want to exit a certain block, you can use leave in MariaDB syntax or exit in the Oracle syntax. You can also set variables using MariaDB syntax with equals or Oracle with dot equal. This works with system variables too. So if you have something which is not only using store procedures, this will also work. You can define exceptions in MariaDB and in Oracle, but where you define these exceptions and how they're handled is different. So MariaDB has them initially in the top. Oracle has them at the end. With Oracle mode, this works. Also, there's a difference between in-out and in-out. This is MariaDB. This is Oracle. This was a simple change in the parser, but without this, it would not have worked. Also, there is no longer just a value. It can also be a statement. You can have it not to do anything. Now, there is also a problem with return. So Oracle requires you to do return when you're creating a function. MariaDB required returns instead, so it was create function f1 returns int. Oracle has a return int. We now support both. And also, you can now use returns in stored procedures as well. Before, you could only return it from a function, because only a function can return a value, but now it also works to finish execution of a stored procedure in MariaDB. While loops, you could execute continue like in a regular programming language with MariaDB, but the statement was a bit confusing. We now support a continue statement, so it tells you to basically go through another loop of the while loop. And there's also this matching between data types. So varchar2 is synoned into varchar, number to decimal, date to date time, and so on. So all these were necessary in order to support PLSQL syntax. The good part is that these were not actually too complicated to do. And this is a list of multiple different features, which we had to add. One of the key ones is we now support for loops. So we could use while to simulate a for loop, but now there is for loop syntax available. And all these are oracle attributes for cursors. I'm not going to go through all of these. I will have this presentation available, so if there's anything that you think you're missing from this, you will be able to find the presentation of problem. I've already mentioned go to statements here. And now... So these are mostly details. I don't want to go into too much about those, but let's look at things that are not yet in 10.3, but will be before this release freezes its features. So package is basically like a namespace for functions and procedures. It's currently supported in Oracle. We will support it in MariaDB as well. And hidden columns. This is one of the more interesting aspects. So how do hidden columns work? Well, for a regular column, if you do select star, it's going to show up in the data results. If you hide the column, you can hide it depending on how hidden you want it in various ways. So you can have them a little bit hidden and that if you do select star, it's not going to be visible to the application. So in case you have a legacy application which does select star, you can hide columns which are adding in your newer applications. But if you want to use them, you just have to query them explicitly and it will work. More hidden columns are hidden if they're not explicitly queried, but this also affects create and alter statements. You can think of them like a pseudo column. These are quite frequent in Oracle. So if you specifically mention that column, it gets generated for that particular query. Or very hidden. This is mostly oriented for performance. If you know that a certain column, if computed, will speed up queries based on how the optimizer will fit. We'll find query plans. You may want to just create this column and have it only on the database side. So the keyword here is that this very hidden column may be indexed. Also, we do support compression, but you can now also compress individual columns. So maybe you want to have some which are not compressed for performance reasons whilst you want to compress others for storage space reasons. And then spider storage, which is a distributed storage engine, is going to be updated to the newest release. Things which we would want to have, but we're not sure if they're going to make it, is an update for Galera 4. I think we're still waiting on them to provide it. Data types, arrays, support for time zones. And sub partitioning this may come in. It's not really that complicated, as well as table functions which are a natural progression following the row data type which we now have. All right, that's about it when it comes to features. I hope this was not just a full, just a long list of things. So now, if you have any questions, particularly about MariaDB, even a 10-1 version which is now in Debian, I'm more than happy to take any questions. So let me see if I understand the question. So the question is if there is a big difference between MySQL 5.7 and 10.1. So there are differences when it comes to the data directory. MySQL has done backwards incompatible changes in the data directory, so where it stores metadata about users, procedures, etc. But we have tried to make it work as much as possible. So you should not have any immediate problems when you're migrating. The potential problems are on the replication side. So if you're using a master-slave replication, the implementation for global transaction IDs are completely different. They are not compatible with each other. We try to support MySQL's replication statements, but we do not support their full set of features there. And it doesn't work the other way around, so MySQL will complain horribly if we try to use MariaDB as a master. The thing that I can suggest to you is to first make a backup. That's a sensible thing to do. Try it out, see if it works for you. We've had large corporations switch from MySQL to MariaDB, so it is possible. If you have big problems, you can always ask on the mailing list. We are very active and responsive. It's just that for the regular user, this should not be a problem. One question from IOC, actually. I'm not sure what he means by that. Does MariaDB have any plans to support data warehousing? Yes, so how does this IRC thing work? They're basically looking at the live stream, right? Okay. MariaDB is trying to move towards the data warehouse market. This is mostly driven by the MariaDB Corporation at the moment, so not the MariaDB Foundation. If you're interested, you can look up ColumnStore, which is a storage engine specifically aimed at analytical queries. That's probably the thing to look at. It's still open source, so it's still available. Probably the version 10.2 is where you're interested in, because that's where we support window functions and commentable expressions, things which are very used in analytical queries. Is it all using Python with MariaDB? Does it work similarly to the Python interfaces to MySQL? Are there particular libraries that exist? The VConnector for Python MySQL works for MariaDB. Sorry? The Python connector for MySQL plays nicely with MariaDB. Anything that works for MySQL should work for MariaDB in this case. I personally have created a few websites using Django, and they are running on the MySQL backend, but running MariaDB as a server, and it works just fine. In converting from an Oracle database, I'm thinking of a specific database that has lots of stored procedures and things like that. Can you talk about the process of coming from that database to MariaDB? I don't have personal experience with migrating directly, but I know that there are companies who are doing this right now. I think the best approach is to actually ask on the mailing list and see if there are people who have direct experience with migrating. There probably will be. The way I would tackle the problem is to slowly add the stored procedures directly. You should copy-paste whatever code you have to create your database in Oracle, move them to MariaDB, see if everything... you don't get any syntax errors, and then see how you can port the data itself from Oracle to MariaDB. Another question online. What's the difference between the foundation and the corporation? Okay. So the foundation is a non-profit organization. The corporation is a for-profit organization. The foundation has copyright over the MariaDB server code, and the MariaDB foundation has the final say when a release happens and what it contains. If we think that something the corporation really wants is not in the best interest of the community, the MariaDB foundation has the final say in this. And now if somebody is concerned about the independence of the foundation, it is true that the corporation does sponsor the foundation. It is one of these sponsors, but it is not one of the largest sponsors. So there isn't the financial incentive if you're worried about that. There was an announcement about this, I think, in April, where the corporation is funding about one-sixth of the foundation's financial resources. I think now it may be even less because we've had larger sponsors come up. What the corporation does provide, however, is development resources. So the corporation is one of the major providers of software engineers that will work on the MariaDB server. Then again, if these developers are doing the wrong thing, the foundation can just say no, this is not what we want. I hope that answers your question. Just curious you can feel free to refuse to answer, but I'm just curious how Oracle may perceive the compatibility. I'm not aware of any other products or any other projects that have taken on that, kind of directly saying that we would like this piece of the market. So I'm not quite sure I understand the question. My question is, do you know or do you feel that Oracle will have strong thoughts about this compatibility being added to MariaDB? I tend not to think about the commercial aspect, because I don't have any stake in this commercially, but our view is that we want people to make use of open-source software, and the barrier is the transition between proprietary solutions and open-source solutions. If we can help ease this transition, then it's a win for everybody. If there are no other questions, I also held Reddit to ask me anything around March, so if anybody is interested in hearing more of my view on how MariaDB works, you can find it on reddit slash MariaDB. I think right now it's about page, second page of the list of topics, but I do provide a few points, especially when it comes to open-source development. I thank you everybody for joining my talk, and if you have any questions, I'll be around till the end of DebConf. Thank you.