 Well, I'm going to talk to you a little bit about MariaDB server 10.3 and I'm happy to talk to you also about other things like community developer relations and so forth. And thank you Oracle for sponsoring this track because we realized that MariaDB is also kind of important and that was absolutely no talk about it, no unsubmitted. And Harish, who was one of the organizers of Boss Asia a while ago, was asking, you know, would you go and use MariaDB or MySQL? And actually the answer is really depends on your use case, right? They're now two fairly different databases. They're not the same anymore. With the exception of Nebisa, very nice folks say Alibaba will actually run services on MySQL and then port things to MariaDB so that it can go upstream. Most people are just going to be like, hey, I'm going to hack on MySQL and make MySQL better and that's what other people like, for example, Facebook do when they migrate stuff and Percona as well. So I think things are changing and Red Hat very famously in Enterprise NX7 actually went to use MariaDB as a default, but that's pretty much when everything starts diverging around the Pi Pi times and if you're sticking around this track, I think they're excellent docs and 80s so plenty of diverging. So MariaDB server, I actually took this straight out of the website today, MariaDB.org. It still claims to be an enhanced drop-in replacement from MySQL and frankly that is false. It is not an enhanced drop-in replacement from MySQL, it is a GPL fork of MySQL by Pi. It has some features that are different from MySQL and MySQL has some features that are different from MariaDB and some features may be the same but most of them are fairly different now. So it's not a full drop-in replacement. You can upgrade still from say MySQL 5.7 to MariaDB but if you want to crossgrade which is what the Debian people face a lot because Debian actually went all in on MariaDB and if you want to crossgrade between say MySQL and MariaDB that's not going to work for you. If you want to replicate between each other that's also not going to work for you because global transaction IDs have changed. MySQL has a different global transaction ID format compared to MariaDB but you can attach a MariaDB replica to MySQL master and MariaDB will throw away the global transaction IDs that it gets from MySQL and generate its own. So you can migrate to MariaDB. It is much harder to migrate out and migrating out would probably require a dump and restore. However, there are some cases where even a dump and restore will not work like if you use data types like the decimal data type. MySQL's decimal data type limits 30. Is that still true at 80? Yes. MariaDB decided to extend it to 38 to make it more Oracle compatible. So if you decide to extend it yourself and then dump, you are not going to be able to restore. That's not the only subtle change. There are many other subtle changes. Data types are just one of them. So this is a wonderful diagram of divergence and you could generally say MySQL 5.5 is a sport with a bonus of a 5.5 and MariaDB 5.5. MySQL 5.6 was kind of a bit of a rewrite compared to 5.5 and 5.7 and 8.0 are even further rewrites. MariaDB stopped merging after 5.5. MariaDB started cherry picking patches after 5.5. So this is why not all features are included. And I think that's a very important milestone. For 1.5.5, there's a lot of people who love MariaDB and use MariaDB. Yesterday, I was on a phone call with a client and they were like, oh yeah, we're using MySQL. It's 2019. Why? So people still use MySQL. That's unfortunate. 5.6 also brought us a lot of optimized improvements in MySQL. But MariaDB went their own way from 5.3 onwards to have optimized improvements of their pool. So the optimizer is, for all of these purposes, not the same. And then just to add some confusion, MariaDB, if you go to MariaDB.com, what documentation is, you'll find that there's this thing called MariaDB TX, 3.0. I don't even know why this number exists, but TX, it turns out, is a combination of the open source MariaDB server, which you get from MariaDB.org, and it is services, maybe not fully open source, from MariaDB.com. So you may be able to get things like connectors, which are LGPL. Lots of people love the LGPL connector, so Amazon will encourage you to use it with Aurora, for example. But then you also get access to things like MaxScale, which is a proxy that is not open source license, right? It's business source license. And so you have alternative proxies that one could use, like proxy SQL that works with both MySQL and MariaDB. There is another wonderful proxy called Router, which I think, at least there will be one talk about here later, when it comes to the UDB cluster stuff. That does not work with MariaDB. Now, of course, there's MariaBackup, which is a for-properly extra backup. That's open source. SQL log and on-log are not open source, but they are used as well. And then for added confusion, there's also something called TX cluster, which includes support for Galerite cluster. Galerite cluster is based on the same paper that group replication is based on, and I guess it's been around for a lot longer than group replication has. It's been around maybe since 2008-ish. So it probably has a lot more uses than group replication in production, but I suspect group replication is also getting a lot of investment from Oracle, so we're going to start seeing some significantly useful synchronous replication solution that people start adapting. And I don't know who will adapt it first, but in a wide-scale fashion, but I expect that will happen. And then there's also this thing called AX for columns. A column store is actually fully open source, but it's not integrated into MariaDB server. It is based on Infinity B, which surprisingly, Oracle only copyrights to when they picked it up at the bankruptcy court. So anyway, key points from MariaDB 10.3, which was announced last May, so 10.4 will come out this May. It has Oracle compatibility, at least some semblance of Oracle compatibility. How do you use the Oracle database? Show that. Anybody write PLSQL here? Okay, so if you fancy not a group, Oracle, for your database use case, you may consider my rating for Oracle compatibility, and I think one of the biggest use cases that have been promoted by MariaDB cooperation for this is Singaporean company, actually. It's a famous bank. Can anybody give me a guess as to which famous bank in Singapore has migrated to use Oracle compatibility from MariaDB? DBS? DBS, yes. So there, I guess, yeah, one of the, I think we migrated some 30 odd applications. I've got to be careful what I say because it's being recorded, and I don't work at the cooperation, and I also want to make sure I don't say anything that's not public. So yes, Oracle compatibility. Lots of people seem to like it. Now, is it equivalent to what you get in Postgres? The answer is no. But is it maybe 80% of what you get? The answer is probably yes. You'll probably be the 20% that get annoyed when something doesn't work, and then you know, because it's open source, you cannot contribute to make it better. Plenty more storage engines that people could use. So MySQL is all in on InnoDB, and MySQL 8 comes with another storage engine surprising that it's not InnoDB called Temptable. The Temptable storage engine, yes. So of course it's got my eyes on it still. But the reality is MariaDB ships things like MyRock, Spider, and we have slides of that as well. Temptable data, which is system version tables, this is something new from the Oracle, from the SQLs that are not from Oracle. It's from SQL 2011, and it doesn't exist in MySQL yet, probably will eventually. And of course it's got some features from earlier versions of MariaDB that are most likely, that may not be MySQL, and I'm going to highlight only those features because the reality is, MariaDB may catch up, but MySQL eventually may catch up, but as of 10.3 I'm going to mis-focus on what was not available. So in terms of releases, MariaDB aims to release cadence now of once every year around the May timeframe, and the 10.4 is released candidate already. From what I gather, Oracle's release cadence is around the 24 month plus mark, because they only want to support two releases at any given time. And it was noting that, for example, 5.5 is end of life already. It was end of life last year. And this is going to be interesting from a security-reporting standpoint because you're going to start finding that there are MariaDB bugs that exist, same in MySQL 8, and maybe don't exist in MariaDB and MySQL 7. So MySQL and MariaDB, of course, are very unique when it comes to storage engines. Well, they were very unique. To be fair, MongoDB, for now, about three audios, have this capability of having multiple storage engines. But what MongoDB ended up doing is they basically said, look, we like this Wi-Tiger storage engine, so they integrated it, and they've deprecated and disabled MMV1, which is the out version of MyISM. So I think MongoDB is a little ahead of MySQL from a deprecation standpoint. And it's also much easier to write a storage engine for MongoDB than it is for MySQL. MySQL, you have to provide for index types, if it's got transactions and all, you've got to provide for backup strategy. If it has foreign keys or not, JS functionality is not provided by the engine. It's provided by the storage engine itself. Full text search capabilities and so forth. Lots of things make a difference. And MongoDB, if you type show engines, is the smallest board of engines. It has so many storage engines that it looks really tiny on the slide back. So I have slides dedicated for, say, MyROMs and slider. You know, MongoDB is the default for read-write applications, as I've been for a while. It used to be Prokona XDB, but although it actually features, it's going to MariaDB anyway, to be fair. It has been migrated towards InnoDB upstream. There's not much variance in XDB any longer. And they also have a couple of InnoDB hackers working at MariaDB now. ColumnStore is not included, as I mentioned earlier. OQ Graph. So what I don't have slides for, as an example, is OQ Graph. And it also actually still gets changes to it. It's got something called the leaves algorithm that actually returns all the reachable leaf nodes. So you can do graph-based queries in a relational database. Now, if you ask why you should use OQ Graph over Neo4j, my advice is use Neo4j. Like, OQ Graph is kind of like a little toy, so to speak. It's a toy graph. The partition engine, which is now still part of, it's going to be, obviously it's part of MariaDB, but it's not part of MySQL 8, because partitioning is now built inside of the InnoDB engine. But partitioning is how spider works. And we'll have some spider as well. Cassandra is still around. So if you have a Cassandra engine pre-Cassandra 1, it can actually buy and live through, actually allow you to run SQL queries against a Cassandra back end. Should you use this today? My answer is also no. Don't connect. This is actually quite an interesting engine, because it can read, say, MongoDB, it can read JSON, it can read DB4. Anybody use DB4 before? Because DBase4, basically. If you still happen to have something that exists, you know, files, you find a floppy disk from 20 years ago, and you manage to find a reader, you can actually open up your DBase4 files with connect. It's still kind of good for ETL operations, like you make all DB's connection and so forth. There's also another engine called TalkUDB, which is basically engine focusing on good insert speeds and compression. But I suspect that eventually, MIROX is once going to take over that use case. Probably have to go much quicker now, because I only have about 10 minutes left. So 3DB has a bunch of aims around storage engines. It wants to be a general-purpose database with many purposeful storage engines. So the 3DB idea is you shouldn't be going out there and using a time-series database or a graph database. Use 3DB for everything. And that might have been true all time ago, but your database professionals see it well. It's, of course, the good use cases. But with many storage engines, it also means that you can maximize the strength of the engine and minimize its weakness. So what is MIROX? MIROX is an engine that Facebook made. It's a fork called LabelDB. And it's an interface to ROXDB, and it's good for write-optimized workloads. You need to install it. If it's not there by default, you've got to then load it up. Basically, you install its own image at ROXDB. And it turns out that Facebook has migrated most of their workloads from ROXDB to MIROX. And they've actually managed to stay running with less hardware. So the compression is at least maybe 2x for them. CPU usage hasn't increased. And it's not based on a balanced B plus tree. It's based on a log-structured moj tree. And it's good for compression workloads. And it seems to be good enough for write-optimization. The other thing that MIROX does is apparently also has less write amplification. So it's generally quite good in terms of extending the life of your flash. Presumably most of you are using flash and not spinning disk anymore for your databases. All your laptops are flash mounted. You probably can't buy spinning disks anymore. So you can load data really fast. Also, you can avoid your compression domains. It also has something called range-free replication which basically allows you to make sure that you can migrate easily and also give you greater performance. My recommend reading is because there are variances in MIROX implementations. So there are three variants of MIROX implementations. One is from the Facebook MySQL 5.6.3 which you should never run unless you know what you're doing and how to do it yourself and nobody will support you. Then there's Pekona server. So you've got MIROX with Pekona server and you've got MIROX with MariaDB. So far, nobody is making just MIROX with MySQL yet. There is the spider storage engine which allows you to transparent reshard and reshard via SQL. So spider is kind of interesting because people like to shard the databases and sometimes they want to reshard because we've got one user who's sending too much data. So typically, if you're running a web-scale service this could be one shard and that could be one shard but because she loves to upload a lot of photos so she maybe needs to be rebalanced to another shard possibly and sharding is easy. It's the resharding that's hard and sharding is something that MySQL doesn't seem to really have built-in generally speaking so they have frameworks like Tumblers, JetPants, CNCFs, BitS which ours YouTube so if you ever go to YouTube you'll be looking through actually querying MySQL via BitS and BitS is like fully baked with food and anything stuff but spider's aim is to ensure that it's fully baked inside the server and you can write SQL queries to reshard and you can make shards via SQL they've made some improvements around the partition storage engine as well as the ability to have condition push-down which means the conditions get pushed down to the storage engine area and typically spider needs to be backed by InnoDB as well so you can't use all the fancy engines that we talked about earlier but you can use spider with InnoDB and really it's likely to push spider forward because the lead developer of spider now works for that and this is an example of what you do with spider so your application will query many table one and it goes looking at a bunch of rows which are basically spider positions in the back and you can query large, large data sets now with spider proven there are definitely customers that use spider out there that if you go to the InnoDB you will actually see a list of them even is this going to be more famous that's hard to say should you bet on your test also hard to say but it's all open source so go for it and try storage engine is excellent but you can mind there are always limitations encryption for example does not work with Myrox encryption only works with InnoDB and RAF-Temporary Table Storage no cluster only works with InnoDB as a back end so a lot of things tend to work mostly with just InnoDB first that maybe eventually become more expanded to other engines so there is lots of compression available as well so you've had initially your work compression then you've got page compression and now you also have the ability to have column compression the only supported method for column compression with dictionary support is Xenium in MariaDB now this is a feature that also Protonus has and there are other compression methods besides Xenium this is an example of compression so you can just show status by column and we'll tell you how many compressed columns there in this case one so dictionary support is something that exists in both variants invisible columns allow you to basically remove dependencies on applications so in this case we've created a table with a secret column and then we inserted some data and then when we do a select even do a select star we actually only get the ID and name back and not the invisible default column and if you do select hiding any secret then you actually get it back and you can actually add columns to the tables without hiding them from an app which otherwise may fail to run maybe changing your schema down the line just keep historical columns that the new application doesn't have access anymore you can hide system created columns and basically a select star will not actually show it so this is something still unique I guess to MariaDB there is the ability to have instant app column but this is not as exciting any longer because MySQL has it as well it was made about in an 8.0 release it was contributed by 10 cent and remember adding a column typically you could be problematic because you could get an application lag and you need to have previously copied the data but here you go isn't that a column now system version tables this I think still makes MariaDB kind of unique at the moment maybe MySQL 9 will have this too I don't know maybe that's the other thing that MariaDB has going for it is that all the plans are on JIRA so MySQL opens up their workloads when they decide it's time to open them up MariaDB has it available on JIRA so if you are judicious and you'd like to go searching for what's coming up in the roadmap for the future you can go check on JIRA now system version tables you all can read that typically it can be used for forensic analysis maybe legal requirements data analytics it can also be used for point of time recovery recovery table state or particular state and you can also make sure that you also get a timestamp version of the data so you can track changes inside of the database again this is really really good to work very well and you can try for running that engine and you may actually start seeing big problems and of course you can also delete history so here's an example of system version tables I apologize it's kind of small but in this case a greater table called employees and I've inserted employees that call in me is $1,000 as a marketer a month then $1,000 living in Singapore is pretty expensive it's too cheap right I mean what would I do I'd have to live on the street probably so I decided to tell the company now I need to learn $10,000 $10,000 is about the average Singaporean yeah but of course we can't pay a marketer $10,000 it's pretty insane so you've got to move to engineering now so that's actually what happens in this particular example so then you can go back in time so now I'm in engineering I only have $10,000 and I can actually live in Singapore and then come to Southeast Asia but if you want to look at history we can go back and see that I made a mistake I jacked my salary up to $10,000 I actually issued $10,000 and then you also do things like select staff from employees from system time now might as say an interval I'll say a year and you can get different stats back so you can go back in time for your database it's kind of nice and it leads on to this thing called as-of point in time and at that point in time I was always marketing earning $1,000 and trying to eat free in addition my skills always had auto-improvement but in Oracle they had this thing called sequences which allows you to have also number of fields for sequences it's not meant to replace auto-improvement in MariaDB but it does exist this is more for Oracle compatibility to migrate from Oracle now sequences show up when you do show tables so the way it's implemented is like a table so it turns out that if you do lock table it will actually lock your sequence your sequence generation so this is unlike other databases so not quite like Oracle but also available for you to use here's an example of sequences where you do these things like select max del sequence as opposed to actually getting auto-improvement and if you turn on sql mode equals Oracle you actually can use Oracle like sequences like sequence, underscore, meaning max del so only one person said they write plsql here but if you happen to write plsql you know that you can sequence, max del, packages exist there is compatibility like documentation here I highly recommend you to read it so I'm going to guess that most people don't use Oracle's database as much as in a false environment lots of people use Oracle's database and false APIs expect to use open source databases proxy support so if you use HA Proxy sitting in front of your mid-team application and your database typically you need a proxy protocol support it sounds like as a HA Proxy spec basically client connects to the query to be and then it actually has the ability to know what the client is as opposed to the proxy and this is good for various things including when you're setting up all the tables there's also some other good stuff in previous releases I'm just highlighting some of them things like receiving the speed of reading binary logs from the master decimals being larger, executing immediately there's one plugin to be fed there's also one from MySQL they're both different implementations MySQL might only be in enterprise release not the open source period table elimination if you do anchor modeling sql2008 standard that's something that's available in your statistics if you don't want to use performance schema and so forth there are a few other bits, slides will be available online don't worry if you want to check out this query you can realize that there's a whole bunch of nice stuff that MySQL has that really does not have and you may never have for example, based on functionality while it's there the operators are different so MySQL has 26 operators and we already have 20 and all the same I personally love this thing called the x-portable and MySQL says that if you have a query with an sql you can say I don't have any of this but this doesn't exist in my database but what we see here is 5.6.6 5.7.8.0 so migrations password migrations so if you have users who are using caching, shouts and physics in MySQL and inside the migrations in my database so all users are going to have to regenerate passwords my great users with M25519 in gravy and you migrate to MySQL you're going to have to do the same thing you're going to have to regenerate passwords because they're both different why don't you stop running passwords in users it's more compatible with old MySQL as opposed to anything else if you like optimizer nins, it's up there the optimizer tracer is also up there I love this because if you say I want to set the buffful size to something larger while I'm running I want to set the persistence of it so that upon restart it takes time there's something you don't get in meridity so I will be around here so if you have questions about meridity and its differences feel free to say hello or write me an email any questions like we'll take one question if you have one anybody from where did you get the presentation from where did you get the presentation 2019.fossation.org and slideshare I should have put that slideshare.net thank you