1.一致性hash 算法做的数据分布，partition key （PK）+ sort key，当然这里还有虚拟节点的加入。即使分区键共享一个前导前缀，或者顺序增加——它们也会随机分布在底层虚拟分区上。
2.GSI，这里还有一个全局二级索引概念，相当于是数据的另外一种组织方式。可以有不同的pk和sort key，和基表之前做异步同步.只有写入基表并且匹配主键索引的item才会被写入GSI。 如果非GCI映射的列改变是不会有写入并且GCI也不会消耗WCU的。所以GCI消耗的WCU在有些情况写会比基表的少。
其他GSI行为：
1/ 另一方面，GSI可以消耗容量超过基表的写入容量。
2/ 如果你选择GSI的主键不同于基表，修改基表的item的attribute会消耗一个write，如果改变的attribute是GSI主键的一部分，还会涉及到删除index item然后再创建一个新的主键值。
3/ 一个基表的单个更新可能会导致GSI的两次写，写放大（amplification）。
4/ 一个基表的GSI最多20个。
3.数据的多版本控制使用vector clock 时钟向量，可能会出现多版本返回，可以由用户决定使用哪一个版本，也可以使用时间戳决定。
4.数据存储分区为3个副本，一个leader 使用Paxos算法实现节点间消息和数据同步， 两个节点确认写入，客户端即可收到200返回，第三个节点同步时间为millsecond内。 leader的选举也是Paxos进行管理的，使用Paxos算法中的heartbeat协议进行主节点的指定。每1.5s进行节点间通信，如果主节点的心跳没有收到的话，另两个节点会进行选主，其中有最近的版本的节点将会被选为新主。
5.数据读取分为最终一致性读（any of three node）和强一致性（leader node）读，写入只能写leader 节点。当一个item确认被写入，它将会存在于3个节点中的2个上，当进行强一致性读的时候，读将会发生在leader节点上，这也可以保证最新版本的数据会被返回。当最终一致性读要求发出时，read请求将会被随机的发送到3个节点中的任意一个节点。因为写入时候的第三个节点会很快很快的被同步，所以读到旧版本的概率是很小的，EC/SC可以在每一次读请求的时候配置，EC消耗50%的RCU。 那么第三个节点的延迟会有多久呢？这个看情况，比如重启之后会有一个延迟出现，或者在存储节点自动失败退出然后被替换，或者一个短暂的网络抖动，种种原因我们不能做出任何保证，这也是最终一致性的自然特性，正常情况下，一般是会有几毫秒的延迟。
5.主要分两部分，一个前端路由处理，一个后端存储 DDB服务由很多自动化的服务组成，主要分两个层级： 前端: 请求路由，它们是无状态的，将传入的 HTTPS 请求路由到存储层中的相应节点。 后端: 存储节点，无状态的存储item。（items会被复制三份）。
6.CAP CAP理论一般只能完全满足2个，DDB实现的是CP，这意味着它在发生中断时无法提供完美的可用性。 DynamoDB会实现最终一致性读已实现比读更改的可用性但是最终一致性读可能会返回一个就版本，在最终一致读取的情况下，为了获得更高的可用性而牺牲了一致性，因此可以说 DynamoDB 有时是 AP。
