[MUSIC] One approach that you can use, for optimizing for reads is to try to group all the data that you'll need for a particular query into an entity that you can fetch by a, a key in one go. So let me give you an example of this. Let's say that I have, the comments page that we described before. And so for each of these comments, we're going to have the user name that posted it, we're going to have their particular comment and then we might have maybe the home town or the country of the. user. And maybe we have Belgium, some other information. And so we have a set of these comments. Now, one way that we could support this, is we could have a set of user entities, where each one has a name. And a country. And then we can have a set of comment entries, where each comment in, in as well as having the text for it has the user ID. Or key for the user that created it. So every time we want to go and create this particular page, what we have to do, is we're going to first query for all of the keys or all of the comments, for that particular page. So we'd probably also have some, you know, page or product ID or something to associate comments and go and search for comments. That are relevant to display here. So we get the list of all the comments back. Now, once we've gotten that list of comments back we can go and get the user ID's for each user that are in this table and hopefully be smart about it and, and only then query for the name and country of all the users. That are in this table, are that are in this list of comments, and then we go and get back to user and name and country for each particular user that posted a comment. Now, this is certainly one way to do it and helps us, you know, keep our database more normalized, because we're only storing name and country in one place. With the down side is, is that we go and get this list of comments and then we have to go down and get this list of users, in order to display the users name and the country that their from. So, when we display this page we essentially have two round trips that we're dealing with. Another way to do it would be. Rather than having a separate comment and user, what we can do is we can have a separate user. But our comment can directly embed the user, name, and country into the comment object. So this way, when we need to go and display this page. So let's call this approach 1, and we'll call this approach 2. We'll put a little versus here to show that these things aren't related. When we need to display this page, all we do is go down and fetch the list of the comet entities, or objects. And return it, and we can instantly display the page, because we have all of the information we need. So, if this is a mobile device, and we want to very quickly give it all the information that it needs. Now, obviously, the server would be doing these two round trips. So, the mobile device, hopefully, isn't doing theses round trips. This should be something that's done on the server, even if we doing it this way. But either way, we're going to data back to that mobile client to display much faster if we have an entity that has exactly the information that is needed to display this particular page in the mobile interface. So, if we design our entities in ways that give us exactly the data that we need, it can make it much faster. Another way that we could do this is if we new we weren’t going to have to many comments, and we weren’t going to be writing to them to often. We could even take all the comments for a particular product, and have a single comments, for let's say product. Entity that directly inside of it stores the raw text of all of this. So, in this case, we have multiple of these comment objects that we're going to be fetching, that we could just as easily have a single aggregate object. That puts all of the information that we need to display this page into one entity that we just look up with one key value look up. So there's lots of different approaches and they'll give you different performance and different ones will makes sense in different cases. Probably in most cases if your really trying to optimize for the reads, it maybe makes more sense to do something like this, but maybe it doesn't. Maybe it makes sense to have comments for product and embed them all. ANd you really have to look at each case. Now the downside is, here we have normalized data, so if the user wants to go and update the country that they live in. They, they are currently in the US and they are moving to France. Now they're going to have to go and update their France, you know, their country, if they're currently, in France and they're moving to the US, we're going to have to go and update their country. Well, here, that's no big deal, we just go and update the user entity. If we do it here, now we have problem. We have to, if we, they update their country we also have to go in and update every instants in the comment entries, where their countries shows up. So we have to find every one of that users comment, we then have to find the country field in it and that were in the value or however it's been stored and update it, over and over. And similarly we'd have to do something like that for here. So that, that denormalization, and these different approaches, they can make reads really, really fast. But they make, make writes or changing just one entry in the data really expensive. So, you have to be careful that if you're going to go for a model like this. Or a model like this, that the data that you're denormalizing into these things, hopefully is not something that will change frequently. So if you were duplicating over and over, you don't want that data item that you're duplicating over and over, to be something that will change frequently. So, username for example, you can have a system where you could say, a user cannot change their name, as long as they are having an account with me. I'm going to have them have the same username, they can never change it. They can change their email address to their hearts content, but the can't change their username. So going in duplicating username, in all of the comments, probably isn't going to hurt you. But if they can change their username or you're doing first and last name and the person can change their name potentially or you're going to allow them to, then suddenly it is expensive. So you have to think through those issues when you're trying to make a design decision about whether you're going to do something like this. Or you're going to try to optimize it and make it a really fast read that has all of the information already embedded into the entities that you're getting back, or the single entity that you're getting back. But you are understanding that you are going to pay a price if any of this duplicated data ends up changing. And that price is, is you're going to have to search through all these entities and change it. And ten or 100 or 1,000 places rather than one place. So, every time you duplicate that data you're adding write overhead if you try to go and update it in some way.
