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

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

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

平均行大小不能大于200k

我们预计三年内每月最多上传500份文件

我们不希望数据库的大小超过6GB

我们的最大目标是有20000人可能同时访问该系统

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

---

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

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

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

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

最终，仅使用数据库的解决方案可能会更简单，但我不会低估为数万用户存储大型文件可能带来的负载。

这不仅仅是一个“基本”系统。因此，以下是我立即关注的问题：

• 3年内每月500个文档的数据库大小可能会超过6GB。您可能需要确定最大文档大小，并查看该计算是否有效
• 20000个用户是很多。你一次能想到多少？如果并发用户超过100个，我将开始调查服务器集群/web场，以便能够处理负载
• 只是吹毛求疵，但您不会在.NET“可序列化”意义上进行“序列化”。您只需将原始文档字节存储在数据库中
• 如果您需要高可用性，您需要考虑将数据库复制到另一个数据库实例，以防数据库服务器停机

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

---

Mike

编程的一个重要部分是知道什么时候你处于超负荷状态。如果您发布的CTQ是真实的，特别是并发访问要求，那么您将受到伤害。即使是那些在战壕里呆了很长时间的人，也会因为这种要求而受到伤害。我会用以下心态来解决这个问题：

我将以我目前能想象到的更多方式弄错

知道了这一点，保持这种体系结构越简单，它就越有可能扩展。然而，我工作的公司规模绝对庞大，我甚至怀疑我们是否有真正拥有20000个并发用户的系统。所以不要咬得太多

将您的体系结构设计为简单而健壮（这是一个很高的要求），您会发现它会自然地扩展，直到您最终需要召集大人物

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

---

如果出于某种原因您只有SQL Server 2005，那么您将不得不处理

BLOB

s，这并不困难，但有点混乱。我建议您阅读Microsoft Research，以决定是否将数据存储在SQL Server 2005中是您的最佳选择。如果是这样的话，有很多文章详细介绍了如何将文件放入SQLServer

BLOB

s。请注意，这很少是最有效或可扩展的解决方案。

新手是如何成为“新手”的？您有一些相当严格的要求，以及相当适度的可扩展性要求。在反序列化数据库中的大blob（是的，在这种情况下，200K是大的）的同时处理可能20000个请求将需要认真的设计深思熟虑。嗨，John，谢谢。新手在这种情况下是“非常”。你说的“认真的设计前瞻”是什么意思？你能给我一个这种设计的例子吗？+1，但我要补充的是，Oracle 11和SQL Server都提供了文件“在”数据库中，但实际上位于文件服务器上的功能。也就是说，它们由DB管理。Oracle11甚至还提供了WebDAV对文件的访问，这非常简洁。我们一直在使用SecureFiles for Oracle 11，在处理超大文件（500mb+）方面取得了巨大成功。您好，Marcus。我们想完全取代那种体制。我们有过很多断开链接的例子，因为文档被从目录中删除，而路径没有从数据库中更新或删除。您好，SQL Server 2008是否提供了您描述的功能？我用的是2005年，我肯定不是。我们已经研究了升级到2008年的可能性。@aspNetAficionado-编辑了我的回复，将这些问题包括在内。你好，迈克，谢谢你的意见。你能解释一下“只是吹毛求疵，但你不会在.NE中“序列化”吗