[MUSIC] One of the nice things about the cloud is that it doesn't require you to do everything yourself from scratch. So, although we may want control over the database that we're using and we may want to set up a particular database and configure it a specific way, we don't have to do that necessarily. We can also essentially outsource the management, and scaling of our database to somebody else by using database as a service. Now there are lots of different databases of services that you can use, we're going to talk in particular on this lecture about Amazon's DynamoDB, which is a DB that's backed by solid state devices. And has a nice property that you can specifically ask and allocate the number of reads or writes per second that you would like your application to have and then Dynamo will charge you for that provision to capacity. So, this is a nice capability in that not only can we outsource our database. And, you know, not deal with how we set up and maintain, and manage it, and try to scale it. But we can also specifically buy them out of reader right capacity that we actually need for application, and be guaranteed that we can get it by contract from Amazon. So, what we're going to do now is, again, we're going to be using spring data, just like we did before. And we've seen how we can use spring data within memory, we can use it with H2, or HSQLDB, we can use it with Mongo. And now we're going to see how we can take this same abstraction. And we can use it to connect to Dynamo, where Amazon's database is a service, or their high performance key value score, if you want to think about it in terms of a key value score. So, very quickly we can go and again switch over to a new type of database. So let's look at this example in specific code, and what we need to in order to connect our application to DynamoDB. So, if you'll open up the video class and we're going to start by looking at this specific changes to the video class, because they're connected to the configuration changes that we have to make in Amazon. So if you open up, the video class underneath the org.magnum.mobilecloud.video.repository, package and open up this video class. What we'll see is we have the same video class that we had before, but we're starting to see a theme here. We've seen it throughout this course, we're just changing the annotations or the meta information. In order to support persisting or saving these objects in DynamoDB. So we're still doing the same thing we did before, we're mapping our objects into a database. So let's take a look at this very first annotation, and we're going to look at the work, the work we have to do on the Amazon side in order to support this annotation. So the first thing we're going to do is we're going to tell. Spring the data dynamo, the particular dynamo table that we want to store these objects in. So in this case, we're adding the @dynamo table annotation, and then we're specifying the table name is videos. So what this means is, if we go to our AWS console, is that we need to create a videos table. So, we'll go ahead and create the videos table. And then the next thing we're going to see, is that there's, it's asking us for the type of primary key. Now, Dynamo is a key value store, but it has this concept of a hash key and a range key. So the way to think of the hash key is the hash key is just purely the typical keys that we've seen before. So we've had a, a key mapped to a value, the way to think of the hash key is that if we want a key that's a combination of a key, where the key is something like, let's say we want to store all of the events for a particular conference, or we want to store all of the videos uploaded by a particular user. We can make the first part of the key the user, and then the range part of the key the particular ID of a video. So if we wanted to quickly go and scan through all of the videos that have been uploaded by a particular user, we could use the hash part of the key, which would be the user ID, to go and scan all of the unique keys that were created by that user ID plus an individual video ID. So. Really, what a hash and range key are, is they're a composite key, where the key part is something that's like a common prefix, almost like, the user ID that stored the video. And the range key is an extra bit of information that when combined with the user, there are, when combined with the hash key, creates an overall unique key. So there'll be, there could be potentially if your using a hash and a range key there could be potential multiple keys that have the same hash key. But they all would combine with their range key, the combination of the two will be unique. If you don't use a range key, then the hash key always have to, has to be unique, so if you use a hash key, just a hash key, it always has to be unique for each object that you're storing. If you use a hash and a range key, then the combination of them has to be unique, but the individual hash key may not be unique. So, this is kind of a nice capability of Amazon's DynamoDB, and it can be helpful in many situations. In this case, we're not going to use a hash and range key, we're just going to use a hash key. So if we go back and we look at our video class, we'll see this ID which looks suspiciously like an ID that we've been using to store our videos before although we're using a string rather than a long. And if we go down to the getter for the ID, what we'll see is it's annotated with @dynamoDHashKey. And then at that arrow DB autogenerating key. So basically what this is telling Spring Data Dynamo is that you should use this particular property, this ID property, as the unique hash key for the object. And you'll want it to be automatically generated by Spring data DynamoDB when it's saved into the database and assigned to this value. So if we go back to the setup of our table, what we need to do is choose a hash key, since we only have a hash key in this class and we need to set it to the ID property. So this, whatever we're putting into the hash attribute name needs to match up with what we're specifying as the DynamoDB hash key in our particular object. So, once we've done that and aligned that, we can continue on. Now we get to another interesting part of DynamoDB, and that's the ability to actually specify the read and write capacity, or number of reads per second that are 4 kilobytes, or writes per second that are 4 kilobyte. That we like to have Amazon support for us. So, this is a nice capabilities that we don't have to worry about how we scale our database up to that particular quality of service. We can just ask Amazon for it and pay for it. We're going to go ahead in this case just use a simple example of one read per second, and we're going to click through and finish completing this table, which will now show up in Amazon. When we go back, we have now created, our Dynamo table, for the videos, and the other thing we've done is we've annotated the particular get method that has the ID that we care about with the appropriate DynamoDB hash key and auto generated key annotations that we need to tell Dynamo, that's what we want to use as the unique ID of the object. And we want it to be automatically generated by Dynamo. Then we also have the app DynamoDB attributes that are then placed on each of the different member variables, the getters for those member variables that we would like to persist into Dynamo. So one thing to note is if you have other methods. That are simple get named methods, like get foo, and foo is some property that you calculate but isn't necessarily a member variable. If you add @dynamoDB attribute to it, dynamo will try to store that. So you want to make sure that if you add @dynamoDB attribute to a particular getter, that it's actually a member variable in something that you can persist and set. But that's the main work, just like we did before with Mongo DB and when we did with Data JPA. We had to go and add annotations to our video class to explain how to map it into the database. We've done the same thing with that half DynamoDB annotations. We can now go and take a look at the video repository. And one of the nice things that we'll see in this particular case, is we don't have to make any changes to our video repository. It's still extending the cred repository that we extended before. And just like with Mongo DB, we're not making any changes to the underlying find methods, we still can support the custom queries, like find by name. All of these things are still working just like they were before, so, we're, we're getting this benefit of having spring data as an abstraction layer between our app. And our custom code and all the different databases that needs spring data that we might want to go and use. So just by plugging in the right annotations, we can swap out the database underneath because of this nice abstraction layer. And with some simple annotations with our objects we can change. Repository implementation creators, so just like with the other examples where we used spring data, we're not actually creating the implementation of the repository ourselves, we're just providing the interface for it that we want to be created based on the underlying database that we're connecting to. So, this is another example where this abstraction spring data separates us with just a little bit of annotation changes we can get to a new database. And there will be cases where it's helpful to know and look at a particular database's format and how it does things like the hash and range keys in DynamoDB or the ability to provision through put in DynamoDB. Or a more understanding more about Mongo's documented oriented data store. But we can still very quickly move between these databases, and then figure out what other things that we need to know about that particular database, and will they affect our application at all. And in many cases they won't, and we won't have to worry about them, we just can swap out underneath Spring Data if we focus on key value is a sort of abstraction that we're using
