Java面试题-LuceneSolrElasticSearch

@、Lucene和Solr和Elasticsearch的区别

@、Elasticsearch的优缺点

@、Solr的优缺点：

@、Elasticsearch 与 Solr 的比较

@、solr如何实现搜索的？

@、Solr原理

@、Solr基于什么

@、solr怎么设置搜索结果排名靠前

@、IK分词器原理

@、solr的索引查询为什么比数据库要快

@、solr索引库个别数据索引丢失怎么办

@、Lucene索引优化

@、solr如何分词，新增词和禁用词如何解决

@、solr多条件组合查询

@、elasticsearch 了解多少，说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段。elasticsearch 的倒排索引是什么。

@、elasticsearch 索引数据多了怎么办，如何调优，部署。

@、lucence 内部结构是什么

@、solr和lucene的区别

@、ElasticSearch使用场景

@、为什么要使用Elasticsearch?

@、Elasticsearch是如何实现Master选举的？

@、Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？

@、详细描述一下Elasticsearch索引文档的过程。

@、Elasticsearch索引文档的过程@、详细描述一下Elasticsearch更新和删除文档的过程

@、详细描述一下Elasticsearch搜索的过程

@、Elasticsearch执行搜索的过程@、Elasticsearch在部署时，对Linux的设置有哪些优化方法？

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

@、Elasticsearch对于大数据量（上亿量级）的聚合如何实现？

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

@、如何监控Elasticsearch集群状态？

@、是否了解字典树？

@、拼写纠错是如何实现的？

@、ElasticSearch中的集群、节点、索引、文档、类型是什么？

@、ElasticSearch中的分片是什么?

@、Lucene和Solr和Elasticsearch的区别

Lucene

Lucene是apache下的一个子项目，是一个开放源代码的全文检索引擎工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎。官网地址：https://lucene.apache.org/

Solr

Solr是一个高性能，采用Java5开发，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。官网地址：http://lucene.apache.org/solr/

Elasticsearch

Elasticsearch跟Solr一样，也是一个基于Lucene的搜索服务器，它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。官网地址：https://www.elastic.co/products/elasticsearch

@、Elasticsearch的优缺点

优点：

1.Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。

2.Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。

3.处理多租户（multitenancy）不需要特殊配置，而Solr则需要更多的高级设置。

4.Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。

5.各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。

缺点：

1.只有一名开发者（当前Elasticsearch GitHub组织已经不只如此，已经有了相当活跃的维护者）

2.还不够自动（不适合当前新的Index Warmup API）

@、Solr的优缺点：

优点

1.Solr有一个更大、更成熟的用户、开发和贡献者社区。

2.支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。

3.Solr比较成熟、稳定。

4.不考虑建索引的同时进行搜索，速度更快。

缺点

1.建立索引时，搜索效率下降，实时索引搜索效率不高。

@、Elasticsearch 与 Solr 的比较

1.二者安装都很简单；

2.Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;

3.Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；

4.Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；

5.Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。

6.Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。

使用案例：

1.维基百科使用Elasticsearch来进行全文搜做并高亮显示关键词，以及提供search-as-you-type、did-you-mean等搜索建议功能。

2.英国卫报使用Elasticsearch来处理访客日志，以便能将公众对不同文章的反应实时地反馈给各位编辑。

3.StackOverflow将全文搜索与地理位置和相关信息进行结合，以提供more-like-this相关问题的展现。

4.GitHub使用Elasticsearch来检索超过1300亿行代码。

5.每天，Goldman Sachs使用它来处理5TB数据的索引，还有很多投行使用它来分析股票市场的变动。

@、solr如何实现搜索的？

倒排索引，先抽取文档中词，并建立词与文档id的映射关系，然后查询的时候会根据词去查询文档id，并查询出文档
Solr过滤器

Solr的过滤器对接收到的标记流（TokenStream ）做额外的处理

过滤查询，在查询时设置

@、Solr原理

Solr是基于Lucene开发的全文检索服务器，而Lucene就是一套实现了全文检索的api，其本质就是一个全文检索的过程。全文检索就是把原始文档根据一定的规则拆分成若干个关键词，然后根据关键词创建索引，当查询时先查询索引找到对应的关键词，并根据关键词找到对应的文档，也就是查询结果，最终把查询结果展示给用户的过程

