通过 BLOB 外部化优化 SharePoint 存储

由 和 SharePoint 专区 为您呈现

随着组织将 SharePoint 作为内容管理系统（支持文档管理、记录管理、协作和归档）的规模化使用，他们正在将传统上由文件共享和电子邮件附件支持的工作负载转移到 SharePoint。在此过程中，以文档为中心的内容的存储负担落在了 SharePoint 的数据层上——由 SQL Server 托管的内容数据库，并且通常位于企业中性能最高、最昂贵的 Tier 1 存储资源上。

结果包括显而易见的——存储成本飙升——和反直觉的——SharePoint 性能可能下降。组织正在努力为 SharePoint 构建一个优化的、可扩展的、经济高效的存储架构，以支持可能达到数 TB 或数十 TB (TBs) 的内容。

在 SharePoint 和 SQL 社区中，客户之间、专家和 MVP 之间，甚至微软内部，一直存在关于内容可扩展性、文档对存储容量和性能的影响以及 BLOB 外部化作用的争论，BLOB 外部化允许您将二进制大对象 (BLOB)——表示文档内容的非结构化数据——重新定位到更具成本效益的存储层。

2011 年 7 月，微软更新了 SharePoint 规模指南，支持协作工作负载中高达 4 TB 的内容数据库，以及用于文档归档的无限大小的内容数据库，这再次引发了争论。微软的新指南包含了深思熟虑的架构、高性能存储子系统、全面的治理以及 SharePoint 提供的功能之外的有效管理工具的指导，以支持性能、备份、恢复和可用性的服务级别协议 (SLA)。

本白皮书将阐明 BLOB 外部化相关的问题以及各种观点和指导。

我们将首先回顾 SharePoint 的默认配置——SharePoint 将文档内容作为 BLOB 存储在内容数据库中——并检查 BLOB 在文档整个生命周期中对存储层可能产生的令人惊讶的乘数效应。然后，我们将详细介绍微软为 BLOB 外部化提供的两种选项：外部 BLOB 存储 (EBS) 和远程 BLOB 存储 (RBS)。

白皮书的其余部分将详细探讨 BLOB 外部化的潜在好处，其中包括

• 降低存储成本
• 优化性能
• 改进存储管理和减少存储占用空间
• 高效的内容重构
• 更大的可扩展性

我们还将探讨 BLOB 外部化的潜在缺点：增加架构复杂性，特别是必须考虑备份、恢复、高可用性和灾难恢复。

本白皮书是由 SharePoint MVP 团队撰写的一系列存储优化和管理资源的第一篇。本白皮书的目标是全面而平衡地探讨概念和问题，并使您能够充分理解、与同事和管理层沟通，并就 BLOB 外部化在您的存储架构中的作用做出明智的决策。

基本原理

让我们首先检查 SharePoint 中文档存储的默认配置和选项。

文档、数据库和 BLOB

在大多数组织中，SharePoint 托管着无数文档：包括 Word、PowerPoint 和 Excel 文件在内的 Office 文件格式；PDF；图像、播客和视频等多媒体文件；以及地图、工程规范、扫描文档等其他文件。

用户将文档上传或保存到一个或多个网站集中的文档库，或将文档附加到列表项。默认情况下，这些文档存储在包含文档库或列表的网站集的内容数据库中。

在内容数据库中，文档或列表项的元数据存储在 AllUserData 表中。如果文档存储在库中或作为附件，SharePoint 会在 AllDocs 表中维护内部使用的文档元数据。文档内容以称为 BLOB 的非结构化数据格式存储在 AllDocStreams 表中。全局唯一标识符 (GUID) 用于链接这三个表中的记录。如果启用版本控制，文档历史版本的元数据存储在 AllDocVersions 表中，BLOB 的历史版本存储在 AllDocStreams 表中。

SQL Server 是一种数据库服务，针对结构化关系数据的性能进行了优化，其中记录大小小于 8 KB。微软将 BLOB 移动到单独的表中，以优化 SQL 和 SharePoint 的性能。虽然在打开或保存文档时会产生少量性能损失，因为 SQL 必须在访问文档二进制数据之前将 AllUserData 表与其他表连接起来，但依赖于高效 SQL Server 性能的无数其他进程将受益匪浅。因此，内容数据库表的拆分设计对 SharePoint 来说是一个净收益。

