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

前端之家收集整理的这篇文章主要介绍了.net – 当元数据在SQL数据库中时,存储/检索数百万个文件的最佳方法前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个流程,最初将生成3-4百万个PDF文件,并以80K /天的速度继续.它们每个都很小(50K),但我担心的是如何管理我生成文件总量以便于查找.一些细节:

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

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

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

谢谢你的想法!

解决方法

我将文件分组到特定的子文件夹中,并尝试以某种业务逻辑方式组织它们(子文件夹).也许在某一天制作的所有文件?在每天的六个小时期间?或者每个#文件,我会说最多1000个. (那里可能有一个理想的数字,希望有人会发布它.)

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

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

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

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

原文链接:https://www.f2er.com/mssql/79062.html

猜你在找的MsSQL相关文章