Elasticsearch
Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎
Elasticsearch与Solr的比较
- 当单纯的对已有数据进行搜索时,Solr更快
- 当实时建立索引时, Solr会产生io阻塞,查询性能较差, Elasticsearch具有明显的优势。
- 随着数据量的增加,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的数量。
一般查询流程
- 客户端请求发给某个节点
- 节点转发给个个分片,查询每个分片上的前10条
- 结果返回给节点,整合数据,提取前10条
- 返回给请求客户端
查询方式
- from+size
深度分页问题
- scroll方式
不适用于实时的请求
- 原理上是对某次查询生成一个游标 scroll_id , 后续的查询只需要根据这个游标去取数据,直到结果集中返回的 hits 字段为空,就表示遍历结束
- 注意: 从 scroll 请求返回的结果反映了 search 发生时刻的索引状态,就像一个快照。后续的对文档的改动(索引、更新或者删除)都只会影响后面的搜索请求。
- 所有文档获取完毕之后,需手动清理掉scroll_id,虽然es 会有自动清理机制,但是srcoll_id的存在会耗费大量的资源来保存一份当前查询结果集映像,并且会占用文件描述符,所以用完之后要及时清理
- search_after(5.0版本之后提供)
- 根据上一页的最后一条数据来确定下一页的位置
- 分页请求的过程中,如果有索引数据的增删改查,这些变更也会实时的反映到游标上
- 每个文档必须有一个全局唯一值