自己现在在做的项目，我个人一直觉得并不适合dynamodb，不过老大强烈要求，那就只能做了。
homework-answer-reply的结构，另外加上teacher和student，我觉得是很明确的关系型数据。
看过一些文章，说nosql是not only sql。不过我现在还是新手，对我来说，至少dynamodb的优势只是查询速度快，但是对于原本很需要交叉查询的数据结构是非常不友好的。
另外我非常忧虑的一点就是一些原子操作，和数据回滚的问题。dynamodb虽然有batchWriteItem的方法，但是根据文档表述，是有可能失败的。这种失败不是报错，是有几条做成功，有几条没有做成功。其实我开发到现在还没有遇到这种情况，UnprocessedKeys、UnprocessedItems的值一般都是空的，所以到目前为止也没有处理（因为一直在赶着功能的进度，前端小哥还催我快点写……）。不过如果真的有问题我还真的不知道怎么办才好。
之前一直用rails+mysql，只要在begin rescue end当中加了ActiveRecord::Base.transaction do 就很容易回滚数据，不过如果dynamodb中遇到发生错误，已经提交的数据怎么做回滚也是一个很麻烦的事情。
另外，因为前端页面的列表中有很多数据统计的地方，比如在作业列表中显示有几条答案，几条已经批改，几条尚未批改等等，逐条请求查询也是不现实的，所以在homework表就直接做了几个统计的column。但是这样一来，等于提交答案，和批改答案的时候都需要修改这几个column，万幸dynamodb支持 count = count + 1，这种更新数据的方式，但是我还是很担心会失败，一旦失败那么统计数据就乱了（哇，我觉得我可能太过悲观了）
最近做到查字典的模块，调用的是有道的接口。不过后来和老大合计了一下，决定在dynamodb上做一个表进行缓存。因为比起有道的接口一次只能查询一个单词，缓存到自己是数据库里可以批量查询，减少http请求的次数。而且中学之前的词汇量比较少，又只缓存基本释义，所以量不会很大。（目前设置为如果dyanmodb上没有的数据，查询一下有道的接口在缓存下来）
做字典这种，我觉得才是dynamodb+S3的正确打开方式。语音文件可以专门建一个bucket来存放，uk和us分开。因为dynamodb支持数组column，所以有多个基本释义可以直接存成数组，也相当方便。
=
关于dynamodb，在网上找到的各种sample里，一般都多见以下两种例子：
1、动物
以动物的大品种做hash key，以具体品种做range key。
比如 { hash：猫，range：波斯猫 }，差不多这样结构的数据。
对于动物来说，这个结构基本上就可以保证了key的唯一性，如果强行说一定有两个同科的品种同名，也可以通过分别添加后缀来区别。
2、音乐专辑
以音乐家做hash key，以歌曲名称做range key。
比如{ hash：人名，range：歌名 }，也基本上保证唯一。
如果遇到同一首歌曲的不同版本，比如现场演唱版，变奏版，等等，也可以通过添加后缀来区别。
