提问人：EnlightenedMonk 提问时间：11/17/2023 更新时间：11/21/2023 访问量：37
终端节点设计：查询 AWS Athena 而不是数据库
Endpoint Design: Querying AWS Athena instead of a database
问：
我正在构建一个端点，它将由 5k - 10k 用户使用，比如说：
GET /magic/spells?spellIds=1,2,3
“spells”的基础数据源经常更改，并以压缩格式存储在 s3 上。基础数据的大小相当小（< 100mb）。
每次用户命中终端节点时，我都会直接对 Athena 进行查询，以便检索要在 api 响应中返回的拼写数据。我正在使用缓存来帮助减少原始 Athena 查询的数量，但我仍然担心该方法可能无法很好地扩展。
Athena 查询不是免费的，如果用户决定查询随机生成的以避免缓存，它可能会很快产生账单。spellIds
或者，我可以按计划的时间间隔将 Athena 中的拼写数据加载到更传统的数据源（数据库）中，然后对其进行查询。这样做的缺点是数据可能会过时，这是我可能不得不做出的权衡。
在面向用户的终端节点中查询 Athena 是一种常见做法，还是更可取的是先将数据存储在更传统的数据存储中？
答：
2赞
Guy
11/21/2023
#1
Athena 被设计为分析查询引擎，而不是查找服务。
将数据加载到 DynamoDB 中，然后根据键进行查询。您可以使用其他数据存储;但是，DynamoDB 是最具成本效益的。
评论
0赞
EnlightenedMonk
11/21/2023
这也与我得出的结论相同，AWS Glue Catalog 对索引没有很好的支持，这意味着每次查询特定键时都必须进行表扫描。我决定将数据加载到 OpenSearch 中，因为它更适合我的使用案例，尽管 DynamoDB 也可以正常工作。
评论