3 ms·

This still doesn't prevent you from having a bunch of lookup tables if ever want to query your dynamo db data on anything but the primary key =( I wish it was

This still doesn't prevent you from having a bunch of lookup tables if ever want to query your dynamo db data on anything but the primary key =( I wish it was more like the Google App Engine datastore where you could have indexes on any column and then fetch objects based on that.

tom_b 14y ago
This exact issue continues to confuse me. I don't want to be in the business of maintaining some weird, non-intuitive structure to simplify my queries. I've pondered just concatenating (or hashing a concatenation) of fields (a compound primary key) to use as a primary key on DynamoDB tables. Makes me nuts - this turns into analysis paralysis for me with DynamoDB . . .
- socialist_coder 14y ago
  Yeah, it's kind of bogus. While I would say, "just go nuts with your lookup tables", you have to manage your quota for those additional lookup tables, so then instead of just figuring out how much quota to buy for 1 table you now have to do it for 1+X tables. And since you never want to run out of quota you end up paying for a lot more quota than you are using. Luckily in my app I only have 1 lookup I ever want to do (find your account based on your social network id, so you can restore your account after reinstalling the app + connecting to facebook), so just maintaining this single lookup table is not that bad. If you really need to query on a bunch of other fields then maybe you should maintain a single table in RDS (MySql) and just use it for looking up the DynamoDb primary key. I think that is what I would do.
bkirkbri 14y ago
I wouldn't be surprised if they roll out hash-key-less lookup at some point. This announcement shows they realize that the inclusion of a feature which _could_ be built on the initial primitives can reduce barriers to adoption. IMHO the challenge is to communicate the increased cost when making use of these enhanced features. One of the amazing things about DynamoDB is that AWS have learned the pain points of DBaaS from SimpleDB and structured the features and pricing of DDB to be more "true" to the limitations of distributed datastores. So, while they can likely introduce hash-key-less lookup, they have to balance the increased adoption with the downside of unhappy/confused customers that expected it to be free. As it stands now, customers need to build that capability themselves, which is instructive in terms of the costs to implement it.
- socialist_coder 14y ago
  100% agree. I'm really looking forward to it. They have a great service so far and it seems like they are improving it all the time.

tom_b 14y ago

This exact issue continues to confuse me. I don't want to be in the business of maintaining some weird, non-intuitive structure to simplify my queries. I've pondered just concatenating (or hashing a concatenation) of fields (a compound primary key) to use as a primary key on DynamoDB tables. Makes me nuts - this turns into analysis paralysis for me with DynamoDB . . .

socialist_coder 14y ago
Yeah, it's kind of bogus. While I would say, "just go nuts with your lookup tables", you have to manage your quota for those additional lookup tables, so then instead of just figuring out how much quota to buy for 1 table you now have to do it for 1+X tables. And since you never want to run out of quota you end up paying for a lot more quota than you are using. Luckily in my app I only have 1 lookup I ever want to do (find your account based on your social network id, so you can restore your account after reinstalling the app + connecting to facebook), so just maintaining this single lookup table is not that bad. If you really need to query on a bunch of other fields then maybe you should maintain a single table in RDS (MySql) and just use it for looking up the DynamoDb primary key. I think that is what I would do.

bkirkbri 14y ago

I wouldn't be surprised if they roll out hash-key-less lookup at some point. This announcement shows they realize that the inclusion of a feature which _could_ be built on the initial primitives can reduce barriers to adoption. IMHO the challenge is to communicate the increased cost when making use of these enhanced features. One of the amazing things about DynamoDB is that AWS have learned the pain points of DBaaS from SimpleDB and structured the features and pricing of DDB to be more "true" to the limitations of distributed datastores. So, while they can likely introduce hash-key-less lookup, they have to balance the increased adoption with the downside of unhappy/confused customers that expected it to be free. As it stands now, customers need to build that capability themselves, which is instructive in terms of the costs to implement it.

socialist_coder 14y ago
100% agree. I'm really looking forward to it. They have a great service so far and it seems like they are improving it all the time.