Mapping属性详细介绍/常见的字段数据类型：

         映射(mapping)︰mapping是对索引库中文档的约束信息（例如字段名、数据类型），类似表的结构约束；每个索引库都应该有自己的映射          

        数据库一定要先创建表才能去添加数据。ES里面也一样，你得先有了索引库才能往里边去添加文档，要想去创建一个索引库，就像建表一样，建表语句里面是要指定个schemer，也就是对字段的一些约束。我们的索引库它在创建时需要去指定对应的mapping映射: 对文档的约束。

mapping常见的属性： 

       ES中的文档是jason风格的，作为一个jason，它里面要么是数值，要么是布尔值，要么是字符串，要么数组，要么是对象嵌套。这些类型对应到我们的这个ES中都有对应的一个类型去进行约束：

注意事项： 

• text是可分词的文本，比如说我这里的info，info是个人信息；
• keyword是精确值，它只有合在一起才有意义，不能拆开，如邮箱；
• index代表是否创建倒排索引，为true，就会给你创建倒排索引，就可以参与搜索了，如果说这儿给了false，就不会倒排索引，就没有办法去搜索这个字段。 它的默认值就是ture，也就是说你在做字段映射时，如果你不去设置index，默认所有的字段都会被创建倒排索引，将来每个字段都可以参与搜索。

• 我们在实际开发的过程中，不是所有的字段都需要搜索，比如邮箱、商品的图片是一个url地址，没有搜索意义。

• analyzer其实是结合text类型去用的，所有数据类型里，只有text类型需要分词，其他所有类型都无需分词

• 常见的字段数据类型还有 GEO 地理位置相关类型。

• 在ES当中是没有数组这种类型，但是它允许你某一个类型的字段有多个值，比如说你是一个部门类型，但是你里边有多个值没问题，数据类型要一致：

                                

       Object将来要结合Properties声明子字段 ，Properties是该字段的子字段。例如name有两个子属性：firstName 、 lastName, 将来我就可以用property来指定name的子属性：

                                                

ElasticSearch是如何实现Master选举的？

ElasticSearch的选举是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；

对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。

如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己， 那这个节点就是master。否则重新选举一直到满足上述条件。

前置前提：

1、 只有候选主节点（master：true）的节点才能成为主节点。

2、 最小主节点数（min_master_nodes）的目的是防止脑裂。

这个我看了各种网上分析的版本和源码分析的书籍，云里雾里。

核对了一下代码，核心入口为findMaster，选择主节点成功返回对应Master，否则返回null。选举流程大致描述如下：

第一步：确认候选主节点数达标，elasticsearch.yml设置的值discovery.zen.minimum_master_nodes；

第二步：比较：先判定是否具备master资格，具备候选主节点资格的优先返回；若两节点都为候选主节点，则id小的值会主节点。注意这里的id为string类型。

ElasticSearch如何避免脑裂？

可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上，来解决脑裂问题。

定义副本、创建副本的好处是什么？

副本是 分片的对应副本，用在极端负载条件下提高查询吞吐量或实现高可用性。

所谓高可用主要指：如果某主分片1出了问题，对应的副本分片1会提升为主分片，保证集群的高可用。

对于 GC 方面，在使用 Elasticsearch 时要注意什么？

1、 SEE

2、 倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segmentmemory 增长趋势。

3、 各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用，也就是各类缓存全部占满的时候，还有 heap 空间可以分配给其他任务吗？避免采用 clear cache等“自欺欺人”的方式来释放内存。

4、 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api 来实现。

5、 cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过 tribe node 连接。

6、 想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做持续的监控。

请解释一下 Elasticsearch 中聚合？

聚合的分三类：

主要查看7.10 的官方文档，早期是4个分类，别大意啊！

分桶 Bucket 聚合

根据字段值，范围或其他条件将文档分组为桶（也称为箱）。

指标 Metric 聚合

从字段值计算指标（例如总和或平均值）的指标聚合。

管道 Pipeline 聚合

子聚合，从其他聚合（而不是文档或字段）获取输入。

解释一下Elasticsearch Cluster？

Elasticsearch 集群是一组连接在一起的一个或多个 Elasticsearch 节点实例。

Elasticsearch 集群的功能在于在集群中的所有节点之间分配任务，进行搜索和建立索引。

说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段  

在并发情况下，Elasticsearch 如果保证读写一致？

（1）可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；

（2）另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

（3）对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。