ElasticSearch基本概念介绍

Elastic Search：一个基于lucene的搜索服务器，提供一个高可用、分布式多用户能力、开源的全文检索引擎、分布式文档存储引擎、数据分析引擎。可以存储、搜索和实时快速的分析大量数据。提供简单易用的RestFul API接口，Java API接口，设计与云计算中，能够达到实时搜索、稳定、可靠、快速、安装和使用方便。

Elastic Search的功能：
1、分布式搜索引擎和数据分析引擎；搜索：百度、电商网站的站内搜索、IT系统的检索；数据分析：电商网站最近7天某种商品销量排名前十的商家
2、全文检索、结构化检索、数据分析
3、对海量数据进行近实时的处理：ES自动可以将海量数据分散到多台服务器上去存储和检索。分布式以后，就可以采用大量的服务器去存储和检索数据，自然而然就可以实现 海量数据的处理了，另外，可以在秒级别对数据进行搜索和分析

Elastic Search适用什么类型的应用程序？
1、数据量较大，ES的分布式本质，可以帮你快速进行扩容，承载大量数据
2、数据结构灵活多变，随时可能变化，而且数据结构之前的关系非常复杂，如果我们用传统数据库，就很坑，要面临大量的表
3、对数据的相关操作，较为简单，比如就是一些简单的增删改查，用常用的document操作就能搞定
4、NOSQL数据库，适用的也是上面这种场景

举个例子，比如说一些网站系统，或者普通的电商系统、播客系统，面向对象概念比较复杂，但是作为终端网站来说，没什么太复杂的功能，就是一些简单的CURD操作，而且数据量还可能比较大，这时候选用ES这种NOSQL型的数据存储，比传统的支持复杂功能的关系型数据库，更加适合，无论是吞吐量，还是性能，都更好

Elastic Search的核心概念：
1、Near Realtime(NRT)：近实时，两个意思，从写入数据到数据可以被搜索到有一个小延迟（大概1秒），基于ES执行搜索和分析可以达到秒级

2、Cluster：集群，包含多个节点，每个节点属于哪个集群是通过一个配置（集群名称，默认是elasticsearch）来决定的，对于中小型应用来说，刚开始一个集群就一个节点很正常

3、node：节点，集群中的一个节点，节点也有一个名称（默认是随机分配的），节点名称很重要（在执行运维管理操作的时候），默认节点会去加入一个名称为“elasticsearch”的集群。如果直接启动一堆节点，那么它们会自动组成一个elasticsearch集群，当然一个节点也可以组成一个elasticsearch集群

4、Document，文档，es中的最小数据单元，一个document可以是一条用户数据，一条商品分类数据，通常用JSON数据结构表示，每个index下的type中，都可以去存储多个Document。一个document可以有多个field，每个field就是一个数据字段

5、Index，索引，包含一堆有相似结构的文档数据，比如，可以有一个客户索引、商品分类索引、订单索引，索引有一个名称，一个index包含多个document，一个index就代表了一类类似或者相同的document。比如说建立一个product index（商品索引），里面就可能存放了所有的商品数据，所有的商品document

6、Type，类型，每个索引里面有可以有一个或多个type，type是index中的一个逻辑数据分类，一个type下的document，都有相同的field，比如播客系统，有一个index，可以定义用户数据type，播客数据type，评论数据type。每一个type里面都会包含一堆document
例如：商品index中存放了所有的商品数据（商品document），但是商品分很多种类，每个种类的document的field可能不太一样，比如电器商品，可能包含一些诸如售后时间范围这样的特殊field；生鲜商品，可能包含一些诸如生鲜保质期之类的特殊field

7、shard，即primary shard，单台机器无法存储大量数据，es可以将一个索引中的数据切分成多个shard，每个shard就会存放这个index的一部分数据，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能，每个shard都是一个lucene index

8、replica，即replica shard，任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本，replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能；搜索读的请求也可以发送到replica，这样读的吞吐量即可翻倍。
primary shard（建立索引时一次设置，不能修改，默认5个）、replica shard（随时修改数量，默认一个），默认每个索引10个shard，5个primary shard，
5个replica shard，最小的高可用配置，是2台服务器（es规定shard和replica不在同一台服务器上）。

_index元数据
1、代表一个document存放在哪个index中
2、类似的数据放在一个索引，非类似的数据放不同索引，product index（包含了所有商品），sales index（包含了所有的商品销售数据），inventory index（包含了所有 库存相关的数据），如果把这些数据都放在一个大的index里面，显然是不合适的
3、index中包含了很多类似的document，类似指的就是这些document的fields很大部分是相同的，如果放了3个document，每个document的fields都完全不同，这就不是类似 了，就不太适合放到一个index中去了
4、索引名称必须是小写的，不能用下划线开头，不能包含逗号

