Elasticsearch分布式机制和document分析

1. Elasticsearch对复杂分布式机制的透明隐藏特性

1.1）分片机制

1.2）集群发现机制

1.3）shard负载均衡

1.4）shard副本，请求路由，集群扩容，shard重分配

2. Elasticsearch的垂直扩容与水平扩容

垂直扩容：采购更强大的服务器，成本非常高昂，而且会有瓶颈；

水平扩容：普通服务器组织在一起，就能构成强大的计算和存储能力；

3. 分布式架构

ES中节点时平等的，每个节点都能接受请求，他会自动路由请求到对应的node上，在获取到数据的时候，在把接受到的数据返回；

master节点：他是负责管理ES中元数据，维护索引的元数据和集群的元数据；默认情况下，会自动选择一台节点，作为master节点，master节点不承载所有的请求，所以不会单点瓶颈；

4.shard & replica机制

1）index包含多个shard；

2）每个shard都是一个最小工作单元，承载部分数据，lucene实例，完整的建立索引和处理请求的能力；

3）增减节点时，shard会自动在nodes中负载均衡；

4）primary shard和replica shard，每个document肯定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard；

5）primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改；

6）primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard；

7）primary shard不能和自己的replica shard放在同一个节点上（否则节点宕机，primary shard和副本都丢失，起不到容错的作用），但是可以和其他primary shard的replica shard放在同一个节点上；

5. 索引创建时的设置

PUT /test_index
{
       "settings" : {
            "number_of_shards" : 3,
            "number_of_replicas" : 1
       }
}

6. Elasticsearch的容错机制

1）master node 宕机，一个primary shard就没了，此时就不是所有的primary shard 都active了，所以status=red;

2）容错第一步：master选举，选择另一个节点为新的master；

3）容错第二步：新的 master将丢掉的primary shard的节点的replica shard提升为primary shard， 此时的cluster status=yellow。因为primary shard 全部是active了，但是少了一个replica shard；

4）容错第三步：重启故障的node，new master 将缺失的数据copy一份到该node上，该node还是会使用之前的数据，只是同步一下宕机之后发生的修改；

7. Elasticsearch的元数据

1） _index元数据

    1.1）代表一个document存放在哪个index中

    1.2）类似的数据放在一个索引，非类似的数据放不同索引

    1.3）index中包含了很多类似的document：类似是什么意思，其实指的就是说，这些document的fields很大一部分是相同的，你说你放了3个document，每个document的fields都完全不一样，这就不是类似了，就不太适合放到一个index里面去了。

    1.4）索引名称必须是小写的，不能用下划线开头，不能包含逗号;

2)  _type元数据

   2.1）代表document属于index中的哪个类别（type）

   2.2）一个索引通常会划分为多个type，逻辑上对index中有些许不同的几类数据进行分类：因为一批相同的数据，可能有很多相同的fields，但是还是可能会有一些轻微的不同，可能会有少数fields是不一样的;

   2.3）type名称可以是大写或者小写，但是同时不能用下划线开头，不能包含逗号;

3) _id元数据

   3.1）代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document;

   3.2）我们可以手动指定document的id（put /index/type/id），也可以不指定，由es自动为我们创建一个id;

   3.2.1 手动指定document id

            根据应用情况来说，是否满足手动指定document id的前提：

           一般来说，是从某些其他的系统中，导入一些数据到es时，会采取这种方式，就是使用系统中已有数据的唯一标识，作为es中document的id。举个例子，比如说，我们现在在开发一个电商网站，做搜索功能，或者是OA系统，做员工检索功能。这个时候，数据首先会在网站系统或者IT系统内部的数据库中，会先有一份，此时就肯定会有一个数据库的primary key（自增长，UUID，或者是业务编号）。如果将数据导入到es中，此时就比较适合采用数据在数据库中已有的primary key。

          put /index/type/id

        PUT /test_index/test_type/2
       {
        "test_content": "my test"
       }

     3.2.2、自动生成 document id

        post /index/type

        POST /test_index/test_type
          {
        "test_content": "my test"
         }

          自动生成的id，长度为20个字符，URL安全，base64编码，GUID，分布式系统并行生成时不可能会发生冲突;

4） _source元数据

put /test_index/test_type/1
{
  "test_field1": "test field1",
  "test_field2": "test field2"
}

get /test_index/test_type/1

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field1": "test field1",
    "test_field2": "test field2"
  }
}

_source元数据： 我们在创建一个document的时候，使用的那个放在request body中的json串，默认情况下，在get的时候，会原封不动的给我们返回回来。

定制返回结果： GET /test_index/test_type/1?_source=test_field1,test_field2