ElasticSearch面试题2

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 使用情况做持续的监控。