Elasticsearch学习笔记（一）

Elasticsearch

Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎

Elasticsearch与Solr的比较

1. 当单纯的对已有数据进行搜索时，Solr更快
2. 当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。
3. 随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。

Solr的架构不适合实时搜索的应用。

存储

类型	field	field	field	field
关系数据库	数据库	表	行	列(Columns)
Elasticsearch	索引(Index)	类型(type)	文档(Docments)	字段(Fields)

索引

Elasticsearch索引的精髓：一切设计都是为了提高搜索的性能

• 一个Lucene索引我们在Elasticsearch称作分片。一个Elasticsearch索引是分片的集合。当Elasticsearch在索引中搜索的时候，他发送查询到每一个属于索引的分片(Lucene索引)，然后像执行分布式检索提到的那样，合并每个分片的结果到一个全局的结果集。
• elasticsearch插入一条记录(文档)–>put一个json对象，如果对象存在多个field，还会同时为它们建立索引(倒排索引)

将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种奇技淫巧的压缩算法，用及其苛刻的态度使用内存。

索引注意点

• 不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
• 同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
• 选择有规律性的id，随机性太大的ID(比如java的UUID)不利于查询

分片(Shard)和副本(Replica)

分片实现了集群的分布式存储，而副本实现了其分布式处理及冗余功能

• Primary shard用于文档存储，每个新的索引会自动创建5个Primary shard，此数量可在索引创建之前通过配置自行定义，一旦创建完成，其Primary shard的数量将不可更改。
• Replica shard是Primary Shard的副本，用于冗余数据及提高搜索性能。每个Primary shard默认配置了一个Replica shard，但也可以配置多个，且其数量可动态更改。ES会根据需要自动增加或减少这些Replica shard的数量。

一般查询流程

1. 客户端请求发给某个节点
2. 节点转发给个个分片，查询每个分片上的前10条
3. 结果返回给节点，整合数据，提取前10条
4. 返回给请求客户端

查询方式

• from+size

  深度分页问题

• scroll方式

  不适用于实时的请求

  • 原理上是对某次查询生成一个游标 scroll_id ， 后续的查询只需要根据这个游标去取数据，直到结果集中返回的 hits 字段为空，就表示遍历结束
  • 注意: 从 scroll 请求返回的结果反映了 search 发生时刻的索引状态，就像一个快照。后续的对文档的改动（索引、更新或者删除）都只会影响后面的搜索请求。
  • 所有文档获取完毕之后，需手动清理掉scroll_id，虽然es 会有自动清理机制，但是srcoll_id的存在会耗费大量的资源来保存一份当前查询结果集映像，并且会占用文件描述符，所以用完之后要及时清理
• search_after(5.0版本之后提供)
  • 根据上一页的最后一条数据来确定下一页的位置
  • 分页请求的过程中，如果有索引数据的增删改查，这些变更也会实时的反映到游标上
  • 每个文档必须有一个全局唯一值

参考文章

1. Elasticsearch－基础介绍及索引原理分析
2. 如何选择一个高效的全局ID方案
3. Elasticsearch与Solr的比较
4. elasticsearch 的滚动（scroll）
5. ElasticSearch 深度分页解决方案