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

Question

我需要开发一个基本的.NET文档管理系统，其中包含以下规范：

1. 数据应该是可移植的并且是自包含的，因此我将文档（典型格式包括Word，PDF，Excel和Powerpoint）序列化为二进制数据。然后，我将所述二进制数据存储在SQL Server 2005数据库中。当用户需要下载文档时，系统将反序列化二进制数据并以原始格式显示。

2. 平均行数不能超过200k。

3. 我们预计每月最多可上传500份文件，为期三年。

4. 我们预计数据库的大小不会超过6 GB

5. 我们的最大目标是20,000人，可能会同时访问系统。

我的问题是：为了提供可靠的性能，防止网站停机等，该技术需要多强大？

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

Answer 1

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

如果你在我建议的系统中遇到移动/删除文件的问题，那么也许还要考虑其他选项，例如：

• 将基础文件系统的权限锁定到除运行应用程序的角色之外的所有人（最简单的选项）
• 运行后台服务，该服务侦听文件夹等的更改并相应地更新数据库

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

Answer 2

这不仅仅是一个“基本”系统。所以这就是我的担忧：

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

最后。我必须相信有现成的系统能够满足您的需求，并且还包括更多高级功能，如基于权限的访问和文档修订。

麦克

Answer 3

编程的一个重要部分就是知道什么时候你在脑海中。如果您发布的CTQ是真实的，特别是并发访问要求，那么您将面临一个受伤的世界。即使我们这些在战壕中有相当多时间的人也会因为这种要求而处于一个受伤的世界。我用以下思维方式解决问题：

  

我会以更多我目前想象的方式弄错。

了解这一点，保持这种架构越简单，就越有可能进行扩展。但是，我工作的公司绝对是庞大的，我甚至怀疑我们有任何真正拥有20,000个并发用户的系统。所以不要咬你的东西，也不要咀嚼。

将您的架构设计为简单而强大（一个很高的订单），您会发现它会自然扩展，直到您最终需要调用大枪。

我可以建议你至少应该花钱访问SQL Server 2008.对于那个版本，你的问题对于初学者来说应该是相当基本的。使用FILESTREAM存储空间存储文件。不需要序列化。这将把文件存储在NTFS文件系统上，并最大限度地提高编程，维护和可扩展性。

如果由于某些原因只有SQL Server 2005，那么你将不得不处理BLOB这不是很难，但有些混乱。我建议您阅读Microsoft Research的{​​{3}}，以确定将数据存储在SQL Server 2005中是最好的选择。如果是这样，有很多文章详细说明了如何将文件放入SQL Server BLOB。请注意，这很少是最有效或可扩展的解决方案。