How to implement Composite Sort Keys

Question

Best Practices for Using Sort Keys to Organize Data  
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-sort-keys.html  
presents the following example structure for a sort key:  
$$country$$#$$region$$#$$state$$#$$country$$#$$city$$#$$neighborhood$$  
  
I have searched for any information or example on how to implement Composite Sort Keys and have found nothing useful.  
  
in Secondary Indexes (local or global):  
- How does one define a composite sort key?  
- How are these composite sort keys updated when one or more of the included attributes is modified?  
  
One obvious solution would be to create a new string attribute that contains the concatenated attribute values, and then reference this "calculated" attribute as the SK attribute. The application layer would then be responsible for updating the calculated attribute each time any one of the attributes included in the concatenation was updated. This seems the kind of thing the database should do automatically (like function indexes in some relational database do). Also, another  downside of this approach is the duplication of the attribute values and resulting waste of storage space (or at least the extra cost of such storage).  
  
Is there a better solution?

Padma_aws · Answer

Yes, you should concatenate the data in your application to create the composite sort key. The primary key should be selected based on your access patterns so that you retrieve the required result set as efficiently as possible by avoiding unnecessary round trips to the database. This means that you will duplicate (and de-normalize) some of the data to gain the efficiencies in speed and performance. The datamodel you pick depends entirely on your application access patterns and business requirements. This NoSQL best practice is documented here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html#bp-general-nosql-design-concepts  
That said, there are a few ways to lower your storage costs although the effort is greater than the benefit. I would encourage you to weigh the overall application requirements before finalizing your approach. For example, you can store the concatenated data values in the sort key only and not store them as individual attributes. The tradeoff would be to parse the sort key in your application if you require it. Also, you can store abbreviations for the data values. For example, you may have a “status” attribute with values \[Success, Failure, In Progress]. You can represent this data set as \[S,F,I] and use a config file to match the values on the fly using your application.

mojimi · Answer

The application layer manages it, that's often the case with NoSQL and DynamoDB specially.  
  
The point of DynamoDB is to use extra storage space but gaining speed, because storage is cheaper than processing power.

How to implement Composite Sort Keys

Relevant content