json - Best DynamoDB Structure for Implementation -

json - Best DynamoDB Structure for Implementation -

i working on save application, user go article , click save store in profile. instead of using relational database application using dynamodb. each article has specific type of article. way construction used application is:

user-id [string][dynamodbhashkey] type-of-article [string] [dynamodbrangekey] json [string]

user-id unique identifier user, type-of-article well.. type of article, , json articles saved in json format. json format being:

[{article-id: timestamp}, {article-id: timestamp}] article #1 ^ article #2 ^

article-id (again) article unique identifier , timestamp timestamp when article stored .

note done before dynamodb started supporting json documents map , lists. , code not mine.. done..

so when application needs remove article saved calls dynamo json modify json , stores again. when going add together new article same thing. problem appeared when wanted display articles ordered timestamps. had phone call types , merge them in dictionary sort them. (in user profile need show saved articles, no matter type, sorted) application taking more 700 or 900 ms respond.

personally don't think best way approach this. i'm thinking on rewriting previous code implement new features dynamodb (list , maps). thought construction in dynamodb this:

user-id [string] [dynamodbhashkey] saved-articles [list] article-type_1 article_1 [map] {id: article-id, timestamp: date} article_2 [map] {id: article-id, timestamp: date} article-type_2 article_1 [map] {id: article-id, timestamp: date}

but i'm relatively new dynamodb, made test code store in dynamo using list , maps. did using low level api , object persistence model.

now, question is: improve approach or if not why ? , improve approach.

this way think can utilize low level api saved-articles of article-type #2. or if need them phone call all.

i stick solution bit more nosql-like. nosql databases, if have nested info models and/or updating existing records, indicators info model can optimized. see 2 objects application using, 'users' , 'articles'. avoid nested info model , updating existing records doing following:

'user' table

user id hash key

'article' table

article id hash key timestamp range key user id (used in global secondary index described below) article type , other attributes non-key attributes

you'd have global secondary index on article table allow search articles user id, (assuming want user's articles sorted date):

user id hash key timestamp range key article id projected attribute

with model, never need go , edit existing records, add together records 'edited' new records, , take 1 recent timestamp current version.

one thing remember nosql storage space cheap, reads cheap, editing existing records expensive , undesirable operations.

json amazon-web-services amazon-dynamodb