我有一些我将称之为在AWS Lambda上运行的“microservice”（使用node.js）。
基本上它提供了从几百兆字节的二进制blob中抽取的简明摘要。 有很多可能的输出和预产生的所有可能性是不是一个选项，它需要是合理的响应（最坏的亚秒），因为它是从交互式网页访问（通过API网关），允许参数要迅速改变。 blob中的访问模式基本上是随机的，尽pipe所产生的汇总通常只能访问总数据的〜0.1-1％。 数据和访问模式与将数据存储在数据库中不是很兼容（尽pipe参见下面提到的DynamoDB）。
我目前的方法是在S3上托pipe大的二进制blob，并让Lambda处理程序在Lambda调用之间本地cachingblob（就像javascript代码中的缓冲区一样，范围在hander函数之外;显然，Lambda的内存configuration足够大）。 处理程序实例似乎是持久的，一旦服务器启动并运行，它运行良好，响应速度非常快。 但是至less有几个缺点：
S3的数据初始读取似乎在50-60MByte / s左右（似乎与其他有关我看到的S3带宽的报告一致），所以在第一次访问时可能会有一个令人讨厌的多秒延迟。
与前一点相关的是，如果客户机非常活跃并且/或者用户负载增加，则更多的服务器实例被启动并且用户可能发现它们的请求被路由到在获取数据blob时停滞的实例，这导致恼人的毛刺否则顺利运作的客户。
我毫不犹豫地承认，我可能期望从真正意图成为“无状态”的服务中得到太多，因为它实际上有一大块状态（二进制BLOB），但是我想知道是否可以做任何事情改善情况。 请注意，数据不是特别可压缩的（也许可以取1/3的数据，但这并不是我要查找的数量级，或者至less它只是解决scheme的一部分） 。
任何build议如何更快地将数据导入Lambda？ 我想象的是：
把你的数据从其他地方拉姆达斯有更高的带宽…但是什么？ DynamoDB（根据需要分成多达40万个二进制logging）？ ElastiCache？ AWS上的其他东西“菜单”我没有注意到。
使用一些狡猾的技巧（什么？）来“预热”lambda实例。
你完全用错了这个工具。 用…代替？ （尽pipe我确实很喜欢Lambda模型;不需要担心所有的实例configuration和自动扩展，只关注function）。
如果谷歌或微软最近宣布的类似Lambda的产品（我几乎不知道这些产品）有什么特点可以更好地帮助这个用例，那也是非常有趣的信息。
我所考虑的一个select是将二进制数据烘焙成“部署包”，但是250MByte的限制对于某些预期的使用情况来说太低（即使blob被压缩了）。
如果二进制blob只有几百兆字节，你可以将它作为“依赖”包含在函数中。 您可以将其作为一个文件添加到您的代码并相应地引用它。
另一种select是有两个lambda函数。 一个函数什么都不做，只是提供blob（你通过发送blob的函数来创build），然后你可以使用一个定时器（基本上是cron）来每分钟“发痒”这个函数来保持它的活跃。 然后你的第二个lambda是做这个工作的那个，它在启动时首先调用第一个lambda来获得blob。 Lambda到lambda的调用是高带宽，所以启动时间不应该是一个问题。
理想的解决scheme是找出总结数据并将其存储在DynamoDB中的方法，但听起来像是您尝试了这条路线，而且对您来说没有任何意义。