存储优化挑战

支持企业 SharePoint 服务的存储基础设施影响着众多利益相关者。存储架构师、数据库管理员、SharePoint 管理员、SharePoint 最终用户和组织管理层都不同程度地关注存储基础设施是否可用、可恢复、可扩展、可管理、具有成本效益，并能满足性能预期。

SharePoint 的开箱即用配置将所有内容都放置在 SQL Server 的内容数据库中。这带来了潜在的可扩展性问题。SQL Server 通常托管在 Tier 1 存储上——企业中最快、功能最丰富且最昂贵的存储层。如果所有容量负担都放在 SQL Server 上，那么随着企业内容管理使用规模的扩大而扩展 Tier 1 存储的成本可能令人望而却步。

问题会随着时间的推移而增加，因为随着时间的推移，典型的 SharePoint 部署将托管越来越多的内容，但其中大部分内容将是不活跃的。虽然总内容通常呈几何级增长，但活动内容的数量以较低的线性速度增长。结果是，昂贵的 Tier 1 存储被用作大量飙升内容的归档，而这些内容并未受益于 Tier 1 存储的性能或功能。

您可能会认为将内容移动到更便宜的存储层可能会损害性能。即使是这种情况，也有机会通过创建分层或分级存储架构来优化存储，其中不太重要或不太活跃的数据移动到更便宜的存储层，而更重要或更活跃的数据保留在 Tier 1 存储上。但是，正如您将在本白皮书后面看到的那样，在许多情况下可以降低存储成本并提高性能。

BLOB 外部化

SharePoint 和 SQL 社区中有人认为，SharePoint 不应该被设计成将文档作为 BLOB 存储在像 SQL Server 这样的结构化关系数据库中。事实上，SharePoint 1.0 版本（SharePoint Portal Server 2001）使用 Web 存储系统，而不是 SQL Server 来存储内容。从 SharePoint 2.0 版本（Windows SharePoint Services 和 SharePoint Portal Server 2003）开始，存储移至 SQL Server。

近年来，微软已在 SharePoint 和 SQL Server 中内置了选项，可以将 BLOB 从 SQL Server 移到其他存储层，同时在内容数据库中保留元数据并指向相关联的文档。

EBS 和 RBS

在 SharePoint 2007 Service Pack 1 (SP1) 中，微软引入了外部 BLOB 存储 (EBS)。在 SQL Server 2008 中，微软将远程 BLOB 存储 (RBS) 添加到 SQL Server。从非常高的层面来看，EBS 和 RBS 都执行相同的基本任务：它们使 SharePoint 能够将 BLOB 存储在 SQL Server 内容数据库之外。

EBS 是 SharePoint 产品的一部分，在 SharePoint 2007 Service Pack 1 及更高版本以及 SharePoint 2010 中均有提供。SharePoint 2007 仅支持使用 EBS 进行 BLOB 外部化。4

在 SharePoint 2010 中，BLOB 外部化支持使用 EBS 或 RBS。然而，EBS 已被弃用，并可能在 SharePoint 的未来版本中被移除，转而支持 RBS。

RBS 可通过下载 SQL Server 2008 R2 的功能包（网址：http://go.microsoft.com/fwlink/?LinkID=177388）获取。SharePoint 2010 需要此版本（或更高版本）的 RBS。RBS 的服务器组件可以安装在 SQL Server 2008 R2 或 SQL Server 2008 SP1 上。客户端组件安装在所有 SharePoint Web 前端 (WFE) 服务器上。

模块和提供程序

EBS 和 RBS 都需要额外的组件来管理 SharePoint 与非 SQL Server BLOB 存储位置（称为 BLOB 存储）之间的通信。EBS 使用插件框架，需要第三方模块来实现。RBS 公开了一组应用程序编程接口 (API)，开发人员和 ISV 可以基于此构建提供程序。提供程序是 RBS 和特定类型 BLOB 存储之间的接口。

