paper amazon dynamo
http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
* ACID vs CAP.
* 需求与假设
-- 以key-value方式查询，数据之间没有关联。在amazon的服务中，value相对较小（小于1MB）
-- ACID：保证一致性（consistency）会降低可用性，因此应用程序应该是有较弱的一致性要求。同时，不保证任何的隔离性（Isolation），系统只根据key更新数据
-- 效率：应用程序应该能够在响应时间与性能之间权衡（？？）
-- 系统仅供amazon内部使用，不涉及安全与认证
* 服务的性能指标（Service Level Agreements, SLAs）
* 设计考虑
-- 数据的可用性。当服务器与网络经常fail时，可通过数据复制来保证可用性，那么就带来数据一致性问题。当数据不一致（冲突）时，a)何时同步数据（resolve conflict）？b)谁来同步数据？
-- 何时同步数据？在write时还是在read时？传统的做法是在write时，这使得read很简单。在write时同步数据会导致write常常失败，这在amazon的服务中会降低用户体验，是不可接受的，因此要保证总是能写成功。那么就要在read阶段来同步数据。
-- 谁来同步数据？如果是Dynamo来做，那么它的做法仅仅是有线的几种，比如以最后一个写入的数据为准，这对应用程序来说显然也是不可接受的。而应用程序是“知道”数据的含义的，因此应用程序来处理数据同步更合适。
-- 可扩展性，增加服务器应该很容易。
-- 对称性，每个服务器都是对等的，没有特殊角色。会降低维护成本。
-- 去中心化，对称性的另一个具体措施。
-- 异质性，系统可以运行在不同硬件的服务器上。
* 其它相关工作
-- 有的系统使用了强一致性的设计，这使得应用程序接口比较简单，但是强一致性不能处理网络隔离（network partition）的情况。
* Dynamo与其它去中心化存储系统的不同
-- 总是可写，
-- 内部使用，系统和应用总是可信的，
-- 不需要分层的名字空间和复杂的关系数据模型，
-- 对读写响应时间要求高，为达到此要求，Dynamo的每个节点都能直接把读写请求路由（route）到其它节点。Dynamo使用的是一种zero-hop的DHT（distributed hash table）
syntactic reconciliation, semantic reconciliation
跨数据中心的数据复制。
使用Merkle trees检查数据的一致性。优点：减少数据传输。树的构造？
4.9 当新加入一个node时，其它node上的部分key/value会转移到这个新的node上来，以平衡数据的分布。当一个node从集群中删除时，会执行一个相反的过程。
* 实现
-- 用Java实现。
-- 分成三部分：请求处理，成员管理与错误检测，本地持久存储。
-- 存储部分的实现是插件化的，目前的实现有几种：BDB，Java班BDB，MySQL，内存缓冲区（包括一个持久存储的后端）。BDB用的最多。
-- read有个readrepair机制，用于修复陈旧的数据
* 实际系统的运行情况
-- Dynamo之上对数据的同步（reconciliation）主要有三种类型：
# 业务逻辑型，由应用来纠错
# 时间戳类型，根据数据更新的时间戳来纠错，即最后一个写入的生效
# 高性能读的类型，数据很少更新，主要是读，而且对读性能要求比较高
-- 关于N, R, W的配置，大多是（3, 2, 2）
------------------------------------------------------
数据一致性在read阶段保证，会不会增加read的响应时间？
它的hash算法
每个node所维护的ring是否相同？是否最终相同？
preference list
数据应该是存放在磁盘上，是mmap到内存中还是读到内存中？
* ACID vs CAP.
* 需求与假设
-- 以key-value方式查询，数据之间没有关联。在amazon的服务中，value相对较小（小于1MB）
-- ACID：保证一致性（consistency）会降低可用性，因此应用程序应该是有较弱的一致性要求。同时，不保证任何的隔离性（Isolation），系统只根据key更新数据
-- 效率：应用程序应该能够在响应时间与性能之间权衡（？？）
-- 系统仅供amazon内部使用，不涉及安全与认证
* 服务的性能指标（Service Level Agreements, SLAs）
* 设计考虑
-- 数据的可用性。当服务器与网络经常fail时，可通过数据复制来保证可用性，那么就带来数据一致性问题。当数据不一致（冲突）时，a)何时同步数据（resolve conflict）？b)谁来同步数据？
-- 何时同步数据？在write时还是在read时？传统的做法是在write时，这使得read很简单。在write时同步数据会导致write常常失败，这在amazon的服务中会降低用户体验，是不可接受的，因此要保证总是能写成功。那么就要在read阶段来同步数据。
-- 谁来同步数据？如果是Dynamo来做，那么它的做法仅仅是有线的几种，比如以最后一个写入的数据为准，这对应用程序来说显然也是不可接受的。而应用程序是“知道”数据的含义的，因此应用程序来处理数据同步更合适。
-- 可扩展性，增加服务器应该很容易。
-- 对称性，每个服务器都是对等的，没有特殊角色。会降低维护成本。
-- 去中心化，对称性的另一个具体措施。
-- 异质性，系统可以运行在不同硬件的服务器上。
* 其它相关工作
-- 有的系统使用了强一致性的设计，这使得应用程序接口比较简单，但是强一致性不能处理网络隔离（network partition）的情况。
* Dynamo与其它去中心化存储系统的不同
-- 总是可写，
-- 内部使用，系统和应用总是可信的，
-- 不需要分层的名字空间和复杂的关系数据模型，
-- 对读写响应时间要求高，为达到此要求，Dynamo的每个节点都能直接把读写请求路由（route）到其它节点。Dynamo使用的是一种zero-hop的DHT（distributed hash table）
syntactic reconciliation, semantic reconciliation
跨数据中心的数据复制。
使用Merkle trees检查数据的一致性。优点：减少数据传输。树的构造？
4.9 当新加入一个node时，其它node上的部分key/value会转移到这个新的node上来，以平衡数据的分布。当一个node从集群中删除时，会执行一个相反的过程。
* 实现
-- 用Java实现。
-- 分成三部分：请求处理，成员管理与错误检测，本地持久存储。
-- 存储部分的实现是插件化的，目前的实现有几种：BDB，Java班BDB，MySQL，内存缓冲区（包括一个持久存储的后端）。BDB用的最多。
-- read有个readrepair机制，用于修复陈旧的数据
* 实际系统的运行情况
-- Dynamo之上对数据的同步（reconciliation）主要有三种类型：
# 业务逻辑型，由应用来纠错
# 时间戳类型，根据数据更新的时间戳来纠错，即最后一个写入的生效
# 高性能读的类型，数据很少更新，主要是读，而且对读性能要求比较高
-- 关于N, R, W的配置，大多是（3, 2, 2）
------------------------------------------------------
数据一致性在read阶段保证，会不会增加read的响应时间？
它的hash算法
每个node所维护的ring是否相同？是否最终相同？
preference list
数据应该是存放在磁盘上，是mmap到内存中还是读到内存中？
还没人转发这篇日记
