

DynamoDB Local Secondary Indexes - jeffbarr
http://aws.typepad.com/aws/2013/04/local-secondary-indexes-for-amazon-dynamodb.html

======
socialist_coder
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.

~~~
bkirkbri
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
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.

------
tav
For any AWS folk on here, it'd be great to know how this fits with the
consistency guarantees. Can we do strongly consistent index queries?

Also, any chance we could have strongly consistent auto-expiring keys in
DynamoDB? Would make DynamoDB a very useful tool for synchronisation/lease
management and other funky uses.

I also sent Werner an email asking if it would be suitable to use DynamoDB as
a block device — you could then build a filesystem on top and benefit from
DynamoDB features like replication, consistency, etc. Unfortunately, I fear
the email must have slipped through his no-doubt-busy-inbox. If any of
DynamoDB developers could shed any light on its suitability as a block device,
that would be awesome! Thanks.

~~~
bkirkbri
> I also sent Werner an email asking if it would be suitable to use DynamoDB
> as a block device — you could then build a filesystem on top and benefit
> from DynamoDB features like replication, consistency, etc.

This. 100 times. A filesystem was my first thought when DDB was announced last
year. I can't imagine it would be harder to build than GridFS was. [1]

That said, I'm not talking about a FUSE-like filesystem. More like HDFS or
GridFS -- a blobstore+ if you will.

[1] <http://docs.mongodb.org/manual/core/gridfs/>

~~~
cpleppert
DynamoDB is optimized for storing relatively small records on redundant fast
SSDs. You would blow through all your read and write units instantly using it
as a BLOB store.

~~~
bkirkbri
Well, that depends on your BLOBs, how you use them and what it's worth to you,
doesn't it?

------
tom_b
The ability to "project some or all of the table's other attributes into a
secondary index" smells a bit like a materialized view in the description.

I am often thinking in a star-schema direction (too much time data
warehousing) rather than normalized designs. For DynamoDB, I stumble around
the primary key for such setups given that a rather large subset of the tuple
values in a star schema row (plus a timestamp) actually represent the primary
(compound) key for the metric measurement.

Probably need to re-think all that sometime.

------
Kartificial
Ah, nice feature addition. I recently started using DynamoDB and was wondering
why the range was restricted to only one field.

