今天的帖子，由FullScale 180 首席Trent Swanson撰写介绍该公司如何使用 Windows ">Azure 和数据库分区，为其客户构建可扩展的解决方案。
Full Scale 180是雷德蒙德，一家华盛顿的专门从事云计算解决方案、 提供从专业体系结构咨询到解决方案交付等专业服务的咨询公司。Full Scale 180团队是因为解决看似不可能解决的问题提供Windows Azure上的创新的云计算解决方案而树立名声的。Full Scale 180与跨越广泛的行业的客户工作，虽然每个项目都非常独特，但这些解决方案常有很多共同的考虑和要求。
尽管对于客户有各种不同项目， 设计、实施，公司面临一些非常有趣的挑战，但我们也在 Windows Azure上部署一些非常酷的解决方案。我们经常遭遇的挑战是数据库缩放。
就充分使用数据存储而言，需要集中考虑两点：
数据的存储位置 存取数据的最佳方式
在软件开发领域中，复杂性和高抽象度的层是非常有趣的一个东西。使用一种手段（这个词代表许多不同的概念，在这里如 API、库、 编程范式、 类库，框架） 来做一些事情，到最终得到一个平衡状态，要么你想出更高级别的抽象构造，要么使用一种来自别人，通常被称为生成/获取的决定。像别的不说，数据存储是按照一样的模式。当处理关系存储，如SQL Azure 时, 您需要按系统设置的规则操作。
数据存储位置
当使用 SQL Azure，数据存储的物理组件不再是你的担忧，所以你不必担心数据文件、 文件组和磁盘已满的状况。你要考虑是服务本身的资源限制。目前 SQL Azure 提供个人数据库为 150 GB。
随着时间推移，普遍预期应用程序的数据库的消费是不断增长的。与非云端数据库不同，您可以控制的唯一维度是附加从 Windows Azure 采购的来的数据库空间。对此有两种方法： 要么计划扩张并提前采购新空间 （这可能破坏运行在云上的目的）要么基于策略自动扩展需求。如果选择后者，我们就需要找到跨数据库的数据分区的方法。
优化数据传输和分片
抛开空间的管理，我们需要确保传入数据和数据存储是快速的。对非云端系统，可以通过优化网络和磁盘的速度。但在云平台上，这通常是不能优化的，所以需要一种不同的方法。通常，这将转化为并行数据访问。
数据存储需求将会增加，但我们需要的是在平台设置的规则里使用最大的数据库。同样地，对于这些规模和吞吐量的限制，我们必须学会设计解决方案。无论是否连接到数据存储，数据存储的物理存储吞吐量，或对数据存储大小的限制，扩展超越这些单位限制往往是需要设计解决方案。如果我们可以采用一种机制，利用一个个小的数据库集合来存储我们的数据，在这里我们可能会并行访问这些较小的数据库，我们就可以优化我们的数据存储解决方案的规模和速度。这里的机制应采取自动数据分区和数据库采购。一个通用的解决办法是分片。使用分片，不论已使用什么方法，数据管理和数据访问将发生变化。 SQL Azure协会为SQL Azure提供了一个出箱分片实施方案。
在我们与一些客户接触时，我们发现SQL Azure的联合将是一个解决方案。除了简单扩大超出150GB单一的数据库大小的限制，我们已经找到了在联合多租户云解决方案是有效的。