Oracle Live: MySQL HeatWave—New Machine Learning Capabilities | FULL SHOW

Hi, my name is Edward Screven. I'm Oracle's chief corporate architect. Since we introduced MySQL Heatwave back in October of 2020, MySQL Heatwave has been one of the fastest growing OCI services. Many customers have adopted MySQL Heatwave and they've experienced much better performance and lower cost than whatever it is they were using before. Fancom 10 times faster than Aurora. Red 3i a thousand times faster on complex queries and 60% lower cost in Aurora. VR glass five times faster and 50% lower cost than running MySQL themselves on EC2. MySQL Heatwave is experiencing an unprecedented rate of innovation. We introduced MySQL Heatwave in October of 2020. In August of 2021, we introduced MySQL Autopilot, which uses machine learning to automatically tune MySQL Heatwave and automatically choose the optimal number of nodes to run your queries and many other operational characteristics that normally a DBA would have to perform themselves. In addition, MySQL introduced much better scalability. We could scale MySQL Heatwave up to 64 nodes. We introduced storage for scale out. And since that time, since August, we've introduced many other compelling features in MySQL Heatwave. Support for views, support for date and time functions, support for native end clause. We increased our mixed workload performance by a factor of two. All of these things have led to MySQL Heatwave being unparalleled best solution for customers who want to run both transactional workloads and analytic workloads together in the world's leading open source database, MySQL, Heatwave. Customers will love it, but of course they want more. Customers want to be able to run ML. They want to use machine learning with their Heatwave data. They want Heatwave scaling to be faster and easier. They want to know if there's a lower entry point, an even lower cost option for running MySQL Heatwave. And of course, they want to know, you know, if MySQL Heatwave is going to work on their schema, on their kind of data, which may be somewhat different than some of the benchmarks that we've run in the past. Well, I'm here to introduce features and functionality that answer all of those requests. First, let's talk about machine learning. The key factor for machine learning in MySQL Heatwave is that it is built in.

Okay, why is it that more people don't use machine learning? I mean, all of you out there have heard of machine learning. All of you out there have heard of AI. I'm guessing most of you have never actually implemented machine learning or implemented AI in your application. And if you have, I bet you're not using machine learning and AI as broadly as you could in your application. Machine learning seems like magic, but it's very hard to actually use. If you use conventional tools, if you use, you know, what comes out of the box from most vendors, from most clouds, machine learning is hard and it's expensive. Let's talk about the basics of machine learning. What is it you have to do to use machine learning? Well, first you have to take a bunch of data, often terabytes of data. You have to pick an algorithm. And there are lots of different machine learning algorithms. Machine learning is not like a single capability, a single API, a single process. You could be using logistic regression. You could be using boosted trees. You could be using support vector machines. You could use neural networks and lots and lots of different possible machine learning algorithms that might or might not work for your application. And even after you pick an algorithm, you now have to pick something called hyperparameters. Values that dramatically affect the performance and both in terms of time and in terms of accuracy of the machine learning algorithm. That takes expertise. Once you've chosen an algorithm, once you've chosen hyperparameters, you now have to train. That means running statistical algorithms over the data with that algorithm with those hyperparameters to create a model. Okay, once you have a model, you can now perform inference. That means running the machine learning model to either do what's called a regression, which is essentially a function of data, right? Or doing classification, you know, making decisions about what to do based on data. This is expensive. This is difficult. This requires a great deal of expertise using traditional tools. You have to take your data out of the database and put it somewhere else. You have to have really pretty amazing expertise and deep insight into machine learning and AI. I mean there are specialists, data scientists, who this is all they do. Pick algorithms, tune hyperparameters. And even when you get to the end, you've done all of that work, you've done all that training, you get to the end, you get a model, great, you can apply the model to your data, you can perform inference. You can make classification decisions, but you can't understand why the model does what it does. You don't get explainability.

