在使用 mysql 时，将图像作为 BLOB 存储在数据库中是一个坏主意，因为这会使数据库变得非常大，这对数据库的正常使用是有害的。然后，最好将图像文件保存在磁盘上，并将它们的链接保存在数据库中。
但是，我认为这对于 MongoDB 来说是不同的，因为增加数据库文件大小对性能的影响可以忽略不计（这就是 MongoDB 可以成功处理数十亿条记录的原因）。
您认为将图像文件保存在 MongoDB（作为 GridFS）上是否更好，以减少服务器上存储的文件数量；还是还是让数据库尽可能小更好？
【问题讨论】：
标签： mysql mongodb file database
在任何数据库中存储图像都不是一个好主意，因为：
- 读取/写入数据库总是比文件系统慢
- 您的数据库备份变得庞大且耗时
- 现在访问文件需要通过您的应用和数据库层
最后两个才是真正的杀手。
来源：Three things you should never put in your database。
所以如果你可以让你的应用变得狡猾，那么最好不要将你的图片上传到MongoDB。
但是，如果您接近最后期限...并且数据库将非常小以至于不会增长很多并且其大小永远不会超过运行您的应用程序的机器上的可用 RAM，那么我认为（如与引用文章的作者相反），您可以考虑将图像存储在 MongoDB 中。它简单、方便、快速实施，并为您提供了一定的灵活性。
【讨论】：
答案是肯定的。回到古老的洞穴人时代，服务器具有可以更改的可变文件系统。在我们尝试扩展之前，这很棒。
现在洞穴人使用immutable deployments 构建应用程序。 Heroku 和 Dokku 就是这样的例子。由于 Web 应用服务器没有状态，因此可以轻松地创建、升级、扩展和销毁它们。
既然我们还有文件，我们需要把它们放在某个地方。有几种解决方案：nfs、我们的数据库、别人的数据库。
nfs 是一个“网络文件系统”，可让您在网络资源上执行文件 i/o。如果您无论如何都在处理网络，恕我直言，除非它是您已经知道的，否则它不会增加太多价值。
我们的数据库 - 对于 MongoDB there are two options: (file > 16mb) ? GridFS : BinData
其他人的数据库 - 有些是基本的，例如 Amazon S3，有些提供额外的服务，例如 Cloudinary 或 Dropbox。
如果您在一个高预算的企业团队中，并且有人每周花费 40 小时来维护服务器，那么请务必使用文件系统。如果您要构建可扩展的 Web 应用程序，将文件放入数据库是有意义的。
如果您担心性能：
1) 使用代理（例如 nginx）或 CDN 为客户托管您的内容。您的服务器应该只是处理缓存未命中。
2) 使用流式 IO Nodeschool has a cool tutorial for Node.js。
【讨论】：
问题不在于数据库变大，而是数据库可以处理（尽管 MongoDB 在这方面不如其他许多）。问题在于，要将数据发送到客户端，首先必须由数据库将其移动到 RAM 中，然后复制到应用程序的内存中，然后移交给内核以通过套接字发送。它浪费了大量的 RAM 和 CPU 周期。文件系统中最好有大文件的原因是它更容易复制它，您可以要求内核将文件从磁盘直接流式传输到套接字。
在文件系统中存储大文件的缺点是更难分发。使用数据库和 Mongo 的 GridFS 之类的东西可以向外扩展。您只需要确保不要一次将整个文件复制到应用程序的内存中，而是一次复制一个块。如今，大多数 Web 应用程序框架都支持发送分块的 HTTP 响应。
【讨论】：
MongoDB 的 GridFS 专为这种存储而设计，非常方便地以所有服务器都可以使用的方式在许多不同的服务器上存储图像文件。
【讨论】：