 Okay, better like that. So we have done this and now we have in it. This is what we can hear. It's too easy, right? One line and we have two lines, one export, one import, and we have now all your documents from the MongoDB inside MySQL. So let's query it to see what it looks like, right? So here you can see I'm using JavaScript inside the shell and I do restaurant find. It's a bit long because I will receive all the 25,000. So let's limit it to one. So I will do this, restaurant find limit one, and we have the first document in the collection. This is MySQL. MySQL 8, you can have this, right? More example, so you do, okay, restaurant find, and I want to see the name and the cuisine, and I want to limit to two records. So two documents. I have this first one, so cuisine Irish, this is the name of the restaurant, and this is cuisine American, and another name, right? All that without any single line of SQL. So documents, not using SQL, this is what people want. So we go there, right? We can add criteria. So we can say, okay, restaurant find, I want no Italian cuisine, and it runs, and we have Italian cuisine. I can use in, I want Italian or Spanish cuisine, right? And it does. Of course, here you have the first two are only Italian, but it would work. So what means for developers? So for developers, NoSQL, NoSQL is MySQL 8, and this is what you can have and this is some, I tried to jump again in PHP that I did a long time ago, so this was my best design I was able to do, right? The code is on GitHub if you want to see how it works, right? So this is what's behind the form you just saw, right? So we use MySQL X, we get the session, so we connect using the new X protocol, because MySQL 8 has two protocols, the standard protocol and the X protocol. We connect with the login password where we connect, then I say, okay, I want the schema, I want to get that collection, and then I run the search I was adding here, right? And then for each result, I can show them, and this is what we see here, right? So I was able to do this form in web form without any single line of SQL. Easy, right? We only use credit operation. This is an example. This works for the credit operation that you have seen, works for all the documents, but it works also for normal tables if you want. So if you have standard table and you want to give the possibility to your developers to only use credit operation on tables, it's also possible. So these are the different type of credit operation. So we have the add, remove, and this is the syntax, right? Modify, it's cool because you can say, okay, I want to modify the name and I put the name, I will bind with the new value, or you can also use the patch function and you can patch your JSON document like that. So all you need to know is here on the user guide with all the credit operations. But like I said earlier, in MySQL, we also do care about your data, right? So the MySQL document store is fully ACID compliant. So it means that it relies on InnoDB. So your data, it's stored on InnoDB. It's not yet another engine behind MySQL. No, it's the InnoDB, which is the most, let's say, powerful engine and robust that we have, right? So by default, you have flushed lots at transaction commit. So every time you do a transaction, every time you're going to insert document, it will be flushed also on disk. Double write buffer. So if you have an issue writing a new DB page, we're going to find it. Sync bidlock equal one. So it means that every time you write a new document, it will be written also synced on the binary lock and sent to the slave. So all that works with the norm, everything you have in MySQL now, you have it with the document store. So your replication, all that, group replication, the isolation, all that works, but with documents. So we do care about your data, as I already said. So if you care about your data, but if you want to use credit operation and if you want to have documents, MySQL document store. More. So this is transaction support that we are just saying, oh, I don't use transaction when I do document store, but it's possible. So we just do star transaction. We add what we want. And then we can see it. And after that, we can roll back, check again. It's gone because we haven't committed the transaction. So it's possible to play with transaction inside the document store. So it's cool, right? So we have document store. We can store our documents. We have credit operation. So we can add, remove. We can use all that data without playing with SQL. It's ACID. Perfect. We have the durability that it's missing sometimes on the older document store. But what makes the document store of MySQL that unique, right? A challenge. I like challenges, right? So you know, some of you already know the collection of the restaurants. If I want to ask you, OK, now, some of you are developers, I want to have the list of the best restaurants of each type of cuisine we have. And show me, so for each type of cuisine, I want the best restaurant. And then I want, of course, that the best of all of them is the one on top, right? So for example, if the best restaurant ever is an Italian restaurant, I want Italian, then the restaurant, and then the average rate it has. But don't forget, behind that, so in the background, this is only documents that we just imported right now. How do you do that? How easy it is to do that in using Mongo? Sorry to point you, because you said you're using Mongo, so how do you do that in Mongo? Will you be able to do this in Mongo easily? Yeah. This is the point I wanted to go, right? So when most of the people, when they do that, they give to the developers, OK, please play a prototype and make me a product that stores data. Then they say, yeah, but we need now to make some queries on that, reporting, whatever. How do we do that? And what I saw when I was doing consulting is that people extract data from the document store, put it in a rational database to do the queries. So they copy the data on two different systems, and they need people to maintain the document store, they need people to maintain the relational database, and they need to copy the data tries and all that kind of stuff. With the MySQLA document store, just use SQL with your NoSQL data and aggregation. So we make a common table expression, SQL is powerful. We do some Windows function, and here we are. So we have the cuisine, juice, mousse, fruit, salad. The name is Juice I.T. Health Bar as an average of 75. So for all the juice, mousse, fruit, and salad restaurants we have, this one is the best, and it's the best of all of them. Then the second best cuisine is Chinese food, and this is the restaurant. So you don't need to copy all the data somewhere else. You don't need to transfer your data. You don't need to use to maintain another system. It's all on the same system. And this system, it might escalate. So, and of course, exactly the same way we were doing the crowd operation, at a certain point to, let's say, to answer one of the requirements that we need. For example, I need to make this report. You can say here, okay, now in my session, I don't do add, remove, delete. I will go back to SQL and do SQL. And if you see, and if you follow the document stores, the leaders in the document store, they are trying now to do that. They are trying to say, oh, we should use SQL also because we need that. But it will be very complicated for them to have SQL because they don't have the backend that a relational database has like we do. So good luck to achieve that for them. So what's for DBA? For DBA, in fact, all the secret of what we have seen now is just the JSON data type, right? So this is, we can also add columns that we could index. So if you see all, our query are too slow, DBA can add indexes for your JSON queries. And for example, like this. So this is virtual columns. So the index is materialized on disk, but the data is still in your document, in the JSON data type. It's not that it didn't create a new column physically, so you don't copy the data. Just the index, extra index you have. And you can validate, but I have just some few time left, so I will pass this. But the slides will be available. So what can we do all that? So all these indexes is also then to speed up. For example here, we do full scan of the table. When we create some indexes, we do the same queries and we use the index. So it's possible to do it inside of the document store or outside. You can have this index to speed up everything, right? Yeah, this is how it looks like. A table for the DBA. But the developer doesn't need to care about that. It works, right? Here you can do a race. I can have the first one, the last one, and see whatever you want. It's very easy to use. Okay? This is a new... There is a plenty of JSON function in my SQL, and this is one that it allows you to extract the document and shows it and use it like it was a normal table. So what do I gain? I gain the best of the two words in one product. Data integrity. I am completely ACID compliant. I have my transaction. I can use SQL if needed. But I'm also schema-less. I have also flexible data structure and very easy to start because I can use crowd operation. All that in one single product with all the benefits, with all the ecosystem around MySQL we have seen, so you can use the ProxySQL or you can use Ghost if you need to do changes, whatever you want, all the ecosystem of MySQL, it's still compatible with this. So again, the cars against humanity. So they said that the MySQL document store is the best thing since the sliced bread. It's a quote of Dave, my colleague here. So thank you very much. Do you have questions? Yes.