 So, in this module, I will talk about the hybrid advantages of a NoSQL solution. Hybrid means that it is a combination of different things. For example, if you say it's a hybrid car, it means it is running on petrol and on electricity also, that is hybrid, or running on compressed natural gas, that is hybrid. So, we are talking about the hybrid NoSQL features. Now, a problem can be solved using different approaches or different data structures, so to say. For example, a problem might be solved using a key linking feature. It can be solved using triples or a document-based solution or a big table-based solution. So, there are a number of ways of solving a problem. And of course, if we have this key-value-based feature that supports indexing, and of course, the document model also supports indexing. So, the point I am trying to make over here is that NoSQL is already hybrid. But of course, one has to do things in a formal way in a certain way that hybrid ability and the features are used properly. And what are those features, and what do we need to look at them, so that is the purpose of this module. So, let's first look at the module coverage. The first point which I will be discussing in this module coverage is the death of the polyglot persistence, death of the, so what is that? I will cover this. And advantages of the hybrid approach, of course, I will talk about it. And one thing is very obvious that of course, if it's a single product, it will, the overhead, the maintenance will be less also. And all those things. So, let's go into more details because what you can see on the screen or without going to a lot of depth, that could not be showing you the entire picture. So, let's go ahead. What is polyglot persistence? Polyglot persistence means that I have a complex problem and I divide that problem into segments and I use different data models to address the parts of the problem for those different segments. And then I aggregate the solution. And then I have the final solution with no sequel, which has four different types of data structures, okay, there is there's no need to have polyglot persistence that is already supported to that is what is meant by the death of polyglot persistence to one product many features to one if I have a single product, which has lots and lots of features, then of course, I need to train people on one product, okay, and I need to have the people that are working that are developing in a single environment. And of course, I don't have to do the plumber plumber coding plumber coding is how do I connect different parts of the code together, because that has already been done by the vendor who is providing the solution. Now the question is that best of the breed or a single best of the breed is that means that I have the best solution, okay, and a single solution may not have all the solutions to the different domains in which I want to apply it a very high quality, okay. So there is a limit, there is a limit between when I need a single solution and of a jack of all trade, or I need multiple solutions, so you as a trusted advisor knows where is that boundary, where you shift from the boundary of a single jack of all trade kind of a solution to multiple solutions, each one of them is a unique or best solution. So the general strategic technology stack implements a single data layer to power all your applications, okay. As an IT professional, you probably unknowingly been using relational database management system to do this, but no sequel means there is no upfront schema design, then is the common indexes and no duplication, storing a single index rather than having an index of the same data and multiple products is advantages, storing a document in an enterprise content management system or platform means indexings are held in an RDVMS, similarly more real time data through the stack fewer moving parts, because indexes are updated as information is added to hybrid no sequel, document database and search engine, pure indexes as well as nearly real time indexes are produced, or at least they are transactionally consistent. And finally, easy administration, pure moving parts database admins need to be absolute expert on the systems they manage. And of course, instead of having multiple people, multiple experts of a domain, you have a single domain expert. And with the moving parts, I believe you understand what a moving part is. So with a single product, the costs are lower, less integration costs, because you don't have to integrate different things from different vendors that has already been integrated from or buy the vendor which you buy the product, ETL extract, transform load, that takes humongous cost, okay, and when when you have a single product, you don't have to connect things, you don't have to bring different things into a uniform format, okay, so there's less ETL coding, lower software license and other costs, instead of buying multiple softwares to do the job and paying multiple license fees, you pay upfront fee for a single license. Of course, lower training costs instead of, of course, it costs more to train people in multiple products than to train in a single product. And of course, you don't need multiple specialists. If you have multiple specialists, you have multiple salaries. And of course, that costs more. But if you have a single product, then you have a single specialist for which you don't have to pay a salary of four people and fewer moving parts. Search technology and column store, as I've already discussed in the slide before that, that as the document database in NoSQL is updated, the indexes are also updated in almost real time. So that makes the search very relevant and very fresh, real time index, all common aggregation algorithms are present. And if you are not satisfied, you can write your own aggregation algorithm in C++. That is the benefit of hybrid NoSQL. Now, the thing is that everything or every problem cannot be modeled using the relational model. You have to look for the, for the relationships, not based upon the primary key and the foreign key, but how things are connected so to say, for that, you need a triple store, which is supported by the hybrid approach of the NoSQL solution. But remember that semantic web is not a graph store problem. It is not. You, we have, I gave you the examples also, okay, subject of subject predicate object. I gave you the examples also, so you know what I'm talking about. Then you can make it more powerful by adding in which context the search was made, because the search is not sufficient until it kind of differentiates what you are looking for. And if you look at the prior search results and integrate them, that is going to help you present those results based upon which people were differentiating using the same or similar keywords, which you have used now. And of course, you can have a combination of this document database of NoSQL with the triple store, which will reap the benefits of both data structures. And it will be a powerful hybrid solution. That is all I have for this morning.