Elasticsearch基础但很是有用的功能之一：别名

时间 2020-12-09

标签 html mysql linux git sql windows api 安全数据结构 app 栏目日志分析繁體版

原文原文链接

0、题记

本文是系列文章第一篇。介绍Elasticsearch的一些很是基础但实战开发确很是有用的技术点。了解这些技术点会帮助你设计更易于维护的数据索引，预先知道PB级大数据索引实战中的坑，提高工做效率。html

本文从别名分类、索引别名实践、索引别名的好处、索引别名常见问题及坑解读、字段别名实践一把五个方面进行详细解读。mysql

一、别名分类

别名在Elasticsearch中有两种分类。linux

1.1 索引别名

官方释义：索引别名能够指向一个或多个索引，而且能够在任何须要索引名称的API中使用。别名为咱们提供了极大的灵活性。它们容许咱们执行如下操做： git

1）在正在运行的集群上的一个索引和另外一个索引之间透明切换； sql

2）对多个索引进行分组组合（例如，lastthreemonths的索引别名：是过去3个月索引 logstash201903, logstash201904, logstash_201905的组合）；windows

3）在索引中的文档子集上建立“视图”（结合业务场景，会提高检索效率）。api

通俗解释：索引别名相似：windows的快捷方式，linux的软连接，mysql的视图。安全

前提：Elasitcsearch建立索引后，索引名不容许改。不少业务场景下单一索引可能没法知足要求。数据结构
场景1：PB级别增量数据，借助rollover api实现，由基于日期的n个索引组成，显然，对外提供服务使用别名会很便捷。app
场景2：试想，线上提供服务的某个索引出了问题，好比：某字段分词定义不许确，如何保证对外提供服务不中止（不更改业务代码）的前提下更换索引，显然，别名更合适。

注意：实际业务场景使用别名会很方便、灵活、快捷、业务松耦合！！

1.2 字段别名

在Elasticsearch Mapping定义的6.4+版本才有的字段类型。

通俗解释：

试想一下有一种业务场景。好比在实际的业务开发中：须要对Facebook、twitter行采集,采集入库的是两个业务团队。

他们对content，分别使用了两个字段。其中一个是，content。另一个是cont。这时候存储到elasticsearch会有两个字段。

这样若是咱们在检索、写业务代码的时候，是否是要写两个不一样的字段来处理呢？若是有可能写成一个字段，代码方面就很避开业务耦合，就很方便了。

我认为这是字段别名的由来。

二、索引别名实践

2.1 假设没有别名，如何处理多索引检索？

方式一：多索引逗号分隔检索。

POST visitor_logs_2017,visitor_logs_2018/_search

方式二：通配符索引检索。

POST visitor_logs_*/_search

2.2 有了别名后，操做变得简单

实战中，咱们不须要知道操做的实际索引名称，咱们能够透明地更改别名引用的索引而不会影响使用别名的用户。

步骤1：别名关联已有索引。

POST /_aliases?pretty
{
  "actions": [
    {
      "add": {
        "index": "visitor_logs_2017",
        "alias": "visitor_logs"
      }
    },
    {
      "add": {
        "index": "visitor_logs_2018",
        "alias": "visitor_logs"
      }
    }
  ]
}

步骤2：使用别名检索

GET /visitor_logs/_search

三、索引别名的好处

3.1 大数据量的管理

场景：实战中，可能须要基于时间的数据保留策略（利用rollover机制实现），并从系统中删除旧数据。使用索引别名：

好处1：来简化从Elasticsearch中删除数据的过程。
好处2：在没有任何停机时间的状况下从Elasticsearch中删除最旧的数据，不会出现任何查询中断，也不会进行任何客户端更改。

基于时间索引的实现机制以下：

推荐阅读：

https://gitbook.cn/books/5c52c6923417565017a61ce0/index.html

试想一下：若是不是基于时间的索引，而使用大索引，删除历史数据会发生什么？

答案：

一、删除索引数据只能使用：deletebyquery，相比删除索引，deletebyquery删除数据只是逻辑删除；
二、真正的删除实际是段合并后的物理删除分段，也就是deletebyquery后，有一段时间磁盘空间不降反升。此时的检索效率会很是低。