微软创建了 FILESTREAM 提供程序，它随 RBS 安装文件免费提供。FILESTREAM 提供程序允许您将 BLOB 外部化到 SQL Server 的本地文件系统。这可以包括直连存储和 iSCSI 连接的 SAN 和 NAS 卷，前提是这些卷满足 SharePoint 的存储性能要求，即每 GB 存储至少 0.25 IOPS，且首次字节时间 (TTFB) 不超过 20 毫秒。

虽然业界许多人诟病 FILESTREAM 提供程序的性能，但经验表明其性能至少好于预期。一些 ISV 提供商的性能优于 FILESTREAM，一些则不如。例如，面向云存储平台的 RBS 提供商由于云存储本身的特性，速度可能会较慢。建议您在您的环境中测试 BLOB 外部化提供商，以识别性能差异，更重要的是，确定这些差异是否对整体 SharePoint 性能产生重大影响。

除了性能之外，许多组织转向 ISV 提供商是因为他们广泛支持各种存储平台、外部化业务规则、管理功能和维护。ISV 已经为远程服务器上的共享文件夹、云存储平台以及特定的 NAS 和 SAN 平台构建了 BLOB 存储提供商。ISV 存储解决方案提供了各种级别的基于规则的 BLOB 管理，因此组织可以指定外部化和不外部化的 BLOB 类型，从而创建分层存储管理平台。ISV 提供商的安装和配置通常比 FILESTREAM 提供商的体验好得多。维护任务通常是自动化的。ISV 提供商通常提供监控和报告功能。当然，这些功能是有成本的，也必须加以考虑。在本白皮书的后面，我们将讨论第三方 BLOB 外部化解决方案的功能。

功能对等

值得注意的是，BLOB 外部化对 SharePoint 的其余部分是透明的。SharePoint 将 BLOB 视为其内容存储库的一部分，无论内容物理位于何处。

因此，无论 BLOB 是存储在内容数据库中还是外部化，SharePoint 都会管理对内容的 SharePoint 权限。SharePoint 会继续索引内容。所有 SharePoint 文档管理功能，包括签出和版本控制，都将继续可用。当 BLOB 外部化时，SharePoint 的任何业务价值功能都不会改变。

迁移到 EBS 或 RBS

一般来说，您可以在 SharePoint 旅程的任何时候启用 EBS 或 RBS。同样，您可以随时修改管理哪些 BLOB 外部化的规则。您可以使用一些工具——RBS 的情况下是 Windows PowerShell——扫描内容数据库并将内容移到 BLOB 存储。

以下部分将探讨您在规划 SharePoint 优化存储基础设施时应考虑的相关因素——好处和注意事项。由于 EBS 和 RBS 在概念上提供相似的优点和挑战，我们将统称其为 BLOB 外部化解决方案。

优点

BLOB 外部化有可能在许多工作负载中带来显著效益。效益包括降低成本、优化性能、改进存储管理、减少存储占用空间、高效内容重构和更大可扩展性。

降低存储成本

与 SharePoint 存储优化相关的首要且最明显的考虑因素是成本，这直接与容量以及托管 SharePoint 内容的存储层相关。BLOB 对容量和成本的影响究竟有多大？答案可能会让您感到惊讶。

80% 估计

在典型的内容数据库中，文档——其元数据和包含其内容的 BLOB——往往占用大量空间。内容数据库被其存储的 BLOB 撑大。

通常，对于企业级部署的 SharePoint Foundation，多达 80% 的数据由作为 BLOB 数据存储的文件流数据组成。这些 BLOB 对象包含与 SharePoint 文件相关的数据。

http://msdn.microsoft.com/en-us/library/bb802976.aspx

然而，这个“80% 的估算”并未讲述全部故事。这个 80% 的估算未能阐明 BLOB 存储影响的规模。在典型的协作环境中，人们通常会发现一个文档不仅仅存储一次——单个文档所需的存储量远超您的预期——事实上，是文档大小的许多倍。

让我们检查一个文档及其 BLOB 存储在文档整个生命周期中的总影响。

文档和元数据存储

SharePoint 支持最大 2 GB 的文档（http://technet.microsoft.com/en-us/library/cc262787.aspx#ListLibrary），这是一个由 SQL Server 中使用的 32 位指针导致的软件限制。无法超过此限制并在内容数据库中存储更大的文档——无论是否进行 BLOB 外部化。

