 So, students in this module, we will discuss the misconceptions about NoSQL, misconceptions. So, people have the wrong understanding, people have the wrong concepts, the wrong ideas, the wrong notions about NoSQL and of course, those wrong notions are negative. So, the purpose of this module is to look at some of the fundamental misconceptions people have about NoSQL and those 10 misconceptions I will be discussing as shown on the slide. So, you see there is a host of misconceptions and among them I have selected 10 of them. So, now let us look into more details about those misconceptions because as you can see over here that these misconceptions are very, they are addressing some very important aspects, very critical aspects for example, asset compliance for example, bread and butter of databases. Now, that is not the case that NoSQL does not comply to asset, that is not the case and it is just a hype that is not the case. NoSQL is used by Facebook, used by Amazon, used by Google, Oracle has NoSQL solution, Microsoft has. So, it is not a hype. So, I will go through these 10 of these misconceptions and after this module, you will be more comfortable and you will be more confident about knowing that the area, the domain in which you are working with NoSQL that has a bright future and it also has a bright present. So, let us talk of those misconceptions starting with single type of database. It is not the case unlike the relational model which only supports the relational model. NoSQL supports four different types of databases, not one but four and three types of storage mechanisms. So, if you look at the combination, it is a wide variety. It is totally wrong that it supports only one type. Then is the list is given over here. It is not asset compliant, that is not the case. For example, it is fully serializable in certain types of implementations and it is read, commit, asset compliance also. And of course, then there is the asset like consistency which is there at the client side setting. So, you have this NoSQL solution and you have to set certain settings at the client end which will ensure asset like consistency. So, that is not the case. That is a misconception. NoSQL lose data. That is not the case. Why is not the case? Because there are number of things for why because of which the data might might be lost. For example, it is a product which has not been properly configured. It is a product which is not mature enough. It is a product in which certain features have not yet been implemented. Because by definition, NoSQL is is open source, except for the license which have those lot of features. So, one cannot make a passing general judgment based upon something which is open source, which people are developing groups are developing and publishing it making it public. So, it is for less mature products and incorrect use. Guarantee of durability in asset compliance. This D, this D over here, okay. This D, this is there. This is there. Whatever is written, okay, that stays there. It stays there. Mission critical workloads. Now, if that was the case, so for example, if the loss of data, if there is a loss of data, then why would defense and intelligence agencies would have been using for mission critical applications? Why the banks would have been using for mission critical applications? Why the media companies would have been using NoSQL for storing their digital assets? Why the government healthcare system is using NoSQL when, of course, because there is no loss of data. It's a misconception. NoSQL databases not secure, okay. They support cell level security. Cell level means that I run a query, I secure a table or a group of rows and columns subset and I can secure at the cell level, which is intersection of a row and a column. That level of security is supported. And accumulo came from national security agency. This came from NSA. So, how come if it's, if it's not secure, then it's coming from NSA? Many open source commercial trying to replicate the red hat successful model. Okay. So the point is that many features come at a premium. You have to pay for them. They come at a premium. So the open source things, okay, which, which is open source groups are coming up with it. They may have certain issues, right? But that is open source. And there are many, they are all open source. That's, that's wrong. All Microsoft has their document DB oracle have and then France. So there are many companies like Microsoft may be a new intern, but France has been around for a long time. So it's not only open source companies. There are a lot of established players in the market who have no SQL solutions, their own no SQL. Only for web 2.0 application, it is just a hype. Now, since no SQL is is is public domain, so many startups adopted no SQL, okay, as their fundamental database. So that gives an impression that it is only for the no SQL is only for the web 2.0. That is not the case, because there are social media business there. But the most of the applications of no SQL are where the RDBMS was inadequate, more applications in the domain where RDBMS was not because as we have discussed before, that what we are trying to do with the RDBMS, the relational model is trying to force, we are trying to force certain certain problems, map them on the relational model for which the relational model is not suitable. And for those kind of models, we have the no SQL solution more popular. Big DBMS players have their own versions established players like Mark logic, which has been around for more than 10 years. It is not a hype if something is around for 10 years, if the major, major players in the database market have their own versions, it is not a hype. These major players have invested time, money and resources and people in it. If it was a hype, they would never ever have invested that kind of money in it. And finally, developers are not no SQL developers, don't do RDBMS, that is totally wrong. That is incorrect. The reason being that the RDBMS problems are different types of problems. The no SQL addresses different types of problems, right? So there is no points in comparing apples with motorbikes. This is the kind of comparison which people make it is irrelevant. No SQL will be gone. Okay, if that was the case, we have new SQL also, which is the blending of no SQL with the RDBMS. So it is evolving, we are getting new things. So if, if no SQL didn't have a future, why we have new SQL? So you see that there are many misconceptions about no SQLs, which are ill, I will never say they're ill founded or not, but they are misconceptions. And in this module, I have tried to make an effort to clarify those misconceptions. That is all I have for you in this module. Thank you for your time.