@、Solr基于什么

基于lucene搜索库的一个搜索引擎框架，lucene是一个开放源码的全文检索引擎工具包

@、solr怎么设置搜索结果排名靠前

设置文档中域的boost值，值越高相关性越高，排名就靠前

@、IK分词器原理

本质上是词典分词，在内存中初始化一个词典，然后在分词过程中逐个读取字符，和字典中的字符相匹配，把文档中的所有词语拆分出来的过程

@、solr的索引查询为什么比数据库要快

Solr使用的是Lucene API实现的全文检索。全文检索本质上是查询的索引。而数据库中并不是所有的字段都建立的索引，更何况如果使用like查询时很大的可能是不使用索引，所以使用solr查询时要比查数据库快

@、solr索引库个别数据索引丢失怎么办

首先Solr是不会丢失个别数据的。如果索引库中缺少数据，那就向索引库中添加

@、Lucene索引优化

直接使用Lucene实现全文检索已经是过时的方案，推荐使用solr。Solr已经提供了完整的全文检索解决方案
多张表的数据导入solr(解决id冲突)

在schema.xml中添加uuid，然后solrconfig那边修改update的部分，改为使用uuid生成

@、solr如何分词，新增词和禁用词如何解决

schema.xml文件中配置一个IK分词器，然后域指定分词器为IK

新增词添加到词典配置文件中ext.dic，禁用词添加到禁用词典配置文件中stopword.dic，然后在schema.xml文件中配置禁用词典：<filter class="solr.StopFilterFactory" ignore="true" words="/禁止词文件目录"/>

@、solr多条件组合查询

创建多个查询对象，指定他们的组合关系，Occur.MUST（必须满足and），Occur.SHOULD（应该满足or），Occur.MUST_NOT（必须不满足not）

@、elasticsearch 了解多少，说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段。elasticsearch 的倒排索引是什么。

ElasticSearch（简称ES）是一个分布式、Restful的搜索及分析服务器，设计用于分布式计算；能够达到实时搜索，稳定，可靠，快速。和Apache Solr一样，它也是基于Lucence的索引服务器，而ElasticSearch对比Solr的优点在于：

轻量级：安装启动方便，下载文件之后一条命令就可以启动。

Schema free：可以向服务器提交任意结构的JSON对象，Solr中使用schema.xml指定了索引结构。

多索引文件支持：使用不同的index参数就能创建另一个索引文件，Solr中需要另行配置。

分布式：Solr Cloud的配置比较复杂。

倒排索引是实现“单词-文档矩阵”的一种具体存储形式，通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。

@、elasticsearch 索引数据多了怎么办，如何调优，部署。

使用bulk API

初次索引的时候，把 replica 设置为 0

增大 threadpool.index.queue_size

增大 indices.memory.index_buffer_size

增大 index.translog.flush_threshold_ops

增大 index.translog.sync_interval

增大 index.engine.robin.refresh_interval

http://www.jianshu.com/p/5eeeeb4375d4

@、lucence 内部结构是什么

索引(Index)：在Lucene中一个索引是放在一个文件夹中的。如上图，同一文件夹中的所有的文件构成一个Lucene索引。

段(Segment)：一个索引可以包含多个段，段与段之间是独立的，添加新文档可以生成新的段，不同的段可以合并。

segments.gen和segments_X是段的元数据文件，也即它们保存了段的属性信息。

文档(Document)：文档是我们建索引的基本单位，不同的文档是保存在不同的段中的，一个段可以包含多篇文档。

新添加的文档是单独保存在一个新生成的段中，随着段的合并，不同的文档合并到同一个段中。

域(Field)：

一篇文档包含不同类型的信息，可以分开索引，比如标题，时间，正文，作者等，都可以保存在不同的域里。不同域的索引方式可以不同，在真正解析域的存储的时候，我们会详细解读。

词(Term)：

词是索引的最小单位，是经过词法分析和语言处理后的字符串。

@、solr和lucene的区别

