如果以连接数据库来类比，lucene就是JDBC，是基本的用法。ES就相当 Mybatis， 方便开发人员配置，访问和调用。也就是说，ElasticSearch 也是基于 Lucene进行了封装，底层就是lucene，提供了更为便利的访问和调用 。而且它也是一个分布式搜索引擎。
【1】为什么使用ES
因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，大多数情况下，只是查询字符串里面是否包含某个字段，也就是%**%，这样是不会走索引的，会进行全表扫描。在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格放入我们索引库里，可以提高查询速度。
【2】ES的原理
【1】倒排索引
其实mysql的全文索引也是基于倒排索引。
在搜索引擎中，每个文档都有一个对应的文档 ID，文档内容经过“分词”之后，被表示为一系列关键词的集合。例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。那么，倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。
比如下面的文档，每个文档号对应不同的文档内容
对文档进行分词之后，得到以下倒排索引。
那么，有了倒排索引，搜索引擎可以很方便地响应用户的查询。比如用户输入查询 Facebook，搜索系统查找倒排索引，从中读出包含这个单词的文档，这些文档就是提供给用户的搜索结果。
【2】写入数据的底层原理
数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（ES是通过translog的机制来保证数据的可靠性的，这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，然后会利用FSYNC，将缓冲区的数据都 flush 到 segment file 磁盘文件中。
也就是说如果忽略掉缓存的话，其实数据就是不断从内存buffer,“refresh”到磁盘的segment file 的过程，每隔 1 秒钟，es 将 buffer 中的数据写入一个新的 segment file，这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。
【3】删除和更新数据：
删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更；
如果是删除操作，磁盘上的每个 segment file都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。因为每秒都会生成segment file，防止他越来越多，因此会定期执行 merge。每次 merge 的时候，会将多个 segment file 合并成一个，同时这里会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘。
如果是更新操作，其实就是删除+写操作，就是将原来的 doc 标识为 删除状态，然后新写入一条数据。
【4】讲一下ES的搜索过程
搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch（查询和取回）；
首先是query阶段，这个阶段：每个节点将自己的搜索结果（其实就是一些 doc id）返回给协调节点，由协调节点进行数据的合并、排序等操作，产出最终结果。
然后是fetch阶段：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。
