Azure DocumentDB 与 Blob 存储，用于每个用户的多个 PDF 文件答案

【问题标题】：Azure DocumentDB vs Blob Storage for multiple PDF files per userAzure DocumentDB 与 Blob 存储，用于每个用户的多个 PDF 文件
【发布时间】：2016-07-16 10:12:25
【问题描述】：

我正在开发我的第一个应用程序作为一个学习项目，几乎可以做任何事情：

客户端前端（角度）
后端（OWIN 自托管，ASP.NET Web Api 2）
数据库和托管（Azure 部署）

到目前为止，这是一个学习过程，我在我的应用程序中使用令牌完成了登录/注册授权，但我使用身份框架和 Azure SQL DB（存储在为我创建的 dbo.AspNetUsers 表下存储我的用户凭据） )。

为了配合我的用户表，我希望有一个表来实际存储与我的用户关联的元数据，在我的应用程序案例中：

信用卡信息

PDF 文件（BLOB 格式，但每个帐户关联多个文件）这些 BLOB 文件是在他们上传 PDF 和后来他们下载后又变成了PDF。

我在 Azure 门户上看到有一个文档 NoSQL 数据库以及 BLOB 存储。我想知道是否可以将信用卡信息添加到我已经存在的 AspNetUsers 表中，这可以简化我只需将 PDF 数据单独存储在单独的表中。

我也不确定表格的结构，因为一个用户可以拥有多个 PDF 文件。我的业余知识认为，也许拥有一个键值数据库可能会更好，格式如下：

  Key-UserName            Value- JSON object of BLOB's with Id's.

我觉得对于检索代表 PDF 的 BLOB 的 PDF 表，如果我可以将 ID 与每个条目相关联并计算出一个 JSON 对象，我可以添加任意数量的字段，那么最好不要检索所有这些字段查询，但不确定。

显然这还为时过早，我只是在寻找资源和经验，而不是直接的答案。

【问题讨论】：

标签： asp.net azure asp.net-identity azure-blob-storage azure-cosmosdb

【解决方案1】：

我想知道是否可以将信用卡信息添加到我的已经存在的 AspNetUsers 表只能简化我必须通过以下方式处理将 PDF 数据存储在单独的表中自己。

我不确定您是否可以在此表中添加一列，但实际上我不会将用户的信用卡信息存储在应用程序数据库中。如果可能的话，我会使用第 3 方支付处理器并将我的解决方案与它集成，而不是自己存储信用卡信息（我知道有点偏离主题的评论 :)）。

现在谈到关于存储 PDF 的其他问题，我建议使用 Azure Blob 存储而不是 DocumentDB。我在这里概述的一些原因：Create a cloud storage app with ASP.NET and Azure。我能想到的其他原因是：

虽然您确实可以使用 DocumentDB 将文件存储为附件，但附件的大小有限制（上次我检查它是 2MB）。对于 Blob 存储，此限制为 200GB。
您不能直接从 DocumentDB 流式传输附件内容。您首先需要在应用程序中获取内容，然后流式传输内容，但是使用 Blob 存储，您可以直接流式传输内容。

就解决方案而言，您可以采取两种方法：

创建一个Attachments 表。实际上，它是一个具有复合主键的简单表 - 用户 ID + Blob Url。每当用户在 blob 存储中上传文件时，您都会获得一个 blob URL。然后，您可以将其与其他一些信息（如文件名、上传日期等）一起存储在该表中。如果您想查询数据，这种方法会很好用，例如按时间倒序排列文件。
创建容器/用户。在这种情况下，用户上传的所有文件都放在一个容器中。有关详细信息，请参阅上面的链接。在这种情况下，当您想要显示用户上传的文件时，您只需列出分配给该用户的容器中的 blob。但是请记住，如果用户上传的文件少于 5000 个，这种方法会很有效，因为一次调用列出容器中的 blob 最多只能返回 5000 条记录。另请注意，blob 存储是一种简单的对象存储，没有查询功能。

【讨论】：

您是否推荐或知道我可以在其中安全存储其信息的任何第三方信用卡应用程序？只需将用户与他们的付款信息相关联。另外我可能会误解，但您的意思是在我当前的 Azure SQL DB 中创建一个附件表？因此，在此您建议用户在此表中有多个行，每个 blob 指针对应一个？我认为这对我来说很有意义。感谢您的回复！
对于我们的应用程序，我们使用 FastSpring (fastspring.com)，我们对此非常满意。还有更多像 PayPal 等。Also I may be misunderstanding, but you mean create an Attachments table in my current Azure SQL DB? --> 没错。
请问，为什么是用户 ID + Blob URL 的复合主键？为什么不将标识列作为主键？
@nmit026 如果您使用的是 SQL 数据库，那么我同意您的看法。如果您使用的是 Azure Tables，那么如果您想为每个用户搜索附件，那么使用标识列路由会给您带来问题，因为 Azure Tables 的查询支持有限。

【解决方案2】：

对于信用卡信息，Azure SQL 中用户 ID 和 CC 号码之间的简单映射表就足够了，并且允许您处理用户和信用卡之间的一对多关系（您没有指定，所以也许现在这不是问题......也许以后？）。

关于 PDF... 从成本或性能的角度来看，DocumentDB 并不是您理想的解决方案。它不适合存储和检索 PDF 等二进制数据。在您的场景中，我强烈考虑使用 Blob 存储来保存 PDF 内容本身，并通过 SQL Azure 中的映射表将 PDF 映射到用户，该映射表将用户 ID 与 Blob URI 相关联。如果您需要存储和查询 PDF 的额外元数据，您可以使用 SQL 映射表中的额外列。在创建或删除 Blob 时将映射同步到 Blob 会有一些负担，但这是云中相当常见的数据场景。

祝你好运！

【讨论】：