假设:应用程序是基于web的

我很惊讶没有人真正提到这一点……委托给其他专家->使用第三方映像/文件托管提供商。

将文件存储在付费的在线服务上，比如

Amazon S3 Moso云存储

另一个StackOverflow线程在这里讨论这个。

这篇文章解释了为什么你应该使用第三方托管提供商。

太值得了。它们能有效地储存。没有带宽从你的服务器上传到客户端请求等等。

尝试使用SQL模拟文件系统通常是一个糟糕的计划。如果您坚持使用文件系统作为外部存储，那么最终编写的代码会更少，结果也会更好。

有一件事我还没有看到任何人提到，但绝对值得注意的是，在大多数文件系统中也存在与存储大量图像相关的问题。例如，如果您采用上面提到的方法，以主键命名每个图像文件，在大多数文件系统上，如果您试图将所有图像放在一个大目录中，一旦您达到了非常大的图像数量(例如数十万或数百万)，您将遇到问题。

常见的解决方案是将它们散列到平衡的子目录树中。

我负责一些管理许多TB图像的应用程序。我们发现在数据库中存储文件路径是最好的。

这里有几个问题:

database storage is usually more expensive than file system storage you can super-accelerate file system access with standard off the shelf products for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization. things like web servers, etc, need no special coding or processing to access images in the file system databases win out where transactional integrity between the image and metadata are important. it is more complex to manage integrity between db metadata and file system data it is difficult (within the context of a web application) to guarantee data has been flushed to disk on the filesystem

对于大量的小图像，数据库可能更好。

我有一个带有许多小缩略图的应用程序(每个缩略图2Kb)。当我将它们放到文件系统中时，由于文件系统的块大小，它们每个都消耗了8kb。空间增加了400% !

有关块大小的更多信息，请参阅这篇文章: iphone文件系统的块大小是多少?

如果你需要在文件系统中存储大量的图像，需要考虑以下几点:

备份和恢复。你如何保持图像同步。 文件系统的性能。这取决于您正在做的事情和文件系统，但您可能希望实现一个散列机制，这样您就不会有一个包含数十亿个文件的目录。 复制。您是否需要在多个服务器之间保持文件同步?