SharePoint 包含一个文件上传大小限制，可按每个 Web 应用程序配置。默认最大上传大小为 50 MB——远小于 2 GB 的硬性限制。这个较低的限制反映了实际考虑因素，包括网络性能、通过 HTTP 传输大型文件的性能以及用户对文件传输性能的期望。许多组织保留此默认上传大小或提高限制。如果您选择提高最大上传大小，请缓慢进行并在仔细测试后进行。

SharePoint 库中的每个文档都关联有元数据。某些元数据由用户配置，例如库中的列。其他元数据由 SharePoint 内部使用。与文档关联的元数据量主要取决于用户配置的元数据。

很容易理解，文档较大的场景会看到更高的 BLOB 与元数据存储比率，而文档较小且元数据较多的场景会看到较低的 BLOB 与元数据比率。80% 的估计是基于多个 SharePoint 环境的平均值。

但问题在于：一个文档很少（如果说有的话）只存储一次。

文档版本

当为文档库启用版本历史记录时，对文档或其元数据的任何更改都会导致额外的存储利用。在启用版本控制时，以下两点经常被误解，并对存储产生重大影响

1. SharePoint 内部不使用差分压缩。当保存新版本时，存储量代表文件的整个大小——而不仅仅是版本之间的差异或增量。从概念上讲，两个只有细微更改的文档版本将占用 2 x (文档大小 + 元数据) 的存储空间。

2. 如果文档或其元数据被修改，将创建一个新版本的文档。如果一个文档上传到库中后从未更改，但与该文档关联的元数据在一个月内更改了五次，则该文档占用的存储空间大约是 5 x (文档大小 + 元数据)。

启用版本控制时，文档对存储的影响将乘以该文档的版本数。因此，限制版本历史记录至关重要——无限版本保留可能导致数据库严重膨胀。

回收站内容

删除文档后，文档及其版本将根据 Web 应用程序的 SharePoint 回收站设置进行保留。用户可以从回收站恢复她删除的文档。

当用户清空回收站时，文档及其版本将继续保留，并且可以由网站集管理员从所谓的二级回收站恢复。

每个网站集都有一个回收站。但是，回收站有两个可配置的设置，这两个设置都作用于 Web 应用程序。这些设置适用于 Web 应用程序中的所有网站集回收站。

第一个回收站设置指定删除的文档将在回收站中保留的总天数。此设置从文档删除的那一刻起生效。无论文档是在用户回收站还是二级回收站中，都无关紧要。文档最初被用户删除 X 天后，它将从回收站中删除，并且文档将从内容数据库中移除。

第二个设置对二级回收站应用了存储配额。当项目移动到二级回收站时，它们会占用此配额。当配额达到时，二级回收站中最旧的项目将被移除，以便为新删除的项目腾出空间。配额配置为相对于网站集配额。因此，如果网站集受 50 GB 配额限制，并且二级回收站限制为配额的 50%，则该网站集的二级回收站实际上限制为 25 GB。

因此，文档对内容数据库的总存储影响必须考虑这样一个事实：在文档从二级回收站清除之前，文档（其 BLOB 和元数据）以及文档版本的 BLOB 和元数据将继续影响内容数据库。

审计

审计活动会在审计日志中生成条目。审计所需的存储量可能很大，特别是如果您正在审计查看活动。但是，审计条目大小和审计日志大小与文档大小无关，也与 BLOB 是存储在 SQL 中还是外部化无关。因此，虽然您在估算内容数据库的总存储需求时应考虑审计（http://technet.microsoft.com/en-us/library/cc298801.aspx#Section1），但我们不会在本白皮书中更深入地探讨审计。8

Office Web Apps 缓存

为了提高 SharePoint 在使用 Microsoft Word web app 和 Microsoft PowerPoint web app 时的性能，web app 会在名为 Office Web Apps 缓存的缓存中创建文档的渲染。当文档被渲染时，可以从缓存中提取。只有当文档在缓存中不存在，或者文档在缓存中创建渲染后发生更改时，文档才会重新渲染。计时器作业会在可配置的过期时间后从缓存中删除文档。