Okay. What native ML capabilities exist in most databases? Well, you're looking at it right here. Most databases, in fact, almost all databases have no built-in support for machine learning. Almost none. And so what that means is that if you want to perform machine learning on data stored in your database, you have to take the data out of the database. Again, remember maybe terabytes of data, put it into some completely different infrastructure, use a completely different set of tools to do analysis, a completely different set of tools to run the algorithms, a completely different set of tools to do the training. And then once you have a model, you have to again perform the inferencing outside of the database and all of that infrastructure. All of those tools running in that box outside of the database. It needs to be administered, it needs to be operated by experts, by data scientists. And let's face it, you know, there are not a lot of data scientists in the world. That has fundamentally limited the number of applications that AI and ML have been applied to. And that's too bad because AI and ML can give you great insights into your data, can help you and your customers make better decisions.

Okay, now I'll be honest with you. Until now, that's exactly what you'd have to do with MySQL Heatwave too. We didn't have ML built into MySQL. You'd have to take the data out of MySQL Heatwave if you wanted to do ML. But not anymore. What we are announcing today is that ML, machine learning is built into Heatwave for our customers. All of that activity, model building, choosing hyperparameters, running the training, running the inferencing, all of that happens inside MySQL Heatwave. You do not need to take the data out. In fact, that entire process is automated by MySQL Heatwave. Choosing algorithms, choosing the hyperparameters, all of that is completely automated in MySQL Heatwave. You do not need to be an expert in machine learning and AI to use machine learning with your data stored in MySQL Heatwave. You don't need to take the data out, which means your infrastructure and your architecture for data is radically simplified. You use AutoML capabilities, actual AutoML capabilities in MySQL Heatwave to choose the algorithm, to choose the hyperparameters. And very importantly, the training activity itself is unbelievably fast. I'll show you a comparison later. Much much faster than the competition. And finally, and also subtly important is explainability. Every model that you create using MySQL Heatwave is explainable and that is critically important. Now you might have noticed I said MySQL Heatwave has actual AutoML. Now why did I say that? Well that's because some of our competitors have something they say is AutoML, but it's not really AutoML. Redshift has something they call AutoML. What is that? What do you have to do to use Redshift AutoML? Well, here's an example use of AutoML from Redshift. And what do you see? You see a couple parameters there. You see max cells. You see max time, right? How much resources should Redshift AutoML use to actually choose hyperparameters for machine learning? Okay, now that seems ridiculous to me because first of all, higher numbers mean you're going to spend more money, but higher numbers don't mean that you're going to get better results. I mean, take a step back and think about this for a second. Redshift AutoML has hyperparameters. So the algorithm they use to eliminate hyperparameters in machine learning requires hyperparameters. That's what we don't do that. You know, MySQL Heatwave does not require such a thing. You just run it and it's done. Okay, that is why I call it actual AutoML.

Heatwave machine learning is dramatically faster than the competition. Here we're comparing it against Redshift. Okay. Now, this comparison, by the way, is really overly fair to Redshift. What you see in this table are a bunch of standard machine learning benchmarks. This is used to evaluate machine learning algorithms all the time. Now you'll notice that on four of them there's a failed for Redshift. If you run Redshift AutoML using their default suggested values for those hyperparameters I mentioned before they fail. It doesn't work. Now we just took the 21 cases they do pass or however many cases are there they do pass and we calculated the geometric mean of their performance on the ones they can manage to run versus ours. MySQL Heatwave machine learning is 25 times faster than Redshift. Now, of course, we also like to compare cost. Now, there's a little problem here and that is the marginal cost of Heatwave ML is zero. It's built in. It's free. It comes with it. You don't have to buy anything else to get it. But we decided to try to be again as fair as we possibly could, overly fair. And we said, suppose you had a MySQL Heatwave cluster and you weren't going to do anything on it at all other than run AutoML and training. Okay, if the cost of that configuration, you're doing no work on it at all. All you're doing is doing AutoML, that cost would be 1% of the cost of using Redshift AutoML and really for most people the marginal cost of using Heatwave ML is zero because it comes with it. It's built in. Now, why is this important? Why does the training time matter? Why does the cost matter? Because you think, hey, training, is that something I do once and then I'm done? I have to do it again. It's a one-time cost. No, it is not. Most data, especially enterprise data, almost certainly your data is data that changes over time. You know, the nature of your customers change, what your customers care about changes, the way your employees think changes, the amount of data you have changes over time. And what that means is that the models that you create through training, they become stale. They become less useful over time. And so that means you need to rerun training to rebuild your models, maybe even with different hyperparameters to get the best possible result. Now, if you're using a system with poor AutoML or you're using a system with no AutoML, okay, that becomes very expensive, right? That means you've got a lot of expensive people tied up doing this activity again and again and again. Well, because MySQL Heatwave AutoML is so fast and so inexpensive, you can afford to do it very often. You can keep your models tuned maximally for the latest data you have at hand.

