2

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

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

  2. 平均行大小不能大于 200k。

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

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

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

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

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

4

3 回答 3

5

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

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

  • 将底层文件系统的权限锁定给除运行应用程序的角色之外的所有人（最简单的选项）
  • 运行一个后台服务来监听文件夹等的变化并相应地更新数据库

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

于 2009-12-02T22:54:17.923 回答
5

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

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

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

麦克风

于 2009-12-02T23:01:49.547 回答
0

编程的一个重要部分是知道你什么时候陷入困境。如果您发布的 CTQ 是真实的，特别是并发访问要求，那么您将陷入痛苦的世界。即使是我们这些在战壕里待了很长时间的人，也会因为这种要求而陷入痛苦的世界。我会以以下心态解决这个问题：

我将以我目前可以想象的更多方式来解决这个问题。

知道了这么多，你保持这个架构越简单，它就越有可能扩展。但是，我工作的公司绝对是庞大的，我什至怀疑我们是否有任何真正拥有 20,000 个并发用户的系统。所以不要咬得比你能咀嚼的多。

将您的架构设计为简单而健壮（要求很高），您会发现它会自然扩展，直到您最终需要召集大炮。

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

如果您出于某种原因只有 SQL Server 2005，那么您将不得不处理BLOBs，这并不难，但有些混乱。我建议您阅读Microsoft Research 的To BLOB or Not to BLOB来决定是否将数据存储在 SQL Server 2005 中是最适合您的选择。如果是这样，有很多文章详细介绍了如何将文件放入 SQL ServerBLOB中。请注意，这很少是最有效或可扩展的解决方案。

于 2009-12-02T23:22:31.993 回答