数百万个小文件的块大小

rab*_*dde 10 linux raid storage filesystems block

我在 Debian Wheezy 上的硬件 RAID1(可能是 LSI MegaRaid)中有 2 个 4TB 磁盘。物理块大小为 4kB。我将存储 150-2 亿个小文件(3 到 10kB 之间)。我不是在要求性能,而是为了节省存储空间的最佳文件系统和块大小。我已将 8200 字节的文件复制到块大小为 4kB 的 ext4 上。这占用了 32kB 的磁盘空间!?写日记是原因吗?那么有哪些选项可以为这些小文件节省大部分存储空间呢?

小智 1

如果我处于这种情况,我会寻找一个可以将所有数据存储在一个具有紧凑的、基于偏移量的索引的文件中的数据库,而不是作为单独的文件。也许一个数据库有一个 FUSE 驱动程序,可以在必要时作为文件与其进行交互,而实际上它们并不是单独的文件。

或者,您可以查看文件大小的第 60--70 个百分位,并尝试将该文件大小直接放入文件系统树节点中,而不是作为磁盘上的单独块。在每个节点中存储 10k 可能是一个很大的要求,但如果您能在其中获取 60%-70% 的文件,那可能是一个巨大的胜利。

只有某些文件系统才能做到这一点(reiserfs 就是其中之一),我想这完全取决于百分位数的大小,以及它是否适合树。您也许可以调整它。我想尝试将其余部分放入一个块中。

不用担心期刊;无论如何,它们都有尺寸上限。

  • 不不不不不不不不只是...不对你的第一段。我几年前就犯过这个错误,后来不得不改正。我也继承了使用这种设计模式的系统。文件属于文件系统,或者作为折衷方案,如果您“必须”将它们组合起来,则属于 SQL Server FileStream 对象(因此可能是您的 FUSE 驱动程序,但仍然不行)。在文件系统中工作时还有其他注意事项,例如不要将 400 万个文件放在一个文件夹中(我也犯过这个错误)。 (4认同)
  • @MarkHenderson,但问题是定义什么应该是文件,什么应该是记录。在没有提供更多细节的情况下,数以亿计的微小事物对我来说听起来更像是唱片。仅仅因为他目前将它们作为文件保存,并不意味着它们需要保持这种状态,或者应该一直保持这种状态。另外,我从来没有建议使用 SQL Server 来完成这项工作;) (2认同)
  • 5年前,我继承了一个系统,单个文件夹中有100万个文件,每天大约有10,000个新的1-4KB文件。我决定将它们全部放入 ISAM 表中,因为“嘿,它们只是用于分析的纯文本!” 然后结果证明这是一个巨大的错误,因为我现在有一个 12GB 的表,其中有大量的行,这些行在处理后几乎什么也不做。因此,我转回将它们放入具有基于文件名 GUID 的分层文件夹的文件系统中。 (2认同)
  • @MarkHenderson:这不是一个不同的问题,这就是为什么你说这是错误的解决方案(“......巨大的错误,因为我现在有一个带有十万行的单个 12GB 表......”)。您选择了错误的数据库引擎/表格式,但是只要您做得正确,将大量小东西放入带有索引的单个文件中的概念是合理的。您想要的是一个擅长存储数百万个小对象的键/值并具有自动分片功能的数据库。另请注意,他甚至不关心性能,只关心空间。 (2认同)