Elasticsearch：Elasticsearch 中索引映射的非规范化

Elastic 中国社区官方博客

已于 2022-10-24 23:07:29 修改

阅读量1.7k

点赞数

分类专栏： Elastic Elasticsearch 文章标签： elasticsearch 大数据数据库 1024程序员节

于 2021-03-08 11:39:29 首次发布

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/UbuntuTouch/article/details/114523140

版权

Elastic 同时被 2 个专栏收录

1848 篇文章

订阅专栏

Elasticsearch

1264 篇文章

订阅专栏

在写这篇文章之前，我首先来讲一下 normlization （规范化）以及 denormalization (非规范化）两个概念的区别。

Normalization （规范化）：规范化是数据库中用于减少表中数据冗余和数据不一致的方法。这是将非冗余和一致性数据存储在设置的架构中的技术。通过使用规范化，表的数量增加而不是减少。

Denormalization（非规范化）: 非规范化也是数据库中使用的方法。它用于添加冗余以快速执行查询。它是一种将数据组合起来以快速执行查询的技术。通过使用非规范化，减少了与规范化相反的表数量。

规范化和非规范化之间的区别
系号	在规范化中，非冗余和一致性数据存储在集合模式中。	在非规范化中，数据被组合以快速执行查询。
1	在规范化中，减少了数据冗余和不一致。	在非规范化中，添加了冗余以快速执行查询
2	数据完整性通过规范化维护。	在非规范化中无法保持数据完整性。
3	在规范化中，减少或消除了冗余。	在非规范化中，添加了冗余，而不是减少或消除了冗余。
4	规范化中的表数量增加了。	非规范化，表数减少。
5	规范化优化了磁盘空间的使用。	归一化不会优化磁盘空间。

在很多的描述中， Elasticsearch 被描述为：store （存储），analyze (分析）及 search（搜索）。也就是说 Elasticsearch 也是一个数据库。我们必须了解的一点是 Elasticsearch 它不是一个 RDMS，也即关系数据库。你不可以在搜索的时候 join 不同的索引。非规范化是不自然的，但是这是提高 Elasticsearch 应用程序效率的关键。在实际的使用中，尽早考虑数据映射将使你的应用运行数年。

为什么要使用非规范化？

如果你寻找 Elasticsearch 的定义，则可能会发现以下内容：

Elasticsearch 是基于 Apache Lucene 构建的分布式开源搜索和分析引擎

但是也有很多人是这么说的：

Elasticsearch 是为搜索优化的分布式 NoSQL 数据库

NoSQL 数据库带有其自己的规则。通常，它们针对特定用例进行了优化，并且设计为最适合特定需求。因此，当 Elastic 优化其 NoSql 数据库进行搜索时，重点是 SPEED。在分析经典关系数据库的性能时，我们都知道 JOIN 具有成本，并且可能非常繁重且非常缓慢。

最大限度地提高它们的最佳方法是…删除它们。

因此，在 Elasticsearch 中，索引不能与另一个索引 join。因此，如果需要数据，则必须将其包含在索引中。

作为开发人员，多年来，你一直在努力利用规范化的技术水平，从未在任何地方重复任何信息。你应该为某些 DB Design 感到骄傲。

如何使你的数据结构非规范化？

在等效的 SQL 中，你的目标是将多个表收集到一个表中。为此，你将不得不扁平并重复很多次！但这是将 200 毫秒的响应时间转换为 5 毫秒的关键。在 Elasticsearch 范例中优化数据并不意味着与在 PostgreSQL 中优化数据相同。

我们来看一个非常简单的博客数据库示例：

经典规范化博客文章模型

首先，我们会问自己要搜索什么？
我们想搜索帖子，因此我们的索引将放在帖子（而不是博客）上，并将针对我们的搜索用例跟踪有趣的数据。

然后，Elasticsearch 文档可能看起来像这样：

POST denormalized-blog-posts
{
  "id": "12345",
  "title": "Denormalization for elastic search",
  "post_content": "my long text content",
  "blog": {
    "id": 1,
    "title": " Elasticsearch is a powerful search engine",
    "slogan": "better, faster, bigger",
    "user": {
      "id": "1",
      "username": "John"
    }
  },
  "tags": [
    "elasticsearch",
    "bdd",
    "beginner"
  ]
}

在这里：

针对每个 blog， user 部分都会在每个帖子上重复
我们只对 tag 名称感兴趣。因此，我们将它们平整为数组在我们的每个帖子上。

我们可以简单地把一个 Elasticsearch 的文档和一个传统的关系数据库表格的结构做一个比较：

在右边的数据库是关系数据库。STUDENT 和 ADDRESS 表由外键 ADDRESS_ID 关联，外键 ADDRESS_ID 表示在两个不同的表中。 Elasticsearch 没有关系的概念，因此整个学生文档都存储在一个索引中。内部对象（图 3.4 中的 “address” 字段）也与主字段位于相同的索引中。

Elasticsearch 中的数据被非规范化以帮助快速搜索和检索，这与关系数据库中的数据以各种形式进行规范化不同。虽然你可以在 Elasticsearch 中某种程度上创建父子关系，但它确实存在潜在的瓶颈和性能下降。如果你的数据预计是关系型的，那么 Elasticsearch 可能不是正确的解决方案。有关如何建立父子关系的文档，请参阅文章 “Elasticsearch：在 Elasticsearch 中的 join 数据类型父子关系”。

作为 Elasticsearch 中的新手，这可能会非常令人不安，但我们必须这么做，这样才能使得我们的搜索效率更高。

在 Elasticsearch 中，确实有一个叫做 join 的数据类型。它能解决一部分关系数据库中的 join 问题，详细阅读请参阅文章 “Elasticsearch：在 Elasticsearch 中的 join 数据类型父子关系”