非规范化与子/父和嵌套答案

【问题标题】：Denormalization vs Child/Parent & Nesting非规范化与子/父和嵌套
【发布时间】：2017-12-23 18:33:51
【问题描述】：

我们正在为活动设计 Elastic Search 模型，包括活动的日程安排和活动举办地点。设计如下：

我们可能需要的查询示例：

查找 2017 年 1 月 7 日至 2017 年 7 月 7 日之间的音乐会，即音乐会

寻找在伦敦演出的艺术家，该活动是戏剧表演

查找分数 > 70% 的电影事件

查找参加活动 AwesomeEvent 的用户

查找地点，地点是伦敦，并且从今天起计划在未来举办任何活动

我读过elastic doc 和一些像this 和一些堆栈questions 这样的文章。但我仍然不确定我们的模型，因为它非常具体。

可能的用法示例：

1) 使用嵌套模式

{
  "title": "Event",
  "body":  "This great event is going to be...",
  "Schedules": [ 
    {
      "name":    "Schedule 1",
      "start":   "7.7.2017",
      "end":     "8.7.2017"
    },
    {
      "name":    "Schedule 2",
      "start":   "10.7.2017",
      "end":   "11.7.2017"
    }
  ],
  "Performers": [ 
    {
      "name":    "Performer 1",
      "genre":   "Rock"
    },
    {
      "name":    "Performer 2",
      "genre":   "Pop"
    }
  ],
  ...
}

优点：

更扁平的模型应该坚持“键：值”方法
实体自己携带所有信息

缺点：

大量冗余数据
更复杂的实体

2) 以下实体之间的父/子关系（简化）

{
  "title": "Event",
  "body":  "This great event is going to be...",
}

{
  "title": "Schedule",
  "start":   "7.7.2017",
  "end":     "8.7.2017"
}

{
  "name":    "Performer",
  "genre":   "Rock"
}

优点：

避免重复冗余数据

缺点：

更多连接（甚至父/子都存储在同一shard）
模型不是那么平，性能我不确定

到目前为止，我们有一个关系数据库，其中模型运行良好，但速度不够快。尤其是当你想象一个电影院时，一个事件（电影）可以在不同的地方有数千个时间表，我们希望实现非常快速的过滤响应，正如我在第一部分中所写的那样。

我期待任何有助于正确设计数据模型的建议。我也会很高兴回顾我的假设（可能其中一些可能是错误的）。

【问题讨论】：

你不清楚。什么“模型”？什么“非规范化”？什么“假设”？您似乎有 2 种设计——非弹性（关系）和弹性。请给他们。解释你将如何使用它们。你似乎有两个“问题”——一个导致弹性和一个弹性“非规范化”。请解释一下。给出你的激励假设/期望/权衡。 PS请编辑掉你许多不清楚的句子和无法解释的联系。例如“当我在想……我很担心……”、“对我也是……”、“喜欢……”、“实际上将所有数据存储在弹性中”和“复制大量冗余信息”。
感谢您的回复。我添加了简化模型，还（我希望）更清楚地指定了我一直在考虑的模型并添加了一些示例。我还编辑掉了不清楚的句子。感谢反馈
不确定您是否已经阅读过这篇文章，但在您发布的文章中深深链接的this article 很好地总结了为什么您可以选择嵌套关系与父/子关系。这有帮助吗？或者您觉得那篇文章缺少什么？
好多了。我不知道您打算遵循什么（伪）ER 信息建模和/或数据库设计方法，但该图有两个未命名的 M:M 关联/关系，因此不清楚如何将它们映射到表，而且您不知道也不要说如何映射 M:1s。即你没有给出一个完整的关系模式。请给一个。（无类型更短。）包括 CKs & FKs & 任何其他约束。 PS 在问题中尽可能使用文本，即如果您给出了前面的内容，那么图表将是多余的。
一旦你比较清楚，你的问题的问题，就像所有“最佳”问题一样，是给定成本、收益和架构的唯一方法是说两种设计中哪种情况更好是尝试它们。并且通常“更好”的功能是混乱的——一个小的改变可以产生很大的不同——所以这对点告诉你关于任何其他点的信息很少。（我想说，你需要告诉我们你所说的“最好”是什么意思（比如任何技术术语）&我们可能会能够告诉你可能是什么——除了一个实用“最佳”既复杂又混乱。

标签： mysql elasticsearch filtering normalization nosql

【解决方案1】：

很难对数据进行非规范化。例如，一个事件中的表演者人数是未知的；因此，如果您要为表演者提供特定字段，则需要 perofrmer1.firstname、perofrmer1.lastname、perofrmer1.lastname、perofrmer2.firstname、performer2.lastname 等。但是，如果您使用嵌套字段，则只需在事件下定义一个嵌套字段 Performer具有正确子字段映射的索引，然后您可以添加任意数量的内容。这将使您能够按执行者或按事件执行者查找事件。这同样适用于其余索引。

就父子与嵌套而言，父子提供更多依赖，因为子文档驻留在完全独立的索引上。父子字段和嵌套字段都可以指定“include_in_parent”选项来自动为您非规范化字段

【讨论】：