architecture - 构建文档管理系统的想法

Question

客户需要一个document managment system我正在构建有关此的信息。

我知道 sharepoint 和 alfresco，但在这种情况下，我正在评估从头开始构建它的必要信息，所以请不要建议使用其中任何一个(我们正在单独评估它们，这是所有关于开发，而不是实现现有解决方案)。

这是要求:

• 对我们地方政府特定文件的法律管理有非常具体的要求，但除此之外:
• 从最终用户的角度来看类似于 google docs 的操作
• 需要 200 多个最终用户的商店信息(更新:实际上是 700 多个最终用户)
• 主要是办公文档、pdf、文本。我已经从这个二进制文件中提取了纯文本。
• 没有 wiki，没有创建门户，几乎没有工作流程但非常简单，只是文件管理
• 中央存储库，在公司内共享，与 Active Directory 集成
• 快速搜索
• 透明的桌面集成
• 网络界面
• 多平台，如果可能的话

所以，这是我脑子里的事情:

• 存储:我知道 sharepoint 将所有内容保存在数据库中(Alfresco 也一样？)。那是一场噩梦，恕我直言。我更喜欢将元数据放在数据库中，将文件放在磁盘上。

我考虑在这种情况下强制使用 ZFS 并利用其功能进行版本控制、快照和缩放。或者可能使用 git 作为存储后端(git 可以正常工作吗？)

那么，我在哪里可以了解更多有关如何在 ZFS 或任何常规文件系统中处理大量文档的信息？例如，如何布局文件夹结构以方便管理和快速响应，便于备份等。

• 元数据:我认为这里是常规数据库，但想知道在 Lucene 中保存所有内容是否有更多优点(我对 Lucene 有一些经验，但担心因为 Lucene 无法联合，对吗？)。

如果我使用搜索引擎作为元数据数据库，我可以节省一些工作(不需要第二次通过索引)，但常规数据库引擎更标准。

• 技术人员:我可能会在 Django、PyLucene、Postgress 中构建它，并为 Windows 进行 shell 集成(我对此没有任何问题)。

我将感谢有关如何正确实现此解决方案的任何提示或信息。

Answer 1

我个人觉得“类似于 Google 文档”和“透明桌面集成”的要求有点模糊，恕我直言。但是从问题来看你更关心后端和文档存储，更关注使用更开源的堆栈(与 AD 集成)？

无论如何，我个人使用 KnowledgeTree作为我们的文档管理系统及其实现，所有文件都驻留在一个文件目录中，数据库将跟踪路径、相应的元数据、访问日志和版本控制信息。如果文档已更新，他们基本上会保留同一文件的多个版本 - 考虑到 Microsoft Office 文档大多是二进制文件(直到 2003 年)，我认为这是一个明智的实现明智的想法。

您可能想了解他们目前有多少文件，以及他们预计每天有多少文件流入该系统。 (或者从不同的角度来看，他们计划存储什么样的文档通常会给你提示你的服务器应该处理什么样的负载)

我的猜测是，除非您确定系统预计每天要处理大量文档(想象一下 Flickr用于文件 ;))。