我在C上编写软件,在AWS上运行,在7200万个文件中处理240TB的数据。
数据将分布在24个或更多节点上,因此每个节点上只有10TB,每个节点有300万个文件。
因为我必须每60秒将数据附加到这300万个文件中的每一个,所以最简单快速的操作就是能够一次打开这些文件。
我无法将数据存储在数据库中,因为读取/写入数据的性能太慢。我需要能够很快地读回数据。
我的问题:
1)甚至可以保持打开300万个文件
2)如果可能的话,会消耗多少内存
3)如果有可能,表现会很糟糕
4)如果不可能,我需要将所有单个文件合并到几十个大文件中。 Linux中是否有最大文件大小?
5)如果不可能,我应该使用什么技术每60秒附加一次数据并跟踪它?
答案 0 :(得分:0)
以下是对可以解决您的问题的架构的非常粗略的描述,假设当您有足够的实例时,文件描述符的最大数量是无关紧要的。
首先,看看这个:
https://aws.amazon.com/blogs/aws/amazon-elastic-file-system-shared-file-storage-for-amazon-ec2/
EFS提供了一个可以作为文件系统挂载的共享存储。
您可以将所有文件存储在EFS的单个存储单元中。然后,您将需要一组N个工作机器,它们以文件处理程序的全部容量运行。然后,您可以使用Redis队列来分发更新。每个工作人员必须从Redis中取出一组更新,然后打开必要的文件并执行更新。
同样:打开文件处理程序的最大数量不会有问题,因为如果达到最大值,则只需增加工作机器的数量,直到达到所需的性能。
这是可扩展的,但我不确定这是否是解决问题的最便宜方式。