在 Microsoft Build 2017在这次事件中，我遇到了CosmosDB Table API。它看起来像Azure 表存储。
这是否意味着 Microsoft 最终将停止支持 Azure 表存储？
现在，Document Db 已不复存在。现在已经转换为CosmosDB。
此外，表存储的主要问题是备份。这已在 CosmosDB Table API 中得到解决。
此外，Table API 的定价策略是基于吞吐量，而表存储的定价策略是基于存储。
那么表存储对于大容量应用程序来说仍然是一个不错的选择吗？
最佳答案
正如 Peter 回应的那样，DocumentDB 现在是 Cosmos DB 的一部分，它是 many Data Models 之一新服务已可用，包括 MongoDB API , Premium Tables API ，和Gremlin Graph API .
它们都有相同的 global distribution能力和consistency levels .
现在，回到您的表格问题，这两种服务都有不同的场景和定价模型。
虽然 Azure 存储表的目标是单个区域的高容量(可选的辅助只读区域，但无故障转移)，但通过 PK/RK 建立索引和存储优化定价； Azure Cosmos DB 表的目标是实现高吞吐量(个位数毫秒延迟)、全局分布(多次故障转移)、SLA 支持的预测性能(对每个属性/属性进行自动索引)以及专注于吞吐量的定价模型。
根据您的场景，您可能想要使用的服务，Azure 存储表仍然是一个很好的解决方案，但是，例如，如果您需要全局分发，Cosmos DB 表是最适合的服务。
关于Azure 表存储与 CosmosDB 表 API，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44005805/