我感兴趣的是如何为给定的查询需求设置表和索引的最佳实践。我对分区和排序键或LSI和GSI辅助索引等相关概念有基本的理解,但在将它们放在一起并设计一个或多个表时遇到了问题,这些索引支持一个明显的示例。
我正在看的例子是一个“书签存储”,多个用户可以将书签存储到URL并用多个标记对这些书签进行注释。User有多个Urls (=书签)。每个Url都有一个日期,可以有一个或多个Tags。
书签可能具有以下基本结构:
{
"user": "watQuadrat",
"url": "http://stackoverflow.com",
"date": 1494161436362,
"tags": [ "forum", "programming" ]
}目前,我最大的问题是如何设置表结构,以便能够适应查询数据的各种不同方式,例如:
User的所有User,按用户使用标记的频率排序User的所有User,按字母顺序排序Url的所有Url,按为url分配此标记的频率排序Tags,按使用标签的频率排序(例如搜索“商店”,按使用频率返回所有匹配的标签,如“购物”订单)User的所有User,按日期排序User和Tag的所有TagTag的所有Tag,按标记分配给每个url的频率排序Url的所有Url,按日期排序如何设计它,以便我能够以一种高效的方式执行所有这些查询?如果你想降低成本的话,你的设计会有什么不同吗?
发布于 2017-05-07 12:19:02
考虑到您所描述的场景,我将按照下面提到的方式设计该表。在这里,我假设一个用户只能从给定的url创建一个书签。此外,我还使用了一个名为TagCount的新派生属性,它表示该书签的标记数。
表结构
主分区键: UserID
主排序键: Url
本地二次指标
指数1
分区键: UserID
排序键:日期
指数2
分区键: UserID
排序键: TagCount
全球次级指标
指数1
分区键: Url
排序键:日期
指数2
分区键: Url
排序键: TagCount
使用此设计,您可以以下列方式执行查询。
如果你担心成本的话。您可以根据预期的查询模式松散一些GSI。
更新1
考虑到更新的需求,由于有许多基于标记的查询,我认为应该有第二个表,其结构如下
主分区键: TagName主排序键: UserID
全球二级索引
分区键: UserID
排序键:类似于标签计数的使用派生属性,标记的总使用量。
https://stackoverflow.com/questions/43830928
复制相似问题