Linux：大文件与大量文件答案

【问题标题】：Linux: huge files vs huge number of filesLinux：大文件与大量文件
【发布时间】：2015-05-29 00:28:26
【问题描述】：

我正在用 C 语言编写软件，在 AWS 上运行的 Linux 上，它必须处理 7200 万个文件中的 240 TB 数据。

数据将分布在 24 个或更多节点上，因此每个节点上只有 10 TB，每个节点上只有 300 万个文件。

因为我必须每 60 秒向这 300 万个文件中的每一个附加数据，所以最简单、最快速的做法是让这些文件中的每一个都保持一次打开状态。

我无法将数据存储在数据库中，因为读取/写入数据的性能会太慢。我需要能够非常快速地读回数据。

我的问题：

1) 是否有可能保持打开 300 万个文件

2) 如果可能，它会消耗多少内存

3) 如果可能，性能会很糟糕

4) 如果不可能，我需要将所有单独的文件合并成几十个大文件。 Linux 中是否有最大文件大小？

5) 如果不可能，我应该使用什么技术每 60 秒追加一次数据并跟踪它？

【问题讨论】：

“我无法将数据存储在数据库中，因为读取/写入数据的性能会太慢” - 你的依据是什么？
设计您的软件，以便您可以轻松使用分布式文件系统，这样它就可以扩展。增加吞吐量只是意味着将另一台服务器与其链接。我想知道你的服务器是否可以处理数据流的唯一方法就是尝试一下。
@Mitch，我认为尽可能快地读回数据是一个巨大的竞争点。因此，除了对磁盘的原始读/写之外，任何其他操作都会使我们与竞争对手相比处于劣势。
@ShellFish，每个文件大约 5MB。对于分布式文件系统，我期望每台服务器能够处理的合理文件数量是多少？我在互联网上找不到任何讨论这个的东西。高性能可以处理 5,000 个文件或 500,000 个文件吗？
@user994179 我听说有些服务器处理 100k 文件句柄。这个信息可能已经过时了，但我听说它在 Linux 上每 100 个文件句柄需要 1 兆字节。因此，如果是这种情况，3 百万将需要大约 30 GB 的 RAM（但仅适用于文件描述符）。我认为，如果您试图与商业数据库竞争，一个更大的问题是磁盘寻道时间，因为处理这么多单独文件的潜在碎片开销。如果您以这种方式组织数据，至少您可能需要一些非常好的 SSD。

【解决方案1】：

以下是可以解决您的问题的架构的非常粗略的描述，假设当您有足够的实例时文件描述符的最大数量无关紧要。

首先，看看这个：

EFS 提供了一个共享存储，您可以将其挂载为文件系统。

您可以将所有文件存储在 EFS 的单个存储单元中。然后，您将需要一组 N 台工作机器以满载文件处理程序运行。然后，您可以使用 Redis 队列来分发更新。每个工作人员必须从 Redis 中取出一组更新，然后打开必要的文件并执行更新。

再次重申：打开文件处理程序的最大数量不会成为问题，因为如果达到最大值，您只需要增加工作机器的数量，直到达到您需要的性能。

这是可扩展的，但我不确定这是否是解决您的问题的最便宜的方法。

【讨论】：