Solr和Lucene的本质区别有以下三点：搜索服务器，企业级和管理。Lucene本质上是搜索库，不是独立的应用程序，而Solr是。Lucene专注于搜索底层的建设，而Solr专注于企业应用。Lucene不负责支撑搜索服务所必须的管理，而Solr负责。所以说，一句话概括Solr: Solr是Lucene面向企业搜索应用的扩展

Lucene: 是一个索引与搜索类库，而不是完整的程序。

Solr：是一个高性能，采用Java5开发，基于Lucene的一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。
solr 实现全文检索

索引流程：客户端---》solr 服务器(发送post请求,xml文档包含filed，solr实现对索引的维护)

搜索流程：客户端---》solr 服务器(发送get 请求，服务器返回一个xml 文档)
solr和lucene之间的区别

lucene全文检索的工具包,jar包

solr     全文检索服务器,单独运行的servlet容器

@、ElasticSearch使用场景

ElasticSearch作为一个建立在全文搜索引擎Apache Lucene基础上的实时的分布式搜索和分析引擎，适用于处理实时搜索应用场景。此外，使用ElasticSearch全文搜索引擎，还可以支持多词条查询、匹配度与权重、自动联想、拼写纠错等高级功能。因此，可以使用 ElasticSearch作为关系型数据库全文搜索的功能补充，将要进行全文搜索的数据缓存一份到 ElasticSearch上，达到处理复杂的业务与提高查询速度的目的。

@、为什么要使用Elasticsearch?

因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，可以提高查询速度。

@、Elasticsearch是如何实现Master选举的？

Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；
    对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
    如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
    补充：master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

@、Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？

当集群master候选数量不小于3个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题；
    当候选数量为两个时，只能修改为唯一的一个master候选，其他作为data节点，避免脑裂问题。

@、详细描述一下Elasticsearch索引文档的过程。

协调节点默认使用文档ID参与计算（也支持通过routing），以便为路由提供合适的分片。

shard = hash(document_id) % (num_of_primary_shards)

当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem Cache的过程就叫做refresh；
    当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；
    在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。
    flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；

@、Elasticsearch索引文档的过程
@、详细描述一下Elasticsearch更新和删除文档的过程

删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更；
    磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。
    在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

@、详细描述一下Elasticsearch搜索的过程

搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
    在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。
    每个分片返回各自优先队列中所有文档的 ID 和排序值给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
    接下来就是取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
    补充：Query Then Fetch的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch增加了一个预查询的处理，询问Term和Document frequency，这个评分更准确，但是性能会变差。

@、Elasticsearch执行搜索的过程
@、Elasticsearch在部署时，对Linux的设置有哪些优化方法？

64 GB 内存的机器是非常理想的，但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反。

如果你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。

如果你负担得起 SSD，它将远远超出任何旋转介质。基于 SSD 的节点，查询和索引性能都有提升。如果你负担得起，SSD 是一个好的选择。

即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。

请确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的。在 Elasticsearch 的几个地方，使用 Java 的本地序列化。

通过设置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟。

Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。

不要随意修改垃圾回收器（CMS）和各个线程池的大小。

把你的内存的（少于）一半给 Lucene（但不要超过 32 GB！），通过ES_HEAP_SIZE 环境变量设置。

内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。再想想那么多 10 微秒的操作时延累加起来。不难看出 swapping 对于性能是多么可怕。

Lucene 使用了大量的文件。同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。所有这一切都需要足够的文件描述符。你应该增加你的文件描述符，设置一个很大的值，如 64,000。

补充：索引阶段性能提升方法

使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。

存储：使用 SSD

段和合并：Elasticsearch 默认值是 20 MB/s，对机械磁盘应该是个不错的设置。如果你用的是 SSD，可以考虑提高到 100–200 MB/s。如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加 index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的值，比如 1 GB，这可以在一次清空触发的时候在事务日志里积累出更大的段。

如果你的搜索结果不需要近实时的准确度，考虑把每个索引的index.refresh_interval 改到30s。

如果你在做大批量导入，考虑通过设置index.number_of_replicas: 0 关闭副本。

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

SEE：https://elasticsearch.cn/article/32
    倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment memory增长趋势。
    各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采用clear cache等“自欺欺人”的方式来释放内存。
    避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api来实现。
    cluster stats驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过tribe node连接。
    想知道heap够不够，必须结合实际应用场景，并对集群的heap使用情况做持续的监控。

