To me it sounds more like the issue is selecting the Keys. GSI / LSI help you avoid needing to create additional DynamoDB tables for the sole purpose of improving data access. The issue here is that you still need to 'know' the Partition Key for your secondary data structure. I have found that I have way more success with DynamoDB if I think about the queries I want to make first, and then go from there. I think the real question you are asking is what should my sort keys and partition keys be? That will depend on exactly which queries you want to make and how frequently each type of query is used. WHERE User='Bob' AND Emails LIKE YOU MUST know the partition key in order to perform a Query no matter what you choose as your Sort Key and no matter how that Sort Key is constructed. In other words a data object could use a Sort Key like you could query that (assuming you knew what the partition key is) with something like this:
I also used several attributes that were not dates but were integers with a fixed character length.īy using the BETWEEN comparison I am able to individually query each of the variables that are concatenated into the Sort Key, or construct a complex query that matches against all of them as a group.
#Local dynamodb rebuild indices iso
I used this concept to create a composite Sort Key that consisted of multiple ISO 8061 date objects (DyanmoDB stores dates as ISO 8061 in String type attributes).
What you CAN sometimes do is concatenate several variables (or an Array) into a single string with a known seperator (maybe '_' for example), and then use that string as a Sort Key. Stu's answer has some great information in it and he is right, you can't use an Array it's self as a key.
0 kommentar(er)
