Hol*_*roe 11 architecture ntfs
我可能会参与一个项目,其中一个重要组件是大量文件的存储(在这种情况下是图像,但它应该只是作为文件存储).
传入文件的数量预计约为每周500,000(平均每个约100 Kb),每天大约100,000个文件,每秒5个.在达到平衡状态之前,文件总数预计将达到数千万,其中文件因输入速率的各种原因而过期.
所以我需要一个系统,可以在高峰时间每秒存储大约5个文件,同时读取大约4个文件并随时删除4个文件.
我最初的想法是,一个简单的NTFS文件系统,其中包含一个简单的存储,过期和读取服务应该足够了.我可以想象服务创建每年,每月,每天和每小时的子文件夹,以保持每个文件夹的文件数量最少,并允许手动过期以防需要.
这里讨论了一个大型的NTFS解决方案,但我仍然可以使用一些建议来解决在构建具有上述规范的存储时会遇到的问题,期望的维护问题以及存在哪些替代方案.优选地,如果可能且实用的话,我想避免分布式存储.
编辑
感谢所有的意见和建议.关于该项目的更多奖励信息:
这不是最终用户提供图像的Web应用程序.没有透露太多,因为这是在合同阶段,它更多的是质量控制类别.想想带有传送带和传感器的生产工厂.这不是传统的质量控制,因为产品的价值完全取决于图像和元数据数据库的顺利运行.
自治应用程序以先进先出的顺序访问图像99%,但也会发生用户应用程序的随机访问.超过一天的图像将主要用于存档目的,但这一目的也非常重要.
由于各种原因,图像的到期遵循复杂的规则,但在某些日期,应删除所有图像.删除规则遵循依赖于元数据和用户交互的业务逻辑.
每天都会有停机时间,可以进行维护.
优选地,文件存储器不必将图像位置传送回元数据服务器.如果选择某种散列或分布式系统,则可以通过映射数据库从元数据中唯一地扣除图像位置.
所以我的问题是:
以下是基于以下假设的实施和可能问题的一些随机想法:平均图像大小为100kb,稳态为50M(5GB)图像.这也假设用户不会直接访问文件存储,而是通过软件或网站进行访问:
存储介质:您提供的图像大小相当于相当微不足道的读写速度,我认为最常见的硬盘驱动器不会出现这种吞吐量问题.不过,我会将它们置于RAID1配置中以保证数据安全.备份似乎不是太大的问题,因为它只有5GB的数据.
文件存储:为了防止目录中的最大文件出现问题,我会采用哈希值(MD5最小值,这可能是最快的,但可能是大多数冲突.在人们叽叽喳喳地说MD5被破坏之前,这是用于识别,攻击者可以填充图像以进行第二次原像攻击,并用goatse替换所有图像,但我们会认为这不太可能),并将其转换为十六进制字符串.然后,当需要将文件存储在文件系统中时,以2个字符的块为单位取十六进制字符串,并根据该字符串为该文件创建目录结构.例如,如果文件散列到abcdef,则根目录将ab位于该目录cd下,在该目录下,您将存储名称为的图像abcdef.真实姓名将保存在其他地方(如下所述).
使用此方法,如果您从目录中的太多文件开始达到文件系统限制(或性能问题),则可以让文件存储部件创建另一级目录.您还可以使用元数据存储创建文件的目录级别,因此,如果稍后展开,则不会在较新的较深目录中查找旧文件.
这里的另一个好处是:如果您遇到传输速度问题或一般文件系统问题,您可以轻松地将启动文件拆分到其他驱动器.只需更改软件即可将顶级目录保存在不同的驱动器上.因此,如果您想将存储分成两半,一个驱动器上的00-7F,另一个驱动器上的80-FF.
Hashing还可以为您提供单实例存储,这可能很不错.由于正常文件群的散列往往是随机的,因此这也应该使您在所有目录中均匀分布文件.
元数据存储:虽然50M行看起来很多,但大多数DBMS都是为了嘲笑那些记录,当然还有足够的RAM.以下是基于SQL Server编写的,但我确信其中大部分都适用于其他人.创建一个表,其中包含文件的哈希作为主键,以及诸如大小,格式和嵌套级别之类的内容.然后用一个人工密钥创建另一个表(一个int标识列就可以了),还有文件的原始名称(varchar(255)或其他),并将散列作为返回第一个表的外键,以及文件名列上的索引添加日期.还要添加您需要确定文件是否已过期的任何其他列.如果您有人试图以不同的名称放置相同的文件(但在其他方面相同,因为它们散列相同),这将允许您存储原始名称.
维护:这应该是计划任务.让Windows担心您的任务何时运行,而不是调试和出错(如果您每天晚上2:30进行维护,那么您可以在某个地方观察夏令时/夏令时.2:30 AM不会发生在春季转换期间).然后,此服务将对数据库运行查询以确定哪些文件已过期(基于每个文件名存储的数据,因此它知道指向存储文件的所有引用何时过期.任何未引用的散列文件不再需要文件名表中的至少一行.然后该服务将删除这些文件.
我认为主要部分是关于它的.
编辑:我的评论太长了,将其转移到编辑中:
哎呀,我的错,这就是我厌倦了数学所得到的.在这种情况下,如果您想避免添加RAID级别(51或61,例如跨条带集镜像)的额外冗余,则散列将为您提供将5个1TB驱动器插入服务器的好处,然后具有文件存储软件通过像2中结尾提到的哈希来跨越驱动器.您甚至可以RAID1驱动器以增加安全性.
备份会更复杂,尽管文件系统创建/修改时间仍然适用于此(当添加对该文件的新引用时,您可以让它触摸每个文件以更新它的修改时间).
我看到目录的日期/时间有两个方面的缺点.首先,分发不太可能是统一的,这会导致某些目录比其他目录更丰富.哈希将均匀分配.至于跨越,您可以在添加文件时监视驱动器上的空间,并在空间用完时开始溢出到下一个驱动器.我想到期满的一部分是与日期相关的,所以当较新的驱动器填满时,你会让旧的驱动器开始清空,你必须弄清楚如何平衡它.
元数据存储不必位于服务器本身上.您已经将文件相关数据存储在数据库中.与仅直接从使用它的行引用路径相反,请引用文件名密钥(我提到的第二个表).
我想用户会使用某种类型的网络或应用程序来连接到商店,因此找出文件在存储服务器上的位置的聪明人会住在那里,只是分享驱动器的根源(或做一些花哨的东西)使用NTFS连接将所有驱动器放入一个子目录中).如果您希望通过网站下载文件,请在站点上创建一个采用文件名ID的页面,然后在数据库中执行查找以获取哈希值,然后它会将哈希值分解为任何已配置的哈希值等级,并请求通过共享到服务器,然后将其流回客户端.如果期望UNC访问该文件,请让服务器改为构建UNC.
这两种方法都会使您的最终用户应用程序减少对文件系统本身结构的依赖,并使您以后更容易调整和扩展存储.