3.2 用户无感知的重建索引

实战中，索引的设计可能不是一步到位。随着业务的扩展，可能会在开发的中后期，调整索引Mapping结构，好比：

1）iksmart改为ikmax_word分词以高效分词，
2）long类型改为keyword以提高检索效率，
3）修改索引分片数以便于机器横向扩展，
4）索引分红更小粒度的索引等以提高性能。

一般的作法，都须要借助：reindex操做完成索引的迁移。若是要确保线上环境的可靠运行且用户无感知（即无需告知用户，不影响用户的业务），使用别名指向更改前和更改后的索引是绝佳方案。

实战举例:

POST /_aliases?pretty
{
  "actions": [
    {
      "remove": {
        "index": "visitor_logs_2018",
        "alias": "visitor_logs"
      }
    },
    {
      "add": {
        "index": "visitor_logs_2018_01",
        "alias": "visitor_logs"
      }
    }
  ]
}

试想一下，若是没有索引别名呢？

答案：

一、没法保证查询的连续性；
二、没法保证线上业务查询的可靠性（须要告知用户，业务中断一段时间）。

四、索引别名常见问题及坑解读

问题1：ES批量插入可使用别名插入吗？

会报错：

no write index is defined for alias[xxx]....

注意：索引别名不是在任何地方都通用。写入或更新数据的时候须要指明物理索引，不要向别名写入数据。

问题2：ES怎么获取全部别名信息 alias?

或者问题：如何经过索引别名查找实际索引名称？

GET _cat/aliases

返回信息：

visitor_logs visitor_logs_2017 - - -
.kibana      .kibana_1         - - -
visitor_logs visitor_logs_2018 - - 
`

问题3：使用别名和基于索引效率同样吗？

是一致的。

前提：索引和别名指向相同的数据，相同的检索条件。

原理：索引别名只是物理索引的软连接名称而已。

问题4：如何使用别名提高检索效率？

方式一：基于时间建立索引，指定多索引别名。好比分为：近1年索引别名，近3个月索引别名，近1个月索引别名，近1周索引别名，近3天索引别名。检索的时候，先敲定时间范围，而后在指定范围的别名下检索。

核心原理：物理上基于时间作了分隔，再加上冷热数据分离机制，会极大缩小了检索样本。

方式二：使用filter 别名或者路由别名机制，提高效率。 filter Alias上代码，实际业务中极易被忽视，但会极大提高效率。

POST /_aliases
{
    "actions" : [
        {
            "add" : {
                 "index" : "test1",
                 "alias" : "alias2",
                 "filter" : { "term" : { "user" : "kimchy" } }
            }
        }
    ]
}

路由机制参考官方文档便可。

五、字段别名实践一把

星友的问题：

“Aliasdatatype，这个数据类型，在现实工做中的使用场景是什么？看官方文档，没有很好理解？”

字段别名原理第一部分已详细解释，再也不赘述。这里实践一把，加深理解。

PUT trips
{
  "mappings": {
    "_doc": {
      "properties": {
        "distance": {
          "type": "long"
        },
        "route_length_miles": {
          "type": "alias",
          "path": "distance"
        },
        "transit_mode": {
          "type": "keyword"
        }
      }
    }
  }
}

注意：当用户使用检索时，实际可使用routelengthmile字段替代distance作检索，以达到distance同样的效果。

六、小结

实战中，通常在开发中后期才发现索引别名的妙处。正如文中分析：一、高效索引管理；二、用户无感知维护数据修改更新。
建议：相同索引别名的物理索引有一致的Mapping和数据结构，以提高检索效率。
注意：发挥索引别名在检索方面的优点，在写入和更新还得使用物理索引。

你的实际Elasticsearch业务场景，有哪些很是基础但实战开发很是有用的技术点呢？欢迎留言留下你的思考，让咱们一块儿精进！

参考：

https://cambium.consulting/articles/2018/2/22/our-favorite-elasticsearch-features-part-2-index-aliases