数据结构化问题
首先要提到的是两者存储数据属性上的区别，虽然两者都是以key/value形式进行存储，但Dynamo偏向存储原数据，因为其所存储的数据是非结构化数据，对value的解析完全是用户程序的事情，Dynamo系统不识别任何结构数据，都统一按照binary数据对待；而Bigtable存储的是结构化或半结构化数据（web数据特点就是介于结构化和非结构化之间，因此称为半结构化数据。我这里不展开说它了，不了解半结构化数据的赶紧去google一下吧！），其value是有结构的数据——就如关系数据库中的列一般，因而可支持一定程度的Query(比如可按单列进行）。这点上看Bigtable更接近数据库（接近而不是等价！至于和关系数据库的具体区别可去google 一下，网上论述可不少！）；另外, Bigtable所存储的数据都是以字符串格式实现，所以对主建或者列（以及其自动加上的时间戳）排序都是以字符序进行，而dynamo的键值并非以字符串存储，而是统一经过md5算法转后成16字节md5_key存储的，因此对数据的访问必须知道key才可进行，故而对扫表(用游标）或者query访问则无能为力。当然在dynamo的基础上，配合一些方式我们实现query也并不可能，一些具体方式我们后面慢慢探讨！
控制与存储架构比较
Dynamo是采用DHT（分布哈希表，请参看有关资料吧）作为基本存储架构和理念，这个架构最大特点是能让数据在环中“存储”均匀，各存储点相互能感知（因数据需要在环内转发，以及相互之间进行故障探测，因此需要节点之间的通讯），自我管理性强，因为它不需要Master主控点控制，有点是无热点，无单点故障危险——插一句，目前新浪的memcachedb(改造memcached，增加了持续化能力）其实可认为是这种架构的最简单代表（数据进入系统后，使用DHT算法均匀的发送到存储节点上，而最后存储引擎采用Berkelery DB，将数据持续化到本地硬盘）。
Bigtable的控制是采用传统的server farm形式，使用一个主控服务器＋多个子表服务器构成。而数据存储形式是采用多维Map的稀疏结构,可看成是由多个列表组成，所谓稀疏是说每条记录并非要求有全列。其数据（包括索引，日志，记录数据）最终是存储在分布文件系统DFS之上——数据被以DFS所特有的文件形式分布存储在各各节点之上。相比DHT的存储环自管理技术，它需要有master主控服务器来负责监控各客户存储节点（分配子表，失效检测，负载均衡等），另外索引文件的根也是集中存储，需要客户端首先读取（之后可以采用预读和缓存的技术减少读取索引表的次数）。这种集中控制的做法有一个缺陷就是系统存在单点故障 —— 因此单点需要高可用性，如记录恢复日志或双机备份等——但好处是更人为可控，方便维护，且集中管理时数据同步易于方便——显然，更新集中存储的原数据（如数据索引或节点路由等）相比DHT环中各个节点存储的原数据（如membership，即各点的路由关系）需要利用“闲谈机制”依次通知式地进行渐近更新要容易许多。
负载均衡问题
负载均衡（意义在于数据存储均衡和访问压力均衡）对于Dynamo系统而言是天生的优势，因为它采用了DHT方式将数据都均匀存储到各个点了，所以没有热点在（或者说要热，则环中所有的点一起热），各点的数据存储量和访问压力应该都是均衡的（这点由md5算法特性决定）。 另外这里还要提一下Dynamo系统中的Virtual Node概念——VNODE 可看成一个资源容器（类似于虚拟机），存储作为一个服务运行于其中。引入VNODE 目的在于将资源管理粒度单元化。 比如一个VNODE 让你且只让你管理5G硬盘，500M内存等，那么你就只能使用这么多资源。这样有两个显而易见的好处：1 方便管理不同配置的异构机器，比如资源多的机器多部署一些VNODE ,而资源少的机器少不部署一些VNODE 。 2 对于扩容大有好处，因为DHT环中加入一个新节点，如果想保持数据均匀分布的特性，那么必须将全环的数据都要移动才有可能，这样无疑增加了网络震荡，因此最理想的方式是在环内每个点都进行扩容，这样就只需要移动旁边节点的数据了。那么单增加一个或几个机器显然不能均匀分配环的其他存储点旁，因此需要将一台物理机器划分成众多个VNODE ，这样才有可能能将这些VNODE 比较均匀的散布在环内其他节点旁了。随着逐步添加机器，那么数据均匀性逐步提高，可见这是一种逐渐式的数据均衡过程。
对于Bigtable的负载均衡是也是基于传统上server farm ：依靠一个master服务器监视子表 server的负载情况，根据所有子表服务器的负载情况进行数据迁移的，比如将访问很热的列表迁移到压力轻的子表服务器上(数据最终还是落在了chunk server —— DFS上的存储服务点，从层级结构上来说处于子表服务器之下）。具体做法你可参见他们的论文，总的来说有没有太多创新。