@、Elasticsearch对于大数据量（上亿量级）的聚合如何实现？

Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确＝更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关 .

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

可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
    另外对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
    对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分片，确保文档是最新版本。

@、如何监控Elasticsearch集群状态？

Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标

@、是否了解字典树？

常用字典数据结构如下所示：

常用字典数据结构

Trie的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有3个基本性质：

根节点不包含字符，除根节点外每一个节点都只包含一个字符。
从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。
每个节点的所有子节点包含的字符都不相同。

字典树

可以看到，trie树每一层的节点数是26^i级别的。所以为了节省空间，我们还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数×单词长度。
    实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿子右兄弟表示法记录这棵树；
    对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太大的空间，而且查询速度上可以保留哈希的复杂度O(1)。

@、拼写纠错是如何实现的？

拼写纠错是基于编辑距离来实现；编辑距离是一种标准的方法，它用来表示经过插入、删除和替换操作从一个字符串转换到另外一个字符串的最小操作步数；
    编辑距离的计算过程：比如要计算batyu和beauty的编辑距离，先创建一个7×8的表（batyu长度为5，coffee长度为6，各加2），接着，在如下位置填入黑色数字。其他格的计算过程是取以下三个值的最小值：

如果最上方的字符等于最左方的字符，则为左上方的数字。否则为左上方的数字+1。（对于3,3来说为0）

左方数字+1（对于3,3格来说为2）

上方数字+1（对于3,3格来说为2）

最终取右下角的值即为编辑距离的值3。

编辑距离

对于拼写纠错，我们考虑构造一个度量空间（Metric Space），该空间内任何关系满足以下三条基本条件：

d(x,y) = 0 -- 假如x与y的距离为0，则x=y

d(x,y) = d(y,x) -- x到y的距离等同于y到x的距离

d(x,y) + d(y,z) >= d(x,z) -- 三角不等式

根据三角不等式，则满足与query距离在n范围内的另一个字符转B，其与A的距离最大为d+n，最小为d-n。
    BK树的构造就过程如下：每个节点有任意个子节点，每条边有个值表示编辑距离。所有子节点到父节点的边上标注n表示编辑距离恰好为n。比如，我们有棵树父节点是”book”和两个子节点”cake”和”books”，”book”到”books”的边标号1，”book”到”cake”的边上标号4。从字典里构造好树后，无论何时你想插入新单词时，计算该单词与根节点的编辑距离，并且查找数值为d(neweord, root)的边。递归得与各子节点进行比较，直到没有子节点，你就可以创建新的子节点并将新单词保存在那。比如，插入”boo”到刚才上述例子的树中，我们先检查根节点，查找d(“book”, “boo”) = 1的边，然后检查标号为1的边的子节点，得到单词”books”。我们再计算距离d(“books”, “boo”)=2，则将新单词插在”books”之后，边标号为2。
    查询相似词如下：计算单词与根节点的编辑距离d，然后递归查找每个子节点标号为d-n到d+n（包含）的边。假如被检查的节点与搜索单词的距离d小于n，则返回该节点并继续查询。比如输入cape且最大容忍距离为1，则先计算和根的编辑距离d(“book”, “cape”)=4，然后接着找和根节点之间编辑距离为3到5的，这个就找到了cake这个节点，计算d(“cake”, “cape”)=1，满足条件所以返回cake，然后再找和cake节点编辑距离是0到2的，分别找到cape和cart节点，这样就得到cape这个满足条件的结果。

@、ElasticSearch中的集群、节点、索引、文档、类型是什么？

群集是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为“elasticsearch”。此名称很重要，因为如果节点设置为按名称加入群集，则该节点只能是群集的一部分。
    节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
    索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。 MySQL =>数据库 ElasticSearch =>索引
    文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
    类型是索引的逻辑类别/分区，其语义完全取决于用户。

@、ElasticSearch中的分片是什么?

在大多数环境中，每个节点都在单独的盒子或虚拟机上运行。

索引 - 在Elasticsearch中，索引是文档的集合。
    分片 -因为Elasticsearch是一个分布式搜索引擎，所以索引通常被分割成分布在多个节点上的被称为分片的元素。