存储上传的照片和文档 - 文件系统与数据库 blob

发布于 2024-07-27 16:09:41 字数 269 浏览 11 评论 0原文

我的具体情况

物业管理网站,用户可以在其中上传照片和租赁文件。 对于每个公寓单元,可能有 4 张照片,因此系统中的照片数量不会过多。

对于照片,每张照片都会有缩略图。

我的问题

我的第一要务是性能。 对于最终用户,我想尽快加载页面并显示图像。

我应该将图像存储在数据库或文件系统中,还是无关紧要? 我需要缓存任何东西吗?

提前致谢!

My specific situation

Property management web site where users can upload photos and lease documents. For every apartment unit, there might be 4 photos, so there won't be an overwhelming number of photo in the system.

For photos, there will be thumbnails of each.

My question

My #1 priority is performance. For the end user, I want to load pages and show the image as fast as possible.

Should I store the images inside the database, or file system, or doesn't matter? Do I need to be caching anything?

Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

海的爱人是光 2024-08-03 16:09:41

虽然凡事都有例外,但一般情况是将图像存储在文件系统中是最好的选择。 您可以轻松地为图像提供缓存服务,无需担心处理图像处理的额外代码,并且如果需要,您可以通过标准图像编辑方法轻松地对图像进行维护。

听起来您的商业模式非常适合这种情况。

While there are exceptions to everything, the general case is that storing images in the file system is your best bet. You can easily provide caching services to the images, you don't need to worry about additional code to handle image processing, and you can easily do maintenance on the images if needed through standard image editing methods.

It sounds like your business model fits nicely into this scenario.

最偏执的依靠 2024-08-03 16:09:41

文件系统。 没有比赛。
当您将数据存储在数据库中时,数据必须经过更多层。

编辑缓存:
如果您想在用户上传文件时缓存文件以确保操作尽快完成,则将其直接转储到磁盘(即文件系统)大约是最快的。 只要文件不是太大并且没有太多并发用户,您就可以将文件“缓存”在内存中,返回给用户,然后保存到磁盘。 说实话,我不会打扰。

如果您要在上传文件后在网络上提供文件,并希望缓存以提高性能,文件系统仍然是最佳选择。 您将从网络服务器免费获得缓存(可能需要调整一两个设置)。 如果文件位于数据库中,您将不会得到此信息。

毕竟,听起来您永远不应该将文件存储在数据库中。 事实并非如此,您只需要一个充分的理由即可。

File system. No contest.
The data has to go through a lot more layers when you store it in the db.

Edit on caching:
If you want to cache the file while the user uploads it to ensure the operation finishes as soon as possible, dumping it straight to disk (i.e. file system) is about as quick as it gets. As long as the files aren't too big and you don't have too many concurrent users, you can 'cache' the file in memory, return to the user, then save to disk. To be honest, I wouldn't bother.

If you are making the files available on the web after they have been uploaded and want to cache to improve the performance, file system is still the best option. You'll get caching for free (may have to adjust a setting or two) from your web server. You wont get this if the files are in the database.

After all that it sounds like you should never store files in the database. Not the case, you just need a good reason to do so.

江湖正好 2024-08-03 16:09:41

一定要将图像存储在文件系统上。 人们在考虑这些类型的事情时没有充分考虑的一个问题是臃肿。 将图像作为二进制 blob 塞入数据库是一种使数据库膨胀的快速方法。 大型数据库会带来更高的硬件要求、更困难的复制和备份要求等。将图像粘贴到文件系统上意味着您可以使用许多现有工具轻松简单地备份/复制它们。 文件系统上的存储空间比数据库上的存储空间更容易增加。

Definitely store your images on the filesystem. One concern that folks don't consider enough when considering these types of things is bloat; cramming images as binary blobs into your database is a really quick way to bloat your DB way up. With a large database comes higher hardware requirements, more difficult replication and backup requirements, etc. Sticking your images on a filesystem means you can back them up / replicate them with many existing tools easily and simply. Storage space is far easier to increase on filesystem than in database, as well.

萌︼了一个春 2024-08-03 16:09:41

对 Sheepy 的回答进行评论。

通常,当文件大小小于 256 KB 时,在 SQL 中存储文件会更好,而当文件大小大于 1 MB 时则值得。 因此,在 256-1024 KB 之间取决于几个因素。 阅读本文,详细了解使用 SQL 或文件系统的原因。

Comment to the Sheepy's answer.

In common storing files in SQL is better when file size less than 256 kilobytes, and worth when it greater 1 megabyte. So between 256-1024 kilobytes it depends on several factors. Read this to learn more about reasons to use SQL or file systems.

优雅的叶子 2024-08-03 16:09:41

在某些操作上,数据库可能比文件系统更快,但加载数百KB的明确识别的数据块并不是其中之一。

此外,一个好的前端 Web 服务器(如 nginx)比您必须编写以从数据库读取 blob 的任何 Web 应用程序层都要快得多。 在一些测试中,对于中型文件(如大 HTML 或中型图像)的原始数据服务,nginx 与 memcached 大致相当。

去FS。 没有比赛。

a DB might be faster than a filesystem on some operations, but loading a well-identified chunk of data 100s of KB is not one of them.

also, a good frontend webserver (like nginx) is way faster than any webapp layer you'd have to write to read the blob from the DB. in some tests nginx is roughly on par with memcached for raw data serving of medium-sized files (like big HTMLs or medium-sized images).

go FS. no contest.

猥︴琐丶欲为 2024-08-03 16:09:41

也许有点偏离,但在 MySQL 会议的 这个 视频中,演示者讲述了网站 smugmug 如何使用 MySQL 和各种其他技术来实现卓越的性能。 我认为该视频建立在此处发布的一些答案的基础上,但也提出了在数据库范围之外提高网站性能的方法。

Maybe on a slight tangent, but in this video from the MySQL Conference, the presenter talks about how the website smugmug uses MySQL and various other technologies for superior performance. I think the video builds upon some of the answers posted here, but also suggest ways of improving website performance outside the scope of the DB.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文