如果 Web 应用程序与 Microsoft Word 或 PowerPoint Web 应用程序关联，则一个内容数据库将包含 Web 应用程序中所有内容的缓存。在文档繁重的 Web 应用程序中，缓存可能会变得相当大。默认情况下，缓存上限为 100 GB。最佳实践是将 Office Web Apps 配置为在 SharePoint Web 应用程序中使用单独的专用内容数据库，并管理缓存大小以优化性能和存储。您可以在 http://technet.microsoft.com/en-us/library/ee837422.aspx 了解更多信息。

Office Web Apps 缓存的大小不取决于 BLOB 是存储在 SQL Server 中还是外部化。相反，它纯粹基于文档的数量和大小、对这些文档的访问频率以及管理员配置。因此，虽然 Office Web Apps 缓存应作为 Web 应用程序所需存储估算的一部分加以考虑，但如果它位于专用内容数据库中，则不会影响 Web 应用程序中其他内容数据库所需的存储。

服务数据库

文档间接影响服务应用程序所需的存储。例如，对文档的访问可能由 Web Analytics 服务应用程序跟踪。标记、评论和评级活动在用户配置文件服务应用程序的社交标记数据库中，每个条目大约消耗 9 KB。这些数据相对可以忽略不计，既不取决于文档的 BLOB 是存储在 SQL Server 中还是外部化，也不直接取决于文档的大小。

然而，搜索服务应用程序直接受文档数量和大小的影响。爬网数据库、属性数据库和索引分区都与文档的数量和大小有直接关系。搜索容量规划既是一门科学也是一门艺术，但典型实现的非常粗略的估算大约是索引内容（语料库）总大小的 20%。9

因此，如果您正在索引 1 TB 的典型内容，您可以预期搜索相关数据库和索引将占用大约 200 GB 的存储空间。有关更多信息，请参阅 http://technet.microsoft.com/en-us/library/gg750251.aspx。

搜索和其他服务数据库的大小不取决于 BLOB 是存储在 SQL Server 中还是外部化。

事务日志

SQL Server 在将事务提交到数据库的数据部分之前，会将所有活动记录到数据库的事务日志中。事务日志会增长，直到进行日志备份，此时日志占用的空间会被清除，但文件大小不会缩小。您可以手动收缩 SharePoint 事务日志，如果事务日志失控增长，这可能会有所帮助，但最佳实践是通过管理事务日志备份来管理事务日志大小。

当文档上传或修改时，文档 BLOB 和元数据首先写入事务日志。然后，事务提交到内容数据库本身的相应表中。因此，文档对总内容数据库大小（包括事务日志）的真实影响可以近似为在日志备份之间的时间窗口内，文档大小 x (创建 + 修改) x 2。

事务日志大小与 BLOB 存储直接相关。如果 BLOB 被外部化，并且不存储在内容数据库中，那么 BLOB 也不会写入 SQL Server 事务日志。

BLOB 外部化、容量和成本

如您所见，仅一个文档所需的存储空间可能会因版本保留、文档或其关联元数据的修改、Web 应用程序设置（例如回收站）、审计设置、Office Web Apps 和其他服务应用程序的使用，甚至备份策略而大相径庭。在典型的、高度协作的场景中，一个活动文档可能消耗的存储空间是文档实际大小的许多倍。

从硬成本和总成本的角度来看，内容数据库内部的 BLOB 存储可能很昂贵。许多组织传统上将业务协作文档存储在文件服务器上，与为 SharePoint 支持 SQL Server 而分配的典型高 IOPS、一级存储相比，文件服务器相对便宜。将此类内容移动到 SharePoint 并进入一级存储——特别是考虑到文档可能需要其大小的许多倍才能在文档的整个生命周期中支持 SharePoint 的业务和内部功能——可能是一项代价高昂的提议。10

BLOB 外部化本身并不能减少 SharePoint 基础设施的总存储占用空间，除了减少对事务日志的影响。但它确实使您能够将存储负担转移到更具成本效益的层级。成本节省是巨大的。一些组织报告每年通过专注于 BLOB 外部化的存储优化工作节省数千万美元。一些存储平台具有与 BLOB 外部化相结合的功能，可以减少 SharePoint 的总存储占用空间。这些功能将在本白皮书的后面讨论。

