在文件系统中有效存储价值25万美元的25TB以上文件的提示

假设您面对着价值25 TB的未压缩日志文件，并且可以随意使用20个商品盒阵列，它们的集体免费存储容量为25 TB。

您将如何存储这些？

a）使用哪个分布式文件系统？

b）哪种压缩/解压缩格式/算法？

c）日志文件大小为1MB，最大7MB，所有文本和大量空白

d）用法是：a）人们想要最新的日志文件比以前更多，因此要使用哪种缓存系统b）人们将只读取日志文件而不删除它们c）人们希望按日期范围列出日志文件

e）在商品包装盒上运行的操作系统是Linux，

f）至于备份，我们有一个存储阵列可以解决这个问题。因此，存在从阵列还原数据的能力。

我不希望他们直接访问文件系统。我该怎么办 ？我如何为此获得一个基于REST的API？

请您多花2美分，您会怎么做？

安库尔

我不是分布式文件系统忍者，但是在将尽可能多的驱动器整合到尽可能少的计算机中之后，我将尝试使用iSCSI将大量计算机连接到一台主机。在那里，我可以将其整合到一个容错存储中。优选地，机器内部（如果驱动器出现故障）和机器之间（如果整个机器关闭电源）的容错能力。

我个人喜欢ZFS。在这种情况下，压缩，重复数据删除和容错的构建将很有帮助。但是，我确信还有许多其他方法可以压缩数据，同时使其具有容错能力。

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

编辑： 我仍然不熟悉ZFS和设置iSCSI，但回想起在德国Sun看到的视频，他们在视频中展示了ZFS的容错能力。他们将三个USB集线器连接到计算机，并在每个集线器中放置四个闪存驱动器。然后，为了防止任何一个集线器关闭存储池，他们制作了一个RAIDz卷，其中每个集线器都有一个闪存驱动器。然后，它们将四个ZFS RAIDz卷分条在一起。这样，只有四个闪存驱动器用于奇偶校验。当然，接下来是拔出的一个集线器，它降级了每个zpool，但是所有数据都可用。在此配置中，最多四个驱动器可能会丢失，但前提是任何两个驱动器不在同一池中。

如果将此配置与每个盒的原始驱动器一起使用，则将保留更多的驱动器用于数据而非奇偶校验。 我听说 FreeNAS可以（或将要）通过iSCSI以“原始”方式共享驱动器，所以我认为Linux可以做到这一点。如我所说，我仍在学习，但是从驱动器奇偶校验的角度来看，这种替代方法比我以前的建议要少浪费。当然，它将依靠使用ZFS，我不知道是否可以接受。我知道，除非您必须学习/学习，否则通常最好还是坚持要了解的内容，否则您将必须进行构建/维护/修理。

希望这会更好。

编辑：做了一些挖掘，找到了我谈论的视频。他们解释将USB闪存驱动器分布在集线器上的部分开始于2分10秒。该视频将演示其存储服务器“ Thumper”（X4500）以及如何在控制器之间分布磁盘，因此，如果硬盘控制器出现故障，您的数据仍然会很好。（我个人认为，这只是一个极客玩的视频。我希望自己能有一个Thumper盒子，但我的妻子不希望我在屋子里用托盘搬运车。：D那是一个大盒子。）

编辑：我记得在一个名为OpenAFS的分布式文件系统中进行通信。我没有尝试过，只读了一些。也许其他人知道它在现实世界中的处理方式。

首先，可以以很高的比率压缩日志文件。我发现我的日志文件以10：1的比率压缩。如果它们压缩到甚至5：1的比例，那就只有5GB，即存储容量的20％。

如果您有足够的存储空间，则特定的压缩算法并不是太重要。你可以...

• 如果Windows用户将直接访问这些文件，请使用zip文件。
• 如果可以通过Linux访问gzip，请使用gzip，并且快速解压缩很重要。
• 如果可以通过Linux访问bzip2，则请使用bzip2，并且拥有尽可能小的文件很重要。

更大的问题是：如何为您的用户提供对这些文件的轻松访问？部分原因取决于计算机的配置方式。

如果可以将足够的存储空间放入一台计算机中，则可以做一些非常简单的事情，例如只读Windows文件共享。只需将文件组织在子目录中，就可以开始了。

如果无法为这些文件创建单个文件服务器，则可能会发现您需要分布式文件系统。Windows具有一个可能适合您需求的分布式文件系统（DFS）。

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

lessfs是一个重复数据删除，压缩文件系统。尽管它不能解决整个问题，但作为后端可能值得一看。

通过NFS导出这些文件夹

将它们以树的形式（在文档根目录下）运行在安装在单机上的apache中

使用zip压缩它们-良好的压缩率，可以从所有操作系统打开zip

列出Apache中的文件-因此，您授予用户只读访问权限（日志文件不应该被编辑，对）

您是否曾经考虑过压缩日志文件？然后，在将其提供给最终用户之前，在前端进行一些操作以解压缩它们。也许是CGI脚本。

@Ankur和@Porch。我非常同意压缩这些日志的必要性。

@jet我认为较简单的方案更好-因此最终用户的httpd接近理想状态。后端可以是任何后端。

我的看法-将日志分为2组-文件夹“旧”和“新”。

将它们合并到httpd的文档根目录中。对具有较大词典和块大小的旧版本（适用于所有操作系统的xz或7z存档）使用强压缩，甚至可能是可靠的存档。

使用新的压缩fs：lessfs（rw，重复数据删除+轻压缩方法），fusecompress 0.9.x（rw，轻到强压缩方法），btrfs / zfs，squashfs（ro，轻到强压缩方法，一些重复，使用对于新轮换的日志）。

您甚至可以透明地将日志写入压缩的fs（fusecompress，lessfs，btrfs / zfs）。通过httpd提供对正在写入的日志的R / o访问。它们对用户是透明的，并且对他们透明地解压缩。

关于fusecompress的警告：1）仅使用0.9.x-稳定。从这里克隆https://github.com/hexxellor/fusecompress

更高版本可能无法很好地支持lzma或丢失数据。

2）它仅使用1个cpu核心来压缩一个文件，因此速度可能很慢。

重新压缩“ new”文件夹中的每个日志（早于某个时间（数月））并移至“ old”。