AWS EFS 用于频繁更新的关键小文件

AWS EFS for critical small files with frequent updates

我们应用程序的用户群已达到 200 万用户,我们计划使用 AWS 扩展应用程序。

我们面临的主要问题是共享数据的处理,包括缓存、上传、模型、会话等

一个选项是 AWS EFS,但它会降低应用程序的性能,因为文件非常小,从几字节到几 MB 不等,而且更新非常频繁。

我们可以使用 Memcache/Redis 进行会话,使用 S3 进行上传,但仍然需要管理缓存、模型和一些其他共享文件。

对于这种经常更新小文件的场景,是否有任何 EFS 替代方案或任何方法可以使 EFS 工作?

小文件和频繁更新对于 EFS 应该不是问题。

一些用户在原始版本中遇到的问题是它有两个维度紧密耦合在一起——可用的吞吐量是你支付多少的函数,而你支付的是多少的函数文件系统的总大小(所有文件合并,不管单个文件大小)...所以越大,越快。

但从那时起,他们引入了 "provisioned throughput," 允许您将这两个维度分离。

This default Amazon EFS throughput bursting mode offers a simple experience that is suitable for a majority of applications. Now with Provisioned Throughput, applications with throughput requirements greater than those allowed by Amazon EFS’s default throughput bursting mode can achieve the throughput levels required immediately and consistently independent of the amount of data.

https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-efs-now-supports-provisioned-throughput/

如果您使用此功能,您需要为您提供的吞吐量与本应包含的吞吐量之间的差额付费,无论如何,这取决于数据的大小。

另请参阅 Amazon Elastic File System 用户指南 中的 Amazon EFS Performance

预配吞吐量可以激活和停用,所以不要将此与还有两种性能模式混淆,分别称为 通用最大I/O,其中之一必须在创建文件系统时selected,并且此selection 以后不能更改。这些与底层基础架构中的可选权衡有关,建议的做法是 select 通用 ,除非您有理由根据观察到的指标不这样做。 Max I/O 模式没有与通用相同的元数据一致性模型。