MOSS 2007作为PDF文档的大型存储库

Question

实际上，我尝试检查基于MOSS2007构建PDF文档存储库的可能性。没有工作流程，只有大量的文档和文档库的访问权限（也可以搜索）。

问题是建立这样一个解决方案的可行性，假设： - 一旦投入文档库并由外部网络提供，PDF文档最多可达一百万（！）;

农场是建议的： - 1x前端Web服务器 - 2x索引服务器 - 1x查询服务器 - 1x MS SQL Server - 2x 12TB存储

是否有可能提供如此大量文件的合理性能？ 有没有人不得不处理数字图书馆类似解决方案的建立？

Answer 1

如果在一个列表中放入超过2000个项目，则会遇到性能问题。解决此问题的一种策略是将文件夹用作存储桶，每个存储区限制为2000个项目。

考虑分成几个网站集也是明智的，这样所有这些文档都不在一个SQL数据库中。

更新和整合：

正如 Benjamin J Athawes 所指出的，内容大小调整也是一个需要考虑的重要因素。有关详细信息，请参阅他的回答。

nRouteNPingMe 提出考虑将2010作为解决方案，因为这已在较新版本中得到解决。如果你不喜欢2007年，我会考虑走这条路。

Answer 2

克里斯的回答并不完全正确。您可以在列表中包含超过2000个项目，只要它们不会全部显示在单个视图中。

在文档库（存储PDF文档的位置）中，最多可以包含500万个项目。只要您找到适用于＆lt;的文件夹结构/视图。 2000项/视图约束。

所以问题是，你能否以对你有意义的方式分离你的文件？如果是这样，我不担心可扩展性。

我在这里提到的数字都来自this technet article。

TL; DR版本：http://www.sharepointkings.com/2009/01/limitation-and-upper-boundaries-of_28.html

Answer 3

到目前为止，我还没有看到的是文件大小。

假设每个PDF的平均大小为1MB，那么在围绕＃items / scope的上述限制之前，您将遇到内容数据库大小限制。

容量规划完全是为了妥协 - 如果您想存储100万个文档，则需要考虑将文件分割到多个内容数据库 - 因此需要多个网站集。

虽然在某些边缘情况下，Microsoft支持SharePoint 2010中每个数据库最多1TB的内容（对于静态存储库），但我不知道SharePoint 2007的类似支持方案。

关于FileStream（我假设你在这里指的是RBS），我不会在没有仔细考虑的情况下在生产场景中推荐它。我认为它主要是为了节省成本，并且要记住它会给备份和灾难恢复策略带来很大的复杂性。

希望有所帮助。

Answer 4

这里有几件事情，没有人可以用你给我们的事实回答你所有的问题。

首先，只要您遵循上面有关在文件夹中存储项目的建议，您建议的文档数量就可以由单个文档库（或多个文档库）处理。这很关键。

我们无法告诉您的是您是否有足够的硬件。当然，很容易知道你是否有足够的存储空间，但获得适当数量的SP硬件取决于你的使用案例和其他因素：

• 有多少用户？
• 如何并发？
• 数据有多久会发生变化？
• 这些项目是否有独特的安全要求？
• 您将对数据进行哪些搜索？
• 等......

最后，您提到要为MOSS2007提供2个索引服务器。虽然MOSS2007中存在依赖于多个索引框的情况，但它们并不像您想象的那样多余。您更有可能拥有一个索引框和多个查询框（或者也是查询服务器的Web服务器）。