在什么时候将基于连接的查询从NoSQL移到SQL是明智的

Question

我有一个NoSQL表()，它包含视频元数据和流的URL。其中分区键是视频ID和行键，定义了视频的版本。简化版本：

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

一项新的要求要求存储观看过视频的用户以及该用户观看视频的次数。

解决方案1

如果我们继续使用一个NoSQL解决方案，我们就可以创建一个新列，该列将所有惟一的用户If都保存为JSON (或类似的)--非常容易解析。不幸的是，我们无法跟踪哪个用户多次很好地看到了视频。

解决方案2

然后，我们可以使用第二个表来保存用户的唯一id，他们看了哪些视频，看了多少次。分区键基于视频ID，行键是用户ID。

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

查询非常容易，可以根据视频键编写，如果我们有一个特定的用户，我们想要查询。

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

在这里，我们目前的设置不需要任何复杂的SQL特性，而且NoSQL对我们来说更便宜。如果将来我们需要编写一些简单的查询，那么NoSQL可能还能工作--但是我们可能不得不编写复杂的查询。

在什么时候转移到关系数据库是明智的，因为几个简单的查询在非关系的范围内很好，但是大致上是什么临界点呢？

这不是关于每种类型的数据存储的利弊的问题，而是集中在两个都可以完成工作的灰色区域，以及何时从一个跳到另一个。

Answer 1

对此没有明确的答案，但以下是我对这个问题的看法：

A-解决方案1是各不相同的，它不会让您跟踪用户，它将需要一个JSON更新(获取JSON，更新它并保存它)，每次一个用户观看一个视频，而且，这个专栏的价值可以变得非常大非常快。

B-解决方案2可以工作，但是如果您想查看用户观看的电影，我建议添加第二个/反转表，其中分区键是userId，行键是movieId。当然，这将需要用户每次观看电影时进行两次更新，但您将避免表扫描，这是一种糟糕的做法，会使性能下降到数据大小。

C不一定会提供更好的性能，也不一定会有任何附加值。除非您需要进行复杂的连接或完整的数据扫描(当您没有userId或movieId)，比如“查找所有看过5部或5部以上电影的用户”或“查找两个同时看过同一部电影的用户”等。

因此，只有充分理解所期望的用例，才能回答架构问题。

我希望这会有所帮助(：