保存图像：文件还是 blob？
当您保存图像时（假设您有很多图像），您会将其存储为数据库中的 blob 还是文件？为什么？
When you save your images (supose you have lots of them) do you store then as blobs in your Database, or as files? Why?
Duplicate of: Storing Images in DB - Yea or Nay?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我通常将它们存储为文件，并将路径存储在数据库中。对我来说，这是一种比将它们作为 blob 推入数据库更容易、更自然的方法。
将它们存储在数据库中的一个论点是：进行完整备份要容易得多，但这取决于您的需求。如果您需要能够轻松拍摄数据库的完整快照（包括图像），那么将它们作为 blob 存储在数据库中可能是最佳选择。否则，您必须将数据库备份与文件备份配对，并以某种方式尝试将两者关联起来，以便在必须进行还原时知道要还原哪一对。
I usually go with storing them as files, and store the path in the database. To me, it's a much easier and more natural approach than pushing them into the database as blobs.
One argument for storing them in the database: much easier to do full backups, but that depends on your needs. If you need to be able to easily take full snapshots of your database (including the images), then storing them as blobs in the database is probably the way to go. Otherwise you have to pair your database backup with a file backup, and somehow try to associate the two, so that if you have to do a restore, you know which pair to restore.
这取决于图像的大小。
Microsoft Research 有一个关于该主题的有趣的文档
It depends on the size of the image.
Microsoft Research has an interesting document on the subject
我尝试使用数据库（SQL Server 和 MySQL）来存储中等（< 5mb）文件，但遇到了很多麻烦。
1）某些DB（SQL Server Express）有大小限制；
2）一些数据库（MySQL）变得非常慢；
3）当你需要显示一个对象列表时，如果你不经意地执行了 SELECT * FROM table，大量的数据将尝试从数据库中上下移动，导致响应极其缓慢或内存故障；
4) 一些前端（ruby ActiveRecord）在处理 blob 时遇到很大的麻烦。
只需使用文件即可。不要将它们全部存储在同一个目录中，使用某种技术将它们放在多个目录中（例如，您可以使用 GUID 的最后两个字符或 int id 的最后两位数字），然后将路径存储在 db 上。
I've tried to use the db (SQL Server and MySQL) to store medium (< 5mb) files, and what I got was tons of trouble.
1) Some DBs (SQL Server Express) have size limits;
2) Some DBs (MySQL) become mortally slow;
3) When you have to display a list of object, if you inadvertedly do SELECT * FROM table, tons of data will try to go up and down from the db, resulting in a deadly slow response or memory fail;
4) Some frontends (ruby ActiveRecord) have very big troubles handling blobs.
Just use files. Don't store them all in the same directory, use some technique to put them on several dirs (for instance, you could use last two chars of a GUID or last two digits of an int id) and then store the path on db.
数据库服务器的性能影响是一个有争议的问题。如果您需要文件系统的性能优势，只需在第一个请求时将其缓存在那里即可。然后，可以通过直接链接直接从文件系统提供后续请求（如果是 Web 应用程序，您可以在刷新输出缓冲区之前重写 HTML）。
这提供了两全其美的优点：
数据库，保持事务性和
参照完整性
只需部署数据库
Web 服务器）只会导致
暂时的性能受到影响
自动补充。
对于那些永远不会改变的东西，不需要不断地锤炼数据库，但重要的是用户数据都在那里，而不是分散在不同的地方，使多服务器的运行和部署变得一团糟。
我一直提倡“数据库作为用户数据存储，除非”方法，因为它在架构上更好，而且有效缓存不一定会变慢。
话虽如此，使用文件系统作为权威存储的一个很好的理由是当您确实需要使用外部独立工具来访问它时，例如 SFTP 等。
The performance hit of a database server is a moot issue. If you need the performance benefits of a file system, you simply cache it there on the first request. Subsequent requests can then be served directly from the file system by a direct link (which, in case of a web app, you could rewrite the HTML with before flushing the output buffer).
This provides the best of both worlds:
database, keeping transactional and
referential integrity
simply deploying the database
web server) would only cause a
temporary performance hit while it is
refilled automatically.
There is no need to constantly hammer the database for things that won't change all the time, but the important thing is that the user data is all there and not scattered around different places, making multi-server operation and deployment a total mess.
I'm always advocating the "database as the user data store, unless" approach, because it is better architecturally, and not necessarily slower with effective caching.
Having said that, a good reason to use the file system as the authoritative store would be when you really need to use external independent tools for accessing it, e.g. SFTP and whatnot.
鉴于您可能想要保存图像以及名称、简短描述、创建日期、创建者等，您可能会发现保存在数据库中更好。这样，一切就在一起了。如果您保存了相同的信息并将图像存储为文件，则必须从两个位置检索整个“图像对象”......并且在路上，您可能会发现自己遇到同步问题（某些图像未找到） 。希望这是有道理的。
Given that you might want to save an image along with a name, brief description, created date, created by, etc., you might find it better to save in a database. That way, everything is together. If you saved this same info and stored the image as a file, you would have to retrieve the whole "image object" from two places...and down the road, you might find yourself having syncing issues (some images not being found). Hopefully this makes sense.
通过保存您的意思是使用它们来显示在网页或类似的东西中？
如果是这种情况，更好的选择是使用文件，如果您使用数据库，它将不断受到照片请求的打击。而且这种情况的扩展性不太好。
By saving you mean to use them to show in a webpage or something like that?
If it's the case, the better option will be to use files, if you use a database it will be constantly hammered with the request for photos. And it's a situation that doesn't scale too well.
问题是，您的应用程序是否像其他应用程序数据一样处理 BLOBS 或其他文件？您的用户是否将图像与其他数据一起上传？如果是这样，那么您应该将 BLOB 存储在数据库中。它使备份数据库变得更加容易，并且在出现问题时恢复到事务一致的状态。
但如果您指的是属于应用程序基础设施而不是用户数据的图像，那么答案可能是“不”。
The question is, does your application handle BLOBS or other files like other application data? Do your users upload images alongside other data? If so, then you ought to store the BLOBs in the database. It makes it easier to back up the database and, in the event of a problem, to recover to a transactionally consistent state.
But if you mean images which are part of the application infratstructure rather than user data then probably the answer is, No.
如果我在一台 Web 服务器上运行并且只会在一台 Web 服务器上运行，我会将它们存储为文件。如果我运行多个网络头，我会将图像的参考实例放入数据库
BLOB中，并将其作为文件缓存在网络头上。If I'm running on one web server and will only ever be running on one web server, I store them as files. If I'm running across multiple webheads, I put the reference instance of the image in a database
BLOBand cache it as a file on the webheads.我建议选择文件系统。首先，我们来讨论一下为什么不是 Blob？因此，为了回答这个问题，我们需要思考数据库相对于文件系统为我们提供了哪些优势？
那么为什么是文件系统呢？
select *) 将导致查询性能非常差因为大量的数据将进出数据库。相反，如果我们只将图像的 URL 存储在数据库中，并将图像存储在分布式文件系统 (DFS) 中，速度会快得多。I would suggest to go for File systems. First, let's discuss why not Blob? So to answer that, we need to think what advantages DB provides us over File system?
Then why File systems?
select *) will result in a very poor performance of the query as a lots and lots of data will be going to and from the DB. Instead if we just store the URL of images in DB and store images in a distributed file system (DFS), it will be much faster.Blob 可能会对数据库/脚本造成沉重负担，为什么不只存储路径呢？我们使用 blob 的唯一原因是它是否需要合并复制或资产的超严格安全性（例如除非登录或其他原因否则无法提取图像）
Blobs can be heavy on the db/scripts, why not just store paths. The only reason we've ever used blobs is if it needs to be merge replicated or super tight security for assets (as in cant pull image unless logged in or something)
使用文件系统更好，因为将图像存储为 blob 时将提供的基本功能是
1. 图像不需要可变性，因为我们不会更改图像的二进制数据，我们只会删除整个图像
2.索引搜索：图像不需要索引搜索，因为图像内容无法索引，索引搜索搜索BLOB的内容。
使用文件系统在这里是有益的，因为
1.比较便宜
2. 使用 CDN 进行快速访问，
因此一种前进的方法是将图像存储为文件并提供其在数据库中的路径
Using file System is better as the basic feature you would be provided with while storing images as a blob would be
1. mutability which is not needed for an image as we won't be changing the binary data of images, we will be removing images as whole only
2. Indexed searching :which is not needed for image as the content of images can't be indexed and indexed searching searches the content of the BLOB.
Using file system is beneficial here because
1. its cheaper
2. Using CDN for fast access
hence one way forward could be to store the images as a file and provide its path in database
Blob 和文件系统现在已经过时了
为什么不使用 S3 存储桶来存储图像，因为我们在生产中使用它们，并将它们的路径存储在数据库中
Blob and file system are old now
Why not go for S3 bucket to store images as in production we are using them,and storing the path of them in db