我正在设计一个数据库，它可以轻松地表示为包含固定大小记录的大型文件集合，序列号为 0,1，... 这可以很好地适用于 DynamoDB，文件名作为主键，记录序列号作为排序键，但我正在考虑在 EFS 上只使用松散文件。我不需要任何复制，因为这已经是容错系统中的复制。我的 Lambda 函数不需要任何比读取、写入或更新单个记录更复杂的操作，这些记录始终位于已知文件中的已知偏移量。可能有 100 个同时活动的 lambda，但通常访问不同的文件。看起来我可以使用 fcntl/lockf 来同步任何争用。
从背面来看，使用原始文件至少可以减少一半的成本，而且我猜性能也会更好。我可能会后悔这样做的原因有哪些？
答案1
根据一些简单的实验，这种方法是可行的。使用 Rust，我能够在大约 20ms 的 Lambda 运行时内更新文件（重复调用）。使用 fcntl 咨询锁定 (F_SETLKW)，我可以毫无问题地处理几个并发 Lambda 争用同一个文件的情况。延迟上升到大约 30ms，没有争用，争用期间的等待时间是预期的。
这些似乎与 dynamoDB 差不多。但是，我在许多地方都看到建议避免在涉及许多小文件的工作负载中使用 EFS。但是，我猜这通常是相对于 EBS 而言的，并且忽略了我可以用每个请求 1 个 Lambda 实现的简单并发性。
我猜测，要想通过 dynamoDB 实现这一性能突破，我需要使用简单队列服务来限制并发 Lambda 的数量。
我预见到的最大缺点之一是可升级性。如果需要对文件格式进行任何更改，它很快就会变得混乱。超出核心工作流的任何类型的查询都需要自定义实现。