architecture - 大规模图像存储

Question

我可能会参与一个项目，其中一个重要的组件是存储大量文件(在这种情况下是图像，但它应该只是作为文件存储)。

预计每周传入文件的数量约为 500,000 个(平均每个约为 100 Kb)，峰值约为每天 100,000 个文件和每秒 5 个。
文件总数预计将达到数千万，然后达到平衡，即文件因各种原因以输入速率过期。

所以我需要一个系统，它可以在高峰时段每秒存储大约 5 个文件，同时读取大约 4 个并随时删除 4 个。

我最初的想法是，一个带有简单的存储、过期和读取服务的普通 NTFS 文件系统实际上就足够了。我可以想象该服务为每年、每月、每天和每小时创建子文件夹，以将每个文件夹的文件数量保持在最低限度，并在需要时允许手动过期。

已经讨论了大型 NTFS 解决方案 here ，但我仍然可以使用一些建议，说明在使用上述规范构建存储时会出现哪些问题、预期会出现哪些维护问题以及存在哪些替代方案。如果可能且可行，我最好避免使用分布式存储。

编辑

感谢所有的意见和建议。有关该项目的更多奖励信息:

这不是最终用户提供图像的 Web 应用程序。没有透露太多，因为这是在契约(Contract)阶段，它更多地属于质量控制类别。想想带有传送带和传感器的生产工厂。这不是传统的质量控制，因为产品的值(value)完全取决于图像和元数据数据库的顺利运行。

自主应用程序以先进先出的顺序访问 99% 的图像，但也会发生用户应用程序的随机访问。超过一天的图像将主要用于存档目的，尽管该目的也非常重要。

由于各种原因，图像的到期遵循复杂的规则，但在某些日期，所有图像都应被删除。删除规则遵循依赖于元数据和用户交互的业务逻辑。

每天都会有停机时间，可以进行维护。

优选地，文件存储不必将图像位置传送回元数据服务器。如果选择了某种散列或分布式系统，则应该从元数据中唯一地扣除图像位置，可能通过映射数据库。

所以我的问题是:

哪些技术将发挥强大的作用？

哪些技术的实现成本最低？

哪些技术最容易由客户的 IT 部门维护？

这种规模的给定技术(5-20​​ TB 数据，10-1 亿个文件)存在哪些风险？

Answer 1

以下是基于以下假设的关于实现和可能出现的问题的一些随机想法:平均图像大小为 100kb，稳定状态为 50M (5GB) 图像。这也假设用户不会直接访问文件存储，而是通过软件或网站来访问:

存储介质:您提供的图像大小相当于相当微不足道的读写速度，我认为大多数常见的硬盘驱动器不会有这种吞吐量的问题。但是，为了数据安全，我会将它们置于 RAID1 配置中。备份似乎不是什么大问题，因为它只有 5GB 的数据。

文件存储:为了防止目录中最大文件数出现问题，我会采用散列(最小 MD5，这将是最快的，但最有可能发生冲突。在人们说 MD5 损坏之前，这是为了识别，而不是安全性。攻击者可以为第二次原像攻击填充图像，并用山羊替换所有图像，但我们认为这不太可能)，并将其转换为十六进制字符串。然后，当需要将文件存储在文件系统中时，以 2 个字符的块为单位获取十六进制字符串，并基于此为该文件创建目录结构。例如。如果文件散列到 abcdef ，根目录为 ab然后在该目录下名为 cd ，您将在其下存储名称为 abcdef 的图像.真实姓名将保存在其他地方(下面讨论)。

使用这种方法，如果您从目录中的太多文件开始遇到文件系统限制(或性能问题)，您可以让文件存储部分创建另一个级别的目录。您还可以使用元数据存储创建文件时使用的目录级别，因此如果您稍后展开，则不会在较新、较深的目录中查找较旧的文件。

另一个好处是:如果您遇到传输速度问题或一般的文件系统问题，您可以轻松地将一组文件拆分到其他驱动器。只需更改软件即可将顶级目录保留在不同的驱动器上。因此，如果您想将商店一分为二，一个驱动器上的 00-7F，另一个驱动器上的 80-FF。

散列还可以为您提供单实例存储，这可能很好。由于正常文件群的散列往往是随机的，这也应该使您在所有目录中均匀分布文件。

元数据存储:虽然 5000 万行看起来很多，但大多数 DBMS 的构建都是为了 mock 该数量的记录，当然还有足够的 RAM。以下是基于 SQL Server 编写的，但我相信其中的大部分内容都适用于其他人。创建一个表，以文件的哈希作为主键，以及大小、格式和嵌套级别等内容。然后创建另一个带有人工键的表(一个 int Identity 列就可以了)，以及文件的原始名称(varchar(255) 或其他)，以及作为外键的哈希返回到第一个表，以及它的添加日期，在文件名列上有一个索引。还要添加您需要确定文件是否已过期的任何其他列。如果有人试图将同一文件放入不同的名称(但其他方面相同，因为它们的哈希值相同)，这将允许您存储原始名称。

维护:这应该是一个计划任务。让 Windows 担心您的任务何时运行，减少您调试和出错的时间(如果您每晚在凌晨 2:30 进行维护，并且您所在的地方遵守夏令时/夏令时。凌晨 2:30 不会发生呢？在 Spring 转换期间)。然后，此服务将对数据库运行查询以确定哪些文件已过期(基于每个文件名存储的数据，因此它知道指向存储文件的所有引用何时过期。任何未被引用的散列文件至少不再需要文件名表中的一行)。然后该服务将删除这些文件。

我认为这就是主要部分。

编辑:我的评论太长了，将其移至编辑中:

哎呀，我的错误，这就是我累时做数学的结果。在这种情况下，如果您想避免添加 RAID 级别(51 或 61，例如跨 strip 集镜像)的额外冗余，散列将使您能够将 5 个 1TB 驱动器插入服务器的好处，然后有文件存储软件通过 2 末尾提到的散列跨越驱动器。您甚至可以 RAID1 驱动器以增加安全性。

备份会更复杂，尽管文件系统的创建/修改时间仍然适用于这样做(当添加对该文件的新引用时，您可以让它触摸每个文件以更新它的修改时间)。

我认为按日期/时间查看目录有两个缺点。首先，分布不太可能是统一的，这将导致某些目录比其他目录更完整。散列将均匀分布。至于跨越，您可以在添加文件时监视驱动器上的空间，并在空间用完时开始溢出到下一个驱动器。我想部分到期时间与日期相关，因此随着新驱动器填满，旧驱动器会开始清空，您必须弄清楚如何平衡它。

元数据存储不必位于服务器本身上。您已经在数据库中存储了文件相关数据。与仅直接从使用它的行引用路径相反，而是引用文件名键(我提到的第二个表)。

我想象用户使用某种网络或应用程序来连接到商店，所以聪明地找出文件在存储服务器上的位置将放在那里，然后分享驱动器的根(或做一些花哨的东西使用 NTFS 连接将所有驱动器放入一个子目录)。如果您希望通过网站下拉文件，请在该网站上创建一个使用文件名 ID 的页面，然后在数据库中执行查找以获取哈希，然后它将哈希分解为任何配置级别，并通过共享请求服务器，然后将其流回客户端。如果希望 UNC 访问该文件，则让服务器只构建 UNC。

这两种方法都会使您的最终用户应用程序更少依赖于文件系统本身的结构，并且使您以后可以更轻松地调整和扩展您的存储。