我想构建一个允许数千名用户将图像从平板电脑上传到内容管理系统的系统。在一次上传中，每个用户一次最多可以上传12张图片，每天最多可以上传20,000张图片。由于这些数字每天超过240,000张，我一直想知道在高峰时段避免瓶颈的最佳方法是什么。
我正在考虑使用Web服务器场（IIS）通过HTTP POST上传图像。每张图像小于200kB，我可以将图像存储在文件系统中。这将是每天48GB，每年只有16TB。
然后我可以将图像元数据与其他文本数据一起存储在SQL Server DB中。稍后，用户将想要将图像和其他（文本）数据从DB调回到平板电脑以进行进一步处理。
小规模，这没问题，但我对每个人认为每天上传/检索如此大量图像/记录的最佳方法感兴趣？
答案 0 :(得分：1)
我一直想知道在高峰时期避免瓶颈的最佳方法是什么。
足够的硬件。周期。
我正在考虑使用Web服务器场（IIS）来上传图像 HTTP POST。
除了值得一提之外别无选择。
这将是每天48GB，每年只有16TB。
是。现代存储真是太棒了;）
然后我可以将图像元数据与其他文本数据一起存储在SQL Server DB中。
这使得ia相当小的ldatbase - 这很好。最后，这意味着问题会延伸到图像存储中，数据库并不是那么大。
小规模，这没问题，但我对每个人的想法都感兴趣 每天上传/检索如此大量图像/记录的最佳方法是什么？
我不确定你是否已经大规模了。问题将出现：
文件数量。您需要将它们分成多个文件夹，最好在数据库中使用桶的概念，这样您就可以将它们分成多个桶，每个桶都是它们自己的服务器 - 有利于长期维护。
备份/恢复是一个问题，但如上所述使用（a）磁带和（b）存储桶时要少得多 - 完全问题的可能性很小。另外＆＃34;在不同的机器上复印3-4份＆＃34;可以运作得很好。
除了存储桶问题 - 即你不能把所有这些文件都放到一个简单的文件夹中，那将是不可思议的 - 你完全没问题。这不是特别大。保持Web级别无状态，以便您可以在存储后端进行扩展，然后使用数据库将它们连接在一起，并确保执行FREQUENT数据库备份（如所有15分钟）。
答案 1 :(得分：1)
其中一种可能的方法是从客户端直接上传到Amazon S3。它将扩展并接收任何数量的文件。上传到S3完成后，保存到S3对象的链接以及有用的元数据库。在此设置中，您将避免文件上传瓶颈，并且每天只能将〜240,000条记录保存到您的数据库中，这应该不是问题。
如果要构建添加值并在文件上载时节省一些（实际上是大量）时间的服务，请考虑使用为解决此特定问题而构建的现有第三方解决方案。例如 - Uploadcare及其一些竞争对手。