 And our project is on performance analysis of ROG's DB and trying to subsequently integrate it into open edX. The objective of the project is like basically in the age of SSDs what we need to do is reduce the number of writes and as well as reduce the space that is needed by a database. So ROG's DB was implemented by build by Facebook for this purpose. Our first objective was to benchmark ROG's DB versus you know DB which is the current database engine for MySQL. So we have run the test and we have the results. So I will move on directly to the test results that we saw. Yeah, you know DB versus ROG's DB. So for you know DB we actually ran the test on two virtual machines. Test on an average took us around three to four hours. It was run using JMeter from a main server onto the other distributed servers. So the test procedure is as follows. We have to set up and tune JMeter. Yeah, this is the analysis for insert queries. On the left side you can see that we have the performance analysis for you know DB on the right for ROG's DB. Since it won't be visible quite properly, I can see it kind of. It is the number of estimated threads versus the number of active transactions. Number of estimated transactions is taken per second versus the number of active threads at that time. This was run for 1000 queries and with a ramp of time of 100. Like it will take 100 seconds to start 1000 threads. Which benchmarking software you have? We have just Apache JMeter. Yeah, it's quite high for ROG's DB and low for... Yeah and we have tabulated it. Now you can see it like in insertion queries the average output is around... Yeah, the buy store output is around 12.5% large for ROG's DB. Response latency is about 10% high. Yeah, response latency is about 10% less for ROG's DB. Transaction throughput is about 37% more for ROG's DB. And transaction per second is about 20% more for ROG's DB. Just tell me how many features you have tested on? We have tested the basic queries which are used in any database like insertion, selection, deletion and updation. So you tried it with the multiple databases, joints and indexes? I will be focusing on that point. ROG's DB is currently not feasible for all systems as well as open index because it does not have foreign key nor does it have any equivalent to foreign key. For example, before MySQL 5.5, the default incident was MyISM and it had full text search instead of this primary key which was not a primary key and foreign key which was not present at that point. So in your DB, primary key and foreign key features were added and ROG's DB has not been added yet. Neither is full text search available nor spatial search. So currently there is no scope of adding it. So all in all the broad output is that ROG's DB is not up to the mark to use? ROG's DB is... can I give a small example? It's one of my favorite examples. Suppose I have to go on an all-day Mumbai trip using best buses. I like this example. So there's an all-day pass for 70 rupees. I can travel anywhere and everywhere with that and I have to pay only 70 rupees. But in another case, if I have to go to Hiranandini, I will prefer buying two 10 rupees tickets, one from here to there and from there to here back. So it depends on a data set. Like if we have a large number of rides in a database, then ROG's DB is preferable because it offers huge compression. Like the database we tested upon on two VMs, the compression was 66%. Yeah, we have the sets for that. Let's assume that ROG's DB is better. Yeah. What is your... So our work would have been to implement... Yeah, it was not possible. We have tried every possible way that we could, but it was not possible. So I can promise you this much that if ROG's DB had foreign key, we would have implemented you and given it to you within 10 days. This is a promise and you can remind me of this anytime you want. People in Facebook are working for foreign key in ROG's DB. And the thing is that it does not support foreign key. Now, how exactly the Facebook is using... Sir, actually... Why it is possible for them and how exactly they are... They are not completely replaced in ROG's DB in case of storage. They have replaced. Like it reduces storage up to 50% less in case of ROG's DB. So they have not completely removed in ROG's DB. But if they didn't have foreign key, even though they store into the ROG's DB, how they recover the data? So that data is in a denominalized form which is present in a particular table it does not need to be related to some other data. So the data is being stored into the two different things. The data is being stored into the two different data. The dumping is being done into the ROG's DB and then the sensible data is into the mango DB. That is present for every database, sir. You can have different database engines for different tables in a database. I am talking in context with the Facebook and ROG's DB. It is seen, sir, for them also. They have not completely replaced in a DB as of yet. Okay, anything else to tell? Yeah, and the tool that we use, it is MariaDB. That is an open-source in-place replacement for MySQL. The issue arises because the Facebook branch of MySQL which uses ROG's DB, it does not compile. It has this issue since the last two or three months. So MariaDB has given an in-place replacement for that using the ROG's DB plugin. So all our tests have been run on MariaDB. Like the documentation was not updated. So we could not implement MySQL with ROG's DB. What is MariaDB? Extinction of MySQL with more storage engines and more plugins. Different options for storage engines. It has an in-built ROG's DB engine. It is the same as MySQL. Yeah, it is just a drop-in-place replacement for MySQL. Just a replica of MySQL. Queries are all same. In 2010, actually Oracle took over MySQL. So MariaDB came. That is all, sir. Yeah. Any questions, sir? Anything else? No, nothing. Okay. One thing I want to say. Okay. That anyway we will never use my ROG's DB. Okay. Okay. Even if it comes with foreign key and all that. Yeah. Okay. Because there is no driver, business driver currently. Yeah. In both NVLI and IIT Bombay X to save disk space. Okay. It will not be there for another five years. After five years, we can look at it. Because we have purchased terabytes of disk for NVLI and all. Petabyte. Petabyte. In petabyte, the whole pet and pet will be same. Petabyte won't be same. I have one question, sir, with regard to this. The data storage that you will be using, is it SSD or a hard drive? SSD. SSDs have, sir, when you continuously write and read from them, they have a low life expectancy. And this can reduce, increase the life expectancy, sir. There are too many SSDs. They can keep dying. No, no. No, it is actually really over on you. That is why I was saying, you will not having a collaborative community, tagging it, et cetera. It is going to be a decade long process unless you do something automatically. Okay. Because all these activities are to be done by library folk. They don't get paid to do that. There might be some incentives. He will do that, he will do that. Then it will be horribly done. Then it has to be re-corrected. It is a very long process, complete over-engineering. We have got too much disk space. We have got too much computing power space. You don't have to see it for 5-6 years. Okay. Yeah. Okay. Go. Thank you, sir. Okay. Thanks.