1. 索引别名

在开发中，随着业务需求的迭代，较老的业务逻辑就要面临更新甚至是重构，而对于ES来说，为了适应新的业务逻辑，可能就要对原有的索引做一些修改，比如对某些字段做调整，甚至是重建索引，而做这些操作的时候，可能会对业务造成影响，甚至需要停机调整，由此，ES引入了索引别名来解决这些问题，索引别名就像一个快捷方式或是软链接，可以指向一个或多个索引，也可以给任意一个需要索引别名的API来使用，别名的应用为程序提供了极大的灵活性。

• 查询别名

  # 查询所有索引的别名
  GET _alias
  # 查询某个索引的别名
  GET /index_name/_alias
  

• 新增别名

  # 方法一
  POST /_aliases
  {
    "actions": [
      {
        "add": {
          "index": "index_name",
          "alias": "index_name_v1.0"
        }
      }
    ]
  }
  
  # 方法二
  PUT /index_name/_alias/index_name_v1.0
  

• 删除别名

  # 方法一
  POST /_aliases
  {
    "actions": [
      {
        "remove": {
          "index": "index_name",
          "alias": "index_name_v1.0"
        }
      }
    ]
  }
  
  # 方法二
  DELETE /index_name/_alias/index_name_v1.0
  

• 重命名

  POST /_aliases
  {
    "actions": [
      {
        "remove": {
          "index": "index_name",
          "alias": "index_name_v1.0"
        }
      },
      {
        "add": {
          "index": "index_name",
          "alias": "index_name_v2.0"
        }
      }
    ]
  }
  

• 多个索引指定一个别名

  POST /_aliases
  {
    "actions": [
      {
        "add": {
          "index": "index_name1",
          "alias": "alias_name"
        }
      },
      {
        "add": {
          "index": "index_name2",
          "alias": "alias_name"
        }
      }
    ]
  }
  

• 一个索引指定多个别名

  POST /_aliases
  {
    "actions": [
      {
        "add": {
          "index": "index_name",
          "alias": "alias_name_1"
        }
      },
      {
        "add": {
          "index": "index_name",
          "alias": "alias_name_2"
        }
      }
    ]
  }
  

• 通过别名查询索引，如果多个索引都是这个别名，那么就是查询多个索引

  GET /alias_name/_search
  {
    "query": {...}
  }
  

• 通过别名写数据到索引

  PUT /alias_name/type_name[/id]
  {
    data...
  }
  
  # 如果多个索引都是这个别名，那么可以指定具体写入哪个索引
  # is_write_index设置了此索引是可以通过此别名被写入的索引
  POST /_aliases
  {
    "actions": [
      {
        "add": {
          "index": "index_name1",
          "alias": "alias_name",
          "is_write_index": true
        }
      },
      {
        "add": {
          "index": "index_name2",
          "alias": "alias_name"
        }
      }
    ]
  }
  

2. 索引重建

Elasticsearch的索引在创建好之后其数据结构和一些固有设置是不能修改的，如果一定要修改其数据结构和某些设置例如主分片的个数，那么就必须重建索引，ES提供了一些辅助工具来支持索引重建。

索引重建步骤：

• index_old取一个别名index_service，index_service对外提供服务
• 新创建一个索引index_new，数据结构与index_old一样，但是根据需求修改了某些字段或者修改了某些设置
• 将index_old的数据同步到index_new
• 给index_new取别名index_service，删除index_old的别名
• 删除index_old

案例：

# 创建index_old
PUT index_old
{
  "mappings": {
    "_doc": {
      "properties": {
        "id": {"type": "long"},
        "name": {"type": "text"}
      }
    }
  }
}

POST /_bulk
{"index":{"_index":"index_old","_type":"_doc","_id":"1"}}
{"id": 1001, "name": "张三丰"}
{"index":{"_index":"index_old","_type":"_doc","_id":"2"}}
{"id": 1002, "name": "张无忌"}
{"index":{"_index":"index_old","_type":"_doc","_id":"3"}}
{"id": 1003, "name": "虚竹"}
{"index":{"_index":"index_old","_type":"_doc","_id":"4"}}
{"id": 1004, "name": "云中鹤"}
{"index":{"_index":"index_old","_type":"_doc","_id":"5"}}
{"id": 1005, "name": "杨过"}

# 此时我们要把name字段的类型由text修改为keyword，就必须重建索引
# 1.index_old取一个别名index_service，index_service对外提供服务
POST /_aliases
{
  "actions": [
    {
      "add": {
        "index": "index_old",
        "alias": "index_service"
      }
    }
  ]
}

# 2.新创建一个索引index_new，数据结构与index_old一样，但是name字段的类型为keyword
PUT index_new
{
  "mappings": {
    "_doc": {
      "properties": {
        "id": {"type": "long"},
        "name": {"type": "keyword"}
      }
    }
  }
}

# 3.将index_old的数据同步到index_new
# ES6.X需要指定旧索引的type和新索引的type
POST /_reindex?wait_for_completion=false
{
  "source": {
    "index": "index_old", 
    "type": "_doc"
  },
  "dest": {
    "index": "index_new", 
    "type": "_doc"
  }
}
# ES7.X不需要指定type
POST /_reindex?wait_for_completion=false
{
  "source": {
    "index": "index_old"
  },
  "dest": {
    "index": "index_new"
  }
}
# wait_for_completion=true，同步执行，会一直等待直到同步完成或者报错，默认
# wait_for_completion=false，异步执行，返回taskId，然后后台进行同步，数据量大的情况下建议使用