优化性能

为了降低存储成本，似乎所有 BLOB 都应该移动到更便宜的存储层。但您还必须考虑 BLOB 外部化对 SharePoint 性能的影响。

例如，如果您使用第三方提供商将 BLOB 外部化到云存储平台，例如 Amazon 或 Azure，那么读取和写入文档的速度自然会比本地 SQL Server 存储慢。

有趣的是，并非所有 BLOB 外部化都会降低性能。事实上，在某些场景和配置下，通过 BLOB 外部化可以提高性能。

问题是：BLOB 外部化在哪个点能提高 SharePoint 的性能，又在哪个点会降低性能？

这些问题的答案需要仔细检查两个与性能相关的问题

• 单个文档的读写访问性能
• 在实际场景中，整个 SharePoint 服务（跨内容数据库中的所有网站集和 SQL Server 中托管的所有内容）的性能

SharePoint 社区中的大多数文档只关注第一个问题，这不幸地模糊了决策，并导致了在典型的实际生产环境中牺牲性能的设计。

在以下各节中，我们将探讨性能的这两个方面。但是，至关重要的是要记住，了解 SharePoint 在您的企业中启用或不启用 BLOB 外部化时的实际性能的唯一方法是使用真实且代表您环境的工作负载进行测试。

此外，您必须考虑性能下降是否能被用户察觉，以及即使性能降低，SharePoint 是否仍能满足用户的期望和性能 SLA。最后，您必须考虑您正在支持的每个场景或工作负载。用户可能认为访问归档记录比访问他们正在积极协作的文档慢是可以接受的。11

单个文档的访问性能

SharePoint 的开箱即用配置将 BLOB 存储在 SharePoint 内容数据库中。这可以在某些场景中提供最佳性能。

• Tier 1 存储性能 – 许多组织将高性能的 Tier 1 存储子系统专用于 SQL Server。SQL Server 存储平台的性能直接影响 SharePoint 性能。从高性能 SAN 访问的文档将比 BLOB 外部化到公共云存储的文档性能更好。
• 小文件 – 当从内容数据库中读取或写入小文档时，该单个活动的性能通常是最佳的。
• 频繁读取的文件 – 当小文档定期进行读取访问时，SQL 缓存可以进一步提高对该文档的访问性能。最近访问的缓存文档可以从内存中检索，而不是从磁盘中检索。

SharePoint 达到了一个交叉点，在该点之后，当 BLOB 针对特定工作负载外部化时，性能会更好。

单个小文档的读写速度在存储于 SQL 中时可能更快。当文档由于 SQL 缓存而驻留在内存中时，读取性能可以进一步提高。但是，随着文件大小的增加或访问频率的降低，通过将 BLOB 存储在更适合文件存储的平台上可以提高性能。

写入性能比读取性能更快地达到交叉点，因为 BLOB 必须写入两次——首先写入事务日志，然后提交到数据库表。新文档或修改后的文档也没有缓存优势。因此，随着文档大小的增加，写入文档 BLOB 一次（更不用说两次）的性能损失会降低存储在内容数据库中的文档的性能。

幸运的是，RBS 允许您指定一个文件大小阈值，超过该阈值的文档 BLOB 将被外部化，低于该阈值的 BLOB 将存储在内容数据库中。EBS 解决方案以及自定义或第三方 RBS 解决方案可以使用其他规则（例如文件类型）来确定是否外部化 BLOB。

目前还没有一个公式可以确定 BLOB 外部化时性能会提高的文件大小阈值。性能方程中有太多因素，包括文档的特性和访问模式，以及底层存储平台的性能特性。

我们的测试表明，大于 1 MB 的 BLOB 在外部化时通常表现更好——假设 BLOB 存储本身表现良好——而小于 256 KB 的非常小的文件通常在存储在内容数据库中时表现更好。

我们的发现与顾问的普遍共识一致，即大于 512 KB 或 1 MB 的文档应该外部化，此时在底层存储平台性能相似的情况下，读写性能都得到改善；而访问小于 256 KB 的文档时，BLOB 存储在 SQL Server 内容数据库中会更快。

