 Okay, good afternoon everyone. So I will take you through my journey, my journey with my school and through almost now two decades, not just one. And for me it all starts in 1999 when I was a student in Moscow State University. And the way you see there is snow here, right, because wherever you show Russia you should be showing snow. What is that? Okay, let's see, is that my phone? Maybe that is. Okay, yeah, and I got MySQL to be, to use MySQL in the first startup I co-founded in 1999, which was called Spylog, anything, you know, Russia, Spylog, what kind of startup is that? Well, it was not that kind of startup. It was pretty much Google Analytics of the days, and at that time we would use MySQL for those kind of things. Remember there is no Hadoop, there is no Spark, there is no Clickhouse, there is nothing else in the open source area at that time. So I got to use MySQL and I started with MySQL 3.23 Alpha. I was student, I was not thinking a lot, right, so I used the Alpha software version at that time, and actually I learned a lot through using that variation of software. Believe it or not, at that time the MySum was only introduced, and MySQL was kind of so small that Michael Medianius-Monte would personally reply to many of my questions. And actually, Monty is here today. Monty, can you wave? So the one and, no, not the one and only, but one of a few MySQL founders, the Monty is out there, so you can also chase him down for questions as well after the talk. Well, I didn't ask him, but you know Monty is always good for a good conversation. So what kind of challenges we had in 1999 with MySQL? MySum, that means MySum table locks, that is kind of very painful. My choice, using the Alpha software, we also had a lot of crush, so a lot of Elonian experience. And we also had some basic and funny problem by these days, is what the Linux version at that time would have 2GB file limits for many file systems. So you couldn't have quite large tables. And also with MySum, I had to face those problems of the table checks and repairs that were taken a lot of time. Now, in 1999, we had those MySQL tricks you guys are well aware of by now, perhaps, such as we would chart a number of MySQL nodes for scalability. And even because of MySum table locks, we would chart to have multiple tables and database on the single node to make those less painful. And we would have to build lots and lots of summary tables because I would guess aggregating large amount of data in MySQL was never quite pretty. Now, about the same time in 2000, the MySQL goes open source of GPL license. Before that, and I think many people don't know it, MySQL was not quite open source license. It was still available for free if you would use proper operating system like Linux. But if you choose to create pains for developers to build MySQL on Windows, then you would have to pay for that. In 2001, we get MySQL 3.23 when GA or stable. And that is also the time when in the DB storage engine was introduced in the MySQL Max edition as well as we had initial release of MySQL replication. Another interesting event at that time is what the MySQL was sued by Progress or a news fair company and there was this very famous lawsuit of kind of testing a GPL in the court at that time. Obviously, MySQL won and that's why it's still continuing journey. Now, for me, the challenges in 2001 was stabilizing in the DB. You know, usually I kind of jumped on that in the very early software and then I learned a lot and then I had a lot of downtime. But that is wonderful when you're running your own startup, right? You don't have a boss to fire you. So I could have those kind of experiments. And also we had to do a lot of work to get MySQL replication to work because MySQL replication first was kind of relatively simple. Hey, let us go ahead and stream all our update statements. Maybe we'll supply a little bit of metadata information at them like what was this time at statement execution or what was a random seed, right? But the early days of the MySQL statement replication worked only in most cases, right? Now, the next stage for me was in 2002 I joined MySQL and I did a little bit of development but frankly that was not my thing and I really transitioned to MySQL support and consulting and led what was called MySQL high performance group. In 2002 we were powering what was later known as WebPoint 2 and a lot of WebPoint 2 was based on MySQL. If you really look back at the companies founded in early 2000 and if you look at the open source databases, MySQL was by far their majority. It may not have been completely only game in town but was close to that. And focus for that was changing to the ubiquitous optimization, right? Or as well as working with a lot of those larger companies which would be implementing sharding. Also in 2002 we got this website which is called bugsmysql.com Now the interesting thing is before that MySQL was managing bugs through a mailing list and the goal was what there should not be any bugs in release. But the truth is that it was easy to achieve when you have a mailing list because you can just forget some emails but as soon as we got bugsmysql.com I think we never had a release where we have all the bugs for that completely closed, right? So that's kind of a funny thing, right? So if you want to promise there is no bugs in your software remember dot implement the bug track and database. MySQL in 2003 that is when MySQL 4.0 was released which had improved replication and query cache and it was the first MySQL user conference taking place back in Silicon Valley and I think that was a very important transformational for MySQL because we had brought so many people together to really compare nodes and really be able to face to face, to talk face to face rather than just communicating through mailing list and so on and so forth, right? So I think there was kind of really an explosion of MySQL adoption thinking and the best practice at that time. One of the pretty famous outcomes from that is talks by Brad Fitzpatrick from LiveJournal. Anybody remembers LiveJournal? No? Some? Okay. Yeah, so that was a pretty popular blogging software of the time which used MySQL and they really popular talk a lot about how exactly the things are organized in LiveJournal and that was well before it really became popular, right? Because right now we see all those Netflix, engineering blogs, Facebook, Google everybody mostly talks about how they're building things, right? But that was not too much so in the early 2000s. And what is interesting in this kind of backend architecture today we can see a lot of a very similar concept we still use building MySQL application. There would be some sort of your global database with metadata there would be some sort of shards with the user data you would probably have something like a load balancer there would be some caching, right? With memcache and so on and so forth, right? A lot of those concepts which are quite similar. So in 2003 if you look at what kind of best practice you would adopt from MySQL, one is caching from memcache. That became very important and popular, right? So if you can't have MySQL to handle the load, cheat by caching. And then also you would have a massive replication, right? So you would often have the MySQL node which would replicate to 10 slaves you would often have even people using hierarchical application that would have 10 slaves which each of them would replicate to let's say 5 more slaves and all the kind of really massive MySQL replication here actually became a common place. In 2004 MySQL 4.1 is available and I would call that first checkbox release because at that time a lot of MySQL focus was driven by sales and marketing, hey, how we can get the new features which could be done, you know, serve some customers, right, which are asking for them. So for MySQL we have sub queries which kind of were introduced to MySQL but were never quite optimized until many years later or prepared statements which I think are still in MySQL is by far less mature than, you know, Postgres or number of commercial databases. And that was also here where MySQL cluster or NDB has became first available. For myself, I started blogging about MySQL and I pulled out which is my first post on the live journal about MySQL which is talking about the fact that MySQL doesn't have a hash join and how you can work it around. The funny thing is what is 14 years later MySQL still doesn't have a hash join. So I guess that is still relevant. Now in 2005 we got MySQL 5.0 which I would call the second checkbox release which added store procedures, use and triggers but it wasn't kind of very well integrated. I would say, right, you would get triggers and we wouldn't quite mix with replication well and all this kind of stuff. But hey, you know what, you got a lot of checkboxes in MySQL 5.0. It almost looked like enterprise database at that point. But another important change to MySQL came when the protocol acquired in the base of the creators of InnoDB. Now the thing which I think is very impactful for MySQL outside of this community, we got a puppet release. And puppet was the first of a new generation of automation framework. You know, you think puppet, chef, Ansible which really started to ingrain people in new thinking. You should not be manually managing your databases because that doesn't scale. You should puppetize everything or, you know, automate it with chef and so on and so forth. That wasn't quite a common place in 2005 but that was the start of the practices. In 2006, MySQL was scrapped if InnoBase acquisition fell out because even by 2006 the most large scale MySQL users would be using InnoDB as a storage engine, right? So what MySQL did is what they bought a company called Netfrastructure and Jim Starkey, which was a Firebird founder, joined MySQL to implement the Falcon storage engine which was supposed to be a much better replacement for InnoDB. Anybody remember Falcon? Oh, yes, we have some here. What also happened interesting in this case is we started to have Hadoop being available, right? And why that is important because over years we have started to see some of those analytical workloads crunching through large amount of data moving from MySQL to Hadoop, right? Because MySQL didn't quite was created well for that. For myself, in 2006, I started on MySQL performance blog, right? And that was our pretty popular blog about MySQL performance for a long time. And you see, we picked here the WordPress theme, boxy but gold, which nobody else used and maybe you can see why. But that means even from very far, our website was very well recognizable. And that's also here what I started Percona to give to Vadim Tkachenko. And we were focused on performance. Percona pretty much stays for performance consultants, right? That's where the name comes from. And our focus was helping companies to scale, to optimize MySQL, and we really worked with a lot of companies using MySQL at scale at that time. In 2008, we got MySQL 5.1 coming out, which would include features like partitioning and row-based replication. Right now, again, all those features which we added, it was understood MySQL needs more kind of safe and a mature replication technology and statement-based replication. We also have some microsystem acquires, MySQL AB at that time. That's the first acquisition in the MySQL history. Another thing is what that is a year when we can see the board of a modern cloud. That is where Amazon EC2 has become generally available. And again, while the cloud was nearly mainstream at that time, that's when MySQL started its cloud journey. In 2008, we at Percona saw a lot of what I would call the dysfunction between Oracle-slash-in-ADB and Sun-slash-MySQL in this case, right? Because MySQL was really, while users wanted to use in-ADB and to see that being better, MySQL and Sun wanted to downplay in-ADB and kind of hold off innovation out there and so it was easy to replace with Falcon. And we had a son-opportunity out there and actually we need, because we saw what it was impossible to scale in-ADB without actually writing code and fixing some problems out there. And that is how we created Percona X-ADB, the fork of in-ADB. That is also when we put a lot of time and effort and wrote high-performance MySQL book. That is called second edition, but actually that was a completely rewritten book at that time. And some of you may read that. In 2009, we see the second acquisition in MySQL times, right? We see Oracle acquire Sun Microsystems and so it gets MySQL. And oh my gosh, that was a big deal for everybody because in MySQL we were out there to get Oracle, right? It was the whole idea of the company, hey, we are going to get out there and democratize MySQL market and kind of really make Oracle pretty much irrelevant. But that's not what happened and I think that was the shock for a lot of people in the team, right? And that's where we get a lot also from that as a lot of those rumors what Oracle will kill MySQL. Have you heard about that? No? Anyone? Yeah, well, so what is it? Nine years and counting, right? You have to see. Monty started his second database company, MariaDB at that time or MariaDB project, right? The company had a different name to ensure the future of MySQL and to have independently run MySQL alternative. That is also the data in Amazon RDS for MySQL. The first database as a service became available and also that is when we get the MongoDB, right? I would say the Legion NoiseQL database was first released. 2010 we got MySQL 5.5 which has a lot of focus on scalability finally, right? I would say in 5.5 we get a first big improvement in energy performance because the teams are integrated, Falcon was ditched, and really a lot of focus was to make an energy be actually work very well with MySQL. That is also where we see first release of a performance schema as a way to really understand what's going on inside MySQL better. Now if you look at the highlights of the ecosystem at that time that is where we got open stack initial release, right? And kind of supporting the other thing in the cloud ecosystem, the phenomenon of a private cloud, right? People able not only to use solutions like Amazon, right? Using the infrastructure but have the completely open source way to write cloud in your data center. From Percona side, we have decided it's not enough just to modify in a DB storage engine. There are some performance improvements in the features we want to do on the server side. So we created at that time Percona server which was based on our X3DB storage engine and a lot of additional improvements. Also, there was for years the problem of taking hot backups for in the DB, right? In a base time, it was actually rather inexpensive proposition to go and buy in the DB backup from in the base. When Oracle acquired, it was wrapped into the MySQL support which was actually pretty expensive value proposition and a lot of folks in community were suffering not having a good solution for open source backups. So we created one which is known as Percona extra backup which I guess some of you have used. So what do we have challenges in 2010 with MySQL? Scaling with MySQL with multiple CPU cores. By the end of the first decade of the 2000s, CPUs have not been getting really faster. They have been becoming wider, right? They have been getting more and more cores. So it was not only the question of some big-ass expensive servers to scale to multiple cores. Even a very basic service would have an ever-increasing number of cores and MySQL was not really designed to scale very well with those multi-cores first. So that required a lot of engineering and performance tuning. We also had a lot of work put in the MySQL deployment automation. We have a lot of very large MySQL environment at that time which had to be managed by very small teams of DBAs, right? And that's where the automation of, you know, using Puppet to manage MySQL and stuff like that became important. And also much more prevalent cloud made MySQL automation more feasible, right? Because it's much easier to automate everything than if you have a programmable infrastructure. You can spin up, spin down instances, right? Compared to when your automation is limited, what's in the end? You have to have somebody to come and write a new server. The specific problem in MySQL at that time was also replication failover automation. Unlike some of the modern database system, MySQL doesn't really have a replication failover built-in. So for example, if you have a master and multiple slaves and your master crashed, then what will happen in MySQL? Well, pretty much nothing, right? You will have a bunch of slaves trying to connect to a master which doesn't exist to recreate that replication infrastructure to select the new master, adjust your load balancer or configuration and so on and so forth. That had to be done manually, and there have been a number of tools created at that time to help with that, such as MySQL multi-master manager or later MHA. In 2012, looking at that problem and as well as the prevalence of the cloud, we have introduced our Perconyx review cluster technology, which is really the new generation at that time, cloud-friendly high-ability for MySQL. In 2013, we get MySQL 5.6, and that was, again, focused on better scalability and performance schema, getting GTIDs to make replication at least somewhat easier to manage. A lot of improvements to the optimizer. For example, remember, I mentioned what the subqueries in MySQL 4.1 were introduced, but many common subquery types couldn't really execute in completing the center. In MySQL 5.6, a lot of such optimizations were added. And that is also the day the initial release of the Docker happened, just for the background. In 2014, we have the first release of Amazon RDS Aurora. And why is that, I think, interesting? Because what Amazon Aurora is, is this is the new kind of a software which happens with the cloud systems, which is kind of based on open source, but not open source itself, right, and which really promises some additional features, additional scalability, and so on and so forth, but at the risk of very serious locking, similar to which pretty much comes with your... ...property software. In 2015, we got MySQL 5.7 available. In MySQL 5.7, we had... It's kind of getting boring, right? Again, even more scalability. We have a JSON document store, parallel and multi-source replication. And what we can see in this case is that is where we see a lot of NoSQL and especially JSON-focused solutions given MySQL some heat. Because by that time, a lot of the new generation of developers, they would not really understand relational algebra in this kind of complicated language called SQL, right? They would write their stuff in JavaScript. They would understand, you know, JSON object, right? And that is a way they would like to work with persistence. That is why a lot of them would use MongoDB at that time, right? And MySQL was there to respond to that trend by starting to introduce JSON functions and also the document store, which is a MySQL feature which provides an interface quite similar to MongoDB. That is also the year where ProxySQL was initially released. And in ProxySQL, I think there is an open-source tool which you can really hear a lot about those days if you're part of MySQL community, which really has a lot of very nice features for load balancing and IOS managing MySQL traffic, right? You can use it for all kind of things from implementing your database firewalling to caching to load management, right, or implementing some basic charging. So that is a very important technology for MySQL ecosystem those days. From our side, at Percona, that is where we acquired a company called Tokutek, which has a TokuDB storage engine to integrate that in MySQL. What kind of challenging did we see with MySQL in 2015? Well, as I mentioned, that's where we get a lot of new SQL, no SQL solutions coming up. And a wonderful thing with those solutions is there was no need for manual charging anymore, right? If you look at solutions like MongoDB, Cassandra, and so on and so forth, right, they have charging which is pretty much done automatically for you. You just have to, you need to scale, you add some more node to the cluster, and that works. Yes, you have to trade a lot of SQL features for that, right? But you get a lot easier scalability, which is good enough for some applications. Another challenge or another benefit developer so is those no-SQL solutions is what they have been a schema less. That means you would not need to manage a schema. Like, hey, if you need to add another column, you don't need to alter table, right, which can take a lot of time and be quite painful. So as I mentioned as well, we had many developers which don't quite understand SQL and that was another issue at that time. Now, another challenge that we saw at that time is that the MySQL single thread performance was getting worse release after release. And remember, with CPUs not getting faster, getting wider, that was really the problem, what we may not get better performance with MySQL upgrades and CPU upgrades compared to previous releases. So here is some graphs to illustrate that. Now, if you can see here, these are kind of results from different MySQL versions, you can see what at the high concurrency every single version, every new version would generally provide performance improvements, right? You could argue about the shape of this graph so how much better, but generally the new version would provide better performance at a scale. But at the same time, if you look at single thread performance, that was kind of going down, right? And here is the link here to the blog of Mark Callaghan, who is the self-proclaimed champion of making MySQL single thread performance to suck less, right? So he has been doing a lot of investigations in this problem attracting community attention to it. Now, in terms of 2016, there have not been any big MySQL releases for that, but I think there are a couple of things which are important happening. One is from our side, we released the first version of our pure quantum monitoring management product. And why I think that is important, because if you look at the MySQL ecosystem, what, while there is a good open source core database software, right? You can think about MySQL, Community Edition, Percona Server, MariaDB, they're all open source, right? When it comes to really, that's such a key component as a tool for monitoring, we generally have to be either SAS or proprietary. MySQL Enterprise Monitor, Monyeog, Vivid Cortex, New Relic, all of this stuff is not open source. And yes, you can go ahead and build something together, you know, using Nagyos and some plugins, right, or maybe Zabix, but a lot of that would be do it yourself, which would be, well, pretty hard, right? So that is why we decided to focus our attention on the problem of open source monitoring management first. Another thing I think which is wonderful is what the click house was open source, right? And while it has nothing to do with MySQL, the nice thing about it is it's a SQL language which is kind of very fast and massively parallel, which with the help of proxy SQL can execute queries with a MySQL protocol, and you can replicate the data from MySQL to click house in many cases easier than using something like Hadoop. And I think that is a very cool solution if you don't quite want to go all the way to the kind of big data and Hadoop infrastructure, but you want to have your analytical queries to run much, much faster. Even at a single node, click house may be about 100 times faster than MySQL, right? And it can scale to the clusters of hundreds of nodes. MySQL in 2017, that is where we get MySQL group replication and also in the DB cluster product, which is close to that. And I think a lot of that was based on the success of Galera replication technology and Perconyx DB cluster, which is our product based on that, which shows ideas, hey, what people do want to have something more kind of managed and easier to use than MySQL asynchronous replication. In 2008-18, to date, we get MySQL 8.4 release candidate, which was just recently released, a lot of very cool stuff, right? I mean, I can't wait for MySQL 8 to finally go GA and I hope that will happen in the next few months, right? That's what release candidate supports to mean, hopefully. And from our side, we have shipped the Rogues DB, or MyRogues storage engine as a part of Perconyx server. And what MyRogues DB is and what's wonderful about it is there is a storage engine which Facebook uses to really handle the massive amount of MySQL data much more cost-effectively in terms of disk space, SSD ware, and performance compared to what we ever could get with InnoDB, right? And so now that's available to you in easier-to-use package from Perconyx server. Now, let's look at what is really state-of-MySQL overall in 2018. I believe by now that is clearly not only the open-source database anymore, right? There are other open-source databases, you know, PostgreSQL has been growing very rapidly and has very successful, I think, last three, five years. We also have a lot of general purpose, not general purpose databases, right? Like there is in FluxDB for time-series data, right? There is a solution such as Neo4j if you are looking for graph-based databases, right? So a lot of, or elastic search, right? Again, if you have certain queries where you want to have, you know, full-text search and some other application, elastic is pretty much, much better for that than MySQL. But obviously MySQL is still number one open-source relational database, and I think it really is shown how it can use it very successfully with other database technologies as a part of your data layer. If you look at any large-scale technology company those days, they typically are not using MySQL alone. Most commonly find it's being used with, for example, Redis for caching, or maybe still memcache, elastic for full-text search. Then data will be probably replicated to something like Hadoop for big data analysis and that replication will use technologies like Kafka, right? So we see MySQL taking a very important place but within a portfolio of multiple of technologies in a modern open-source data storage stack. We also see MySQL deployed very commonly in the cloud, increasingly commonly, both as kind of do-it-yourself environment, right, on EC2 as well as with database as a service provider. And you can see what all major MySQL, all major cloud providers now have MySQL-compatible open-source... Oh, not open-source, but MySQL-compatible not open-source database as a service. Let's also look at the modern MySQL scalability and what that means, right? These are, again, the graphs from Oracle Marketing, right? So they probably show us a best-case scenario. And we can see here what the MySQL can reach more than a million of queries per second, right, on the single box. That is a lot of queries. And yes, of course, there is some big-ass box which was used here and these are some very simple queries. But if you really look at the single MySQL of instance, it can do hundreds of thousands of queries a second of a medium complexity. You can generally do tens of thousands of updates or other kind of operations and traverse tens of millions of rows, right, in your database. And you can run successful databases of multiple terabytes in size, right? And again, this is not some extreme numbers, right? We had customers running 50 terabyte database on the single node, right, for example. Well, that is kind of painful. I'll be honest with you. 50 terabytes on a single node is painful, whatever database it is. But some people are doing that and that's possible. Now, let's do some math to understand what exactly that means with those numbers, right, for developers and what kind of applications we could build on the single MySQL nodes. We probably don't want to go single MySQL nodes. We probably would have some sort of replicas if not for reads, but at least for heavy ability. But let's just do some math. So even if we reduce those kind of Oracle marking numbers to much more conservative, 100,000 queries per second, and we will think what our application requires 10 years, the 10 queries, right, to serve the user interactions, right, which is pretty common for, you know, mobile apps, that gives us about 10,000 of those user interactions a second, 10,000, right, which it can support, which gives us this kind of big number of user interactions a day. And if you think about our user engagement, which is about 30,000 per day, that can give us about 20 million of daily active users. Of course you'll say, well, Peter, it cannot be so even, but even if you think about your kind of classical view, skew, right, with ours, you're still looking at, you know, 10 million, 15 million of users, just a single MySQL can support, right. And why I am talking about this? Because the MySQL has a lot of bad press because it is painful to shard. But what I would say out there for 90%, maybe more of a much more application, you don't really need MySQL sharding, right, and MySQL plus replication can be a wonderful database to build the application of a medium size, right. Because majority of applications which are built and exist, they are not Facebook or Google scale, then they are much more manageable scale. Okay, so what kind of challenges we see for MySQL in 2019? Well, one is increasing security and compliance requirement. That is a challenge for everyone in the space, right, especially in Europe with kind of GDPR, deadline, lumen on all of us. And that really gets a lot of kind of destruction for engineering team, if you like. And as well as it requires the product changes to go against the usability, which is another requirement, right, which modern developers are pushing for. MySQL in containers, while that's very much wanted, that is not really well developed, right, and I think in general running databases with strong requirements for persistence are kind of still evolving as of right now. We still don't have an easy-to-use scale-out solution. MySQL sharding is a pain now as it was 10 years ago. We can see some new developments like Vtest, which are designed to make it less painful, but they are not so widely adopted yet. Parallel query execution is still not where, right, and it's needed now more than ever, right, for MySQL to be more usable, handling the medium complexity queries. Another challenge for MySQL, I believe, is the GPL license, right? Why is that? Because it kind of gets squeezed between our permissive license, like, for example, Postgres have, which allow everybody to use that without kind of fear of what you maybe violate in some GPL license, especially in not completely open source environment, right? And while I understand all of us here love open source, well, complete open source nirvana is just not a reality yet, right? And the fact that MySQL is GPL really restricted adoption in some of the cases. But on the other side, the GPL does not protect MySQL from getting the free riders in the cloud, right? If you want to run your own cloud MySQL version, right, like Amazon does, they can easily do that, right, in this case. In this case, the license such as IAGPL, which MongoDB has, is much more protective for a company, right, which does not want, you know, somebody just to take their IP, add something more on that, and run it in the cloud. I also believe it is, what is very painful and disruptive for MySQL is the Oracle reputation. Because there are not too many people which like Oracle. Well, I am not going to run a pool and ask you to raise your hands to save embarrassment to some of the Oracle folks who have an audience. But believe me, not too many people like Oracle in open source community. Right, but the fact is, in my opinion, Oracle has did a fantastic job and all those new MySQL versions 5, 5, 6, 5, 7 released under Oracle umbrella has a very solid engineering, performance improvements, and I would say the better quality of a lot of MySQL versions shipped before that. Now, the real impact of those open source community dislike of Oracle and this kind of bad reputation is what MySQL was removed from number of Linux distribution for what I believe are very misguided reasons. And I think overall, that really does not help their MySQL community. Okay, well, that's all I have to say about MySQL and its scalability, but if you would like to learn more about MySQL, about other open source databases, you would welcome you to join us for Percona Live conference taking place in April this year in Santa Clara in the United States. And now I'm happy to answer some questions. If there are any questions, please raise your hands and we'll come with a microphone to you.