All right. How is it possible for us to do this? How is it we're so much better? How can we do such a good job with AutoML in Heatwave? Well, the answer is we've actually been working on this problem for a really long time. Oracle Labs, which is part of Oracle, delivers technology into all of Oracle. We've been using machine learning and AI as an important part of our products for many years. I mean we've been literally working on AI and ML for at least 15 years long and even longer in some cases for some parts and that all of that work has let us develop things like training in a single pass, highly parallel hyperparameter selection, intelligent sampling of the data without loss of accuracy. We have training that automatically converges and we have training that scales with the size of the cluster. Here I'm showing the performance of training by number of nodes. All right. So as we go from one node to 16 nodes we get an 11 times speed up in autotuning. We get an eight times speed up in feature selection. Now, this is not perfect scalability, but what we'd like to see is, hey, if we went to 16 nodes, we'd get 16 times speed up. We're not there, at least not yet, but it's still very good. So, going from one to 16 nodes gives us a speed up of 11 times for autotune and eight times for feature selection. How does that compare to the competition? This chart is showing you the ratio of Heatwave ML to Redshift AutoML. And so how does training in Heatwave to Redshift compare as we scale up? Well, you can see the ratio goes up dramatically. Now with only a single node, we're a mere 13 times better. Okay, when we scale up to 16 nodes, we're 45 times better. So obviously the scalability of AutoML in Heatwave is dramatically better than Redshift.

