 Another feature in MySQL Workbench is named MySQL Performance Dashboard. So with MySQL Performance Dashboard, you can also brief overview of what's going on in this single MySQL server. So here is, well, I have the window and I'll start kind of quick benchmark. By the way, I still have a small benchmark tool named MySQL Slap. You can slap MySQL. And automatically generating a SQL statement with the option Dash A, iteration, and comparison. So now this benchmark tool is slapping MySQL. First of all, it's loading sample data, then firing a lot of selected statements. So let's back to the Dashboard, what's it like? So we are seeing several changes from the previous screen. On the left-hand side, there are new connections coming in. So roughly you start to see some spike. And when the server is receiving, it starts sending some records. Because it is not just a statement. Once all the slides come in, it starts coming in. And roughly 300 slides from this benchmark slide. So we can instantly go on the situation of this MySQL server. This screen is a bit light, so some number of slides do not look this well, but you can see it creating on the screen for sure. And how much table cache is used, table open cache is used, or database buffer, data buffer, how much data buffer is used, or medieval operations and so on. We can see this single screen. MySQL workbench. And you will learn more details from 2.30 p.m. in this room, which is the MySQL performance schema, which tells you every single details of the MySQL server's internal operation to help you to channel MySQL server. But you can get overview of a performance schema, which in MySQL workbench is named Performance Records. All these information is based on the MySQL performance schema. So after MySQL, one more session from 2.30 p.m., you can learn how these data are built with. But with this performance report, you can instantly know which query is doing, which query is executing the most, which query has a full table scan of what the world operation in database, and how much data transfer, how long it needs to take, and so on. You can see from this single screen, MySQL workbench performance report. Again, good news is, once the workbench is loaded, it sends out the GPL. That's pretty good news. Pretty good news for you. So if you're going to ask me now, this is a right tool to use. Okay, so this looks like pretty much good time to start talking about my main presentation. You missed it? You missed it? So, good news. We're going to be talking about my SQL cluster as a trans-section of my SQL. So, please come. I'm sorry, I'm sorry. I'm sorry. Yes, I know many people have a difficulty to produce my first day. Okay, so I'm from MySQL. Today I'll introduce MySQL NoSQL and SQL in MySQL cluster. As you may know, MySQL is a database, so we just speak SQL statements. That's kind of a basic understanding of MySQL. But today's MySQL server feature, MySQL server, MySQL cluster, both database servers also speak NoSQL. So I'm going to introduce what we can do with MySQL NoSQL features, as well as what is the advantages of MySQL NoSQL features. It's usually focused on MySQL cluster. So MySQL cluster is a different product from regular MySQL server. MySQL cluster is a distributed or shared nothing, active database cluster. Based on the technology of MySQL server, but we added more features and changing the behavior of the storage of MySQL and built up MySQL cluster. And now MySQL cluster is used as a one database cluster to transactional NoSQL. So let me explain what it does mean. One product has two big main features. I guess some of you have seen this diagram released by the 451 group, the research firm. There are lots of different types of database and data management solutions. So they split into several different categories. For example, MySQL server is recognized as a relational and operational database. Operational means more like OLTP operations. Other famous data management solution nowadays, for better one, can be Hadoop. Hadoop is usually recognized as a NoSQL. Yes, it is one NoSQL solution. But it's a Hadoop. It can be the backend database of the online game. It can be the backend of the real-time data transactional operations. Short answer is no. My Hadoop is really strong in this area. So you may not be able to see here's Hadoop. Analytics. Hadoop is excellent technology for the processing analyzing huge amount of data. Not in the telebytes. Pedabytes of data we can analyze easily with Hadoop. So the MySQL server or a local database or any kind of traditional database is quite our way of analyzing all of these localizers, can be like generative and operational. I don't know if it's true or not. There is another story here on the left-hand side. Truly the known relational storage. There are a number of new features and new technologies coming in. But this is one of the interesting things here. New SQL or new SQL is the data management system speaks SQL statement as well as which works as a known SQL solution. So it's a hybrid model. Normally MySQL, there are some other solutions that are here. But MySQL cluster is recognized as a new SQL and operational solution. So I need to tell you MySQL cluster is not designed for the huge amount of data processing. But it's designed to be the backend database of the high-volume, non-connect transactions, such as backend infrastructure of a telecommunications network, backend database of the social gain. By the way, in SQL, we have a big reference customer on MySQL cluster, which is M1, which is mobile carrier in SQL. They're using user management database. Whenever you use services on top of M1, you're running through MySQL cluster. So those from the transaction database, that's MySQL cluster over the characteristics. So we're using SQL database or most SQL database. Then today, first, we look for the different types of the SQL solution. Key by the data store. We're searching records by key. So it's more like data has some kind of index on top of it. By key, we can pick up one record easily. But the key register can do usually is finding the single record, changing the single record, that's it. There's no relational or more like a really simple data set, no complex data set. Document is like a construction of data, and we don't know how much data we have against a single record. So we cannot create the definition of the data schema. In that case, documents may be used. It's okay when you're having the small sets of data with document storage. But once your data is growing bigger, maintaining the document storage will be nightmare. If you want to know the details, I have a more complicated example, but I can't explain how to do it outside. But document storage can be good for some small scale application and it really requires a flexible data format. But it's completely different in the aspect of the data management. There's nothing relational, it's not really a document, it's not a simple data set. You need to know the relations of the people. So that's why we use it in the social network, for the social graph and so on. So today, I'm going to be talking about MySQL Plaster, which is not a graph, which is not a document. It can work as a key-value data store. There are several different types of NoSQL, but MySQL Plaster can work as a key-value data store, which also speaks SQL stages. Why do we need a NoSQL? There are several reasons. Scale of AT. So our database should have some scale of AT, but it's not easy to scale. Updates. The scale of the data changing is always a big challenge. So MySQL Plaster is originally designed to use a right-to-scale database cluster. I'll show you how we have done it. We also need an absolute performance. Of course, now the front-end database must be in high performance all the time. Another thing is H8, high availability for the trend. MySQL Plaster does not have any single point of failure. All components in MySQL Plaster is minimally duplicated. This is a bit of a beauty of the NoSQL, because we don't have operation as a result. Simple, we have a very simple API, and we can change the data structure out of H8. Let's see how we can do this MySQL Plaster. But if you ever remember, our database is still there. What's the beauty of MySQL Plaster? Why do we still need our DMS in IE world? If NoSQL solutions are true, the best solution, but all of our DMS should be there, but it's still there, where we are actually much more adoption- there's a growing somerot between nowadays as well. So most of NoSQL solutions can do the really simple tasks for us, but not really, co-operatively, especially joints of the joint operation will be available only in SQL solutions. Most of our DMS can do a well-defined schema, which means you are sure what kind of record will be stored, and application is free from understanding data structure first before fetching an actual record. Lots of tools are supporting most of our DMS including MySQL, such as LARP, and we show in the slides, but one more thing is this. Transaction. A lot of NoSQL solutions are saying they can do some transaction operations, but most of them are not really easy to provide transaction. That'll be the problem. Some NoSQL solutions are giving up consistency. The giving up consistency makes operation much faster because we don't have to wait for two records to be in sync and so on. But from data manager in how the DMS can be deviated to our managing data, lot of consistency is in kind of 90 meters. Even if it's a social game, online game you're building up the system. There are two records. Player number one's point, player number two's point. If player number one won't against player number two, the points will be transferred from player number two to number one. But if that data storage does not have consistency, point of the player number two can be minus. Player number one, see if you're building it up on. It's already minor trouble and today's social game is not quite up to beat with real mining as well. So that'll be big trouble in the business of those gaming companies as well. And if you don't have any consistency or generality, you'll never be able to step into the real business critical mission critical applications. So minus pure cluster has a face of the original reputation is known as targeting this kind of characteristics. Minus pure cluster does support ACD4 program transaction, of course. But it can reach to the scalability, performance, easy use, which is available in lots of non-SQL solutions at the same time. So this hybrid solution, this cluster has a characteristic benefits of the SQL based on the rest and no SQL code products. Then let me move on to the more details. So minus pure cluster is designed for a highly scalable right operations and it doesn't have any single point of failure. By default it works as an in-memory database so it has a real time performance. But let's move on to the more typical different applications. From your application, you speak with my SQL server using SQL statements. When you are adding one record, the insert, data will be duplicated into servers named database. In minus pure cluster, this minus result does not store any of your application data. Data will be stored in data loads and always data duplication happens here. In scale, we can add more sets of data loads and we can scale the size of data and distributed workflow access to data. We can add one minus pure cluster in front or back end in data loads we can scale smoother of the entire cluster from layouts or scale the size of data from minus pure cluster. My SQL cluster does not have a single point of failure in front end in API, my SQL server the two components data loads, there are always data is duplicated. So even failure of one data load data is still in another load. Then, come to the discussion of flexibility of schema. Some no SQL solution has a really flexible data layout. My SQL cluster has a database or even if you are using no SQL solution we can add loads online without stopping applications. So extending, expanding the platform for the master server for the throughput or data size for data loads we don't have to stop any or changing schema. We can change data layouts online without interrupting any application process. So, my SQL cluster is not schema-less, but it's really flexible. It does have a really flexible schema. You can change the table definitions online. You want to add more columns, changing the column names, adding the indexes on top of the table. Everything is online, real-time. Not only the table schema we can change the server configurations online because all components in my SQL cluster has minimum two components. Stopping cloud server and changing server configurations will be looped. That server will not be rejoined in the cluster. Now we can add more of a list of changing configurations of another server as well. And the application will not realize seeing something behind the scene. Let's check the performance of my SQL cluster. This one is using no SQL API, which I haven't explained much yet. We have 20 million updates per second with using 30 data rows. If your system is much smaller, well still you can reach easily way beyond 1 million updates per second with full data rows. Newest version of my SQL cluster, this is not the operation, but you can reach 200 million selects. This one is through no SQL API. I can't explain in more detail. SQL statement API and we like this. Let's move on to the real no SQL discussion. Let's give them tools. I don't need tools. I already talked about what you can access to my SQL cluster using SQL statements. But at the same time, my SQL cluster has a C++ API facing to the data list. From your C++ application, you can read and write records with no SQL API, which is key value API. And with Java, we have the wrapper for this no SQL key value API. From your Java native application, you can access interface named as class of J without using any single SQL statements. If your application has key value access as well as which requires joining operation operations, use this API named as class of JPA which will do the traffic control for you. If your application access was key value, it will use native C++ API which is the way it's over at done SQL operations and get a quick response. But some operations are not limited to key value. In that case, this traffic control class of JPA would be routing to the MySQL server and run join operations through this SQL API, MySQL server. This is one of the new JPAs a lot in some enterprise applications. In the web applications, this is more copier and discounting on lots of inventions. Don't look at too many caches here, let me explain these things here. From your application, application is the only talking was main caching. Main caching, that's a key value cache, lots of use in the web application, maybe some of you are using in the cache D as well. When application is talking was main caching, operation is always key value structure. So application has set a storing record using a put command, a set command and there's main caching, main caching automatically, persistent data into data. And that caching cache data is all created, persistent in data. When you're fetching a record from cache, trying to get the record from cache, the cache was empty, would want a record will be fetched from backend data and be back into your application. So with MySQL Plaster and main caching, it will work as per data persistence managed by data nodes and KBS. By the way, MySQL in MySQL Plaster transaction is managed in these data nodes, which means your inserts, adding records, or changing record level is managed as a transactional operation as a single product transactional on data storage. So from your application, your adding record may be from main cache D API, but at the same time you want to search record through SQL statement, maybe you're joining different tables. We can do the access the same record for the data nodes through key value API and SQL API in transactional operation. So that's the beauty of MySQL Plaster. So if your application may be using main cache D, you can say this product is MySQL Plaster is transactional key value data store. By the way, this transactional key for MySQL Plaster was made in cache D speaks SQL statements of MySQL server. So that's why it's so called a hybrid data storage. So that's about one of characteristics of MySQL Plaster and between clusters. So here is one set of clusters in data center number one. We can have another cluster in data center number two. We can link these two with MySQL as synchronous replication function. In that case, data center number one and data center number two is designed for disaster recovery configuration. And also, this replication feature is not limited to from cluster to cluster. We can do the cluster to regular MySQL servers. In that case, we can say this transactional key value data store can replicate data from KBS key value data store to our DMS. So there are a lot of no SQL solutions in the world right now but nobody of those can do the replication from no SQL to SQL our DMS. There can be one question if it's key value which means usually schema less or schema less or schema 3. Some application developers do not want to prepare the schema. I don't want to think about schema too much. Or sometimes SQL is missing in some application developers. But if you are managing data sending different types of data, meal, home, age, nickname, pound every single data into one box is kind of making mess. It's not easy for us to find out regular information from the right place. And searching performance can be really cool. But it's happening a lot. So one way of how much people want to store data key and body everything needs to be key type and body type of the one table. That's one way. What does a regular keyword data sort always do? Well, that's a schema less or schema 3. But if you are managing a database from the database manager point of view you feel like you are using proper tables. So in minuscule cluster we have one configuration table in the configuration of minuscule cluster and there's one rule we need to ask please have prefects in your key. Prefects is kind of a category of data. Then in the configuration table, if prefects was there table in the market will be used and count current to be the key and body will be stored in code column of this table. Depending on the prefects we can control the access to the different tables. So that's kind of a hybrid usage of those key application and regular SQL based data management. So that makes easier for the hybrid access. If you are adding a lot of information from key version you can search data still using SQL segmented based operation. So we are adding more logical APIs into minuscule cluster but recently we added load.js API which means from load.js and JavaScript application you can directly access to the backend data. I have something called here but I'm from the regular time so you can check this later while I'm simply at the booth and right after this session. So I can show you more details in the tutorial of how to access to minuscule cluster using load.js API. So these samples you didn't see any SQL segment in this example. Still it is minuscule cluster as basic design as algorithm. So we can have the constraint of a pouring key. So even if you are accessing as a load SQL this pouring key relationship can prevent the kind of load deleting some records by mistake and so on pouring key code right into the cell body even if there is no SQL API access. So that's not often available in other no SQL solutions right now. So again so minuscule cluster is shared enough in active-active database and transactional KVS key value data store. This is a hybrid solution we are using in the mobile interface infrastructure, mobile applications and social gaming as well. Now let me explain what more said in my presentation. So up to here we talked about minuscule cluster which again we have only key version and a larger version. Well another summer products in minuscule is named yes, minuscule server. Newest minuscule server version is version number 5.6 and from minuscule 5.6 no only minuscule cluster, minuscule server also has a no SQL API embedding inside of my SQL server. This one is not designed for the scalability but it's known for the absolute performance. Insert versus minuscule API data add is like nine times faster in this simple data insert operations. Again, how to use I also have examples but I have your time so let me explain. I'm sure I'll approach this one to the web as well. There are several interesting things we are working on. MySQL server will speak HTTP and you can post JSON data structure into MySQL and MySQL server will reply in JSON format. Data storage is still table based but at API we can use a no SQL even that's kind of scary for me. I usually don't like to use this. You can write SQL statement in the URL HTTP or slas-slas server address for 8080 the phone number, slas- SQL, slas- schema label MySQL, slas- select brah-ra MySQL server will return results on select in JSON format. If you're interested you can download it from www.lamsolomysp.com and you can play with this one. Another thing we are currently working on is JSON SQL function you can store JSON into MySQL server and search, replace written, add name to some information looping some components within JSON there are a lot of things we can do like merging different components in documents into one or these are like counting records these are also available in MySQL label.lamsolomysp.com with these SQL functions if you're used to JSON data and you want to replace some components just use JSON. MySQL can be kind of document database which is designed for MySQL server writing Well, MySQL server is not really optimized for the document but if your document is not so huge this is a good idea to use MySQL or server still as a document database it may not show extreme high performance because MySQL is fully optimized in our database but if you're working on this kind of including JSON SQL function previous screen, HTTP plotting MySQL to be kind of interesting solution way beyond regular our database so this is things we are working on as of today but quite recently we've announced MySQL server 5.7 on 6DML which is the next major version of MySQL server which we are working on so we announced MySQL cluster actually this month MySQL cluster now became 7.4 versus 7.4 as a major version and MySQL server we made final MySQL release and in the document it says I'll see to be soon, release can then to be soon so please check both MySQL cluster and MySQL server again MySQL work page as well I agree you love the first of my operations cleaning up the SQL statements ok so that's where my MySQL cluster presentation so I'm going to join you I have any more questions for you use the key you got it right? any questions? otherwise thank you thank you Mr.Gate thank you so much we're cool next to you