在文件系统中高效存储 25TB 以上价值数百万个文件的技巧

在文件系统中高效存储 25TB 以上价值数百万个文件的技巧

假设您面临 25 TB 的未压缩日志文件,并且您有 20 个商品盒阵列,它们的总免费存储容量为 25 TB。

您将如何存储这些?

a) 使用哪个分布式文件系统?

b) 哪种压缩/解压缩格式/算法?

c) 日志文件大小为 1MB,最大 7MB,全是文本,还有大量空白

d) 用法是 a) 人们想要最新的日志文件,而不是以前的,那么使用什么缓存系统呢 b) 人们只会读取日志文件而不会删除它们 c) 人们想要根据日期范围列出日志文件

e)商品盒上运行的操作系统为Linux,

f) 至于备份,我们有一个存储阵列来处理备份。因此可以从阵列恢复数据。

我不想让他们直接访问文件系统。我该怎么办?如何为他们提供基于 REST 的 API?

请您省省吧,您会怎么做?

安库尔

答案1

我不是分布式文件系统专家,但在将尽可能多的驱动器整合到尽可能少的机器中后,我会尝试使用 iSCSI 将大部分机器连接到一台主机。在那里,我可以将东西整合到一个容错存储中。最好是一台机器内(如果驱动器出故障)和机器之间(如果整台机器断电)的容错。

我个人喜欢 ZFS。在这种情况下,内置的压缩​​、重复数据删除和容错功能会很有帮助。但是,我相信还有很多其他方法可以压缩数据,同时使其具有容错能力。

希望我有一个真正的交钥匙分布式文件解决方案可以推荐,我知道这真的很笨重,但我希望它能为您指明正确的方向。

编辑: 我对 ZFS 和 iSCSI 设置还不熟悉,但记得看过 Sun 在德国的一个视频,他们展示了 ZFS 的容错能力。他们将三个 USB 集线器连接到一台计算机,并在每个集线器中放置四个闪存驱动器。然后,为了防止任何一个集线器关闭存储池,他们制作了一个由每个集线器的一个闪存驱动器组成的 RAIDz 卷。然后他们将四个 ZFS RAIDz 卷条带化在一起。这样,只有四个闪存驱动器用于奇偶校验。接下来当然是拔掉一个集线器,这会降低每个 zpool 的性能,但所有数据都可用。在这种配置下,最多可以丢失四个驱动器,但前提是任何两个驱动器都不在同一个池中。

如果每个盒子的原始驱动器都使用此配置,那么将为数据而不是奇偶校验保留更多的驱动器。 我听说FreeNAS 可以(或将能够)通过 iSCSI 以“原始”方式共享驱动器,因此我推测 Linux 也可以这样做。正如我所说,我仍在学习,但从驱动器奇偶校验的角度来看,这种替代方法比我之前的建议更省钱。当然,它依赖于使用 ZFS,我不知道这是否可以接受。我知道,如果您必须构建/维护/修复某些东西,通常最好坚持您所知道的内容,除非这是一次学习经历。

希望这会更好。

编辑:做了一些挖掘,发现视频我谈到了。他们解释如何将 USB 闪存驱动器分布在集线器上的部分从 2 分 10 秒开始。该视频演示了他们的存储服务器“Thumper”(X4500)以及如何将磁盘分布在控制器上,这样如果硬盘控制器出现故障,您的数据仍然会很好。(我个人认为这只是极客们玩得开心的视频。我希望自己有一个 Thumper 盒子,但我的妻子不喜欢我在家里开着叉车。:D 那是一个大盒子。)

编辑:我记得曾经遇到过一个名为开放AFS。我没试过,只读过一些相关内容。也许其他人知道它在现实世界中是如何处理的。

答案2

首先,日志文件可以以非常高的比率压缩。我发现我的日志文件以 10:1 的比率压缩。即使它们以 5:1 的比率压缩,也只有 5GB,即存储容量的 20%。

假设您有足够多的存储空间,那么具体的压缩算法就不是太重要了。您可以...

  • 如果 Windows 用户要直接访问文件,请使用 zip 文件。
  • 如果它们要通过 Linux 访问,请使用 gzip,并且快速解压缩很重要。
  • 如果要通过 Linux 访问它们,请使用 bzip2,并且拥有尽可能最小的文件非常重要。

更大的问题是:你如何让你的用户能够轻松访问这些文件?这部分取决于你的机器是如何配置的。

如果您可以在一台机器上放置足够的存储空间,那么您可以做一些非常简单的事情,例如只读的 Windows 文件共享。只需将文件组织到子目录中,就可以开始了。

如果你不能为这些文件创建一个文件服务器,那么你可能会发现你需要分布式文件系统。Windows 有一个分布式文件系统 (DFS),可能适合您的需要。

如果您的需求更高级,您可能需要一个 Web 应用程序作为前端,以便您的用户可以浏览和下载日志文件。在这种情况下,我建议使用 MogileFS,这是一个分布式文件系统,旨在与前端应用程序服务器一起使用。它很容易与大多数 Web 编程语言集成。您无法将其作为共享驱动器安装在计算机上,但它作为 Web 应用程序的数据存储是一流的。

答案3

更少是一个重复数据删除、压缩文件系统。虽然它不能解决整个问题,但作为后端还是值得一看的。

答案4

您是否考虑过压缩日志文件?然后在前端执行一些操作以解压缩它们,然后再将它们提供给最终用户。也许是某种 CGI 脚本。

相关内容