All right, we just talked a lot about AutoML and especially actual AutoML. Let's talk about explainability. Let's talk about how it is that we can help you explain the results of the ML. There's a lot of reasons why explainability is important. For one thing, you need to comply with regulations. I mean, a lot of times regulators want to know why it is that you make the decisions that you make. You know, how is it that you came to certain conclusions and made certain choices? Fairness, of course, we all care about, right? I mean, we many times we want to use ML to do things like decide which candidates to hire. We want to make sure that ML is making decisions based on factors that do not encode biases that human beings may have. Repeatability is very important. Causality is very important. Suppose that you create a model, an ML model that helps you do something like choose leads to pursue, you know, choose leads your sales force should contact. Well, if that model proves to be effective, you might like to know why the ML algorithm makes the recommendations it makes because that may help you understand how to change your products, how to change your go to market. I mean, if certain marketing programs tend to be indicative of likelihood of a lead to convert, well, maybe you should do more of those programs. Now, if your ML model and your ML system, your ML tools won't let you explain the predictions it makes, you don't get a chance to make yourself better based on what the model has learned. Finally, trust. Now, this is a kind of a subtle issue, right? Many times it is useful to use AI and ML to make recommendations, to make classifications that are then acted on by human beings. Now, if the human beings do not trust the model, if they don't trust the machine learning, if they don't trust the AI, if they think that maybe it's invalid in some way, they may not follow the guidance, right? They may not follow the advice, right? But if you can explain to people and show people why the AI and why the ML made a certain choice, why it made a certain recommendation, they're far more likely to actually trust the recommendation, far more likely to actually follow it. Let me show you how easy this is. Now, I've said that explainability is built into Heatwave ML. Now, in fact, not only is it built in, it's actually just part of SQL in Heatwave. So here we have a simple demonstration application of a bank that is reaching out to its customers to offer them the opportunity to make time-based deposits and we're using an ML model to predict whether or not a customer is going to accept that offer or not. We run our training using AutoML, right? And what we discover is that the model it builds is influenced by two factors most significantly. So the two most impactful features, the two most important features are duration of the call that we have with the customer and the month. So seasonality matters. One factor we discovered that is not important, which maybe is a surprise. I mean, it certainly would be a surprise to me, is that their balance doesn't matter. You know, how much money they have in the bank right now does not affect whether or not they decide, you know, to make a time-based deposit. So in these two particular examples, so we want to understand why was there a yes prediction for one customer and a no prediction for the other. We can see well it's because the time we spent on the phone with the first customer who is predicted to make a deposit was long relatively speaking. The time spent with a customer who rejected the offer was relatively low. The time of the year that we made the offer to one customer was in the summer and the time of the year that we made it to another customer was in the fall. And you can see that in fact in the first case the customer doesn't have any deposit at all. In the second case where they rejected the offer, they had a significant deposit. So there you can see an example where explaining the predictions matters, right? Because if you just looked at the data for those two customers, it might be unintuitive. The balance didn't matter. All right, let's look at Heatwave versus some of the competition. We spent a lot of time talking about Heatwave versus Redshift. You know, the APIs are the same. Both Heatwave and Redshift offer APIs access to ML through SQL. Okay, but Redshift does not have machine learning built into the database. When you do machine learning stuff with Redshift, it goes out to a third-party product outside of the database itself. The data in the model in Heatwave is stored in the database. That means you take advantage of all the security features that are part of the Heatwave database. Explainability is part of all models using Heatwave ML is fully automated, not automated for Redshift. Users can run on more than one node. Definitely in Heatwave, not in Redshift. Well, how about Snowflake? Well, Snowflake is a big no for everything. In fact, Snowflake doesn't even have ML integrated into their SQL at all. You want to do ML with Snowflake, you get to write a lot of code. Heatwave ML is built into the database. It is explainable. It is automated. It is fast. It's secure. It scales to the size of your cluster and is available at no additional charge.

Now to talk about real time elasticity is Nipun Agarwal.

Thank you Nipun. One thing I want to point out is that while our competitors do have some kind of elasticity, it's not very flexible and it requires downtime. So Snowflake you have to pick sizes that are powers of two. I mean so 16 nodes, 32 nodes, 64 nodes, 128 nodes. Now if you need 33 nodes, guess what? You get to pay for 64. I mean that doesn't seem very elastic to me. Amazon, yes, they do have some ability to scale up and scale down, but when you try to add or remove nodes, you get 10 to 15 minutes of a query blackout. So that means your application is down for 10 to 15 minutes. And not only that, after that 10 or 15 minutes, you have to then manually rebalance your data. I mean, that doesn't seem very elastic to me either. Neither of those things are true for MySQL Heatwave.

