我有一個在 AWS Lambda 上運行的「微服務」（使用 node.js）。
基本上，它提供從幾百兆位元組的二進位 blob 中提取的濃縮摘要。有很多可能的輸出，並且預先生成所有可能性並不是一種選擇，並且它需要具有合理的響應能力（最壞的情況下是亞秒級），因為它是從允許參數的交互式網頁訪問（透過API 網關）的被迅速改變。 Blob 中的存取模式本質上是隨機的，儘管產生的任何摘要通常僅存取了總數據的約 0.1-1%。資料和存取模式與將資料儲存在資料庫中不太相容（儘管請參閱下面提到的 DynamoDB）。
我目前的方法是將大型二進位blob 託管在S3 上，並讓Lambda 處理程序在Lambda 呼叫之間本地緩存blob（就像javascript 程式碼中的緩衝區，其範圍位於處理程序函數之外；顯然Lambda 的內存配置足夠）大的）。處理程序實例似乎足夠持久，一旦伺服器啟動並運行，它就可以正常工作並且回應速度非常快。然而，至少有幾個缺點：
最初從 S3 獲取數據的速度似乎約為 50-60MByte/s（似乎與我見過的有關 S3 頻寬的其他報告一致），因此首次訪問時可能會出現惱人的多秒延遲。
與上一點相關，如果客戶端非常活躍和/或用戶負載增加，則更多的伺服器實例會啟動，用戶可能會發現他們的請求被路由到在獲取資料 blob 時停滯的實例，這會導致在否則客戶端可以順利運作。
我坦白承認，我可能對真正的「無狀態」服務抱有太多期望，因為它實際上有一大塊狀態（二進位 blob），但我想知道是否可以採取任何措施來改善情況。請注意，數據並不是特別可壓縮（可能可以壓縮 1/3，但這不是我正在尋找的那種數量級，或者至少它最多只是解決方案的一部分） 。
對於如何更快地將資料匯入 Lambda 有什麼建議嗎？ 我想像的事情是：
從 Lambda 具有更高頻寬的其他地方提取資料…但是什麼呢？ DynamoDB（根據需要分割成任意數量的 400k 二進位記錄）？彈性緩存？ AWS「選單」上的其他內容我沒有註意到。
使用一些狡猾的技巧（什麼？）來「預熱」lambda 實例。
你使用了完全錯誤的工具來完成這項工作；用...代替？ （不過，我確實很喜歡 Lambda 模型；無需擔心所有實例配置和自動擴展，只需專注於功能）。
如果Google或微軟最近宣布的類似 Lambda 的產品（我對此知之甚少）有任何屬性可以更好地幫助這個用例，那也將是非常有趣的資訊。
我考慮過的一種選擇是將二進位資料烘焙到「部署包」中，但對於某些預期的用例來說，250MByte 的限制太低了（即使 blob 已被壓縮）。
答案1
如果二進位 blob 只有幾百兆位元組，您可以將其作為「依賴項」包含在您的函數中。您可以將其作為文件添加到程式碼旁邊並相應地引用它。
另一個選擇是使用兩個 lambda 函數。一個函數除了提供 blob（您透過使用該函數發送 blob 來建立該 blob）之外什麼也不做，然後您可以使用計時器（基本上是 cron）每分鐘「觸發」函數以保持其活動狀態。然後你的第二個 lambda 是完成這項工作的那個，它在啟動時做的第一件事就是呼叫第一個 lambda 來取得 blob。 Lambda 到 Lambda 呼叫的頻寬很高，因此啟動時間應該不成問題。
理想的解決方案是找到一種方法來匯總資料並將其儲存在 DynamoDB 中，但聽起來您嘗試了該方法，但它對您來說沒有意義。