【发布时间】：2019-11-09 15:26:36
【问题描述】：
我从事从 Azure 下载图像的 UWP 应用程序。虽然图像的大小
【问题讨论】：
标签： azure azure-cosmosdb azure-blob-storage
【发布时间】：2019-11-09 15:26:36
【问题描述】：
“更好”是一个见仁见智的问题。但请考虑图像不是元数据 - 它们只是二进制，这往往是 Azure 存储 (blob) 的域。 SQL 数据库和 Cosmos DB 都有特定的限制，您可能会发现自己在尝试存储如此数量的二进制数据时超出了这些限制。
进一步：在 SQL DB 或 Cosmos DB 中存储二进制数据（例如图像）后，您别无选择，只能以编程方式检索所述内容（并受您在数据库/集合中设置的性能约束的约束） .相比之下，Azure Storage有自己独立的缩放目标，对象可以直接访问（无论是公共的，还是私有的+SAS），通过CDN缓存。
这最终将归结为您为应用选择的存储架构，但希望这些信息能有所帮助。
【讨论】：
-
另外，考虑成本。 CosmosDB 很快就会变得很昂贵，因此需要提前进行计算/估算。
-
@Matt - 是的，但是......如果没有基准测试，成本很难估计。如果执行得足够频繁，低级 blob 事务也会变得昂贵，因为每个事务都有成本（而 Cosmos DB 具有基于 RU 的定价，您确切地知道您将支付什么）。这确实会有所不同，具体取决于访问频率。
-
感谢您的建议。在数据库中存储图像似乎更加结构化，每个图像的大小不应超过 2 MB，因为我们有压缩图像的压缩实用程序。如果我们获取 blob，我们如何迭代 500 k + 键 (ImageIds) 并检索选定的键？我们可以在 Azure BLOB 中对数据进行索引和排序吗？
-
Blob 存储没有索引。您的数据库（SQL DB、Cosmos DB 等）将是您的索引。也就是说，将 URL 存储到数据库记录或文档中的 blob。使用您存储在数据库中的元数据搜索您需要的内容，并相应地检索您需要的 URL。
在 Cosmos DB 中要记住的另一件事不是那么明显缩放设置可能会变得相当高，这可能会很快变得昂贵。
正如 David 建议的那样，我会将文件存储在 Blob 存储中，然后将文件 URL 与 ID 一起存储为 Cosmos 中的键值对。这应该使 Cosmos 变得非常小、高效且便宜，但仍然可以让您访问索引。
【讨论】：