Architecture 大规模图像存储

我可能会参与一个项目，其中一个重要组件是存储大量文件（在本例中是图像，但它应该只是作为文件存储）

传入文件的数量预计每周约为500000个（平均每个约为100KB），峰值约为每天100000个文件，每秒5个。 在达到均衡之前，文件总数预计将达到数千万，在均衡状态下，文件将因各种原因以输入速率过期

因此，我需要一个系统，可以存储约5文件每秒在高峰时间，而阅读约4和删除4在任何时候

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

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

编辑

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

这不是由最终用户提供图像的web应用程序。不要透露太多，因为这是在合同阶段，它更多的是在质量控制的范畴。考虑一下带传送带和传感器的生产工厂。这不是传统的质量控制，因为产品的价值完全取决于图像和元数据数据库的顺利运行

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

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

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

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

因此，我的问题是：

• 哪些技术将发挥强大的作用
• 哪些技术的实施成本最低
• 客户的IT部门最容易维护哪些技术
• 这种规模的特定技术（5-20 TB数据、1000-1亿个文件）存在哪些风险

---

将图像存储在一系列SQLite数据库中。一开始听起来很疯狂，但实际上它比直接将它们存储在文件系统上要快，而且占用的空间更少

SQLite在存储二进制数据方面非常高效，通过将文件存储在聚合数据库中而不是单个OS文件中，当图像不适合精确的块大小时（这对于如此多的文件非常重要），它可以节省开销。此外，SQLite中的分页数据可以提供比普通OS文件更快的总体吞吐量

SQLite在写操作上有并发限制，但在您所说的限制范围内，可以通过巧妙地使用多个（数百个）SQLite数据库来进一步缓解

---

尝试一下，你会惊喜万分。

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

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

文件存储：为了防止目录中的最大文件数出现问题，我将使用哈希（MD5最小，这将是最快的，但大多数碰撞是可能的。在人们啁啾说MD5被破坏之前，这是为了识别，而不是安全性。攻击者可以为第二次预图像攻击垫上图像，并用GOATSE替换所有图像，但我们会认为这不太可能）。，并将其转换为十六进制字符串。然后，当需要将文件存储在文件系统中时，将十六进制字符串分成两个字符的块，并基于此创建该文件的目录结构。例如，如果文件哈希为

abcdef

，则根目录将是

ab

，然后在该目录下创建一个名为的目录ode>cd，您可以在其下存储名为

abcdef

的图像。真实名称将保留在其他地方（下文讨论）

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

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