_type元数据
1、代表document属于index中的那个类别（type）
2、一个index通常会划分为多个type，逻辑上对index中有些许不同的几类数据进行分类，因为一批相同数据可能有很多相同的fields，但是还是可能会有一些轻微的不同，可能 会有少数的fields是不一样的
3、type名称可以是大写或者小写，但是同时不能用下划线开头，不能包含逗号

_id元数据
1、代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document
2、可以手动指定document的id，也可以不指定，由es自动为我们创建一个id

手动指定document ID：
1、根据应用情况来说：是否满足手动指定document ID的前提：一般来说，是从某些其他的系统中导入一些数据到ES时，会采取这种方式，就是使用系统中已有数据的唯一标识， 作为document的ID。例如，现开发一个电商网站，做搜索功能，或者是OA系统，做员工检索功能。这个时候，数据首先会在网站系统或者IT系统内部的数据库中，会先有一份，此时就肯定会有一个数据库的primary key（自增长，UUID，或业务编号）。如果将数据导入到ES中，此时就比较适合采用数据在数据库中已有的primary key
2、put /index/type/id

如果说我们在做一个系统，这个系统主要的数据存储就是ES一种，即数据产生出来以后就没有ID，直接就放ES存储，那么这个时候，可能就不适合手动指定的方式，可采取让ES自动生成的方式

自动生成document ID：

1、post /index/type

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

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

document数据：

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "test_content": "test test"
  }
}

type底层数据结构：
1、type是index中用来区分类似的数据的，但是可能有不同的fields，而且有不同的属性来控制索引建立，分词器
2、field的value在底层的lucene建立索引的时候，全部是opaque bytes类型，不区分类型的
3、lucene是没有类型的概念的，在document中，实际上讲type作为document的一个field来存储，即_type，es通过_type来进行type的过滤和筛选
4、一个index中的多个type，实际上是放在一起存储的，因此，一个index下，不能有多个type重名，而类型或其他设置不同的，因为那样是无法处理的

{
   "ecommerce": {             ##index
      "mappings": {
         "elactronic_goods": {      ##type
            "properties": {
               "name": {
                  "type": "string",
               },
               "price": {
                  "type": "double"
               },
           "service_period": {
          "type": "string"
           }            
            }
         },
         "fresh_goods": {       ##type
            "properties": {
               "name": {
                  "type": "string",
               },
               "price": {
                  "type": "double"
               },
           "eat_period": {
          "type": "string"
           }
            }
         }
      }
   }
}

例如数据：

{
  "name": "geli kongtiao",
  "price": 1999.0,
  "service_period": "one year"
}
{
  "name": "aozhou dalongxia",
  "price": 199.0,
  "eat_period": "one week"
}

底层存储：

{
  "_type": "elactronic_goods",
  "name": "geli kongtiao",
  "price": 1999.0,
  "service_period": "one year",
  "eat_period": ""
}
{
  "_type": "fresh_goods",
  "name": "aozhou dalongxia",
  "price": 199.0,
  "service_period": "",
  "eat_period": "one week"
}

最佳实践，把有类似结构的type放在一个index下面，这些type应该有很多field是相同的
假如说，你将两个type的field完全不同，放在一个index下面，那么就每条数据都至少有一半的field在底层的lucene中是空值，会有严重的性能问题

总结归纳：
1、一个index包含一个或多个shard
2、每个shard都是一个最小工作单元，承载部分数据，也称为一个lucene实例，具有完整的建立索引和处理请求的能力
3、增删节点时，shard会自动在nodes中负载均衡
4、primary shard和replica shard，每个document肯定只存在于某一个primary shard和其对应的replica shard中，不可能存在于多个primary shard
5、replica shard是primary shard的副本，负责容错，以及承担读请求负载
6、primary shard的数据在创健index的时候就固定了，replica shard的数量可以随时修改
7、primary shard的默认数量是5， replica shard默认是1，默认有10个shard，5个primary shard，5个replica shard
8、primary shard不能和自己的replica shard放在同一个节点上（否则节点宕机，primary shard和副本都丢失，起不到容错的作用），但是和其他primary shard的
replica shard放在同一个节点上
9、一个primary shard的多个replica shard也是不允许放在同一个节点上的。例如，一个primary shard，有3个replica shard，这3个replica shard不允许在同一节点