我们可以通过Dryad和Dynamo进行分布式云平台来解决云存储扩容困难问题。如果这3台服务器也承载不了更大的数据要求时，需要增加到5台服务器，那必须更改分类方法把用户分成5类，然后重新迁移已经存在的数据，这时候就需要非常大的迁移工作，这种方法显然不可取。另外，当群集服务器进行分布式计算运行的时候，每个资源节点处理能力可能有所不同(例如不同硬件配置的服务器等等)，如果只是简单的把机器直接分布上去，性能高的机器得不到充分利用，性能低的机器处理不过来。

图3 通过Dryad DAG排列的节点(程序)扩展性能

　　? P parses lines(解析线)

　　? D hash distribute(哈希分布)

　　? S quicksort(快速排序)

　　? C count occurrences(事件计算)

　　? MS merge sort(合并分类)

　　? M non-deterministic merge(未确定合并)

　　Dryad和Dynamo解决此问题的方法是采用虚节点。把上面的A B C三类等用户都想象成一个逻辑上的节点。一台真实的物理节点可能会包含一个或者几个虚节点(逻辑节点)，看机器的性能而定。我们可以把那任务程序分成Q等份(每一个等份就是一个虚节点)，这个Q要远大于我们的资源数。现在假设我们有S个资源，那么每个资源就承担Q/S个等份。 当一个资源节点离开系统的时候，它所负责的等份要重新均分到其他资源节点上，一个新节点加入的时候，要从其他的节点“偷取”到一定数额的等份。

　　在这个策略建模算法下，当一个节点离开系统的时候，虽然需要影响到很多节点，但是迁移的数据总量只是离开那个节点的数据量。同样，一个新节点的加入，迁移的数据总量也只是一个新节点的数据量。之所以有这个效果是因为Q的存在，使得增加和减少机器的时候不需要对已有的数据做重新哈希(D)。这个策略的要求是Q>>S(存储备份上，假设每个数据存储N个备份则要满足Q>>S*N)。如果业务快速发展，使得不断的增加主机，从而导致Q不再满足Q>>S，那么这个策略将重新变化。

　　通过上述的论述，我们可以看到Dryad通过一个有向无环图的策略建模算法，提供给用户一个比较清晰的编程框架。在这个编程框架下，用户需要将自己的应用程序表达为有向无环图的形式，节点程序则编写为串行程序的形式，而后用Dryad方法将程序组织起来。用户不需要考虑分布式系统中关于节点的选择，节点与通信的出错处理手段都简单明确，内建在Dryad框架内部，满足了分布式程序的可扩展性、可靠性和性能的要求。在云平台分布式算法上Dryad与Dynamo分布式存储引擎相似，并且有更好的创新。