将图像（jpg、gif、png）存储在文件系统或数据库中？
我无法决定我应该遵循哪一个。 大家能给点意见吗？ 我应该将图像存储在文件系统还是数据库中？ （我想防止别人盗用我的图片）
当您回答这个问题时，请包括安全性、性能等方面的比较。
谢谢。
完全重复： 用户图像：数据库还是文件系统存储？
精确重复： 在数据库中存储图像：是或否？
完全重复： 我应该将我的图像存储在数据库或文件夹中？
精确重复： 您会将二进制数据存储在数据库还是文件夹中？
精确重复： 将图片存储为文件或网络应用程序的数据库？
精确重复： 存储少量图像图像数量：blob 还是 fs？
精确重复： 将图像存储在文件系统中或者数据库？
Possible Duplicates:
Which is more secure: filesystem or database?
User images - database vs. filesystem storage
store image in database or in a system file ?
I can't decide which one I should follow. Can you guys give some opinions? Should I store my images in the file-system or DB? (I would like to prevent others from stealing my images)
When you answer this question, please include comparisons of the security, performances etc.
Thanks.
Exact Duplicate: User Images: Database or filesystem storage?
Exact Duplicate: Storing images in database: Yea or nay?
Exact Duplicate: Should I store my images in the database or folders?
Exact Duplicate: Would you store binary data in database or folders?
Exact Duplicate: Store pictures as files or or the database for a web app?
Exact Duplicate: Storing a small number of images: blob or fs?
Exact Duplicate: store image in filesystem or database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
将图像移入数据库并编写代码来提取图像可能比其价值更麻烦。 这一切都将回到围绕保护图像的需求或性能要求的业务需求。
我建议坚持使用经过考验的真实系统，将文件路径或目录位置存储在数据库中，并将文件保存在磁盘上。 原因如下：
有关此主题的大量讨论还可以在以下位置找到：
问题 如果您的图像存储为
varbinary或某种 blob（取决于您的平台），我建议这比它的价值更麻烦。 您需要扩展的工作意味着您需要维护、单元测试和防御缺陷的代码更多。如果您的环境可以支持 SQL Server 2008，那么您可以利用 SQL 2008 中新的 FileStream 数据类型来实现两全其美。
我'我很乐意看到针对拥有大量用户群（如 Flickr 或 Facebook）的现实场景进行的研究。
同样，这一切都回到了您的业务需求。 祝你好运！
Moving your images into a database and writing the code to extract the image may be more hassle than it's worth. It will all go back to the business requirements surrounding the need to protect the images, or the requirement for performance.
I'd suggest sticking to the tried and true system of storing the filepath or directory location in the DB, and keeping the files on disk. Here's why:
A large amount of discussion for this topic is also found at:
Having your images stored as
varbinaryor a blob of some kind (depending on your platform), I'd suggest it's more hassle than it's worth. The effort that you'll need to extend means more code that you'll have to maintain, unit test, and defend against defects.If your environment can support SQL Server 2008, you can have the best of both worlds with their new FileStream datatype in SQL 2008.
I'd love to see studies in real-world scenarios with large user bases like Flickr or Facebook.
Again, it all goes back to your business requirements. Good luck!
为了防止“盗窃”，将它们存放在哪里并不重要。 如果您将字节流传递给浏览器，任何人都可以拦截并保存它。 没有办法阻止这种情况（我假设您正在谈论将图像传递到浏览器）。
如果您只是谈论保护机器本身上的图像，那也没关系。 操作系统可以像数据库一样安全地锁定，防止任何人获取图像。
就性能而言（向浏览器呈现图像时），我个人认为从文件系统提供服务会更快。 无论如何，您都必须在单独的 HTTP 事务中呈现图像，这几乎肯定需要多次访问数据库。 我怀疑（虽然我没有硬数据）将图像 URL 存储在数据库中（指向文件系统上的静态图像）会更快 - 那么获取图像的行为就是由 Web 服务器打开的一个简单文件，而不是而不是运行代码来访问数据库。
It doesn't matter where you store them in terms of preventing "theft". If you deliver the bytestream to a browser, it can be intercepted and saved by anyone. There's no way to prevent that (I'm assuming you're talking about delivering the images to a browser).
If you're just talking about securing images on the machine itself, it also doesn't matter. The operating system can be locked down as securely as the database, preventing anyone from getting at the images.
In terms of performance (when presenting images to a browser), I personally think it'll be faster serving from a filesystem. You have to present the images in separate HTTP transactions anyway, which would almost certainly require multiple trips to the database. I suspect (although I have no hard data) that it would be faster to store the image URLs in the database which point to static images on the file system - then the act of getting an image is a simple file open by the web server rather than running code to access the database.
您可能必须得到一大堆“但是文件系统是一个数据库”的答案。 这不是其中之一。
文件系统选项取决于许多因素，例如，服务器是否具有对该目录的写入权限？ （是的，我见过 apache 无法写入 DocumentRoot 的服务器。）
如果您希望跨平台 100% 交叉兼容性，那么数据库选项是最好的方法。 它还可以让您存储与图像相关的元数据，例如用户 ID、上传日期，甚至同一图像的替代版本（例如缓存的缩略图）。
不利的一面是，您需要编写自定义代码来从数据库读取图像并将其提供给用户，而任何标准 Web 服务器只会让您按原样发送图像。
不过，当谈到底线时，您应该只选择适合您的项目和服务器配置的选项。
You're probably going to have to get a whole ton of "but the filesystem is a DB" answers. This isn't one of them.
The filesystem option depends on many factors, for example, does the server have write premissisons to the directory? (And yes, I have seen servers where apache couldn't write to DocumentRoot.)
If you want 100% cross-compatibility across platforms, then the Database option is the best way to go. It'll also let you store image-related metadata such as a user ID, the date uploaded, and even alternate versions of the same image (such as cached thumbnails).
On the down side, you need to write custom code to read images from the DB and serve them to the user, while any standard web server would just let you send the images as they are.
When it comes to the bottom line, though, you should just choose the option that fits your project, and your server configuration.
将它们存储在文件系统中，将文件路径存储在数据库中。
当然，你可以使其可扩展和分布式，你只需要保持它们之间的图像目录同步（对于 JackM）。 或者使用连接到多个 Web 前端服务器的共享存储。
无论如何，窃取部分已在您的其他问题中涵盖，基本上是不可能的。 可以访问图像的人总是能够（或多或少的工作）将它们保存在本地......即使这意味着“打印屏幕”并粘贴到 Photoshop 中并保存。
Store them in FileSystem, store the file path in the DB.
Of course you can make this scalable and distributed, you just need to keep the images dirs synched between them (for JackM). Or use a shared storage connected to multiple web frontend servers.
Anyway, the stealing part was covered in your other question and is basically impossible. People that can access the images will always be able (with more or less work) to save them locally ... even if it means "print-screen" and paste into photoshop and saving.
这取决于您期望处理多少图像，以及您必须如何处理它们。 我有一个应用程序每天需要临时存储 10 万到几百万张图像。 我将它们写入文件系统的 2GB 连续块中，将图像标识符、文件名、起始位置和长度存储在数据库中。
为了检索，我只是将索引保留在内存中，文件以只读方式打开并来回查找以获取它们。 我找不到更快的方法来做到这一点。 它比查找和加载单个文件要快得多。 一旦将如此多的单个文件转储到文件系统中，Windows 就会变得非常慢。
我想这可能有助于安全，因为如果没有索引数据，图像检索起来会有些困难。
为了可扩展性，将 Web 服务放在它前面并将其分布在多台机器上不需要很长时间。
It depends on how many images you expect to handle, and what you have to do with them. I have an application that needs to temporarily store between 100K and several million images a day. I write them in 2gb contiguous blocks to the filesystem, storing the image identifier, filename, beginning position and length in a database.
For retrieval I just keep the indices in memory, the files open read only and seek back and forth to fetch them. I could find no faster way to do it. It is far faster than finding and loading an individual file. Windows can get pretty slow once you've dumped that many individual files into the filesystem.
I suppose it could contribute to security, since the images would be somewhat difficult to retrieve without the index data.
For scalability, it would not take long to put a web service in front of it and distribute it across several machines.
对于我管理的 Web 应用程序，我们将图像存储在数据库中，但确保它们在文件系统中得到很好的缓存。
来自 Web 服务器前端之一的图像请求需要快速内存缓存
检查数据库中的图像是否已更改，如果没有更改，则从文件系统提供该图像。 如果它发生了变化，它会从中央数据库中获取它并将副本放入文件系统中。
这提供了将它们存储在文件系统中的大部分优点，同时保留了一些
数据库的优点 - 我们只有一个位置来存储所有数据，这使得
备份更容易，这意味着我们可以毫无问题地扩展到相当多的机器上。 它
也不会给数据库带来过多的负载。
For a web application I look after, we store the images in the database, but make sure they're well cached in the filesystem.
A request from one of the web server frontends for an image requires a quick memcache
check to see if the image has changed in the database and, if not, serves it from the filesystem. If it has changed it fetches it from the central database and puts a copy in the filesystem.
This gives most of the advantages of storing them in the filesystem while keeping some
of the advantages of database - we only have one location for all the data which makes
backups easier and means we can scale across quite a few machines without issue. It
also doesn't put excessive load on the database.
如果您希望应用程序具有可扩展性，请不要在实际的 Web 服务器上使用文件系统。 您可以将文件的位置存储在持久数据存储中，例如数据库或 NoSQL 解决方案。
例如，对于 AWS 解决方案，您应该：
If you want your application to be scalable, do not use a file system on the actual web servers. You can store the location of files in a persistent datastore such as a database or a NoSQL solution.
For an AWS solution to this for example you should:
将文件保存到数据库将提供一定的安全性，因为其他用户需要访问数据库才能检索文件，但是就效率而言，对加载的每个图像进行 sql 查询，将所有负载留给服务器端。 帮自己一个忙，找到一种方法来保护文件系统内的图像，它们有很多。
Saving your files to the DB will provide a some security in terms that another user would need access to the DB in order to retrieve the files, but, as far as efficiency goes, a sql query for every image loaded, leaving all the load to the server side. Do yourself a favor and find a way to protect your images inside the filesystem, they are many.
数据库最大的现成优势是可以从网络上的任何位置访问它，如果您拥有多个服务器，这一点至关重要。
如果您想从其他计算机访问文件系统，则需要设置某种共享方案，这可能会增加复杂性并可能出现同步问题。
如果您确实要在数据库中存储图像，您仍然可以使用本地（非共享）磁盘作为缓存，以减少数据库的压力。 您只需要查询数据库的时间戳或其他内容来查看文件是否仍然是最新的（如果您允许可以更改的文件）。
The biggest out-of-the-box advantage of a database is that it can be accessed from anywhere on the network, which is essential if you have more than one server.
If you want to access a filesystem from other machines you need to set up some kind of sharing scheme, which could add complexity and could have synchronization issues.
If you do go with storing images in the database, you can still use local (unshared) disks as caches to reduce the strain on the DB. You'd just need to query the DB for a timestamp or something to see if the file is still up-to-date (if you allow files that can change).
如果问题是可扩展性，那么将数据移入数据库将会造成巨大损失。 您可以通过 DNS 循环网络服务器，但向每个图像添加 CGI 进程和数据库查找的开销是疯狂的。 它还使您的数据库更加难以维护，并且您的图像更加难以处理。
至于问题的另一部分，您可以像数据库记录一样轻松地保护对文件的访问，但归根结底，只要有一个返回文件的 URL，您就只有有限的选项来防止该 URL 被访问。使用（至少没有强制使用 cookie 和/或 javascript）。
If the issue is scalability you'll take a massive loss by moving things into the database. You can round-robin webservers via DNS but adding the overhead of both a CGI process and a database lookup to each image is madness. It also makes your database that much harder to maintain and your images that much harder to process.
As to the other part of your question, you can secure access to a file as easily as a database record, but at the end of the day as long as there is an URL that returns a file you have limited options to prevent that URL being used (at least without making cookies and/or javascript compulsory).
文件存储在文件服务器中，原始数据存储在数据库中。 虽然文件服务器（尤其是基于 HTTP 的）可以很好地扩展，但数据库服务器却不能。 不要将它们混合在一起。
Store files in a file server, and store primitive data in a database. While file servers (especially HTTP-based) scale well, database servers do not. Don't mix them together.
如果您需要编辑、管理或以其他方式维护图像，则应将其存储在数据库之外。
此外，文件系统具有许多数据库所没有的安全功能。
数据库适合存储指向实际数据的指针（文件路径）。
If you need to edit, manage, or otherwise maintain the images, you should store it outside the database.
Also, the filesystem has many security features that a database does not.
The database is good for storing pointers (file paths) to the actual data.