.NET文档管理系统设计-性能问题

Question

我需要开发一个具有以下规范的基本.NET文档管理系统：

1. 数据应该是可移植和自我包含的，所以我将把文档(典型的格式包括Word、PDF、Excel和Powerpoint)序列化为二进制数据。然后，我将将上述二进制数据存储在Server 2005数据库中。当用户需要下载文档时，系统将反序列化二进制数据并以原始格式呈现。
2. 平均行大小不能大于200 k。
3. 我们预计最多每月上载500份文件，为期三年。
4. 我们不希望数据库的大小超过6GB
5. 我们最大的目标是20,000人同时访问该系统。

我的问题是:技术需要有多强才能提供可靠的性能，防止站点停机等等？

我是一个新手开发人员，不熟悉这种架构和设计。

Answer 1

为什么需要将文件存储在数据库中，而不是仅仅将文档路径存储在文件服务器或CDN上？这将大大减少DB服务器上的负载，并为您提供更灵活的文档存储选项。

如果您对像我建议的系统中的移动/删除文件有问题，那么也可以考虑其他选项，例如：

• 将基础文件系统上的权限锁定给每个人，但应用程序正在运行的角色除外(最简单的选项)
• 运行后台服务，该服务侦听文件夹等的更改，并相应地更新数据库。

最后，只使用数据库的解决方案可能更简单，但我不会低估您通过为成千上万的用户存储大型文件而可能遇到的负载。

Answer 2

这不仅仅是一个“基本”系统。所以我马上要担心的是：

• 为期3年的每月500个文档似乎很可能超过6GB的数据库大小。您可能希望确定文档的最大大小，并查看该计算是否有效。
• 20,000用户是很多。你一次能指望多少人？如果超过100个并发用户，我将开始调查服务器集群/web场，以便能够处理负载。
• 只是一个nit选择，但您将不会在.NET“可序列化”的意义上“序列化”。您只需将原始文档字节存储在DB中
• 如果您需要高可用性，则需要查看到另一个DB实例的DB复制，以防DB服务器崩溃

最后。我必须相信，有些现成的系统可以做你想做的事情，而且还包括更高级的功能，比如基于权限的访问和文档修改。

麦克

Answer 3

编程的一个重要部分是知道什么时候你处于过度状态。如果您发布的CTQ是真实的，特别是并发访问要求，那么您将面临一个痛苦的世界。即使是那些在战壕里有相当长时间的人，也会因为这样的要求而受到伤害。我会用以下的心态来解决这个问题：

我会用我目前所能想象的更多的方式来理解这个错误。

知道得越多，就越容易保持这个架构，就越有可能扩展。然而，我为之工作的公司是绝对庞大的，我甚至怀疑我们是否有任何系统真正拥有20,000个并发用户。所以，不要咬的太多，你不能咀嚼。

将您的架构设计得简单而健壮(这是一个很高的要求)，您会发现它会自然而然地扩展，直到您最终需要调用大人物为止。

我可以建议您至少应该花钱访问Server 2008。使用该版本，您的问题对于初学者来说应该是相当基本的。对文件使用FILESTREAM存储。不需要序列化。这将将文件存储在NTFS文件系统上，并将最大限度地简化编程、维护和可伸缩性。

如果由于某种原因，您只能使用Server 2005，那么您将不得不处理BLOB，这并不是非常困难，但有点混乱。我建议您阅读Microsoft的去还是不去，以决定是否将数据存储在Server 2005中是最好的选择。如果是这样的话，有很多文章详细介绍了如何将文件放入Server的BLOB中。请注意，这很少是最有效或可伸缩的解决方案。