1、为什么要用es
我们的要求：（1）搜索解决方案要快（2）最好是有一个零配置和一个完全免费的搜索模式（3）我们希望能够简单地使用JSON/XML通过HTTP的索引数据
（4）我们希望我们的搜索服务器始终可用，并能够从一台开始并在需要扩容时方便地扩展到数百（5）我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案
2、es的优点（lucene的缺点es都已解决）
Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。但是，Lucene只是一个库，使用非常复杂。
lucene缺点：
1）只能在JAVA项目中使用,并且要以jar包的方式直接集成项目中.
2）配置及使用非常复杂-创建索引和搜索索引代码多
3）不支持集群环境-索引数据不同步（不支持大型项目）
4）索引数据如果太多就不行。索引库和应用所在同一个服务器,共同占用硬盘.共用空间少.
3、es解决了lucene的那些缺点：
（1） 优化Lucene的调用方式，通过简单的 RESTful API来隐藏Lucene的复杂性（调用简单）
（2）并实现了高可用的分布式集群的搜索方案（高可用，分布式）
（3）分布式的实时分析搜索引擎（实时）
（4）可以扩展到上百台服务器，处理PB级结构化或非结构化数据（扩展性好）
（5）高度集成化的服务，支持各种语言
4、类似框架
①Solr（重量级对手） /SolrJ
Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。Solr是高度可扩展的，并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎，SolrJ 还增加了NoSQL支持。
Solr和ES比较：
Solr 利用 Zookeeper 进行分布式管理，支持更多格式的数据（HTML/PDF/CSV），官方提供的功能更多在传统的搜索应用中表现好于 ES，但实时搜索效率低。
ES自身带有分布式协调管理功能，但仅支持json文件格式，本身更注重于核心功能，高级功能多有第三方插件提供，在处理实时搜索应用时效率明显高于 Solr。
② Katta
基于 Lucene 的，支持分布式，可扩展，具有容错功能，准实时的搜索方案。
优点：开箱即用，可以与 Hadoop 配合实现分布式。具备扩展和容错机制。
缺点：只是搜索方案，建索引部分还是需要自己实现。在搜索功能上，只实现了最基本的需求。成功案例较少，项目的成熟度稍微差一些。
③ HadoopContrib
Map/Reduce 模式的，分布式建索引方案，可以跟 Katta 配合使用。
优点：分布式建索引，具备可扩展性。
缺点：只是建索引方案，不包括搜索实现。工作在批处理模式，对实时搜索的支持不佳。
5、传统数据库和ES的对应关系：
关系数据库（MYSQL） -> 数据库DB-> 表TABLE-> 行ROW-> 列Column
Elasticsearch -> 索引库Indices -> 类型Types -> 文档Documents -> 字段Fields
6、es支持的字段类型
① 基本字段类型
字符串（String）：text,keyword
text默认为全文文本，keyword默认为非全文文本
数字：long,integer,short,double,float
日期：date
逻辑：boolean
② 复杂数据类型
对象类型：object
数组类型：array
地理位置：geo_point,geo_shape
7、Bulk（批量操作）一次最大处理多少数据量？
bulk会把将要处理的数据载入内存中，所以数据量是有限制的
最佳的数据量不是一个确定的数值，它取决于你的硬件，你的文档大小以及复杂性，你的索引以及搜索的负载。
一般建议是1000-5000个文档，如果你的文档很大，可以适当减少队列,大小建议是5-15MB，默认不能超过100M
，可以在es的配置文件中修改这个值http.max_content_length: 100mb.
8、ES在高并发的情况下如何保证数据线程安全问题？
在读数据与写数据之间如果有其他线程进行写操作，就会出问题，es使用版本控制才避免这种问题。
在修改数据的时候指定版本号，操作一次版本号加1。
9、ES自动映射的规则
字段映射的常用属性配置列表
|
type |
类型：基本数据类型，integer,long,date,boolean,keyword,text... |
|
enable |
是否启用：默认为true。 false：不能索引、不能搜索过滤，仅在_source中存储 |
|
boost |
权重提升倍数：用于查询时加权计算最终的得分。 |
|
format |
格式：一般用于指定日期格式，如 yyyy-MM-dd HH:mm:ss.SSS |
|
ignore_above |
长度限制：长度大于该值的字符串将不会被索引和存储。 |
|
ignore_malformed |
转换错误忽略：true代表当格式转换错误时，忽略该值，被忽略后不会被存储和索引。 |
|
include_in_all |
是否将该字段值组合到_all中。 |
|
null_value |
默认控制替换值。如空字符串替换为”NULL”，空数字替换为-1 |
|
store |
是否存储：默认为false。true意义不大，因为_source中已有数据 |
|
index |
索引模式：analyzed (索引并分词，text默认模式), not_analyzed (索引不分词，keyword默认模式)，no（不索引） |
|
analyzer |
索引分词器：索引创建时使用的分词器，如ik_smart,ik_max_word,standard |
|
search_analyzer |
搜索分词器：搜索该字段的值时，传入的查询内容的分词器。 |
|
fields |
多字段索引：当对该字段需要使用多种索引模式时使用。 如：城市搜索New York "city": { "type": "text", "analyzer": "ik_smart", "fields": { "raw": { "type": "keyword" } } }
访问分词:city 访问不分词:city.raw 那么以后搜索过滤和排序就可以使用city.raw字段名 |
10、es如何保证高可用（对失败节点的数据进行复制）
- 对于分布式集群来说，当一个或多个节点down掉了，能够保证我们的数据不能丢，最通用的解放方案就是对失败节点的数据进行复制，通过控制复制的份数可以保证集群有很高的可用性，复制这个方案的精髓主要是保证操作的时候没有单点，对一个节点的操作会同步到其他的复制节点上去。
- ES一个索引会拆分成多个碎片，每个碎片可以拥有一个或多个副本（创建索引的时候可以配置），这里有个例子，每个索引分成3个碎片，每个碎片有2个副本，如下：
$ curl -XPUT http://localhost:9200/twitter/ -d ' index : number_of_shards : 3 number_of_replicas : 2
默认是1个分片。不复制
11、es选举（和zk差不多，但是es支持1-N，zk的话必须是奇数）
- 节点启动后先ping（这里的ping是 Elasticsearch 的一个RPC命令。如果 discovery.zen.ping.unicast.hosts 有设置，则ping设置中的host，否则尝试ping localhost 的几个端口， Elasticsearch 支持同一个主机启动多个节点）
- Ping的response会包含该节点的基本信息以及该节点认为的master节点
- 选举开始，先从各节点认为的master中选，规则很简单，按照id的字典序排序，取第一个
- 如果各节点都没有认为的master，则从所有节点中选择，规则同上。这里有个限制条件就是 discovery.zen.minimum_master_nodes，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举
- 最后选举结果是肯定能选举出一个master，如果只有一个local节点那就选出的是自己
- 如果当前节点是master，则开始等待节点数达到 minimum_master_nodes，然后提供服务, 如果当前节点不是master，则尝试加入master.
- ES支持任意数目的集群（1-N）,所以不能像 Zookeeper/Etcd 那样限制节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则，只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的. 但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（Split-Brain）的问题，大多数解决方案就是设置一个quorum值，要求可用节点必须大于quorum（一般是超过半数节点），才能对外提供服务。而 Elasticsearch 中，这个quorum的配置就是
12、es 是如何实现分布式的?
ElasticSearch 设计的理念就是分布式搜索引擎，底层其实还是基于 lucene 的。核心思想就是在多台机器上启动多个 es 进程实例，组成了一个 es 集群。
一个索引，这个索引可以拆分成多个 shard，每个 shard 存储部分数据
primary shard，负责写入数据，但是还有几个 replica shard。primary shard 写入数据之后，会将数据同步到其他几个 replica shard 上去。es 集群多个节点，会自动选举一个节点为 master 节点，这个 master 节点其实就是干一些管理的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举一个节点为 master 节点。
如果是非 master节点宕机了，那么会由 master 节点，让那个宕机节点上的 primary shard 的身份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器，重启了之后，master 节点会控制将缺失的 replica shard 分配过去，同步后续修改的数据之类的，让集群恢复正常。