数据库与文件系统中的图像
我们有一个项目即将到来，我们将build立一个完整的后端CMS系统，将为我们的整个外联网和内联网提供一个包。 我一直在试图find答案的问题是哪个更好：将图像存储在数据库（SQL Server 2005）中，以便我们可以具有完整性，单个复制计划等，或存储在文件系统上？
我们遇到的一个问题是，我们有多个服务器负载均衡，需要始终具有相同的数据。 到目前为止，我们有SQL复制照顾，但文件复制似乎有点困难。 另一个问题是，我们希望同一图像有多个分辨率，我们不确定在文件系统上创build和存储每个版本是最好的，或者可以根据请求dynamic地提取和创build分辨率图像。
我们关心的是以下几点：
- 数据的完整性
- 数据复制
- 多个决议
- 数据库与文件系统的速度
- 数据库与文件系统的开销负载
- 数据pipe理和备份
有没有人有类似的情况或有什么build议？ 先谢谢您的帮助！
微软研究院发表了一篇很好的研究论文，名为To Blob或不是Blob ，他们研究各种variables和影响。
他们的发现最终：
- 最大可达256 KB，blob存储在数据库中比在文件系统中更有效
- 对于1 MB或更大，文件系统更高效
- 在它之间是一个抛硬块
自从这篇文章发表以来，SQL Server 2008还添加了FILESTREAM属性，它使得在文件系统中存储东西，但是在事务控制下，这是一个现实。 强烈build议你检查一下！
这个问题经常出现 – 看到这个search结果。
没有一个正确的答案 – 这取决于具体情况。
就个人而言 – 保留数据库中的文件path和文件系统上的文件。 每个人都有自己的优势。 您可以备份文件以及数据库。 这也是这个pipe理结核数据的家伙的结论。
静态文件的复制，特别是跨多个服务器，可能难以pipe理。 这实际上归结为pipe理，监视和debugging复制问题与数据库大小和负载之间的权衡。
我想我可能会select数据库方法，如果加载成为一个问题，请在图像调用周围放置一些caching层。
在数据库中存储path的build议缺less真正的问题，即在多台机器上复制这个问题。
那么，如果你的前两个需求是完整性和复制，那么答案肯定是DB。
你还有其他的观点：
-
完整性 – 数据库，这就是为什么数据库存在与平面文件系统。
-
复制 – 不知道你的意思是图像复制，但如果是这样，那么显然是DB，因为你不会负载平衡这，当然。
-
可以从数据库图像执行多个分辨率，但这会增加处理成本。 此外，分辨率越高，尺寸越大，networking等待时间越长。 多个决议交换空间的速度。
-
速度 – 取决于对图像的访问，可能可以忽略不计。 如果你在一个文件共享中进行镜像，无论如何你都必须在networking上等待，networking几乎一直是瓶颈。
-
开销 – 坦率地说，这取决于您对开销的定义以及您如何访问图像。
-
pipe理，数据库，手下来。 单一存储=less一点担心，无论如何，您应始终在数据库上运行备份。 通过多个服务器进行文件系统备份在许多方面是昂贵的。
你的担心分解成两个阵营。 以下内容涉及将文档存储在数据库中：
- 数据的完整性
- 数据复制
- 多个决议
- 数据pipe理和备份
这些担心（可能）赞成将文件存储在文件系统上：
- 数据库与文件系统的速度
- 数据库与文件系统的开销负载
所以，决定什么是最重要的，并据此select。
辩论的任何一方都有有效的担忧，所以请始终给出您的要求。 多less数据，多less图片，多大？
内联/ BLOB存储
上游 ：简化体系结构和实施，简化系统的备份和恢复或迁移; 只要做一个转储，备份，导出（无论你的数据库的味道），并将其移动到新的数据库。 版本控制/一致性由DB处理，因此允许时间点恢复。 安全/访问控制也更加清晰，因为对图像BLOB的访问是访问整个行的固有内容。 将图像移动到数据库之外并让HTTP服务器获取它，同时更好地实现并发性和可伸缩性，可能会在确保人们无法破解URL和请求不属于自己的图像时遇到问题。 如果您将它们放在数据库之外，请确保您的安全策略涵盖用户之间的图像访问控制。 您的HTTP服务器身份validation必须与整个系统的身份validation集成，或者您提供映像的HTTP服务器程序使用某种会话机制来确保HTTP请求有效。 这是多租户数据库中非常重要的一个问题。 在单一用途的单租户系统中，只需简单的身份validation就不需要担心了。
缺点 ：对于真正意义上的大型数据库，备份和恢复会令人沮丧，甚至是成本高昂的问题，因为在那里你可能有一个小的核心数据集，否则你可能会有很多GB或TB的图像数据。 从完整性的angular度看，将所有数据视为一个一致的数据库是有好处的，但除非您使用具有企业级质量的数据库，数据仓库调整备份和恢复（例如Oracle RMAN和滚动备份），否则备份将会很糟糕。
始终考虑在任何系统中恢复的时间。 如果您的存储需求<几GB，甚至50-100GB，并且您有足够的备份空间计划，联机存储更清洁。 在此之上，分离关注点并让文件系统完成工作成为一个关键优势。 没有什么比尝试恢复，恢复和打开一个巨大的数据库，为了一个小数据错误。 恢复时间将是我最关心的问题。
通常，就CMS而言，在数据库中保存图像数据可能不如文件系统高效。 有一次，您可能只是想静态显示图像，在其他时候，您希望图像devise人员可以使用该图像进行更新等。
考虑每次您想要使用图像时检索图像的处理开销。
有几点你为什么要考虑FileSystem
- 浏览器可以完成所有的工作，并且可以从代理caching图像等方面受益
- 作为上述的一个分支，您可以轻松使用内容分发networking（CDN）
- 使用rsync等工具很容易复制图像数据
- 处理（即CPU）时间大幅度优化
假设你在一个Windows环境中，没有很好的理由来使用文件系统。 您可能需要小心如何将图像存储在表格中以避免不必要的页面拆分，但这是性能调整，不是一个大问题。
缺乏文件系统
不会自动复制
– 通过为每个实例设置不同的物理位置，可能会使复制复杂化
– 非常大量的文件
文件系统的上游
– 如果你正在存储一些非常大的文件，它会performance得更好一些。
我会;
1）为每个图像分配唯一标识符（GUID）2）使用该GUID标记/命名图像3）在操作系统（文件系统）中存储GUID 4）在数据库中存储完全限定文件名（FQN）指针。
在存储和维护方面将图像存储在数据库中是太昂贵的。 只存储FQN指针将提供更好的解决scheme。 您还可以通过触发器和某些存储过程来构build后端完整性检查。
我不会将图像存储在数据库中的一个原因（我的答案来自sql服务器）：
我不希望SQL Server数据caching由网站的简单图像填充。 我希望数据caching实际上有数据。 另外，如果你有一个多层架构，它比一个二进制数据块更容易传递一个图像的URL。 如果你只是想要某些人看到图像（安全），你会遇到问题。
感谢所有的快速input，我们现在只有大约5-10GB的图像，其中很多是因为我们有相同图像的多个分辨率。
另外一个问题是，如果我们想要扩展以保存文档，演示文稿和无限制的video呢？ 数据库方法是否支持让我们将video存储在数据库中，并将这些video保存在Flash中？
再次感谢所有的input！
