将 Sitecore 媒体库资源存储在文件系统与存储在数据库中的比较

引言

Sitecore（默认行为）将内容树中“媒体库”文件夹内的所有资源存储在数据库中。通过进行一些简单的配置更改，我们可以改变它，将资源存储在文件系统中。

我们将了解如何实现这一点。我们将通过检查各自的优点和缺点来比较这两种方法（文件系统存储和数据库存储），并尝试确定哪种方法适用于哪种场景。

背景

首先，让我们看看 Sitecore 在数据库中存储媒体资源的位置。登录到存在 Sitecore 数据库的数据库服务器。打开 Master DB，有一个 **Blobs 表**。该表将存储所有媒体库资源。

此表有 6 列，其中 2 列需要注意，即 **BlobId 和 Data**。`BlobId` 列包含一个 `GUID`，用于唯一标识一个 blob。Data 列包含 blob 的二进制数据。

因此，当我们上传媒体库中的资源时，Sitecore 会创建一个带有 `media` 字段的媒体项。Sitecore 将实际资源存储在 `blob` 表中，并从该表中获取 `BlobId` 字段值，然后将其放入媒体项的媒体字段中。通过这种方式，Sitecore 将 blob 存储与内容存储分离开来。如果用户需要，Sitecore 可以利用这一概念将媒体存储在文件系统中，而不是存储在数据库中。

如何将媒体资源存储在文件系统中？

Sitecore 将所有媒体库资源存储在数据库中。这是因为 Sitecore 网站的 _web.config_ 文件中存在以下可配置设置。

<!--  UPLOAD AS FILES
            Controls whether Sitecore stores media as files or as database records by default.
            This setting is ignored if the Media.DisableFileMedia setting is true.
            Default: false
-->
<setting name="Media.UploadAsFiles" value="false"/>

要使 Sitecore 将媒体资源存储在文件系统中而不是数据库中，我们需要将上述设置的值更新为 `true`。请参阅下文。

<setting name="Media.UploadAsFiles" value="true"/>

现在，Sitecore 将开始在文件系统中存储资源。默认情况下，它将它们存储在路径“*/App_Data/MediaFiles*”下。Sitecore 也有一个用于更改此设置的可配置设置。请参阅下文。

<!--  MEDIA - FILE FOLDER
            The folder under which media files are stored by the system.
            Default value: /App_Data/MediaFiles
            It should be different from MediaFolder setting
 -->
 <setting name="Media.FileFolder" value="/App_Data/MediaFiles"/>

我们可以更改上述设置的值，将 blob 存储在文件系统中的任何位置。

数据库存储媒体资源 VS 文件系统存储

那么，我们应该何时使用文件系统存储媒体资源而不是默认的数据库存储？让我们比较一下，以便弄清楚。

数据库存储	文件系统存储
优点 它很**方便**，因为树中的所有 Sitecore 项都已经存储在数据库中。这符合 Sitecore 的构建标准。 **没有额外的依赖**（除了数据库本身）即可在移动或同步站点环境（例如，内容管理、内容交付、QA、开发）时处理文件。	优点 数据库**更精简**，因为它们不包含任何二进制媒体数据。 允许通过自定义编码将**文件推送到 CDN**（如 Akamai、Limelight）。 如果您可以访问文件系统（例如开发人员），您可以**直接在文件系统上更改资源**。
缺点 在数据库中存储**大型二进制文件**（尤其是大于 1 MB 的文件）会导致检索速度变慢，因此会**带来性能开销**。有一篇非常古老的（2006 年）微软研究论文指出，“小于 **256K** 的对象最好存储在数据库中，而大于 **1M** 的对象最好存储在文件系统中”。您可以在此处阅读。文章，比较了 SQL Server 中的 Filestream 数据类型（SQL Server 将存储在文件系统中）与 Varbinary 数据类型（默认，存储在数据库中）。 这可能会导致**数据库膨胀**，使其**过大**并由于过多的索引而导致性能问题。例如，假设我们要在 Sitecore 数据库中存储 10000 个产品的图像，每个产品有 4 张图像，每张图像的平均大小为 200 KB（考虑到如今我们处理的是高分辨率图像）。此计算结果为 10000 * 4 * 200 KB = 8 GB。如果我们也存储视频，大小会增加更多。每次我们**备份**这些数据库并**恢复**它们时，都会花费**大量时间**。	缺点 当 Sitecore 创建物理媒体文件时，它会将媒体项的 GUID 添加到文件名中，因此**更改媒体库中的资源将导致文件系统上出现一个额外的文件**。 **同步环境**要困难得多，因为需要同步文件系统上的实际文件夹（例如，2 个内容交付服务器）——可以使用同步工具或暂存模块来帮助解决此问题。

学习

考虑到上述两种方法的利弊，可以说，通过将资源存储在文件系统中带来的性能提升，可以忽略因存储在数据库中而可能丢失的 CMS 提供的功能（安全性、项目工作流、发布）。

因此，如果图像的总数较少，并且大型图像（大于 1 MB）的数量也较少，那么应考虑将资源存储在数据库中以方便起见，否则我们应该考虑文件系统方案。

历史

• 2016 年 2 月 15 日：提示的第一个/草稿版本