电影数据库 - 演员/女演员/标签的存储？答案

【问题标题】：Movie DB - storage of Actors / actress / Tags?电影数据库 - 演员/女演员/标签的存储？
【发布时间】：2010-12-20 22:06:48
【问题描述】：

创建一个电影数据库，我不喜欢给每个演员/女演员和每个标签自己的行的想法，好像总共有 1000 万个电影，每个有至少 20-30 人的演员，我们将有 200-表中有 3 亿行。

而且标签变得更加复杂，每部电影可以不受限制。那么如何最好地存储这 3 个项目呢？理想情况下，这些可以建模为多对多，但仍然会有数亿行。关于存储这些有什么更好的建议吗？我正在使用 MySQL。

我会将其全部转储到一个文本文件中，但我需要在电影之间链接演员并进行一些分析，并允许用户对演员进行评分，按标签查找电影等，因此需要使用数据库。

【问题讨论】：

我会说你不能真正绕过多对多，它甚至听起来是最有效的存储方式。我将坐在这里，看着真正的 DBA 用他们的见解启发我们。
我认为您正在担心一个您没有遇到的问题。您有一个可以巧妙地映射到关系模型的域，其中 RDBM 具有有助于提高性能的功能（索引、分区）。按照所有答案所暗示的设计思路构建事物，并与您的 DBA 就优化它的方法进行交流如果证明有必要
可悲的是，我是我自己的 DBA！所以我一直在学习。但是，是的，我会尝试人们所说的话，并使用大约 1000 万个样本数据集检查性能，然后再反馈它是如何工作的。
@dave 你最终是如何解决这个问题的？

标签： mysql database schema

【解决方案1】：

1000 万部电影似乎雄心勃勃。 IMDb's current statistics 表明他们拥有少于 180 万个标题和大约 390 万用户。

话虽如此，我认为创建一个标题表、一个演员表和一个连接表来解决两者之间的多对多关系没有问题。标签也是如此。

【讨论】：

IMBD 更适合英文电影。我正在尝试从一开始就建立一个多合一的电影数据库，所有国家，所有语言，所有世界演员。此外，这也包括电视节目。
@dave：我仍然认为，通过适当的索引和查询调优，这种设计会很好。
好的，这对演员来说可能会成立。我会对其进行基准测试，但电影标签呢？这些可以是一片开阔的海域。
+1：从这个设计开始，根据需要进行修改。向后水平分区，IF 性能指标决定。
@dave：我会对标签采用相同的方法。正如@p.campbell 所说，从这里开始并根据需要进行调整。如果事情开始失控，你总是可以对每部电影施加 X 个标签的合理限制。

【解决方案2】：

这里听起来可能有点premature optimization。您可以将所有参与者非规范化为 Movie 表上某种类型的 TEXT 列，但您的性能和搜索会受到影响，并且会失去关系数据的所有好处。

建议按照您最初的想法保留标准化架构：

Movie (ID)
Actor (ID)
Tag (ID) --horror, comedy, etc.

MovieActor (MovieID, ActorID)
MovieTag (MovieID, TagID)

在关联实体上照常创建索引：MovieActor 和 MovieTag。
在测试环境中加载一些虚拟数据。 1000 万部电影，1 亿演员，100 万个标签。根据需要为每个条目创建关联条目。
基线和性能测试。
Horizontal partitioning (sharding) 如果您的性能指标需要更高的性能。

无论电影数量如何，或数据是否为 DNA 序列：实施设计、测试、根据您的要求（用户接受度、SLA 等）判断其性能

【讨论】：

MovieTag (MovieID, TagID) = 每部电影 1 个标签？但是这个标签可以在很多电影中，所以要找到所有带有给定标签的电影，我需要逐个标签搜索？
@dave：正确。如果索引正确，数据库在查找给定 TagID 方面表现出色。
听起来不错，将加载虚拟数据并检查性能，然后发回。

【解决方案3】：

您厌恶数百万行的原因是什么？感知到的性能问题？

它将在某个地方拥有数亿个关系。您确实必须捕捉演员和电影之间的映射，正如您所说，其中有 200-3 亿部（尽管我不相信存在 1000 万部电影？）

如果您真的想要，您可以（例如）将一部电影的演员 ID 打包到多列（或一列）中，但这会使搜索变得不愉快。

【讨论】：

创建巨大的查找表。增加搜索时间。更多行 = 更多要管理的数据。电影遍布全球，此外还包括电视节目。我正在尝试创建一个全球娱乐数据库，以便从电影开始到日期，全球所有电影、所有电视节目。
但是数据在那里（这就是为什么我说“关系”而不是行）。它是您正在使用的数据中固有的，您必须以某种方式对其进行管理。大的“谁在什么”表可以以各种方式进行分区，但你将不得不以某种方式存储这些关系
更多行 = 更少需要管理的数据。每个更改只影响最少量的数据——添加演员需要在子表中添加一小行，而不是锁定电影的大量主记录。更新演员的姓名或出生日期只会影响数据库中的一个演员行。
好点。我把它画出来看看。但是标签呢？对我来说，标签就像一本字典。每个单词都可以映射到数百万部电影中的任何一个，所以不要告诉我我需要 (X) 百万部电影 x (X) 百万个单词来存储电影标签？
@dave：也许你的意思是，2 行比列便宜得多。考虑替代方案：在 Movie 实体的 varchar 列中大量重复的标签和演员姓名。

【解决方案4】：

1000 万部电影，每部电影有 20 到 30 名演员（尽管这个数字听起来比现实生活中的要高）总是会带来 200-3 亿个联想。如果您将数据存储在关系数据库中，则每个关联自然会是表格中的一行，将电影与演员联系起来。每行将非常小（两列 - 电影 PK 和演员 PK；可能是一个额外的代理键列）；大部分数据将存储在电影和演员表中。

任何其他解决方案（在 SQL 数据库中）都会以不太理想的格式存储相同数量的数据。

【讨论】：