Question

我有一个NoSQL表（Azure表存储），它包含视频元数据和流的URL。分区键是视频ID，行键定义该视频的版本。简化版：

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

新要求要求存储已观看视频的用户用户观看了多少次。

解决方案1 

如果我们继续使用NoSQL解决方案，我们可以创建一个新列，将所有唯一用户ID保存为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可以工作，但如果您希望能够查看用户观看的电影，我建议添加第二个/反向表，其中partition-key是userId，row-key是movieId 。当然，每次用户观看电影时都需要两次更新，但是您将避免使用表格扫描，这是一种不良做法，会使性能下降到数据大小。

C - SQL不一定会提供更好的性能或具有任何其他值。除非您必须进行复杂的连接或完整数据扫描（当您没有userId或movieId时），例如＆＃34;查找观看了5个或更多电影的所有用户＆＃34;或者＆＃34;查找同时观看同一部电影＆＃34;等的用户

所以这真是一个架构问题，只有充分了解您期望的用例才能得到解答。

我希望这有帮助（：

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

1 个答案: