具有复制功能的数百万个文件的 Linux 文件系统或 CDN

Question

请告诉我这种情况的解决方案：

• 数百万个文件，位于一个目录中（“img/8898f6152a0ecd7997a68631768fb72e9ac2efe1_1.jpg”）
• 平均文件大小约为 80k
• 90% 随机读取访问
• 备份（复制）到其他服务器（每 5 分钟或立即）
• 图像元数据保存到数据库中

当文件数量超过 200 万时，我们遇到了随机访问时间变慢的问题。文件系统是 ext3，诺亚泰和目录索引选项，但不需要使用“ls”或“find”之类的命令。

我认为可能的解决方案：

1. 继续使用 ext3 并将目录树结构简单地转换为“img/889/8f6/152/a0ecd7997a68631768fb72e9ac2efe1_1.jpg”
2. 迁移到其他文件系统（ReiserFS、XFS、EXT4 等）
3. 使用分布式文件系统设置存储引擎（举例说明）
4. 或许是其他的……

如果我们选择 1 或 2，我们该如何复制？rsync 无法处理 ext3 文件系统上如此大量的数据。

对我们来说最好的解决方案是使用 Amazon S3，但这对我们的流量来说太昂贵了...也许你会推荐一些类似物（便宜的 CDN 或开源项目）

Answer 1

一个目录中有数百万个文件的设计很糟糕，而且会很慢。将它们细分为条目数较少的目录。

看一眼https://unix.stackexchange.com/questions/3733/number-of-files-per-directory

使用 RAID 和/或 SSD。这本身并不能解决访问速度慢的问题，但如果你引入多个目录并减少每个目录的文件数量（比如说减少一个或两个数量级），这将有助于防止热点。

考虑 XFS，特别是在使用多个驱动器和多个目录时，它可能会给你带来很好的收益（参见例如这线程以了解要使用的选项。它为 RAID 上的 XFS 提供了一些提示md）。

Answer 2

就我个人而言，我会：

1. 坚持使用您当前的 FS。按照您的建议将它们拆分成目录，如果您愿意，您仍然可以将其显示为单个目录，例如mod_rewrite（猜测这是一个 CDN 类型的应用程序）
2. 记录需要复制的更改，例如每日/每小时等，以便每次需要同步时，找出需要复制的文件就像diff在日志上运行一样简单（即，您总是同步日志并先同步它们，但在替换它们之前做一个差异来计算还需要复制什么）。