.net – 当元数据在SQL数据库中时,存储/检索数百万个文件的最佳

>一旦生成文件,我将会运行其他一些步骤,并且会有一些服务器参与,因此我需要在生成文件时查看这些文件.
>生成后,通过我编写的查找过程,文件将可用.基本上,我需要根据订单号来提取它们,订单号对于每个文件都是唯一的.
>在任何时候,可以重新提交现有订单号,生成的文件将需要覆盖原始副本.

最初,我曾计划将这些文件全部写入NAS上的一个目录,但我意识到这可能不是一个好主意,因为有数百万个文件,Windows可能无法正常处理百万文件查找.我正在寻找一些建议：

>单个文件夹好吗？永远不会列出这些文件 – 它们只能使用我已经确定的文件名的System.IO.File来检索.
>如果我做了一个文件夹,我是否可以使用System.IO.DirectoryWatcher查看新文件,即使有那么多文件,还是会因为那么多文件而变得迟钝？
>它们应该作为BLOB存储在SQL Server数据库中吗？由于我需要通过参考值检索它们,这可能更有意义.

谢谢你的想法！

解决方法

文件是否会老化并被删除？如果是这样,sort和file是可删除的块.如果没有,我可以成为您的硬件供应商吗？

双方都存在在数据库中存储文件的争论.

>一方面,您获得了增强的安全性,因为从数据库中提取文件更加尴尬;另一方面,你的性能可能更差,因为从数据库中提取文件更加尴尬.
>在数据库中,您不必担心每个文件夹,扇区,NAS群集有多少文件 – 这就是数据库的问题,并且可能他们已经为此做了很好的实现.另一方面,管理/审查数据会更加困难,因为它在单个表格中是一个庞大的数据,而且,糟糕的是. (您可以根据上述业务逻辑对表进行分区,这样可以使删除或归档更容易执行.这可能是分区视图,因为表分区的分区限制为1000个.)
> SQL Server 2008具有FileStream数据类型;我不太了解它,可能值得研究.

最后一点需要担心的是保持数据“一致”.如果数据库将文件中的信息与路径/名称一起存储到文件中,并且文件被移动,则可能会完全被清除.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!