Azure 存储表记录过滤建议

Question

使用 Azure 存储表构建类似于博客发布系统的图像。 用户发布一条消息，数据库会记录用户的地区、城市和语言。

之后，用户可以浏览所有其他用户的帖子，并可以按地区、城市和语言的任意组合对其进行过滤。或者两者都不看。

我看到了几种解决方案：

1. 使用 Region-City-Language 组合将每条消息放在 8 个不同的分区中（优点：读取时闪电般的快速点查询；缺点：写入时每条消息 8 个事务）。
2. 将每条消息放在 4 个不同的分区中，结合区域-城市和执行分区扫描以按语言过滤的能力（优点：事务少于 (1)；缺点：分区扫描，每条消息 4 个事务）。李>
3. 根据用户 ID 将每条消息放入分区中（优点：每条消息单个事务；缺点：缓慢的表扫描和之后的分区扫描）。

我的看法：

1. 读取速度快，写入速度慢（可能代价高昂）。
2. 平衡的读/写/成本。
3. 写入速度快，读取速度慢（但成本低）。

“成本/便宜”是指基于交易（而非空间）的定价。 “平衡”是指在这些变体中。

考虑过使用索引表，但在这里看不到它们的帮助。 所以问题是，也许还有另一种更好的方法？

Answer 1

我决定采用 (1) 的变体。

不同之处在于我不会存储区域-位置-语言的所有组合。相反，我决定只存储唯一的：

Table: FiltersByRegion
----------------------
Partition:  Region
Row:        Location.Language
Prop:       Message

---

Table: FiltersByRegionPlace
---------------------------
Partition:  Region.Location
Row:        Language
Prop:       Message

---

Table: FiltersByRegionLanguage
------------------------------
Partition:  Region.Language
Row:        Location
Prop:       Message

---

Table: FiltersByLanguage
------------------------
Partition:  Language
Row:        Region.Location
Prop:       Message

---

因为我只存储唯一的事实，所以每个帖子不会有很多交易。只有那些尚未出现在数据库中的那些。

换句话说，如果有很多来自相同区域位置语言的帖子，则不会更新过滤表并且不会花费交易。唯一性测试可以使用 Redis 来加快速度。

过滤现在只是选择正确的表的问题。

Answer 2

这取决于您的场景和读/写模式。您可能需要考虑一些方面：

1. 设计如何查询记录。将它们放入以消息 ID 作为实体数据的“区域-城市-语言”分区中可能有助于您的快速查询。

2. 每条消息可能有唯一的消息ID，ID-消息映射保存在其他表中，那么每次更新消息时只需要更新一个表，其他表中引用的消息ID保持不变.

3. 在表设计中利用 ParitionKey 和 RowKey，并使用这两个键查询实体。例如：“Region-City-Language”作为分区键，“User”作为行键。

4. 考虑为查询方案存储实体的重复副本。例如，如果您有大量基于用户和基于语言的查询，您可以考虑有两个分别以“用户”和“语言”作为键的表。

有关完整指南，另请参阅https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/。