 Okay. Thank you for everyone for coming today. We're going to talk about MyRox in the Wild Wild West. And to start the talk, if you haven't met, please add me on Twitter or follow. My name is Alken and I work at Paracona and managed services department as Paracona and a few other people over here. Today's agenda will be going to introduce MyRox and talk about some of the background and some notes. We won't get into two details. The slides will be available and I will provide a lot of links, blog posts and information. And if you want to have asked questions, you can reach out to me or some others in the references. So what is MyRox? MyRox is the storage engine. It's a hidden gem in MySQL as I call it because it exists there for a while and not many people know or use it. And it's basically a key value store that is added to MySQL. It's based off of RocksDB and it was also fork of a level DB. So these technologies existed for a while. It's forked and it had its own use cases and started using. Of course, this was needed for some large operations and we know it's been implemented in Facebook. And others also still use it as a RocksDB or MyRox distribution. There's a link provided. There's some new blog posts that actually identifies a few areas of interest that actually utilize RocksDB. And initially it was a source code, then it was kind of picked up some attention and brought into attention of the MySQL providers other than Oracle, like Percona and MariaDB and released. So how do we get MyRox? We get it via Percona server or MariaDB. Percona server institutes this in 2017 and fully supported in 5.7 and 8 or releases. And it's been also available for a while in MariaDB from 10.3 and 10.2 later distributions. Basically they come built in. You don't need to do extra download or anything like that. If you download Percona server 8.0. I think 18 is the latest version. It will come along with that. There are some differences between the distribution. So one main difference is the Facebook distribution. Facebook doesn't use the mainstream version of RocksDB, MyRox implementation. And the Percona server has some different implementations for the compression algorithms. And there are some minor differences in the data file locations. The other thing that I wanted to highlight over here is the gap lock detection. This is like something major in the way that the engine works. So the Percona server and its support doesn't actually use it. Percona server errors out and in MariaDB there's no gap lock detection in the MyRox engine. If you want to read about some details there will be some links which we won't get in now. Okay, going back to the key value store. So we have the DB engine versus LSM tree style which MyRox utilizes. I actually had to put up this infamous page and the link over here. Please have a read. So the way that it works is data streams of key value pairs actually written in the memtables which is the memory actually. And then they're flushed to the disk in a level format and the compaction happens in each level to create a small larger small number of files. That's the main difference between the B3 and where B3 actually handles the data stream is slightly different than the LSM. So this is the right picture is what the MyRox actually utilizes. So in short, over here, the B3 actually mostly read optimizes. We know uses buffer pool utilizes and actually writes are in place and the LSM tree, the writes are sorted stream tables are written in sequentially and then the compaction happens in the background from the algorithms that we mentioned above. You could choose your algorithm and then has a fast access to data. Continue on the InnoDB. So not undermining what InnoDB can, InnoDB is a very powerful storage engine and can be used in other areas of Galera library, writes at replica and Percon extra DB cluster or group replication where MyRox is not. InnoDB also provides different bin log formats that in MyRox we have to be in the roll format and the transactions are limited to memory in MyRox. So if we go back to MyRox and the components of the MyRox, I'm going to skip this and show you the how the write request is handled. And basically we have the memtables, the writer head log which actually they go along together and then the leveled LSM tree structure that actually does the data writing and the compaction happens in the background for the logically partitioning we have also call in families. And when a write request comes in, we have the active memtables are actually written immediately with the writer head log and then they are flushed to the sorted sync files and the compaction happens on that level. And this allows the fast write and sorted files to be available in the disk. So we have a concept of logically partitioning the data with the column families and the memtables actually allow the writes to happen fast while we also have a log of it written in the storage and then get flushed to the table. So they are limited to 64 megabytes and a fast read and write optimized. The wall is the writer head log which we actually compared to our inner DB's reader logs and when an immediate write happens it's also written into the log. This also helps the crash recovery of the engine. And the MyRox actually the similar way on the read request actually the opposite way of trying to achieve that information process via memory, memory tables which is similar to buffer pool in our DB. And then with the index and the balloon filters you can actually access to those leveled and compacted data files and then retrieve them fast. So the level compaction is also targeted for different data sizes and as the compaction happens it gets in a larger and larger. The fewer level is better but if the data size is big then you have actually fewer files that are already sorted and merged into different files. And there's more details about Yoshinori's tutorial over here. There's a link, it's a very detailed explanation that he made. So there are some improvements over the compaction. So they are aligned with the operating system units and then also the Percona server. There has been some tests and benchmarks made in different algorithms. LZ4 was selected as the medium level algorithm and then there are other compression methods are also available. So the column in the other components over here that wanted to highlight is the column families. So it actually allows the partitioning of the and the column families also allows us to configure MyRox properly depending on the data set and that's all the configuration parameters which we will not get into it today but you can actually have a more control over the data how it's been accessed. So there are some advantages on the disk versus in a DB on the LSM side and there's a lower right penalty and reduced fragmentation over it and so this is being advised as a good fit for the right heavy workloads. Also there are some advantages on the flash with the compaction and the compression you get actually saves space and there's a lower right amplification for writing on the flash. We mentioned about the gap lock and there's a there's a roll locking available. It's only read committed and repeatable read and then we don't I mean MyRox doesn't support gap lock as much as the InnoDB. For the replication side it has to be roll level and then they'll have a large bin locks and again once again the statement base replication will cause gap locks but you can still use it on the on the slaves. So this is the high level of MyRox engine and then how do we actually mix and match? It is not very much advised to mix and match InnoDB engine and the MyRox engine at the same server but if you do the extra backup still works it's on only on 8.0 with the later versions of extra backup and it's both optimized to take a backup of InnoDB and MyRox at the same time and there are no partial backups so you can't actually write on an InnoDB and write on MyRox maybe like a different application, different the model. You can't say okay I just need the backup for MyRox if you have the backup you have to backup the whole thing it's so you have to design it that way. MariaDB also Maria backup also supports after 10.2 on later versions they don't also support MyRox partial backups. There's also MyRox hot backup tool that was originally designed to backup the ROXDB and the checkpoint and the log file but that's only for MyRox. So there is a trade-off between using the extra backup Maria backup or the MyRox hot backup and that way you have to be cautious about what your recovery method is. There is also MySQL dump and you can basically dump the data from MyRox and right now snapshots are kind of difficult when you're mixing the engine and then on the MyRox side you have to have the checkpoint and the log to be able to go into that point of recovery. So if we go back to the the other tool comparability, let's say we have a MyRox engine in our ecosystem so okay PMM is per corner monitoring and management utility it has built-in dashboards so what that means is you have a system and catalog files information schema information that you can actually gather show engine ROXDB status output that information is there so that that tool is we consider is compatible you can actually monitor analyze and record the events the extra backup is supported for the online schema change it's partially supported because it's feed committed and PT table checks them and sync you can't do it with because these are required to have a roll level bin log. So that's the tooling comparability there's you need to plan ahead of time if you're actually going to test MyRox and how my tooling and automation and other stuff works. Okay this is the benchmarks aren't the subject of this talk but as a reference we wanted to have an example over here I will not go into too much details which when these tests were ran we were on 8.0.16 now we are on 8.0.18 and on engine there has been some optimizer changes lately and then we believe there's some numbers are might be skewed because of that I am from Percona Percona's engineering department is working on new benchmarks which I will also work with some other friends over here to analyze but we can see in the as the threads are higher the you know DB gets kind of saturated but the IO bound network MyRox DB excels in the cispanch TPCC test I'm sorry these are these are writes and and then we have also read and write test over here same thing over here you can see in the in the ROX DB as the 64 threads and more it excels over you know DB engine like I said we will we will share more benchmarks and details about the latest developments with the latest version we have and and then compare some of the data versus but the the highlight of the the ROX DB MyRox engine is is to have it have a larger data set writes optimization so so why why would you use MyRox because in now there's most of our clients are in cloud they pay per per disk and disk space so your your costs are not going to be just okay I have these storage unit and it's going to run in the background and I can use it this is like as you provision more there's a link over here for another blog post that there is a comparison the chart is very small but it's it's it's cost efficient for for cloud as you can actually utilize and and use use different compression algorithms to get more more out of that than you know DB I mean there are some numbers that Yoshinor actually shared earlier about comparison between you know DB compression versus the the compaction that ROX DB provides it's much higher so that way simply you can save costs in the cloud or your storage in conclusion we we think it's it's big for big data sets are actually more suitable if you have a lot of indexing and again repeating over here for the right intensive workloads are actually much more suitable that we think so basically the data that has has a read write type or a style of applications that actually you're writing and reading quickly and that's might be suitable for that the other thing I wanted to mention is earlier the ROX DB as an as an engine as a technology is used in some other areas they're not like as far as we know they're not like my ROX implementation of the engine but the the technology that relies underlying technology that's that's in the in the ROX DB is being used in several other implementations there's a blog post and a link at the end of the the slides and I wanted to also thank Yoshinori and and Vadim Sweeta and Mark especially they put in a lot of work in in ROX DB and Yoshinori is over here if you have any questions and and there has been extensive research and development to come to this level where Facebook is running with the migration of ROX DB and thank you okay are there any questions can you repeat the question okay okay okay the mic because of the mic sir okay okay the comparison between the my ROX and the Toku DB we have initially made some comparisons and I will have to look up those the Toku DB is also similar technology is there are similar use cases that but all the data that we had or I found they were all outdated so there are really no good comparison and as my ROX is being kind of accepted both Parcona server and the Maria DB server adopted into it it's going into production is one of the largest web scale my sequel topologies in Facebook we don't find too much value in going back and doing testing in Toku DB right now so more more like a more in a DB my SQL 8 comparisons where you actually have an option do I actually have a benefit from ROX DB my ROX implementation any other questions okay so it's not a really a question but it's more like a suggestion and commentary okay so yeah I don't know much of it details on that but we'll have to look at it okay so it's more like a suggestion to use different filters than a balloon filters as the question yes how updates and the leads are handled okay so the so how should I okay how updates and leads are handled basically we had we had a slide over I think over here let me see that's still have time okay okay so basic basically the way the way that it works is the the the MAM tables are handling the rights and and when they actually the sorted strings come in the when there's an update you have you have the merging so that the rights are coming in and the updates are coming in for the data and as you already compacted and the leveled the data into into the files those sorted strings and it gets actually basically it's flushed and and and read on it in the in the memory so basically it's an ongoing operation as far as I know the how it's handled yes any other questions on T right good question does Percona have gap blocking it doesn't have a gap blocking it has a gap blocking detection so it's actually detects there's a gap block there could be a gap block yes yes yes at a route yes you can have you know all you can't you can't have mix and match but you can't support it so but it did it detects that there's a gap blocking it's the detection range update yes okay thank you okay thank you thank you thanks for the question