Now one thing the customers have asked us for is you know how can I have a lower entry price for using MySQL Heatwave and you know if my application doesn't need to run analytic queries all the time you know how can I save money. Well we've done two things. First of all we've dramatically increased the amount of data that we can process on an individual node. So back in August we showed TPC-H benchmarks with 10 nodes. All right. So running with exactly the same data, exactly same benchmark data, we can run that same benchmark on five nodes instead of 10 nodes, we have 820 gigabytes of data on a node as opposed to 410 gig. Now if you choose to use fewer nodes, if you choose to use five nodes, it runs in about twice as much time, you know, because you have half the number of CPUs relative to the volume of data, but the price performance is the same. So you get to pick where you want to be on that price performance trade-off and you still get the same price performance ratio. Your cost is half, takes you longer to run, but maybe that works for you. The way we do that is that we use something called blocked bloom filters to dramatically reduce the size of the intermediate results of the queries. You know, if you look at the way that SQL operations are processed, internally there are intermediate results that are flowing through different sorts of data nodes internally inside those cluster nodes. By using blocked bloom filters, we've dramatically reduced the volume of that data. So, we can put more processing on a node. Furthermore, we actually compress the data itself. So, that's how we go from having 410 gig per node to 820 gig. Now sometimes some customers have applications where they need analytic processing but they don't need it all the time. I mean there's a certain set of queries they want to run at certain parts of the day or certain times of the week but they don't need to run those queries continuously. In order to help those customers save money what we've done is we've implemented pause and resume. So what that means is that you push a button all of your data stored in Heatwave nodes is pushed out into object storage, is saved and then those nodes are de-provisioned. You don't need to pay for them anymore. And when it's time to run your analytic queries, you push a button and all of that data flows back in from object store into provisioned Heatwave nodes and you immediately begin running with exactly the same performance as you had before using exactly the same tuning hints that Autopilot chose for you using exactly the same statistics that is driving the query execution. So you can when you're not actually using Heatwave nodes, you're not paying for anything.

Now, it wouldn't be a MySQL Heatwave presentation if we didn't talk about performance, if we didn't show you some benchmark results and compare ourselves to our competition. But before we do that, I thought it made sense to hear from one of our customers, Estuda, who's experienced dramatic performance improvements and cost savings since moving to MySQL Heatwave.

So we thought that we would run TPC-DS benchmarks. Now TPC-DS is a little bit different than other database benchmarks, especially query oriented database benchmarks, that it has a large number of tables and columns, has a complex schema. So it has a mixture of third normal form and star schema and data distribution that's skewed, you know, things that actually are I think quite representative of real applications out there and probably representative of your application. Now we ran a 10 terabyte TPC-DS against Snowflake and what we found is that we are two and a half times faster than Snowflake. We are also 82% less expensive. Two and a half times faster, 82% lower cost. We ran the same benchmark against Redshift. We are one and a half times faster and we are 67% less expensive. Now, one thing I want to point out here is that we are being extra fair to Snowflake and Redshift because we are only counting the cost of Redshift. We are only counting the cost of Snowflake. We are not counting the cost of whatever transactional system is feeding Redshift and feeding Snowflake. The cost numbers we're using for MySQL Heatwave include the transactional component because remember MySQL Heatwave is both transactional and analytical. The cost that we're using for MySQL Heatwave include that transaction processing. It is not included in the Redshift numbers we use or the Snowflake numbers we use. You know, if we look at all of our competitors, if we look at Azure and we look at Google BigQuery and Snowflake and Redshift as we just did, MySQL Heatwave has dramatically better price performance. Now, as always, we're making all of these benchmarks, all of the data, all of the code available on GitHub so that you can run the benchmarks yourself. And I encourage you to do it, but I should warn you if you run it on Redshift or Snowflake or Google or especially Synapse, it's going to be expensive. MySQL Heatwave lets anyone do machine learning. You don't need to be a machine learning expert. You don't need to be a data scientist. Your data stays in Heatwave. It's secured by Heatwave. It's managed by Heatwave. It's simple. It's fast. It's completely automated. It's explainable. MySQL Heatwave is one of only two databases in the world I know of that can do this. The other one is the Oracle Autonomous Database. MySQL Heatwave gives you real time elasticity. You can grow and shrink clusters without application downtime. You get cost savings. I mean, if you don't need to be using the analytical nodes of Heatwave, you can turn them off. When you need them to be there, you can turn them back on. If you've got a smaller application and you want to use Heatwave, you can because we can now use different price performance for MySQL Heatwave nodes. You can put twice as much data per node as before. And of course, as always, MySQL Heatwave is by far the fastest, most economical database to use for analytical queries. Thank you.