【问题标题】:MOSS 2007 as a large repository of PDF documentsMOSS 2007 作为 PDF 文档的大型存储库
【发布时间】:2011-05-03 13:08:04
【问题描述】:

实际上,我尝试研究基于 MOSS2007 构建 PDF 文档存储库的可能性。没有工作流程,只有大量文档和对文档库的访问(也可搜索)。

问题是构建这样一个解决方案的可行性,假设: - PDF 文档一旦投入文档库并由外部网络提供,最多可达到一百万(!);

农场是什么提议: - 1x 前端网络服务器 - 2x 索引服务器 - 1x 查询服务器 - 1 个 MS SQL 服务器 - 2x 12TB 存储

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

【问题讨论】:

  • 因为您的问题与编程无关,我建议您在这里提问:sharepoint.stackexchange.com
  • 如果这是一个新提案,你不能用 2010 代替 2007 吗?

标签: sharepoint sharepoint-2007


【解决方案1】:

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

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

更新和整合:

正如 Benjamin J Athawes 所指出的,内容大小也是一个需要考虑的重要因素。详情见他的回答。

nRouteNPingMe 考虑将 2010 年作为解决方案,因为这已在较新的版本中得到解决。如果你不拘泥于 2007 年,我会考虑走这条路。

【讨论】:

  • 这是不正确的。 SharePoint 列表可以包含数百万个项目。只要它们不显示在单个视图中。在这里查看我的答案:technet.microsoft.com/en-us/library/cc287790(office.12).aspx
  • 无论它们是否在单个视图中,如果您在具有 > 2000 篇文章(大约)的列表上运行 SPQuery,除非您细分为文件夹,否则性能将受到影响。我知道这将在 2010 年解决。
  • @Hugo,“可以”和“在合理的性能预期内”是两个非常不同的东西。没错,您可以将数百万个项目添加到列表中,但是在单个容器中包含 2000-3000 个项目时会遇到一些性能问题。
  • @Chris @routeNpingme 文件夹细分方法是解决真正接口问题的一种方法。将项目分成文件夹不会影响列表的物理结构 - 文件夹只是平面列表的虚拟抽象。但是,您可能会发现您的网站总体上正在变慢,因为用户试图加载 2000 多个 -item 视图并消耗所有资源。
  • 那么这里的最终答案是什么?我和@Hugo Migneron 有同样的想法,但如果@Chris Ballance 是微软的 SP 开发人员,那么我认为他是正确的......
【解决方案2】:

克里斯的回答并不完全正确。一个列表中可以有超过 2000 个项目,只要它们不是全部显示在一个视图中即可。

在文档库(存储 PDF 文档的地方)中,您最多可以拥有 500 万个项目。只要您找到与

所以问题是,您能否以对您有意义的方式分隔文档?如果是这样,我不会担心可扩展性。

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

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

【讨论】:

  • 文件夹结构是我知道的唯一解决方法,它还解决了 SPQuery 在大型列表上的限制。 500 万个项目的限制有点像神话,当您开始接近 50,000 个以上时,我会考虑将它们分成单独的站点集合。
【解决方案3】:

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

假设每个 PDF 的大小平均为 1MB,那么在上述关于 # 个项目/范围的限制之前,您将遇到内容数据库大小限制。

容量规划就是妥协 - 如果您想存储 100 万个文档,您需要考虑将文件拆分到多个内容数据库 - 从而跨多个网站集。

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

关于 FileStream(我假设您在这里指的是 RBS),如果没有经过非常仔细的考虑,我不会在生产场景中推荐它。我认为它主要是为了节省成本,并牢记它会给您的备份和灾难恢复策略增加很大的复杂性。

希望对您有所帮助。

【讨论】:

  • +1 很好的宣传。我的回答暗示了这一点,但应该像你一样直接解决。
【解决方案4】:

这里发生了几件事,没有人可以用您提供给我们的事实来回答您的所有问题。

首先,您建议的文档数量可以由单个文档库(或多个文档库)处理,只要您遵循上述关于将项目存储在文件夹中的建议即可。这很关键。

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

  • 有多少用户?
  • 如何并发?
  • 数据多久更改一次?
  • 物品是否有独特的安全要求?
  • 您将对数据执行哪些类型的搜索?
  • 等等……

最后,您提到您需要 2 个用于 MOSS2007 的索引服务器。虽然在 MOSS2007 中存在依赖多个索引框的场景,但它们并不像您想象的那样冗余。您更有可能拥有一个索引框和多个查询框(或同时也是查询服务器的 Web 服务器)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多