介于 256KB 和 512KB 或 1MB 之间是交叉点，它很大程度上取决于大小和访问模式。例如，一个 512KB 的文件，如果经常进行读取访问，可能会受益于 SQL 缓存，因此在存储在内容数据库中时表现更好。相同的文件，如果被归档并且很少进行修改访问，那么在外部化时可能会表现更好。写入密集型访问模式通过外部化 BLOB 获得的改进比读取密集型访问模式更大。

性能也高度依赖于您使用的具体 EBS 或 RBS 解决方案，以及 BLOB 存储的特性——底层存储子系统的性能。例如，SAN 上的 BLOB 存储将比公共云中托管的 BLOB 存储性能更好。

文件访问性能提高的阈值取决于多种因素，应使用您的 EBS 或 RBS 存储解决方案以及反映您环境中预期工作负载的内容和访问模式进行测试。

内容数据库、SQL Server 和 SharePoint 场的性能

我们认为，如果您的生产 SharePoint 环境仅由一个用户访问一个文档，那么过度纠结于讨论或测试单个 BLOB 访问的性能阈值是没有帮助的。在真实的 SharePoint 环境中，多个用户同时访问文档、列表、页面、工作流、服务和应用程序。因此，更重要的是您要使用适当且复杂的、能够代表日常使用的工作负载来测试 SharePoint 环境。

随着多个用户访问 SharePoint，BLOB 对 SQL Server 的影响会加剧，内容数据库中的 BLOB 存储可能会显著影响整个内容数据库、运行 SQL Server 的服务器以及随后的 SharePoint 场的性能。

如前所述，SQL Server 是一种数据库服务，针对结构化数据的性能进行了优化。当您将非结构化数据作为 BLOB 存储时，SQL Server 需要更努力地保存和检索数据。SQL Server 根本没有针对文件服务器进行优化。

由于 BLOB 导致的性能下降在 SQL Server 和 SharePoint 之外也适用。一位客户报告称，他们有一个基于 Oracle 构建的定制工程应用程序。当他们使用 Oracle 中的功能从数据库中删除 BLOB 时，性能飙升。

在真实世界的 SharePoint 环境中，当用户访问文档，而其他用户访问页面或列表视图时，可以看到 BLOB 存储在 SQL Server 中的更广泛的性能影响。

如果内容数据库拥有大量的 BLOB（例如，一个文档库拥有许多文件），并且有相当水平的涉及 BLOB 访问的活动，那么所有其他性能都会下降——例如，列表视图的性能会变慢。当一些用户加载和存储 BLOB 时，CPU 和内存利用率会飙升，并且存储在 SQL Server 上的所有内容数据库中其他用户的性能都会受到影响。由于 SQL Server 是请求管道中最常见的瓶颈，SharePoint 性能会受到影响。

我们观察到，BLOB 的存在本身就可以明显降低内容访问的性能，即使您正在测量的内容访问与文档或 BLOB 无关。这部分是由于 SharePoint 和 SQL 服务以及管理员在后台执行操作——包括数据库索引、搜索索引以及数据库备份等管理操作——这些操作涉及 BLOB 访问。

当您从内容数据库中外部化 BLOB 时，内容数据库和 SQL Server 的性能——其 CPU 和内存利用率——可以得到改善。这意味着列表视图以及其他日常用户和维护活动（即使那些与 BLOB 本身无关的活动）的性能可以显著加快。

因此，虽然讨论单个 512 KB 或 1 MB 的文档是否应该外部化以提高该文档的访问性能很有趣，但我们的经验是，这种讨论会分散对更复杂环境中 BLOB（即使是小的 BLOB）更重大影响的注意力。

微软报告称，通过外部化 BLOB，在反映真实协作环境的混合用户工作负载中，性能提高了 25%。微软的发现总结在下表中。SQL BLOB	RBS	增益
数据库大小 - 1 TB	2292 GB	26 GB	98.9%
数据库备份大小 - 100 GB	217 GB	7 GB	96.8%
数据库备份时间 - 217 GB	2490 秒	38 秒	98.5%
数据库碎片整理时间 - 100 GB	120 秒	4 秒	96.7%
平均 SharePoint 响应时间	28 毫秒	21 毫秒	25.0%
大文件上传 - 500 MB	55 秒	29 秒	47.6%