# 4.将index_old的别名删除，index_new的别名设置为index_service
POST /_aliases
{
  "actions": [
    {
      "remove": {
        "index": "index_old",
        "alias": "index_service"
      }
    },
    {
      "add": {
        "index": "index_new",
        "alias": "index_service"
      }
    }
  ]
}

# 5.删除index_old
DELETE /index_old

3. refresh、flush和merge

3.1 document写入原理一

• 一个document先被写入一个内存buffer中
• 当Buffer被写满或者到达一定时间后，执行commit操作，将buffer中的所有数据写入到segment中，一个index在物理上就是由多个segment文件组成的，但此时将buffer中的数据写到segment中，并非是写入磁盘，而是先写到页面缓存中，也就是OS Cache中
• 如果是删除操作，那么在commit的时候，会往.del文件中将此document标记为"delete"，搜索的时候，比如搜索到id=1的文档，发现在.del文件中已经被标记为"delete"了，就不会返回这条数据
• 如果是更新操作，那么commit的时候，那么在.del文件中将旧数据标记为"delete"(document是有版本的)，然后将新数据写入到新的segment中，查询的时候返回最新版本的document
• 然后OS cache将segment刷写到磁盘上，形成segment文件，然后对这个segment文件执行一个"open"操作，这个这个segment文件就可以用于搜索了，同时刷写到磁盘之后，还会清空内存buffer

3.2 document写入原理二：refresh

上述流程是有问题的，从写入一条document到OS Cache将segment刷写到磁盘，并且该segment被打开允许搜索这个过程是有延迟的，可能达到min级别，这就不是近实时的搜索了，上述流程的主要瓶颈在于OS Cache将segment刷写到磁盘的过程，于是，我们想，只要数据被写入OS Cache中了，就可以被搜索，而不用刷写到磁盘后才能搜索，这样就可以提高搜索效率，索引刷新(refresh)功能就是让某条数据在写入OS Cache后就可以被搜索。

refresh默认时间间隔是1s，也就是说每隔一秒，将buffer中的数据写入到OS Cache中，并且允许该数据被搜索。

# 数据写入就强制刷新
PUT /index_name/type_name/id?refresh
{
  "data": "..."
}

# 设置index的刷新时间
PUT /index_name/_settings
{
  "index": {
    "refresh_interval": "5s"
  }
}

3.3 document写入原理三：translog和flush

在原理二的优化之后，ES就可以满足近实时的查询效率，但是还有一个问题是可靠性，因为document在真正的写入磁盘之前都是在内存中的，那么ES宕机就可能会丢失数据，Translog文件可以解决这个问题：

改进后得流程如下：

(1) document写入buffer缓冲，同时写入Translog日志文件

(2) 每隔1s，buffer中的数据被写入新的segment，并进入OS Cache，此时segment被打开并可以用于搜索

(3) buffer被清空

(4) 重复(1)-(3)，新的segment不断添加，buffer不断被清空，而translog中的数据不断累加

(5) 当translog的大小达到一定程度，触发flush操作：

​ (5-1) buffer中的所有数据写入一个新的segment，并写入OS Cache，segment被打开并可以用于搜索

​ (5-2) buffer被清空

​ (5-3) 一个commit ponit文件被写入磁盘，其中标明了index当前所有的segment有哪些

​ (5-4) OS Cache中的所有segment缓存数据，被强行刷写到磁盘上

​ (5-5) 现有的translog被清空，创建一个新的translog

基于Translog如何进行数据恢复？

ES宕机之后，内存中的数据全部丢失，重启之后，上一次flush之后的全部数据都在Translog中保存着，将这些数据重新加载到内存buffer中并形成一个个segment然后写入OS Cache中即可。

相关设置参数如下：

index.translog.durability：新增、删除，更新或批量操作之后是否写入Translog并触发flush操作

• request(默认)：每次请求都写入Translog并触发flush操作
• async：按照时间间隔来写入Translog并触发flush操作

index.translog.sync_interval：写数据请求提交到Translog并触发flush操作的时间间隔，默认5s，最小不能低于100ms

index.translog.flush_threshold_size：Translog触发flush操作的文件大小阈值，默认512mb

PUT /index_name/_settings
{
    "index.translog.durability": "async",
    "index.translog.sync_interval": "5s"
}

# 手动触发flush操作
POST /index_name/_flush

3.4 document写入原理四：segment merge

在上述写入流程中，每秒生成一个segment，segment数量太多，每次search都要搜索所有的segment，性能不好，ES默认会在后台执行segment merge操作，在merge的时候，被标记为deleted的document也会被彻底物理删除，每次merge操作的执行流程：

• 选择一些有相似大小的segment，merge成一个大的segment

• 将新的segment flush到磁盘上去

• 写一个新的commit point，其中记录着新的segment的元数据，删除那些旧的segment的元数据

• 将新的segment打开用于搜索

• 将旧的segment删除

手动执行merge的API：

# max_num_segments指定了合并之后的segments个数
POST /index_name/_optimize?max_num_segments=1