我想了解以下设计的建议。这合理吗？这是愚蠢/疯了吗？
要求：
- 我们有一些分布式计算可以处理大小有时高达50Mb的数据块。
- 因为计算需要很长时间，所以我们希望在小网格（大约20个节点）上并行计算
- 我们每天“生产”大约10000个二进制数据的“块” - 并希望将它们保存长达一年......但大多数项目的大小不是50Mb，所以每日总量空间需求大约在5Gb左右...但是我们想尽可能长时间地保存一些东西（一年或更长时间）......但是，嘿，你现在可以得到2TB硬盘。
- 虽然我们想保留数据，但这本质上是一个“缓存”。如果我们丢失数据，这不是世界末日 - 只需重新计算，这需要一些时间（一两个小时）。
- 我们需要能够有效地获取在特定日期生成的所有“块”的列表。
- 从支持的角度来看，我们经常需要删除在特定日期创建的所有块或删除在过去一小时内创建的所有块。
- 我们是Windows商店 - 我们无法轻松切换到Linux /其他操作系统。
- 我们将SQLServer用于现有的数据库要求。
- 然而，它是一个庞大而合理的官僚公司，它有一些限制我们选择的政策：例如，使用SQLServer的传统数据库空间以极其昂贵的价格在内部收费。分配2 TB的SQL Server空间非常昂贵。这主要是因为我们的SQLServer实例已备份，存档7年等等。但我们不需要这种“镀金”功能，因为我们可以重新创建它丢失的东西。从本质上讲，它只是一个缓存，可以根据需要重新创建。
- 不允许在我们维护的机器上运行我们自己的SQLServer实例（所有SQLServer实例必须由一个单独的组管理）。
- 我们确实有相当小的交易要求：如果产生块的过程中途消失，我们希望能够检测到这种“失败”的交易。
我正在考虑以下解决方案，主要是因为它似乎很容易实现：
- 我们在Windows文件系统（NTFS）上运行Web服务器
- 客户端使用HTTP请求“保存”和“加载”文件，当进程需要相互发送blob时，它们只传递URL。
- 使用GUIDS分配文件名 - 但每个日期都有一个目录。因此，2010年11月12日创建的所有文件都将位于名为“20101112”的目录中。这样，通过获取日期的“目录”，我们可以使用正常的文件复制操作找到该日期生成的所有文件。
- 索引由传统的SQL Server表完成，其中包含“URL”列而不是“varbinary（max）”列。
- 为了保留事务要求，创建blob的进程仅在成功将文件上载到Web服务器后将相应的“索引”行插入SQL Server表。因此，如果它失败或中途崩溃，这样的文件“不存在”，因为用于查找它的相应行在SQL服务器表中不存在。
- 我喜欢这样一个事实：可以通过TCP套接字生成和使用大块数据。
总之，我们在SQL Server之上实现“blob”的方式与它们在内部实现的方式非常相似 - 但是在实际SQL服务器实例上不会占用太多实际空间。
所以我的问题是：
- 这听起来合理吗？这是疯了吗？
- 您认为在典型的Windows NT文件系统上运行的效果如何？ - （每个“日期”目录5000个文件，几百个目录，每天一个）。最终会有数十万个文件（但不会直接在任何一个特定目录下面）。我们是否会开始担心硬盘碎片等问题？
- 如果20个进程都是通过一个Web服务器尝试同时写入20个不同的“块”，那会不会开始颠倒磁盘呢？
- 哪种网络服务器最适合使用？它需要坚如磐石，在Windows上运行，能够处理大量并发用户。
正如您可能已经猜到的那样，除了公司限制之外，我可能会设置一个SQLServer实例，并且只有一个带有“varbinary（max）”列的表...但是考虑到这不是一个选项，那么效果如何你认为这会起作用吗？
这有点超出了我的通常范围所以我自由地承认我在这个部门有点像Noob。也许这是一个令人震惊的设计...但似乎很容易理解它是如何工作的，并且维护和支持它。