 Okay, fantastic. So we'll talk about MySQL 8 today. And because that is a short version of my usual presentation, we will just scrap all the stuff which are for developers and only focus on ops. Now MySQL 8 has been making a great strides in getting close to GA, and it's now released candidates, but it's still not GA, and things are still being changed, right? So this is kind of based on, well, anyway, just know what things are subject to change. And so you know, to give a creative and a creative view, I borrowed a lot of very nice pictures from Oracle team, blogs, presentations, documentation, and so on. Okay, so what are nice things in MySQL 8 for ops people? Well, there are, I think, a lot of great stuff which are in MySQL 8 in the areas of stability, high availability, performance, security, availability, and manageability. The first thing which excites me a lot is a native data dictionary, right? And this is something that is very internal, but also very important, and I would say is about 10 years overdue at this point. What is all about, right, and one focus on operations with care? Now, if you look at the MySQL, before MySQL 8, it will store table information in what so-called FRM files, right? One file per table. And then, if you use in a DB table, it would also store a copy of information in a system table space, right? The problem with such setup is what this data can be getting out of sync. For example, if you would have MySQL to crash in just the wrong time when you were doing alter table, you could have this data to be out of sync, and you have a lot of fun, money recovering, right? It also would not be quite atomic, right? If you do the single drop table or the name table, right, that would either really succeed or fail unless you crash. But if you have some sort of more complicated scenarios, for example, if you have, you know, dropping several tables one after another, before MySQL 8, that would not be atomic statement. You would have two of them drop successfully, then one of them mode to be non-existent, you get an error, right? Boom, half done statement. That is not really what you would expect from our other statements. And MySQL 8 fixes that. We also have, for that, much faster information schema, because now it can read from those real data dictionary instead of having to scan a lot of FRM files, and also no more MySum system table requires. And that is another reason why and how you could potentially have non-transactional behavior in the future, right? You would be creating stored procedure, which goes in MySum tables. Boom, you crash it at exactly that time. MySum tables corrupted. What the hell are you going to get there instead of stored procedure? Well, no one knows. Information schema, that is a great, great example here. And we can see this query with a join on information schema, which used to be pretty much unusable, right? Even with relatively modest amount of tables, it could take many minutes. And if you would go to a million table in this case, it would not complete even in 40 hours, right? Now MySQL 8 is able to handle that quite efficiently. And even if you have a million table, well, it will take you a bit of time. But 78 seconds, that's still usable, right? With such a large amount of tables. UTF 8, an area where MySQL 8 got a lot of focus. And why that is important, especially right now, right? Because even if you are using some of the Western languages and generally do not or did not need UTF 8 beforehand, then now we have in all the applications, we have what? Emojis, right? And emojis require really UTF 8. So if you are having kind of millennial friendly applications, then you need to use UTF 8 wherever you actually need support for languages which don't feel in Latin 1. And in MySQL 8, UTF 8 and before becomes default. And also a lot of performance work has been done to make MySQL much, much faster than it comes to UTF 8. I would also be talking about the case when MySQL 8 actually becomes slower. But that is typically when you use the Latin 1 character set. Now a lot of work has been done a lot about security as well in MySQL 8. We support for roles. Now we have many different privileges instead of super privilege, right? Where you can, for example, give somebody access to restart the instance, but not necessary to do some maintenance, some other maintenance stuff. There is a password history, so you can say, hey, we don't allow you to set one of your previous passwords. Authentication, in this case, has became much more secure with SHA2 authentication, which actually used many, many rounds of SHA2, right, for password hashings to make the brute force attack much more complicated. But it also has a very specially optimized cached version, so it can authenticate the match very quickly at the same time. Open SSL is now used both of community and enterprise edition, right? So there is no this kind of confusing differences in behavior and available options. And another thing I like is what now skip grants block remote connections. In the past, we see many, many users would get into security incident because they need to reset the password. So they start MySQL skip grants and they forget about that and what they get. MySQL open to all the internet and now accepting connections with no password, right? Now, that's not going to work. If you're resetting the password, it will be only MySQL accessible locally for until you recover the password and restart it back in a normal way. Encryption is also improved. In MySQL 5.7, there is a great start in the encryption, which does encrypt energy with table spaces, but that would not encrypt things as your redo logs and undo logs stored in the system table space. In MySQL, it fixes that. So all the information stored in the database is being encrypted. Another thing, persistent after increment. And I think I would say about 10 years overdue, right? So now, in this case, you would not have a case where your after increment value can be reset to something else in some scenarios, right? And you would not have a chance to get duplicate IDs and stuff like that. After manage and do table space. That is another area where I think a lot of folks involved in MySQL operations had a lot of problem through years, right? What would happen before is if you have some expensive update queries or just a select query which was running for a long time and other queries created a lot of undo space in the DB, you could have that space being sort of, let's say, stuck forever in the system table space. And the only way kind of to get it back would be to recreate your database. In MySQL 8, you have undo table space. Those are stored in a separate table space by default. And then it's also automatically purged. So if you need it for some space for a period of time, you use it. Then all those workload completed, it will automatically shift the machine back. Self-tuning for in a DB also I think is very important, especially in the cloud. Now, if you enable this option in a DB dedicated server, then you may be able to set a MySQL and it will automatically scale if you're instant size in the cloud, for example, by setting at least three most important variables appropriately. It is not complete and I think there could be a lot more stuff than with automatic tuning that has a great start. Now, partial update of JSON. That is also another very important performance thing. If you are storing docs, especially large documents in the MySQL, actually even in something like MongoDB, right? Because if you're just updating one field, maybe there's a counter, maybe that's a little some stamp, you need to update it. You don't want the whole document to be kind of completely written in the database. That is very expensive. MySQL 8 can now just update that field inside the document without fetching that and storing it back. Just you have a very small point update and also it can handle that efficiently through a replication. Where you would also only log the change in a row based replication for JSON field, not for a whole big row if you choose so. Invisible indexes, that's another feature I filed in many years ago. And the problem of the indexes is they're easy to add but they're hard to drop because it's hard to be quite sure what that index is really not needed by your application. And if you drop the index which you turned out you actually need, then you often would have queries run so slow it will cause you downtime. And then it may take you many hours to go ahead and rebuild that index back because that's expensive, right? Now what you can do with MySQL is instead make that index invisible. So it will be still maintained but not used by the optimizer. And if you support what there are some queries you still have which needed, you can make it visible back instantly, right? And if it's actually not needed you can drop it in a week or a month or wherever you think is appropriate. Teampeatable storage engine, that is actually one of the things how UTF-8 was optimized. It's much more efficient storage engine for internal temporary tables which are used for many complicated group by queries. And what it provides is much more efficient storage for this temporary data especially if you have VARCAR and VAR binary columns. Now right now it doesn't deal with Globe and Text columns. They'll still would require in the DB temporary table. But those are to be fixed as I understand. Backup logs, that's another neat feature which allows us to prevent inconsistent backups result sometimes, right? So now you can set the special local backup which would ensure the backup can be taken successfully. And it would only prevent some only rare operations. Your normal traffic would not be blocked by this log instance for backup. Optimizer histograms, that gives us a detailed statistics on columns, not just indexes. And it really allows optimizer to do much better choices in many cases. And what is interesting in this case I provide as an example, this statistics is stored as JSON, which makes that much more extensible. And I hope that will allow my school optimizer team to roll in more statistics or different format of those histogram information without needing to redesign it completely from scratch, right? And wait for many years for a new release. Another fix or improvement in the optimizer is improved cost model, which allows for example to keep an account how much data is sketched versus is not, right, which you have to fetch from a disk. Here's a link with some blog post about more information, but in general that can be very important to get the good execute or better execution plans for some workloads. In my school optimizer, I'm actually some other helpful changes. I don't have a time to cover them all, so here's a link for you. An official MySQL guide, it has some more information about MySQL 8 optimizers specifically, as well as some other features. Performance schema is getting much faster as well. And partly that is through having indexes on performance schema. The interesting thing about the indexes on performance schema is what we are actually fake indexes, and the internal information schema just pretends as it has indexes, and just because it's in memory and can scan the data so quickly, that provides their much better execution plan in the works quite neatly. It also has error instrumentations and response time histograms, both global as well as per query digest. And also includes query examples in summary by digest so you can actually take the query example for some slow query and run explain for you to see why is it slow. Here is example of a performance schema performance, right? Looking through the built-in session table, which was designed as a sort of better show process list. But unfortunately in 5.7 it wasn't usable with large number of sessions. So 1,000 sessions would take 30, 40 seconds. That's not as much as you probably would want to wait for a show process list. Now you can see it takes a second or two even if there is a large number of sessions available. Remote management features, I think the speaker before me mentioned and shown action restart common, which I think is fantastic to restart the index. And another one is set persist, which is another very great common which allows us to set a variable to be persisted when it instantly starts. Because there are so many MySQL users would set the global variable to some value and just not modify MyCNF, keep MySQL running for a few months. When restart and boom, it behaves differently is much slower or wherever else you may have changed. And nobody really understands why because that change was long forgotten. If it says persist, you can ensure what those things don't happen. MySQL also assumes defaults is SSD right now, which is great. Not a lot of things are done for that as of yet, but that is good to change in direction at least. MySQL is also prepared to be able to ask as a replication master by default. Binlog is enabled, logslip updates enabled and log expire by default, right? So you don't need to do anything to prepare that to be useful for configuration. Query cache is removed, right? So if you need the query cache, then you probably should be looking at ProxySQL, right? Or you may have some other caching solution in place already. Native partitioning. So generic partition have is removed in MySQL 8. It was kind of substantially slower than native partitioning. That means if you're using storage engines like MySum, which does not have a native partition support, then you would have to either remove partitioning from that or convert it able to in the DB before upgrading. Resource groups, that is another cool stuff where you can essentially map some of the queries in your workload to specific CPU cores, which can help you to reduce the contention. But then, B, it also allows you to kind of to jail some of your expensive queries, right? So for example, maybe you have some analytical queries which can be very expensive and if you let your analytics team to run while they'll consume all the server resources, you can set it so they only are able to use no more than let's say two or four CPU cores and that's it. We also get the better performance at scale, right? You can see with MySQL, again, if you have a really big RN and really large number of concurrently active threads, it can beat the previous MySQL, MySQL versions. We also like what a lot of stuff we can use in our Percona monitoring management solution in MySQL 8, especially much faster performance and information schema and more information available in performance schema is great and allows us to build a lot more features out there. Okay, now things which are not so great, alcohol and feature requests. The single thread performance still sucks and we don't have a parallel query support as of yet, right? And hopefully that will get to roadmap sometime, sometime soon. Here is the graph, right? From the champion of MySQL single thread performance, Mark Colligan, right? And actually I chair picked one with the worst regression, right? Guilt charge charge, but you can see what for some cases, we have less than half performance in MySQL 8 as we had in MySQL 5, right? So I think that is something we would like to see some reverse, right? And it doesn't have to be this way. There is another database which is called SQLite, which is able to both add the new features in the new releases as well as have single thread performance being better release after release. And the last thing, if you guys are interested in much more information about MySQL 8 and MySQL and other open source database in general, we welcome you to come to Santa Clara in the United States. We will have a live conference out here. Just want to let you know. And that's it, and I think I still have a whole three minutes for questions, right, Fred? No questions, yes. So, you mean information schema? Well, yes, pretty much instead of in the internal data detection, right? And the FRM files, now we'll have just one data dictionary. Any other questions, thoughts? What? Memory engine, what about memory engine? Well, so the question is, is memory engine going to be replaced, right? So now we have this team P table engine which is designed for in memory temporary tables. And those tables have a very specific workload which is needed to resolve the queries. Now, wherever that engine is going to be at a future time exposed for general purpose use, I honestly don't know. Okay, well, thank you. Yes, let's make space for Sviada.