虽然 NoSQL 通常推荐 denormalization 的数据模型,但最好不要在单个数据库条目中包含无限列表。要在 DynamoDB 中对此数据建模,您应该使用 adjacency list for modeling the many-to-many relationship。据我所知,没有成本效益的数据建模方法可以让您在一次调用中获得所需的所有数据。但是,您已经说过速度是最重要的(没有给出延迟要求),所以我将尝试让您了解如果将数据存储在 DynamoDB 中,您可以获得多快的数据。
你的架构会变成这样:
Actor {
ActorId, <-- This is the application/database id, not the actor's actual ID
Name,
Age,
Bio
}
Film {
FilmId, <-- This is the application/database id for the film
Title,
Description,
ReleaseDate
}
ActedIn {
ActorId,
FilmId
}
要表明某个演员在电影中表演,您只需执行一次写入(根据我的经验,使用 DynamoDB 始终是个位数毫秒),即可将 ActedIn 项目添加到您的表中。
要获取某个演员的所有电影,您需要查询一次以获取所有演员的关系,然后进行批量读取以获取所有电影。查询的典型延迟(根据我的经验)低于 10 毫秒,具体取决于网络速度和通过网络发送的数据量。由于 ActedIn 关系是一个很小的对象,我认为如果您的查询源自也在 AWS 数据中心(EC2、Lambda 等)中运行的某些东西,我认为您可以预期平均为 5 毫秒的查询。
获取单个项目将在 5 毫秒以下,您可以并行执行。还有一个 BatchGetItems API,但我没有关于它的任何统计数据。
那么,~10ms 对你来说足够快了吗?
如果没有,您可以使用DAX,它为 DynamoDB 添加了一个缓存层,并承诺
在一次调用中完成此操作的不可维护、不经济高效的方法是什么?
对于每个 ActedIn 关系,请像这样存储您的数据:
ActedIn {
ActorId,
ActorName,
ActorAge,
ActorBio,
FilmId,
FilmTitle,
FilmDescription,
FilmReleaseDate
}
您只需对任何给定演员进行一次查询即可获取他们的所有电影详细信息,并且只需一次查询即可获取给定电影的所有演员详细信息。 实际上不要这样做。重复的数据意味着每次您必须更新演员的详细信息时,您需要为他们所在的每一部电影更新它,对于电影详细信息也是如此。这将是一场运营噩梦。
我不相信;看起来 NoSQL 对此很糟糕。
您应该记住,NoSQL 有很多种(NoSQL = Not Only SQL),因此即使一种 NoSQL 解决方案不适合您,您也不应该完全排除它。如果你在一次调用中绝对需要这个,你应该考虑使用Graph database(这是另一种类型的 NoSQL 数据库)。