Azure DocumentDB 提供垂直和水平缩放群集的功能。 虽然计算群集层和存储磁盘在功能上相互依赖，但计算和存储的可伸缩性和成本是分离的。
纵向扩展
垂直缩放具有以下优势：
- 应用程序团队可能并不总是有一个明确的路径来逻辑分片其数据。 此外，每个集合都定义了逻辑分片。 在包含多个未分片集合的数据集中，将数据建模分区可以快速变得繁琐。 只需纵向扩展群集即可规避逻辑分片的需求，同时满足应用程序不断增长的存储和计算需求。
- 垂直缩放不需要数据重新均衡。 物理分片的数量保持不变，并且只会增加群集的容量，而不会影响应用程序。
- 扩展和缩减规模是零停机操作，不会中断服务。 不需要任何应用程序更改，稳定状态操作可以继续不受干扰。
- 计算资源也可以在活动较低的已知时段内缩减。 同样，缩减规模可以避免在更少的实际分片之间重新平衡数据，并且是零停机操作，不会中断服务。 缩小群集后，这里也不需要更改应用程序。
- 最重要的是，计算和存储可以独立扩展。 如果需要更多核心和内存，则可以按原样保留磁盘大小，并且可以纵向扩展群集层。 同样，如果需要更多存储和 IOPS，则可以按原样保留群集层，并且可以独立扩展存储大小。 如果需要，可以单独缩放计算和存储，以便单独针对每个组件的要求进行优化，而没有任何一个组件的弹性要求会影响另一个组件。
水平缩放
最终，应用程序发展到仅靠垂直扩展已不足的程度。 工作负荷需求可能超出最大群集层的容量，最终需要更多分片。 Azure DocumentDB 中的水平缩放具有以下优势：
- 逻辑分片数据集不需要用户干预来平衡基础物理分片中的数据。 该服务会自动将逻辑分片映射到物理分片。 添加或删除节点时，数据会自动重新平衡数据库。
- 请求会自动路由到拥有所查询数据的哈希范围的相关物理分片。
- 异地分布式群集具有同质多节点配置。 因此，逻辑到物理分片映射在群集的主区域和副本区域之间是一致的。
计算和存储扩展
计算和内存资源 比磁盘 IOPS 更影响 Azure DocumentDB 中的读取操作。
- 读取操作首先查询计算层缓存，如果无法从缓存中检索数据，则回退到磁盘。 对于读取操作频率较高的工作负载，纵向扩展群集层以获取更多的 CPU 和内存资源，实现更高的吞吐量。
- 除此之外，对于每次读取操作涉及大量数据的工作负载来说，扩展计算资源的规模也能带来益处。 例如，内存更大的群集层可以促进每个文档的有效负载大小更大，同时每个响应能够包含更多数量的较小文档。
磁盘 IOPS 会影响 Azure DocumentDB 中的写入作，而不是计算资源的 CPU 和内存容量。
- 写入操作始终将数据保存到磁盘（同时将数据保留在内存中以优化读取）。 具有更多 IOPS 的较大磁盘提供更高的写入吞吐量，尤其是在大规模运行时。
- 该服务支持每个分片最多 32 TB 的磁盘，每个分片的 IOPS 更多，以有利于写入繁重的工作负荷，尤其是在大规模运行时。
存储密集型工作负载和大容量磁盘
每个群集层没有最低存储要求
如前所述，存储和计算资源与计费和预配分离。 尽管它们作为一个整体单元运作，但可以独立进行缩放。 M30 群集层可以预配 32 TB 磁盘。 同样，M200 群集层可以预配 32 GB 磁盘，以便针对存储和计算成本进行优化。
具有 32 TB 及以上容量的大型磁盘可降低 TCO
通常，NoSQL 数据库将每个物理分片的存储限制为 4 TB。 Azure DocumentDB 提供高达 8 倍的容量，容量为 32 TB 磁盘。 对于存储密集型工作负荷，每个物理分片的 4 TB 存储容量需要大量的计算资源，只是为了维持工作负荷的存储要求。 由于服务中的容量限制，计算比存储和预配计算更昂贵，可能会迅速增加成本。
让我们考虑一个存储密集型工作负荷，其中包含 200 TB 的数据。
| 每个分片的存储大小 | 维持 200 TB 所需的最小分片 |
|---|---|
| 4 TiB | 50 |
| 32 Tebibytes (TiB) | 7 |
随着磁盘变大，计算需求的减少会显著增加。 尽管可能需要超过最小物理分片数才能维持工作负荷的吞吐量要求，即使分片数翻倍或增加一倍，也比具有较小磁盘的 50 个分片群集更具成本效益。
使用大型磁盘时跳过存储分层
及时响应存储密集型场景中的计算处理成本，对数据进行“分层”处理。 事务数据库中的数据仅限于最常访问的“热”数据，而较大的“冷”数据量被分离到冷存储。 这会导致运作复杂性。 性能也是不可预知的，依赖于访问的数据层。 此外，整个系统的可用性取决于热数据存储和冷数据存储的组合复原能力。 使用服务中的大型磁盘时，无需分层存储，因为存储密集型工作负荷的成本会最小化。