sql - 在什么情况下将基于联接的查询从 NoSQL 迁移到 SQL 是明智的

Question

我有一个 NoSQL 表(Azure 表存储)，用于保存视频元数据和流的 URL。其中分区键是视频 ID，行键定义该视频的版本。简化版:

|---------------------|------------------|---------------------|------------------|
|    Partition Key    |      Row Key     |        Stream       |       Hits       |
|---------------------|------------------|---------------------|------------------|
|    1500-8551-15     |         1        |     https://...     |        56        |
|---------------------|------------------|---------------------|------------------|

A new requirement asks to store the user that has viewed a video and how many times that user has watched it.

解决方案1

如果我们继续使用 NoSQL 解决方案，我们可以创建一个新列，以 JSON(或类似形式)保存所有唯一用户 ID - 足够容易解析。不幸的是，我们无法很好地跟踪哪个用户多次观看了某个视频。

解决方案2

然后我们可以使用第二个表来保存用户的唯一 ID、他们观看过的视频以及观看次数。分区键基于视频 ID，行键是用户 ID

|---------------------|------------------|---------------------|
|    Partition Key    |      Row Key     |        Views        | 
|---------------------|------------------|---------------------|
|    1500-8551-15     |     15085511     |          3          |
|---------------------|------------------|---------------------|

根据视频 key 编写查询很容易，并且如果我们有要查询的特定用户。

这一新要求可能是分析功能的开始。例如，将来我们可能想知道特定用户观看了哪些视频 - 在使用解决方案 2 时通过表扫描。数据集在一段时间内仍然足够小，不会对性能造成太大影响。 著名的遗言。

在这里，我们当前的设置不需要任何复杂的 SQL 功能，而且 NoSQL 对我们来说更便宜。如果将来我们需要编写一些简单的查询，NoSQL 可能仍然可以工作 - 但对于我们可能必须编写的复杂查询来说，NoSQL 就不行了。

什么时候转向关系数据库是明智的，因为几个更简单的查询在非关系数据库中就可以了，但大致的临界点是什么？

这不是关于每种数据存储类型的优缺点的问题，而是试图关注两者都可以完成工作的灰色区域以及何时从一种数据存储跳到另一种数据存储。

Answer 1

对此没有明确的答案，但以下是我对此主题的想法:

A - 解决方案 1 很糟糕，它不会让您跟踪用户，每次用户观看视频时都需要 JSON 更新(获取 JSON、更新并保存它)，而且，该列的值可以很快变得很大。

B - 解决方案 2 可以工作，但如果您希望能够查看用户观看了哪部电影，我建议添加第二个/反转表，其中分区键是 userId，行键是 movieId 。当然，每次用户观看电影时都需要两次更新，但您将避免表扫描，这是一种不好的做法，会导致性能随数据大小而下降。

C - SQL 不一定会提供更好的性能或具有任何附加值。除非您必须进行复杂的连接或完整的数据扫描(当您没有 userId 或 movieId 时)，否则类似于“查找观看了 5 部或更多电影的所有用户”或“查找观看同一部电影的一对用户” ”等

所以这实际上是一个架构问题，只有充分理解您期望的用例才能回答。

我希望这会有所帮助(: