我们正在创建一个多租户应用程序，该应用程序必须在租户之间隔离数据。每个租户将保存各种文档，每个文档可以分为几个不同的文档类别。我们计划将Azure blob存储用于这些文档。但是，鉴于我们的用户群以及每个文档的数量和大小，我们不确定如何通过当前的Azure订阅来最佳地管理存储帐户。
这是一些要考虑的数字。拥有5,000个用户，每个用户每年27,000个8Mb文档，即每年总计1080TB。每个存储帐户的存储容器最大容量为500TB。
所以我的问题是，存储这些数据并保持在Azure限制范围内的最有效和最具成本效益的方法是什么？
我们考虑了以下几件事：
为每个客户端创建一个存储帐户。这不起作用，因为每个订阅只能有100个存储帐户（这是最理想的解决方案）。
为每个客户端创建一个Blob容器。一个存储帐户最多可以有500TB，因此这可能会起作用，除非最终我们必须拆分为其他存储帐户。我不确定如果最终用户在两个帐户中有数据，那将如何工作。可能会变得凌乱。
也许我们在这里错过了一些根本上简单的事情。
更新现在，我们的想法是将Azure表存储与每种文档类型的表一起使用。在每个表中，分区键将是租户的ID，行键将是文档ID。每行还将包含文档的元数据类型信息，以及链接到Blob本身的URI（或其他内容）。
并不是一个真正的答案，而是将其视为“值得思考的食物” :)。基本上，您的体系结构应基于以下事实：每个存储帐户都有一个帐户，scalability targets并且您的设计应不超过为应用程序维护高存储可用性的帐户。
一些建议：
Pods。PartitionKey自由使用并且您可以根据需要分配其他值。现在开始存储文件：
Pod概念：每个租户的文件都驻留在该租户的pod存储帐户中。pod存储帐户并将文件放在此处，然后将Blob URL存储在Files表中。tenant-files），也可以为每个租户使用单独的Blob容器。pod调试新容器时只需创建此容器。但是不利的是，您不能按租户逻辑上分开文件，因此，如果要提供对文件的直接访问（使用共享访问签名），这将是有问题的。希望这会使您对如何设计解决方案有所了解。我们在解决方案中使用了其中一些概念（显式使用Azure存储作为数据存储）。看看您想出什么体系结构真的很有趣。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句