%20%E4%BD%9C%E7%82%BA%20Lambda%20%E5%87%BD%E6%95%B8%E7%9A%84%E5%BB%89%E5%83%B9%E8%B3%87%E6%96%99%E5%BA%AB.png)
我正在設計一個資料庫，可以輕鬆地表示為包含固定大小記錄的大型檔案集合，序號為 0,1,... 這可以很好地適合 DynamoDB，檔案名稱作為主鍵，記錄序號作為排序關鍵，但我正在考慮在EFS 上使用鬆散文件。我不需要任何複製，因為這已經是容錯系統中的複製。我的 Lambda 函數不需要任何比讀取、寫入或更新單一記錄更複雜的操作，這些記錄始終位於已知檔案中的已知偏移量處。可能有 100 個同時活動的 lambda，但通常會存取不同的檔案。看起來我可以使用 fcntl/lockf 來同步任何爭用。
從信封後面看，使用原始文件似乎至少可以將成本減少一半，而且我猜性能也會更好。我可能會後悔這樣做的原因有哪些？
答案1
根據一些簡單的實驗，這種方法是可行的。使用 Rust，我能夠在大約 20 毫秒的 Lambda 運行時（重複呼叫時）更新檔案。使用 fcntl 建議鎖定 (F_SETLKW)，我對少數並發 Lambda 爭用相同檔案沒有任何問題。在沒有爭用的情況下，延遲高達 30 毫秒左右，而爭用期間的等待時間是預期的。
看起來這些與 dynamoDB 處於同一水平。不過，我在很多地方看到了關於避免對涉及許多小文件的工作負載使用 EFS 的建議。但是，我想這通常與 EBS 相關，並忽略我可以透過每個請求 1 個 Lambda 實現的簡單並發。
我猜測要使用 dynamoDB 擊敗這種效能，我需要使用簡單佇列服務來限制並發 Lambda 的數量。
我預見的最大缺點之一是可升級性。如果需要對文件格式進行任何更改，它很快就會變得混亂。核心工作流程以外的任何類型的查詢都需要自訂實作。