1、WHY

      1)、大规模的数据检索应该怎么做？

      2)、怎么样避免单点故障

      3)、如何保证数据安全性，热备、冷备、异地多活

      ES 应运而生，ES 是开源高扩展的分布式全文检索引擎，可以实现近乎实时的查询，检索数据；本身扩展性非常好，可以扩展

到上百态服务器，处理PB级别的数据。所以学习ES 是很有必要的。

2、HOW

      如果去学习：

      1)、了解原理

      2)、熟悉DSL

      3)、安装应用

2.1、基本原理

      总结一句话 面向文档，分片来解决多点存储，副本来保证可用性，写时先写buffer内存，1秒flash到磁盘。filter查询实时查内存数据，filter查询可缓存，精确过滤。master适用全局索引，分值匹配。查询慢且不缓存。



2.1.1、面向文档

      ES 面向文档存储，就没必要将对象扁平化存入表格。它可以存储整个对象或文档。ES不仅存储文档，而且索引每个文档的

内容，使之可以被检索。在ES中，我们对文档进行索引、检索、排序和多虑，而不是对行列数据。ES使用JSON作为文档的序列

号方式。



2.1.2、文档类型（Type）

        类比传统的关系型数据库领域来说，类型相当于“表”。类型是索引内部的逻辑分区(category/partition)，然而其意义完全取决

于用户需求。一个索引内部可定义一个或多个类型(type)。一般来说，类型就是为那些拥有相同的域的文档做的预定义。例如，在

索引中，可以定义一个用于存储用户数据的类型，一个存储日志数据的类型。



2.1.3 索引（Index）

       类比传统的关系型数据库领域来说，索引相当于SQL中的一个数据库，或者一个数据存储方案(schema)。索引由其名称(必

须为全小写字符)进行标识，并通过引用此名称完成文档的创建、搜索、更新及删除操作。一个ES集群中可以按需创建任意数目的

索引。



2.1.4 、Mapping

       相当于数据库中的schema，用来约束字段的类型，不过 Elasticsearch 的 mapping 可以自动根据数据创建。



2.1.5、分片（shard）

       ES的“分片(shard)”机制可将一个索引内部的数据分布地存储于多个节点，它通过将一个索引切分为多个底层物理的Lucene索引完成索引数据的分割存储功能，这每一个物理的Lucene索引称为一个分片(shard)。

       每个分片其内部都是一个全功能且独立的索引，因此可由集群中的任何主机存储。创建索引时，用户可指定其分片的数量，默认数量为5个。



2.1.6、副本

       Shard有两种类型，主shard 和 副本shard。Primary shard用于文档存储，每个新的索引会自动创建5个Primary shard，当然此数量可在索引创建之前通过配置自行定义，不过，一旦创建完成，其Primary shard的数量将不可更改。

      Replica shard是Primary Shard的副本，用于冗余数据及提高搜索性能。每个Primary shard默认配置了一个Replica shard，但也可以配置多个，且其数量可动态更改。ES会根据需要自动增加或减少这些Replica shard的数量。ES集群可由多个节点组成，各Shard分布式地存储于这些节点上。

      ES可自动在节点间按需要移动shard，例如增加节点或节点故障时。简而言之，分片实现了集群的分布式存储，而副本实现了其，分布式处理及冗余功能。



2.1.7、 创建索引

       当分片所在的节点接收到来自协调节点的请求后，会将该请求写入translog，并将文档加入内存缓存。如果请求在主分片上成功处理，该请求会并行发送到该分片的副本上。当translog被同步到全部的主分片及其副本上后，客户端才会收到确认通知。

       内存缓冲会被周期性刷新(默认是1秒)，内容将被写到文件系统缓存的一个新段（segment）上。虽然这个段并没有被同步(fsync)，但它是开放的，内容可以被搜索到。

      每30分钟，或者当translog很大的时候，translog会被清空，文件系统缓存会被同步。这个过程在Elasticsearch中称为冲洗(flush)。在冲洗过程中，内存中的缓冲将被清除，内容被写入一个新段。段的fsync将创建一个新的提交点，并将内容刷新到磁盘。旧的translog将被删除并开始一个新的translog。



2.1.8、实时检索

      由于在buffer中的索引片先同步到文件系统缓存，再刷写到磁盘，因此在检索时可以直接检索文件系统缓存，保证了实时性。这一步刷到文件系统缓存的步骤，在 Elasticsearch 中，是默认设置为 1 秒间隔的，对于大多数应用来说，几乎就相当于是实时可搜索了。

      不过对于 ELK 的日志场景来说，并不需要如此高的实时性，而是需要更快的写入性能。我们可以通过 /_settings接口或者定制 template 的方式，加大 refresh_interval 参数。

      由于Elasticsearch 在把数据写入到内存 buffer 的同时，其实还另外记录了一个 translog日志，如果在这期间故障发生时，Elasticsearch会从commit位置开始，恢复整个translog文件中的记录，保证数据的一致性。

      等到真正把 segment 刷到磁盘，且 commit 文件进行更新的时候， translog 文件才清空。这一步，叫做flush。同样，Elasticsearch 也提供了 /_flush 接口。

      Elasticsearch 2.0 以后为了保证不丢失数据，每次 index、bulk、delete、update 完成的时候，一定触发刷新translog 到磁盘上，才给请求返回 200 OK。这个改变在提高数据安全性的同时当然也降低了一点性能。



2.1.9、 更新删除索引

      删除和更新也都是写操作。但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更。那么，该如何删除和更新文档呢？

      磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并(我们将在本系列接下来的文章中讲到)时，在.del文件中被标记为删除的文档将不会被写入新段。

      接下来我们看更新是如何工作的。在新的文档被创建时，Elasticsearch会为该文档指定一个版本号。当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。物理删除索引：当索引数据不断增长时，对应的segment也会不断的增多，查询性能可能就会下降。因此，Elasticsearch会触发segment合并的线程，把很多小的segment合并成更大的segment，然后删除小的segment，当这些标记为删除的segment不会被复制到新的索引段中。



2.1.10、 索引相关性

          相关性是由搜索结果中Elasticsearch打给每个文档的得分决定的。默认使用的排序算法是tf/idf(词频/逆文档频率)。词频衡量了一个词项在文档中出现的次数 (频率越高 == 相关性越高)，逆文档频率衡量了词项在全部索引中出现的频率，是一个索引中文档总数的百分比(频率越高 == 相关性越低)。最后的得分是tf-idf得分与其他因子比如(短语查询中的)词项接近度、(模糊查询中的)词项相似度等的组合