这篇文章是一个分为两部分的系列文章的第2部分，讲述了组织如何使用azurecosmosdb来满足现实世界的需求，以及它给他们带来的不同。在第1部分中，我们探讨了导致microsoftofficelicensingservice团队从azuretablestorage迁移到azurecosmosdb的挑战，以及它是如何将生产工作负载迁移到新服务上的。在第2部分中，我们将研究团队努力的结果。以最小的努力获得强大的效益微软Office授权服务（OLS）团队从Azure表存储迁移到Azure Cosmos DB的过程简单明了，使团队能够以最小的努力满足所有需求。轻松的迁移在迁移到azurecosmosdb的过程中，由于其tableapi，OLS团队能够重用其大部分数据访问代码，并且他们为避免任何停机而编写的迁移引擎既快速又容易构建。微软软件工程师Danny Cheng领导OLS开发团队，他解释道："迁移引擎是我们必须编写的唯一真正的‘新代码’。而且这三个部分的代码示例都是公开的，所以我们不需要从头开始。总而言之，我们开发的迁移工具需要三名开发人员每人大约4周的时间。"几乎无限的吞吐量今天，数据库吞吐量不再是OLS团队的问题。对于表存储，团队面临着每个存储帐户每秒20000个操作的吞吐量限制，这迫使他们将18个表中的每一个表都维护在不同的存储帐户中，以实现最大吞吐量。该团队现在维护一个azurecosmos数据库帐户，该帐户对吞吐量没有上限，并且可以支持每秒超过1000万个操作，这些操作都是专用的，并有sla的支持。保证高可用性azurecosmosdb为OLS团队提供了一个99.999%的读可用性SLA，用于所有多区域帐户。这导致了存储服务质量（QoS）的显著提高，如以下使用内部开发的工具捕获的指标所示。"在流量高峰时段，Azure Cosmos DB提供的存储QoS比我们看到的表存储要好得多，"Cheng说今天，我们看到的是5个9，而过去我们是3个9。"自动故障转移OLS团队现在可以配置自动或手动故障切换，以帮助防止不太可能发生的区域性停机事件，并维护所有sla。该团队还可以为其多区域帐户确定故障转移顺序的优先级，并可以手动触发故障转移来测试OLS的端到端可用性。"我们已经配置了自动故障转移，但该服务非常可靠，我们还不需要它，"Cheng说。较低的延迟表存储为OLS团队提供了延迟没有上限。相比之下，azurecosmosdb提供了一位数的读写延迟，并保证在世界任何地方，任何规模的读写延迟都在99%以下。以下指标说明了OLS服务在表存储和azurecosmosdb之间的延迟差异。（DbTable是Azure表存储，cosmsdbtable是Azure Cosmos DB Table API。）交钥匙数据分发对于表存储，全局分发的选项是有限的。更重要的是，OLS团队无法独自实现故障转移。有了azurecosmosdb，团队现在可以向任何数量的区域分发，包括多主功能，当启用后，任何区域都可以接受写操作。"只需点击地图，数据就可以自动复制到世界上任何一个Azure区域，"Cheng说此功能非常方便，我们计划尽快投入使用。"其他技术优势除上述之外，Azure Cosmos DB还为OLS团队提供了比表存储更多的优势：自动索引。对于表存储，主索引仅限于PartitionKey和RowKey，并且没有辅助索引。azurecosmosdb在默认情况下为所有属性提供自动和完整的索引，没有索引管理。更快的查询时间。对于表存储，查询执行使用主键的索引，否则进行扫描。使用azurecosmosdb，查询可以利用对所有属性的自动索引来加快查询时间。一致性。对于表存储，OLS团队仅限于主区域内的强一致性和辅助区域内的最终一致性。有了azurecosmosdb，他们可以从定义良好的一致性级别中进行选择，使他们能够在设计解决方案时在读取一致性和延迟、可用性和吞吐量之间进行优化权衡。立即开始使用Azure Cosmos DB访问Azure宇宙数据库。请参阅Azure Cosmos DB Table API简介。