One of the first things you need to do when you're going to optimize your MySQL database and your interactions with it, is to think about do what to optimize a particular. Piece of data, and the access to that data, for read vs write. And this is a really, a fundamental question that you need to ask, because it vastly changes how you want to store and interact with that data. So, lets take an example, and we'll relate it back to our original Java Map example to help understand why. Knowing if you're going to go for reads versus writes is critically important. So let's say that we have a form and we would like users to be able to post comments, let's say on our videos. So, users can go and they can post a comment. And on the page we would like to be able to display, the number of comments, that have been posted by each user. So, somewhere on the display if the user's comment is there, we might have user foo and we might have some number of comments that they've. Posted across all the forums, let's say just for sim, simplicity. So, one of the things we need to be able to do, is we need to be able to keep track of this count, of the number of comments that they posted. So, there's kind of two approaches we can do. One approach is, we can have a table where. Every time the orig, sum structure where every time the user posted a comment, it would be entered as a center entity in this particular store. So I'm using this entity. Name very specifically here, because we're going to go and create a Java class to represent a comment, and we're going to annotate with something like add entity, and each time they create a new comment, we're going to create a new instance of that object, and we're going to store it in the, list of comment objects. So, we've got. These comment entities are objects, stored objects, that represent each time the user goes and posts a comment. And so there might be some number of these. Now, the way that we're going to generate the number of comments is, each time we load this page, a request will go to this table. An we will search, for all comments that, where the users of particular users. So find all comments with particular user. And count them. So, as you can see, this is an operation that is very cheap from write perspective. And very expensive from a read perspective. So if I want to write and add a comment. Then, what I have to do, is just, create a new instance of a common object. And add it. And store it so it's persistent. But there's no, locking or any other things that I have to worry about because, it will never be the case that multiple writers. Hopefully are writing to the same comment at the same time. If the user is on the page entering a comment and hitting save, they're going to be the only one, theoretically, creating that comment. They're hopefully going to be on one page at a time. But they're creating one comment. And there's only one person logged in and even if there were, they had multiple browser tabs open or for some reason. Their, their child is commenting, as well, simultaneously. None of those comments conflict with each other because they're all, each, you know, atomic entities that would be edited separately. So each time they click Add, it's adding a new entity in here. So comic creation, the write, is really cheap because there's no locking of the database. No worries that, that multiple people would write to the same person and comment at the same time. However, our reads are really expensive. If we think back to that job of map example, where when we wanted to know which, people have bought a particular item, we had to go an search through and scan through all of the data and all of the values. Looking for ones that match our particular cr, criteria. In this case we're doing something similar. When we want to know the count for particular, user, what we have to do is count all their comment entity objects and then create the sum of that and then return it. So its an expensive read operation so, read. Is slow, write, is going to be fast in this case. Or at least they're optimized to make reads slower and writes faster. Now if we really cared about was getting the number of comments quickly, what we could do instead we could have. Another table, and, and we have could have entities in this, which it were, comment count. Now, in this case, and we'll just go ahead and make this by user. So if you want to know. The number of comments that a particular user has left. We're going to do something equivalent to what we did with the maps in Java. That is, we're going to create a new map, or a new table, or whatever you want to think of it as, and the entities in here are these comment count objects that we are persisting. And, every time you want to get the comment count, all you have to do is put, pi, push in the, the user as the key, and the comment count pops out. So it's a very simple key based lookup to get a particular user's, comment count. But, the difference is, that every time that we go and add a comment now. We're going to also have to go and update the comment count. So read, or so writes are getting more expensive, because now if we add a new comment object, we also have to go here and update the comment count. And we might want to do this in a transaction, so that it's atomic, and you can't add an object here and then not have it update here, or update here and not work over here. So we might have some transaction issues. We also might have the case where if now, if this users child is, is creating comments at the same time we can't just assume that we don't have to worry about locking. We have to lock this object particularly if there's any situation where the user could be multi, logged in multiple times. Somebody else is using as a count. Now, maybe that doesn't make sense, but you could think of scenarios where you could have multiple writers to the same object. In this case, we have multiple potential writers to the comment count. So if the user posts multiple comments in a very short order from multiple tabs or something else in their browser. They will all simultaneously be trying to create common objects here, and then simultaneously trying to be write to the common account. So we'll have to do some locking on, this particular account, to make sure that we don't end up with inconsistent data. Also we'll probably want to have some type of transaction to make sure you can't add a comment and not update the account. Or vice versa. So, in this style over here, the writes are slow, and the reads are fast. So, this is a thing you're going to see over and over when you're designing for NoSQL. And trying to figure out, how do I design my entities to fetch them? Well, we can go and we can duplicate some of the data. We're suddenly having another representation of the comment count, and we can just make this a Java class called comment count, there's a key for users, but the downside is that suddenly we are, sort of, making our writes more expensive. However we don't have to have this thing we can just have a list of comment objects, that are essentially being added each time we persist a comment object their being added to the table or whatever it is that you're storing these things in. But when you need another comment, count you have to go and actually scan through all the data like we were with the map, and get that count back. So, before you begin doing anything, and you want to look at a particular, query, you need to understand, how often am I going to be writing? How often am I going to be reading? Is it more important that my writes be fast or more important that my reads be fast? And that's what you're going to need to know in order to begin to make reasoned decisions about how you should structure your classes that are annotated with entity and store, or how you're, structuring your classes that are annotated with whatever you're going to use to math them into the underlying NoSQL data store. If you're going to be writing a whole lot. People are going to be writing lots of comments and you want to make comment writing really fast, then you'll probably go for something like this. If, however, every time that you load this page there's thousands of comments, and getting the number of comments for, for each user is incredibly slow and is the bottleneck, then you're going to want to do something like this. And so until you know, what is the, the, what is it you're trying to optimize for? Are you trying to optimize for writes or are you trying to optimize for reads? You really can't go forward with figuring out how to structure your data to make it easy to access.
