 So, first of all, I'll introduce myself. I'm Deepali Trivedi and I'm platform architect for Staples.com. And this session, as part of this session, I'm going to share my learnings, my experience, what we did at Staples and the general application of musical technologies for a scalable e-commerce platform. So if you are here from the last two days, you heard a lot about all these different vendors and companies who actually write, either write the products, NoSQL databases, or they provide the services, right? But this session is from the different angle. It's from a user. If you are part of a, like, if you are a developer architect, manager, executive at any IT company and you are looking at NoSQL, hearing a lot about it, how do you start? I mean, you have a scalability issue, you are not that happy with other things, but how do you really start and make a change in your organization? So this is more from the user point of view, and how do you apply, how do you change your mindset when you start working with NoSQL technologies or big data, and specifically about the scenarios where it can be helpful. I mean, it can solve each and every problem that is there in IT, but it can be applied to specific areas and it is really helpful there. So I'm going to share that. A few years back, when I started to hear a lot about big data and NoSQL, MongoDB, work at Central, everything, I always thought that it's more for search engines and social networks. I mean, it's not for, like, that I think I was working with Pearson and learning and education domain. I thought, yeah, it's great, yeah, very good, like, for PhD students and for search engines and social networks. But as I was introduced more and I started using it, like, in one day, like, we really decided to go with it, after using it for a few years, I realized that it can solve problems in any domain, actually. So I personally use it in learning context and educational websites, identity and authorization and any commerce, for sure. And this is why I thought I should share with everyone that this can solve problem in many other areas. And just to give some background on staples, I mean, how many of you know staples? I hope you don't know how many of you buy from staples or check out on staples and go online and buy it. So for staples, forget about retail, just looking at staples.com is the second largest website in terms of revenue. So of course, scalability is the biggest challenge or one of the key areas, stability and scalability, especially when the holiday season will come, Cyber Monday, Thanksgiving. I mean, that is the focus, scalability and stability. So I'll just start with some of the context around e-commerce. And if you buy online, I mean, you know what e-commerce is. So I think it's not a new domain. But just from the data modeling point of view, I always think of e-commerce as a key entity, and you can disagree with me. But I mean, I always see it revolving around user product and order. So for user, why user is important? Because they are going to pay for it. They are going to buy and you are going to get money from that. And we run a lot of analytics and a lot of logic off of user and what they buy. So we divide the user in all these different segmentation. Oh, this is the user. This is a set of user who buy electronics. These are the user who will generally go for all the printer related stuff. And we target them with different promotions and couponing and ads. So that's why this user, and there is a lot of things. I mean, I just try to capture the main entities, but there are a lot of other entities that goes with the user product. And again, for the user, as I said, we do a lot of things with the user. And I mean, there are many users who are the client of the website. I mean, we need scalability for this part of the system. Now I go to the products. So product is all the skew or skew set that we sell in e-commerce website. And it is part of category and catalog. Ideally, product should not be the need that much of a scalability because there is a fixed set of skew or skew set that you are selling. But with this whole change with marketplace concept, we are allowing all these other vendors to come to our website and sell this stuff. And that's why there are huge number of skew and skew sets on the website. And that's why even product is an entity that needs scalability for e-commerce. If I go to the third one is order, and you can tie it to the shopping cart because we do a lot of things with shopping cart as well. But the order is the final key when you get the money and you do the checkout. And it has all the integrations with the backend system and fulfillment system and inventory check and with the online pickups. All other things are tied to the order. So that is the last push that needed to finish the transaction. And order is the place where you really need the transaction. So we'll visit that in detail how it works out with NoSQL. So this is the very basic data model for e-commerce. Okay, so if you, and some of the slides, I mean, I'm just trying to capture the key aspect of the NoSQL adoption. Like, if you are coming from SQL background, like many of us, right? I mean, I'm coming from SQL background. I studied normalization to that during my engineering and then used it for five, seven years. And I thought I was exported like doing the normalization. I mean, I can work with business and I was for a few hours and have a perfect data model using normalization. And one day my phone turned upside down and there is no normalization. I have to think from other way entirely. So, and that's why I think when you are as a user, as an architect, as a developer, going to end up NoSQL from coming from SQL background, this is the key. You have to just forget about having this normalization and start thinking, you have to try to merge all your data and try to see very few number of tables or very few number of core entities. So, just take the example of user, right? So if you do normalization, like the relational database, you will create one table user and put first name, last name, other attributes there. When you come to address, you will see, oh, address, if a user can have multiple address. So I should put it in a separate table and have some references here. For user segment, again, it's a separate table. No, no, no, it should not be here, it's a data application. So we'll put it in separate table and whenever we want to get the information across the entities, we'll try to do the joints and then get the data. That is the usual way, right? Now, forget all about it. Go to the NoSQL and you have to start with this flat entity. So you should, you have user, you have first name, last name, address. When you go to address, address is the nested entity of the user entity. So you don't create a separate structure for that, separate document for that. But you embed that and you call it nested entity here and you put it there. Same way, all the segmentation, users who buy a printer, this, that, everything, you try to put it here. I mean, I should not say everything, otherwise you will have just one document in for the entire table or entire schema. That's not the way, and we'll go to the next one there. So when we started doing it, we argued a lot. Should we really put user as the nested entity of segment or should we put segment as the nested entity of user? And I tried to find some guidelines like how do we decide per case, right? I mean, I can tell as a happy, oh, for this scenario, this makes sense. But why and how do you repeat that for development? So I think many others are also calling the same thing as question-oriented schema design, right? You work with your analysts, you work with business people, you find all the action that end user will take on your website. Then you try to identify inputs and outputs. So ideally, you are trying to identify the queries that will run on your system. The key here is that all the parameters of the query should be part of one document or one table or whatever you call in no SQL terms, right? If you are doing columnary interest, it should be part of that one structure. Whether, how to divide, how to decide nested entities? So just two examples, and maybe that can give you some answer. So if you are trying to figure out, most of the time, you're trying to figure out what are the products viewed the most in last week, then you start with the product and the viewed by, users are nested entity as viewed by. So that you can run the query efficiently. Or if you are interested in what are all the products viewed by the particular user in last week, you are trying to target the user, then you can start with the user input viewed product as the viewed column there. So, but the key, you can do mistakes here. I mean, that's fine. But the part that is important is that all the input and output parameter of the query should be part of the one structure. And that is the key. So, sometimes as a user, like as a user of technology, you don't really care too much, like how Java does the GV, JVM, how they put the variables in heap and all this thing. Like you really sometimes don't really care how does all this data business put, share the data in this different partitions. Like you know, you want to know limited amount of knowledge so that you can do your work, right? You don't want to know each and everything about that technology that you're trying to use. But there are a few things you really have to understand about NoSQL before you start using it. I mean, you don't have to know each and everything, but there are two or three key concepts when you design your system using NoSQL and eventual consistency is one of that. I mean, if you are attending all the sessions, I mean, you must be expert at eventual consistency. But we have used relational database for so long that we take this asset properties or transaction management as, like default, right? We think, oh, it's always there. But it's not always there when you start with NoSQL. So you have to understand whatever NoSQL technology that you choose, you have to understand whether it have eventual consistency, like weak consistency or strong consistency, like how does it work out and you have to design your scenarios accordingly. Just to give you a very, very basic example of eventual consistency, what it is, and this is a little bit of non-commerce example, that if you have an account in bank with $100 and you open two browsers and fire the event at the same time and try to deduct $60, if that bank website is using relational database, it can throw error for one of the transactions because it's real time consistency, immediate consistency. You can get error in one of your sessions that you don't have enough amount and things like that. But on the other side, if you go to ATM, right, if you somewhere you try to deduct the $60 or $70 from two different ATM, at that time you can get the money, but eventually you will get some message alert and your account will have minus balance because ATM is a different transactional context, so it can't really have global transaction across website and ATM. So I mean, at the end, after some time, after delay of few millisecond or second, it will match up, but it won't be the real time consistency. In eCourse where it's important, inventory check, right? If there is only last printer left and there are two users who are trying to buy the same printer, one of the users should get an error, but it might not happen in that way in real time if you are using no SQL. So you have to design your system that way so that you don't really deduct your money before you know that there is a printer result. And I can discuss that part in detail at the last, but I think we struggle a little bit when we try to design some of this type of a scenario that really need transactionalization using no SQL. OK, so again, I said sometimes you really don't want to know where your data is stored, right? But one key concept that you should know about no SQL is that all of your data or all of your tables are not in one server. It's actually divided, it's partitioned, and it's sharded, and it is on this different physical server. It makes the life of your IT department infrastructure thing very easy because you don't need one beefy server. I mean, you can have a few commodity servers and you are good to go. So it's good in that way. But just on the logic side, you don't understand that your data is divided here. And that's why that is the reason why you can't do the join with no SQL, right? Because the part of your table or part of your documents are divided everywhere. So ideally, you can't really do the join very effectively. Mostly you are coding at application layer, but you still have admin and others who are dealing with this configuration and this logic. So that is one more key aspect of it. So just to recap on design guidelines, you had to think about aggregation and nested entities overjoin. Whenever you say your data is not normalized, you had to be OK with some kind of data duplication. Because normalization is good at that. It will avoid the data duplication. But when you are saying that it's denormalized, there can be some data duplication in your system, you'd understand eventual consistency. Actually, you had to understand the cap theorem. You had to understand you can't get everything. You will either get any two out of consistency, availability, and partition tolerance. So most of the no SQL technologies let consistency go and focus on availability and partition tolerance. So whatever technology that you choose, you should understand what is the product that you are making out of this three. And then sharding and linear scaling. I mean, sharding is the mechanism, but what you get is linear scaling, which is the key benefit. If I go up, how do you really build the e-commerce data model? You decided you want to start with the no SQL, and you did some presentation, and your VP, your director, everyone is, oh, yeah, let's do it. How do you really start doing it? And I think there are many other steps in between that. But I think this is a little bit from the SQL mindset. But still, if you follow this, you will get the initial data model for your no SQL system. So first of all, you have to identify the operations. The operations that end user will perform on your website. You identify all the entities that is referred by that operation. And then you identify the attributes of the entity in context of this operation. And then you identify the relationship between these entities, and then you repeat this for all scenarios and combine the design at the end. So the example here. Very, very basic operations for e-commerce. Find product by category. Or add product to the card. So find product by category. It will refer to product and category. Or add product in the card will refer to shopping cart. And what are the attributes that is needed there? So for a product's name, or two items in stock, price, category, et cetera. For categories, ID, name, or list of products, card, same here. Now, what is the key? As I told you, you have to think about all the parameters needed for each operation. And it should be part of the same structure. So you said find product by category. So you need all the attributes of the product and category in context of that operation part of the same document. And that's how you can match your data model, whether it will work at the end or not. So you can see here product. Product will have skewned the price as whatever is the key entity of the product. But it has category as well. So that you can actually run the query and find product from the category. Or you can find the categories of that product. And the card, so add product to the card. So the card will have all the card attributes here. But at the same time, it will have product that is added to the card. What is the total of it? What is the user that is owning the card? Things like that. Same here for the user. You have all the user. But at the same time, you have segments or products that you bought, card that you have, things like that. And again, I told you, you have to match. You have to look at each operation or each query and see whether you can find all the answer of that query from any one of your documents. And this is more documented or needed. But you can do this anyway. Why is a card separated document from user? I can see over here for you, you have a card also. Are you duplicating or are you duplicating the product? Duplicating. So we are running a lot more analytics and a lot more query on the card, just the card. So every time if we go through the user, it will add some delay to that. And here for the card, we will not have everything. It will have only a subset of the attributes that is needed for here. But this card will have everything. And that's why I said, when you do the denormalization, there will be some amount of data duplication. You can decide. I mean, it's always a trade-off. If you don't want that duplication, you have to be OK with running the query in certain ways. If I go to the next one, again, if you have used any of the NoSQL, I mean, this is no brainer for you. But I still wanted to give you some real queries or example how it can apply to the e-commerce domain. So for example, find product by skew, that is still, oh yeah, that is correct. So I'll say that is like db.catalogs.find. So I mean, I'm just trying to show how different or how similar it is to SQL. Update the card so it will have some kind of push, addition or upend kind of thing to the card and it will increment the subtotal and things like that. Find the user by zip code. This is interesting. And again, this is a whole new topic of using Hadoop. But I will visit that. But how can you, I mean, there are few operations. There are information that is data-intensive, right? And time-intensive. And that doesn't really work out well for real-time queries. But if you want to see some of the trend long-term, we really need analytics and we need some other weekends. So this is the example for that, MapReduce. If you want to aggregate all total orders by zip code, you want to see how effective our website or our campaign or our company in this one particular region, you can map and then reduce and try to run it on orders and find like number of orders by zip code. Actually, if you want to do this for the last two years, you really need MapReduce. But if you want to do it for a shorter time period, like for a month or less than that, you can still do it with this kind of property. It doesn't take that long. So again, because I showed you a lot about MongoDB, just to give another variation of data modeling for e-commerce using Cassandra. And I mean, Cassandra itself a big topic. I can't explain you column and column family and super column and super column family here. But I always think of Cassandra as a recursion of table, right? I mean, if you have one table and you just take out one column and put another table there, I mean, that's how I always think of Cassandra data model. And so here I try to capture the user as a part of a super column family. So each user will make one row. So one row, each row is consist of one user. So that is the key, user one. The value will have again a column family. And in that column family, the first column is product spot and that will have two products. Then cards that will have products in total both. Again, the second row is user two and user two is the key. And again, the column family there. So that is how you can do it. And then you have to figure out the whole new syntax for your queries and things like that. Map header will remain the same. Okay. So next I'll go to analytics. But what I want to say for just on the nosical part is that as part of this presentation, I'm not trying to take a stab at best nosical technology for e-commerce. I mean, I don't think even I have expertise or even there is a finite answer in industry for the best nosical technology for any domain, for say. I mean, you have to look at your use cases. I mean, I don't think there is any e-commerce platform can decide one day I want to rewrite whole system, whole site in nosical. You really can't do it. You have to think incrementally. So you take subsystem of your website, you take one component, try to use nosical and put it out there, see how it goes. And then, so migration is a whole new topic and you learn from your one implementation and apply it everywhere. And it's, I mean, we are going that idea and I don't know how everyone feels about it that maybe we can use different nosical technology for different subsystem of our website. We have to see how that goes. But it's hard to find one nosical technology that works for every scenario for such huge website. So that is just to share some of the thoughts that is going on for some. I don't hear that many slides. If you have a question, you can ask me. I have a question. Sure. Kind of back on the thing where you said I have the three different ways of looking at the data as a user of the old one. And so I have this product, the red paper, and it was $24. And, but you now have a price increase, $26. So does it happen such that if I happened to have gotten in at the $24, then my shopping cart was like $24, even though somebody else who may have come in because of the fact it's not consistent across, they will come up with the $26. So when you don't have consistency, like immediate consistency, this can be one of the scenario. And what we argued at the hard time is that we, I mean, for stipless.com and many other websites, they don't really change price in the middle of the day. They do it like one batch at the night. So anyways, we are not doing it real time. So it doesn't matter. Like we can invalidate all the web session at that time whenever we change the price or we can do some logic there. Like one doing that one time thing is easier than doing it like for every second, right? So then we thought we are just arguing or we are worried about the wrong problem and that was the conclusion. Because generally there are not many sites who will change the price in the middle of the day. Okay, but also I have price here, I have price here, I have price here. And is, from a data management point of view, how do you know that those are all price relation? It's all the same thing. And so in one system, there are different prices? You are talking about? In your system, you had basically three different documents. All had price in it, but you know that those all mean the same thing, those all mean price. From a different point of view, how did you know that those are all the same price? How do you keep it consistent if they're all called price? Yes, so actually for most of the e-commerce website works this way and our website also works this way that we have a different system, subsystem that we call PDB, like product data management. And we store all the pricing information there. So most of the price that we'll copy is the done product, orders that we'll save the price for, but ideally we won't have the real price fitting into our notes equal to store. So PDB is entirely separate subsystem that runs entirely in different, different, what do you call? It runs out of the website and it just has the integrations. Every night it will push the data. After that, the data is read only. So in our website, wherever you are seeing price, it's read only, most of the time it's all done. Either a user already bought that product, that paper at that price and that's why that price doesn't matter or that is the price for that day. And at the night it will be pushed again. No, I got to be in the morning. Sorry? That's what you want to ask. No, it's one of those things where you kind of say, I'm going to work on the price document, right? You're going to go work on the, a different document, the order document. And he's going to work on the third document, whatever it was. If we're not talking, how do I know, how do you know to call it price when I call the price and he knows to call it price? How do you keep track of that? So every night the data will be pushed and all the data. But when you defined it, even when you said this is the data that I want, how do you know that you should call it price? Maybe you say, I'm going to call it the sale number or whatever. No, no. And that's why we have to decide on this first, some basic structure of the document. Otherwise, all these different people will refer to this prices differently and then they can't really, yeah, yeah, definitely. We have to come up with, and that's why I know theoretically we can change the structure anytime we want and all that, but it doesn't work out that well with real scenarios because you have your analytics running on that. Today, suddenly I decide, oh, this is not price. This is my sales price. It won't work for analytics, right? Because it's running off of that. Or some other tools that is running off of that. So, yeah, theoretically, yes. I can still change my document structure and do my website will still work, but it will mess up something. And that's why I'm putting a lot of emphasis on this data modeling. Ideally, if you really go to any NoSQL tutorial, anything, they won't talk about schema. They don't talk that much about data modeling because it's flexible. You can change it as you are, but it doesn't work in real scenarios. That's why I agree with you, totally. Okay, but do you have anything that you can either do someplace else or something? Yes. That you keep track of price is always called price? Yes, so this is our take. That for e-commerce, 80% of transaction is read only. User will just browse, browse, browse, and then they'll buy. So what we are trying to do is that we are trying to use NoSQL. We are thinking about using NoSQL in those read-only scenarios instead of writing those scenarios. And that's why wherever we are writing the price, that system is still SQL. And then we are pushing this here and then everything is NoSQL, but it's all read, you know? So we don't have to worry that much about consistency. Oh yeah, and that's the thing I said, right? I mean, some of, maybe at the end, I shall say what is actually we are doing, what is the plan to do, and what is actually done. We can't really take our whole website. I mean, it's not possible to take the whole website and do NoSQL, right? We are just trying to look at this new subsystem that we are writing, for example, reserve online and pick up in store, okay? So we are trying to look at that and trying to see how we can use NoSQL in that scenario. So it's a very small subset of thing, but we are trying to think about this big bank just to get an idea how it works out, how can we do data modeling, how does it look like, and what are the areas that can give us the pain points. So that is it. Sure. So you talked about data being pushed, but it's been right happened somewhere and the data is pushed over. So have you had any concern over how long that takes and whether you need to bring some pieces of the system down or something like that? So today it works that way and it works really well. So every night something will run and it will load the data, but it will be enabled exactly at midnight or some point of time. So it will be loaded first, but it will be enabled for everything, like at one particular, like 3 a.m. in the morning. So that, I mean, we are not really worried about the loading part, like how long would it take and things like that, not worried about that part. So basically getting the data was a little more than how it's not really that big of a issue. There are a few things that is tricky there, but overall, no, I don't think it's that big of a thing because we are doing it one time. Yeah, sure. What is the usage of your loss equality guy? I'm still not able to understand. Yeah, it's not heavy for students. And maybe we'll go to the next one. So we are looking at the no-sequel technologies for a few specific areas, whatever the new areas that we are. And more on analytic side and more on, I don't know how much you know about staples, but we are using IBM commerce as our core engine. So, but we are trying to come up with all this new subsystem on cloud and open source and using no-sequel. So that is the new initiative and we are thinking about all this for that issue. Is it for order management, posting real-time transactions? No, no, no, no. So these are not your actual documents for cart management? Oh, no, no, no. This is just an example, right? This is not just the example, but this is some of the blueprint of the things. And once I'll get more feedback, that can help us deciding the directions. Good question. I agree with the use of the technology. The data has to be stored in the no-sequel. And for persistence, it has to go in layers, get stored in Hadoop or in your relational data systems. So, for that system to understand that the order is coming from this particular user, it has to be mapped. This ID has to be tracked with that system, right? So how do you do that? Very true. And that's the problem going with the subsystem, right? If you just decide to do no-sequel just for one subsystem, all your other relational systems need that foreign key that you are stuck with. And that's why you have to have that foreign key and you have to have something which will map your foreign key with this user ID, whatever you're talking about. And that's one of the biggest challenges we are seeing with this subsystem design and with this migration and things like that. And that's why we are trying to go with the systems first that doesn't really deal with this core entities, but it will have some, like I'll give you the example, right? It was online and pick up in store or something like that, which is really a top layer on the core website. Can you? So as of today, you have some kind of a mapping table which maps this mostly for unique keys with your relational data as unique keys? No, no, not today. Not today. This is the plan. This is not in production. But we have done very similar at Pearson. I have done very similar at Pearson and where we were trying to just take the user, just the authentication part and map it at MongoDB and everything else was in relational. But that was true so far. So we never had foreign key. It was like, it was vertically partitioned. So only there was a separate user schema and web services that we could replace very easily. And user was interacting with all other entities via web service. And that's why it was easy to really take that subsystem and rewrite it using NoSQL. So if we have the application like that, it's easier to just take one part and rewrite it. So I have a question there. You have a user's entity and over there, there is a product spot. That's one to many relationship. So is that product spot only for that particular session or it is mainly for the history also? So you had to decide if you, I mean actually on our website, one user don't buy that many different product. They buy the same product in reputating quantity, right? Like paper. So they will buy the same paper but like every month or like they buy the quantity will matter but not the total number of products they bought is really that different. But if there are like large number of products bought by one single user, we have to decide like how much data we want to store for that immediate system and how much data we want to store for analytics and long term data. So I mean if there's something like Amazon, they can't really store all the products bought by that user in your immediate scheme. So you can decide how much data you want to store. Do you guys take the data from the SQL store and merge it with like the order data for example which is maybe stored in a SQL store and send it to the do for large scale aggregation? I tell you one thing, whenever we start this migration order either it will never be turned into no SQL or it will be the last thing to turn into no SQL. So that's for sure. For now there is order is something that anyways it's a subset of we are using sterling for that. So it's more like a saspis vendor product for us. So we are not looking at the art but we know all the transactions and complexity around consistency will come into picture when we go to the order and that's the, we are not worried more about the checkout and everything because it's all like, all we just punch into Bank of America and get something out. So we are not worried about that part but we are more worried about the inventory and few other things that really is. It's actually more downstream towards Hadoop. If you're joining the order data from your SQL store with the stuff in your SQL store and sending all that stuff down for Hadoop processing. We are not doing it now but that's the one area we are thinking a lot about. So here, right? So what is, I think I just came out of there but what is more important for e-commerce? On one side you have all your sales data, right? On the other side you have all your co-opening and promotions and ads and everything. How do you correlate that? I mean you want to, you just don't want to give away your stuff, right? You want to sell it at the price where user will buy it but you still make the profit out of it and that's why all this cross channel analytics is the key. Today for IT the problem is that there are many, cross, many ways you can sell data and there are many ways you can target user. Retail, tablet app, mobile app, then web store, there are global other, like Staples have 34, presence in 34 countries. So how do you really reconcile all this data and how do you see what is effective and what is not effective? And that's where we are struggling. I mean ideally we can really plug into all these different SQL and write one centralized SQL database or have some ETL and EDW but it makes it very, very brittle because if retail or if a website will change the data model, all the CTL and everything has to change, everything has to go at once and it's not scalable. I mean we get the data like 10 days back but what if we want to use the data from Black Friday on Cyber Monday, right? I mean we really need new real-time data and that's where we are thinking about using Hadoop and if all the system can send the text output or logs, several logs, et cetera and we can fit into the Hadoop cluster and run some map reviews or high because we still want to store our data long-term in SQL if we really want to or something like that we can still read this text file and have some dashboards or reports and everything out of it, some conclusion out of it and I think that implementing this will be easier than changing the core website into no SQL and this will have immediate success or immediate benefits in terms of that. I don't know how, I mean in that I mean I want the feedback on all these things because we are going to build that and we are thinking very seriously about that. Again I said I'm not going to compare all this no SQL technologies but just very basic overview of challenging advantages and disadvantages of SQL and no SQL. I think asset properties and this transaction management is the key. We are so used to it and there are many advantages with that so that is definitely the plus on SQL side but on the disadvantages. How many of you have tried zero, I mean how many of you get this push from your management that we should do zero downtime deployment and all this like DML changes are always complicated to manage for zero downtime deployment. Like you really want to run this DML queries and then fill the previous data and fix the other data and then that's kind of complicated. So it makes it brittle. There is no real linear scalability to support the master data volume and I mean it struggled with the lightweight analytics and things like that. On the other side no SQL grade, you don't have to worry about schema and brittleness and I mean it works really well for e-commerce because it's all read. Like most of the things are read until an early user will decide to buy that it's all read. So it works really well for that scenario. For normal IT I think the expertise and try to adopt this new technology and make the changes is one of the challenges. Like it's not the technical challenge but it's a challenge for sure and sometimes limited query capabilities and I think there is a lot of improvement in the last few years in this area. Like I mean earlier there was not a control for no SQL but I think all these companies are making progress in that one and migration is the key thing. If you are working on a new product that was the thing with Pearson, I mean working on new product was and using no SQL was, it was easier but having something that is full grown and really change it to adopt no SQL is quite a pain in the ass. Again you don't have to worry about matching it and mapping it to different SQL and things like that. You can directly process the logs and tags and it's highly scalable in the expertise and all of the things are the challenges here. If you have any questions you can ask now. I would love to get your feedback if you think something makes sense, something doesn't make sense. This is not the direction that we should go or we should go. Please send me an email. This is my post email but you can, it's at dipali.3vedi.strippers.com is another one and that's all. Thank you. Thank you all for listening.