在数据库中存储大量图像？好的体验？答案

【问题标题】：Storing large numbers of images in a database? A good experience?在数据库中存储大量图像？好的体验？
【发布时间】：2012-04-24 04:00:00
【问题描述】：

我正在编写一个将存储大量图像（可能还有视频）文件的应用程序。上传后，它们将立即被推送到某个云服务 CDN 上，以便实际向公众提供服务。这个想法是将图像存储在可靠的、可备份的存储中。我预计大约有 200,000 个对象，每个对象最大 10KB，可能还有更少的几 MB 视频文件。

默认情况下，我会使用 documentation suggests 可以的 Postgres。

这是一个明智的想法吗？
这会让备份数据库成为一场彻头彻尾的噩梦吗？经验？
任何可靠性问题？
这会影响数据库其他部分的性能吗？请记住，对于每张图像，数据库只会被点击一次或两次。

【问题讨论】：

Storing Images in DB - Yea or Nay?的可能重复
请重新阅读FAQ，您的问题无法客观回答，您正在征求意见。
请求经验...很好，对吧？
@Mat CW 怎么了？而且我认为我的问题（包括关于不从数据库中为他们提供服务的部分）是完全不同的。哦，好吧。

标签： postgresql blob blobstore

【解决方案1】：

我有在 Oracle 和 MySQL 中以这种方式将图像存储在数据库中的经验。性能和可靠性不是问题。备份是。您的备份将变得非常大。由于备份既费时又昂贵，因此节省空间可能是个好主意。如果这意味着您可以通过从数据库中删除图像来将数据库缩小 80%，那么将它们存储在其他地方可能是个好主意。备份单独的文件效率更高，因为您可以轻松创建仅包含新的和修改过的图像的增量备份。

【讨论】：

【解决方案2】：

我有使用 PostgreSQL 的经验，将图像存储为 ByteA（类似 BLOB 的数据类型），体验很好，并将图像存储在“dual solution”（文件系统中的图像，MySQL 和 PostgreSQL 等数据库中的元数据）中，我不推荐。

有 3 个方面或架构考虑因素可以帮助我们做出决定：

是否统一解决方案？今天，当我们看到图像量（大小和图像数量）不断增长时，在所有应用程序中，“统一解决方案”就是目标。示例：Wikimedia 是 Wikipedia 的统一专用解决方案。
直接存储还是间接存储？ 像旧的“双重解决方案”，不将图像存储到 SQL 表中，一些解决方案可以使用外部数据库或外部数据指针......在 PostgreSQL BLOB 数据类型上具有间接存储（生成单独的备份），并且 BYTEA 数据类型是直接的（与表一起备份）。选择需要考虑技术和性能。
原始图像还是处理后的图像？我们需要区分“原始图像”和“处理后的图像”，例如缩略图，它们需要数据库存储（用于缓存！），但不需要备份。

我推荐：

在您的表中存储为 blob（具有间接存储的二进制大型对象）：用于原始图像存储，但单独备份。请参阅Ivan's answer、PostgreSQL additional supplied modules、How-tos 等。
存储为 bytea（或 blob），在单独的数据库中（使用DBlink）：用于原始图像存储，在另一个（统一）数据库。在这种情况下，我更喜欢 bytea，但 blob 几乎相同。分离数据库是“统一图像网络服务”的最佳方式。
在您的餐桌上存储为 bytea（直接存储的 BYTE 数组）：用于缓存处理后的图像（通常是缩略图）。缓存小图像以将其快速发送到网络浏览器（避免渲染问题）并减少服务器处理。缓存必要的元数据，如宽度和高度。数据库缓存是最简单的方法，但请检查您的需求和服务器配置（例如 Apache 模块）：store thumbnails at file system 可能会更好，比较性能。请记住，它是一个（统一的）Web 服务，然后可以存储在没有备份的单独数据库中，为许多表提供服务。另见PostgreSQL binary data types manual、tests with bytea column等。

【讨论】：

【解决方案3】：

我的经验仅限于 SQL 服务器，但我的数据库中有数百万个大于 10KB 的 PDF 文件，它的性能仍然非常好。当然索引是必需的。对于如此大量的数据，完整数据库备份所用的时间不会比预期的要长。同样，这是针对 MS-SQL 服务器的！

【讨论】：