最新版本官方文档https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
文档增删改参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs.html
ES除了用于搜索尽可能满意的结果,要达到一定的SLA也是可以保证的,例如秒级别。
https://blog.csdn.net/zhangcongyi420/article/details/96508712、https://blog.csdn.net/u010454030/article/details/79586072
例如有一个上亿的表或者有数十万产品的表,每次依赖数据库的like进行模糊匹配,很快就导致系统不堪重负。一种方式是垂直切分表,将部分作为模糊搜索条件的列作为单独的表进行维护,然后将符合条件的ID作为条件传递给主查询(它的限制是排序条件有限的,难以支持按照任意字段如金额排序,更不要说多列),如果用于搜索的部分仍然太大,那么关系数据库就不那么合适了,就需要使用专门的搜索数据库例如ES,如今的ES是可以完全做到精确匹配的。第二种方式的前半部分思路和第一种一样,但是它并不返回符合条件的ID,而是将模糊搜索转为精确搜索,也就是利用补全机制,让用户多选精确条件,以此实现模糊匹配+支持任何排序。对于一个核心页面来说,通常看哪一方强势选择实现方式,平台通常选择第一种,IT供应商通常选择第二种。但是任何的NoSQL存储,都必须考虑如何关联查询,实际中很大一部分都是要关联查询的,ES官方对关联的查询。实际上无论是mongodb还是es,在关联、java的driver上做的都一般般,对于海量数据的to B而言,其实都没有MPP、分区架构来的成本低,尤其是在三范式较好的系统中。
除了ES外,还有oracle全文检索。如果不想再维护一个组件,可以考虑集成lucene。
Elasticsearch主要概念
Index,索引:一系列具有类似属性的文档集合,类似于数据库里的表,集群中可以包含的索引数不限,索引是逻辑概念(对应物理上为分片,shard),一般应提前手工创建而非自动创建便于管理,索引的名称和存储名称不相同但是有着对应关系,可通过查询索引信息的uuid得到。一个典型的索引定义如下:
{
"logstash-2018-06": {
"aliases": {},
"mappings": {
"_default_": {
"dynamic_templates": [
{
"message_field": {
"path_match": "message",
"match_mapping_type": "string",
"mapping": {
"norms": false,
"type": "text"
}
}
},
{
"string_fields": {
"match": "*",
"match_mapping_type": "string",
"mapping": {
"fields": {
"keyword": {
"ignore_above": 256,
"type": "keyword"
}
},
"norms": false,
"type": "text"
}
}
}
],
"properties": {
"@timestamp": {
"type": "date"
},
"@version": {
"type": "keyword"
},
"geoip": {
"dynamic": "true",
"properties": {
"ip": {
"type": "ip"
},
"latitude": {
"type": "half_float"
},
"location": {
"type": "geo_point"
},
"longitude": {
"type": "half_float"
}
}
}
}
},
"doc": {
"dynamic_templates": [
{
"message_field": {
"path_match": "message",
"match_mapping_type": "string",
"mapping": {
"norms": false,
"type": "text"
}
}
},
{
"string_fields": {
"match": "*",
"match_mapping_type": "string",
"mapping": {
"fields": {
"keyword": {
"ignore_above": 256,
"type": "keyword"
}
},
"norms": false,
"type": "text"
}
}
}
],
"properties": {
"@timestamp": {
"type": "date"
},
"@version": {
"type": "keyword"
},
"beat": {
"properties": {
"hostname": {
"type": "text",
"norms": false,
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"name": {
"type": "text",
"norms": false,
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"version": {
"type": "text",
"norms": false,
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
}
}
},
"geoip": {
"dynamic": "true",
"properties": {
"ip": {
"type": "ip"
},
"latitude": {
"type": "half_float"
},
"location": {
"type": "geo_point"
},
"longitude": {
"type": "half_float"
}
}
},
"host": {
"type": "text",
"norms": false,
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"message": {
"type": "text",
"norms": false
},
"offset": {
"type": "long"
},
"prospector": {
"properties": {
"type": {
"type": "text",
"norms": false,
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
}
}
},
"source": {
"type": "text",
"norms": false,
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"tags": {
"type": "text",
"norms": false,
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
}
}
}
},
"settings": {
"index": {
"refresh_interval": "5s",
"number_of_shards": "5",
"provided_name": "logstash-2018-06",
"creation_date": "1527913627481",
"number_of_replicas": "1",
"uuid": "0VidmJtrT1uoz-TygNCn_Q",
"version": {
"created": "6020499"
}
}
}
}
}
Type,类型:在6.0.0之前的版本中,类型用于在索引中进行二次分类/分区以便在相同索引中存储不同类型的文档,比如同时存储blog和user,这个版本开始,不能再在一个索引中创建多个类型,类型是逻辑概念。
Document,文档:文档代表可以被索引的基本单元,类似数据库里的表,文档在ES中表示为JSON,在索引/类型中,可以存储无限的文档。从物理上来说,文档存储在索引中,从逻辑上,文档实际上归属于索引中的某个类型。一个典型的文档如下:
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
其实就是一个json。文档由 _index 、 _type 和 _id 唯一标识一个文档。
Near Realtime (NRT),准实时:Elasticsearch是准实时搜索平台(官方称秒级)。
Cluster,集群:所有Elasticsearch节点都运行在集群中,即使只有一个节点,集群中可以包含的节点数不限,节点是物理概念,集群是逻辑概念。
Node,节点:简单地说,ES中的所有节点都是用来存储数据的。具体地说,从功能上来看,Elasticsearch有5种类型的节点:
- Data节点,虽然每个节点都可以作为数据节点,但是通过在elasticsearch.yml配置文件中进行如下设置,可以限定某些节点只能作为数据节点,设置专用数据节点可以使得数据节点和Master节点隔离。
node.data: true
node.master: false
node.ingest: false
- Master节点,负责管理整个集群,其持有所有节点的状态并周期性的将集群状态分发给其他所有节点,包括新加入的节点以及退出的节点。master节点的主要职责是配置管理,其包含完整的元数据以及所有索引的映射,当更新密集时,状态信息可能会非常大,每秒1w条数据时,状态信息可能有几十M。2.0版本之后,更新的集群状态信息只发diff,并且是被压缩的。如果master节点挂了,新的主节点会从剩余有资格的主节点中产生,默认情况下,每个节点都可以成为主节点。通过在elasticsearch.yml配置文件中进行如下设置,可以限定某些节点只能作为主节点。
node.data: false
node.master: true
node.ingest: false
- Ingest节点,可以在实际索引前执行预处理数据。通过在elasticsearch.yml配置文件中进行如下设置,可以限定某些节点只能作为Ingest节点。
node.data: false
node.master: false
node.ingest: true
- Tribe节点,是一种特殊的协调节点,或者成为联邦节点,用于代理执行跨集群的操作。
- Coordinating/Client节点,在ES中,每个请求的执行分为两个步骤:分发和聚合。这两个均由接收请求的协调节点管理,同时他们也是ES集群的负载均衡器。通过在elasticsearch.yml配置文件中进行如下设置,可以限定某些节点只能作为协调节点,对于较大型的生产系统,应该配置专门的协调节点,因为聚合节点比较消耗资源。
node.data: false
node.master: false
node.ingest: false
Routing,路由:路由允许我们在索引和搜索数据时选择具体的分片。
Lucene:提供了基于java的索引和搜索技术,Solr类似于ES,也是基于Lucene Core,提供了管理接口。
Shards & Replicas,分片与副本:一个索引包含的文档在存储的时候不一定是一起的,存储文档的每个物理单元称为分片(Elasticsearch 没有采用节点级别的主从复制,而是基于分片,跟couchbase一样)(类似于数据库的分区以及段Partition/Segment)。分片的作用无非两个:
- 容量扩展;
- 并行操作;
为了保证高可用,每个分片可以设置副本数量。在索引创建的时候,可以指定分片和副本的数量,副本数可以按需调整但是分片数量一经定义、无法修改。默认情况下,Elasticsearch为每个索引分配5个分片和1个副本(5个主分片,5个副本分片),这意味着双节点模式。
文档根据公式shard = hash(routing) % number_of_primary_shards计算存储的具体分片,默认是根据文档的id计算,可自定义。
每个Elasticsearch分片是一个Lucene索引/实例(需要注意,Lucene的概念和ES不完全一一对应),一个Lucene索引中文档的数量限制为Integer.MAX_VALUE - 128,这一点需要注意不要超出,分片中文档的数量可以通过API _cat/shards监控。
索引和分片的关系如下:
索引和分片在存储的组织上可以看得出关系(通过api也可以看出):
Analysis,分析:ES是一个全文搜索引擎,为了高性能,它会提前或者按需将文本转换为一系列的符号,ES在索引时执行分析。对于全文检索,ES还会对查询字符串执行搜索时分析。
Mapping(6.0.0开始准备移除,见Type),映射:映射定义了文档及其包含的字段如何打分和索引的过程,包括:哪个字段应该用于全文检索,哪些字段包含日期、数字以及地理信息等。
Mapping Type(6.0.0开始准备移除,见Type,移除的原因是因为ES早期的假设不正确,一开始是假设Index是database,type是表,而数据库里面,不同表中的列是无关的,而Lucene的内部实现则认为是一个字段,所以就懵逼了),映射类型:每个索引都有一个映射类型,定义文档如何索引。一个映射类型包含了下列信息:
- 元字段:用于自定义如何处理文档相关的元数据,元字段包括_index(文档所属的索引), _type(文档的映射类型), _id(文档ID)以及_source(代表文档主体的原始JSON),完整的元数据字段请参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/mapping-fields.html。
- 字段/属性:映射类型包含了属于文档的字段/属性列表。需要注意的是,ES文档的每个字段也有数据类型,但是只有text类型才会被全文检索,参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/text.html。
除了在创建索引的时候声明映射类型外,ES还支持动态映射,也就是创建文档的时候自动创建索引、映射类型以及字段(注:生产中应避免使用动态映射特性以最大化性能和存储利用率)。
Mapping parameter,映射参数:对于每种数据类型,我们可以为此声明一定的映射参数,有些参数可以应用于所有数据类型,有些则适用于部分数据类型。比如用于文本分析的分析器就是一个映射参数,完整的映射参数可以参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/mapping-params.html。
===================================
Elasticsearch基于Java编写,最新版本6.2.x要求Java 8。
ES提供REST API给用户用于日常管理,端口是9100,不过一般情况下,我们都会安装插件Elasticsearch Head,具体安装可以参考https://www.cnblogs.com/zhjh256/p/9126144.html。虽然Head不错,但是有时候现成的环境并没有安装Head,又需要及时排查问题,此时就需要对常见的api熟悉,可以参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/_exploring_your_cluster.html。
Elasticsearch REST APIs的规范
所有的Elasticsearch REST APIs都是JSON格式作为出入参,这意味着必备Postman,友好强大。一些通用的参数可以参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/api-conventions.html
Elastic出品的所有产品几乎都包含三个配置文件:XXX.yml,jvm.options,log4j2.properties。Elasticsearch也遵守相同的惯例。
elasticsearch.yml中最重要的包括:
- path.data和path.logs这两个配置,logs中除了记录ES本身的一些日志信息外,还记录搜索异常的日志比如模式无法解析。
- cluster.name:标识一个集群,默认为elasticsearch,一般应该更改,比如对于elk日志平台,可以为logger-dev。
- node.name:节点名,一般来说建议和hostname相同,hostname不应该随机,而是类似elk-es-1便于更好地管理。
- network.host:绑定的网卡,为了方便且网络流量管控不是特别严格的话,可以直接注释掉,也就是任何网卡,默认是本地回环地址,这无论开发还是生产环境都不适用。
- discovery.zen.ping.unicast.hosts:ES使用了一种称为Zen Discovery的自定义搜索来寻找集群节点和master选举。默认情况下,ES仅查找本机回环地址下的9300~9305端口,这在生产中是不适用的,具体可见https://www.elastic.co/guide/en/elasticsearch/reference/6.2/discovery-settings.html。
- discovery.zen.minimum_master_nodes:设置每个有资格作为master的节点集群中应至少有多少个可见的有资格作为master的节点时才组群。为了防止脑裂,一般是N/2+1,通用集群做法(oracle/mysql同)。
jvm.options最主要的是-Xms和-Xmx以及gc、oom、线程池(对于所有的java应用来说,这几方面都是必须事先预防的)。
elasticsearch.yml的所有配置参数可以没有一个统一的地方定义所有,总体在https://www.elastic.co/guide/en/elasticsearch/reference/2.3/setup-configuration.html,索引相关的在https://www.elastic.co/guide/en/elasticsearch/reference/2.3/index-modules.html,分析器相关的在https://www.elastic.co/guide/en/elasticsearch/reference/2.3/analysis.html。注:最新版本的没有去掉了analyse配置的文档,故列出了2.x版本的参考。
注意事项
JDK 8u40之前的版本G1GC有bug,会导致索引损坏。
分析(Analysis)
分析是将文本转化为符号的过程,在文档被索引的时候,内置的english分析器会执行分析。任何一个mapping中的text字段都可以声明自己的分析器,比如:
"mappings": {
"_doc": {
"properties": {
"text": {
"type": "text",
"fields": {
"english": {
"type": "text",
"analyzer": "english"
}
}
}
}
}
}
默认情况下,ES会使用索引创建时设置的default分析器,如果该分析器无效或者不存在的话,使用标准分析器(https://www.elastic.co/guide/en/elasticsearch/reference/6.2/analysis-standard-analyzer.html)。ES提供了一些内置的分析器,见https://www.elastic.co/guide/en/elasticsearch/reference/6.2/analysis-analyzers.html。对于中文而言,这并不合适,因此社区开发了elasticsearch-analysis-ik(中文词语)和https://github.com/medcl/elasticsearch-analysis-pinyin(用于汉字转拼音)。
自定义分析器的创建以及规范参考https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-custom-analyzer.html。
自定义分析器的安装需要在elasticsearch.yml中进行配置,具体可参考https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html。
索引API
ES索引和搜索机制
默认情况下,当有个文档需要索引时,ES会计算文档ID的哈希值,基于该哈希值选择存储的分片,然后这些文档被复制到副本分片。但是查询的时候,由于查询条件并非都是ID等值查询,所以不知道哪个分片中实际存储了匹配的文档,因此需要查询所有的分片,处理客户端请求的节点成为协调节点。如下:
通过API可以看到每个索引的路由信息,如下:
很多时候,在全文搜索的时候,我们会限制仅在某个用户下,比如仅搜索www.cnblogs.com/zhjh256下的文档,此时路由选择就发挥作用了。提供路由值最简单的方式就是在HTTP请求中增加routing参数。即使是最高效的哈希查找,如果可以确保每次搜索时限定具体分片,理论上默认情况下吞吐量就可以提升5倍。
ES REST API提供了一批接口用于管理索引、索引的配置、别名、映射以及索引模板,索引内部信息的监控等。从纯粹使用的角度来说,索引API使用较少,所以它更多地属于管理类API。完整的索引API可以参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/indices.html。创建一个索引,如:
PUT test
{
"settings" : {
"number_of_shards" : 1
},
"mappings" : {
"type1" : {
"properties" : {
"field1" : { "type" : "text" }
}
}
}
}
创建索引的时候映射类型不是必须的。如果没有定义映射类型,创建文档的时候会自动根据api中的类型名进行创建。
有些时候,我们发现有些文本中有的内容,我们查询的时候并不匹配,此时可以针对具体的文本执行手工分析过程,看下ES是如何解析的,这个时候可以使用_analyze API(postman怎么发送参数格式为JSON的get?),如:
GET _analyze
{
"tokenizer" : "keyword",
"filter" : ["lowercase"],
"text" : "this is a test"
}
索引模板顾名思义,就是为索引定义默认设置,在创建索引的时候自动套上去,因为索引本身的创建是不多的,所以可有可无。
cat APIs
对于程序来说,JSON很适合自动化处理,但是对人类而言,其友好性就差了很多。所以,对于管理型的查询API,ES提供了平面化的接口。例如,查看集群中节点的状态:
GET /_cat/nodes?v
返回如下:
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.1.104 56 94 1 0.23 0.33 0.24 mdi * node-1
更多cat APIs,可参考https://www.elastic.co/guide/en/elasticsearch/reference/6.2/cat.html。
文档APIs
ES的数据复制模型
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs-replication.html
文档接口分为单文档接口和多文档接口。
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs.html
index api,插入或者更新一个JSON文档,并使其可搜索。例如,在twitter索引的_doc类型下创建一个id为1的文档。
PUT twitter/_doc/1
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
如果_doc类型不存在,会自动创建。如果已经存在了一个叫做_type的类型,则会创建失败,提示不允许包含多个类型。
查询和搜索类接口
ES提供了两种查询接口:搜索APIs和Query DSL。准确的说,前者能做的事情,后者都能做,前者和文档APIs等一起适合于比较简单的CRUD。
搜索APIs
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/search.html
Query DSL
http://www.querydsl.com/
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/query-dsl.html
Elasticsearch与Solr的适用场景比较可参考:https://www.cnblogs.com/simplelovecs/articles/5129276.html
ES底层原理
动态更新索引
倒排索引(Lucene中的段)被写入磁盘后是 不可改变 的:它永远不会修改
es增加新的补充索引来反映新近的修改,而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到—从最早的开始–查询完后再对结果进行合并
近实时搜索
按段(per-segment)搜索的发展
新段会被先写入到文件系统缓存,稍后再被刷新到磁盘,只要文件已经在缓存中, 就可以像其它文件一样被打开和读取了。
持久化变更
每一次对 Elasticsearch 进行操作时均记录事务日志,当 Elasticsearch 启动的时候,并且会重放 translog 中所有在最后一次提交后发生的变更操作。
段合并
为节省资源,提高检索效率,Elasticsearch通过在后台进行段合并,小的段被合并到大的段,然后这些大的段再被合并到更大的段。
通过optimize API可以将一个分片强制合并到指定的段数目。 (通常减少到一个)。例如在日志这种用例下,每天、每周、每月的日志被存储在一个索引中。 老的索引实质上是只读的;它们也并不太可能会发生变化。
集群扩容
按集群节点来均衡分配这些分片,从而对索引和搜索过程进行负载均衡,复制每个分片以支持数据冗余,从而防止硬件故障导致的数据丢失
当集群只有一个节点,到变成2个节点,3个节点时的 shard 变换图如下:
ES的节点加入与退出机制
- 集群中的某个节点丢失网络连接
- master提升该节点上的所有主分片的在其他节点上的副本为主分片
- cluster集群状态变为 yellow ,因为副本数不够
- 等待一个超时设置的时间,如果丢失节点回来就可以立即恢复(默认为1分钟,通过 index.unassigned.node_left.delayed_timeout 设置)。如果该分片已经有写入,则通过translog进行增量同步数据。
- 否则将副本分配给其他节点,开始同步数据。
- 但如果该节点上的分片没有副本,则无法恢复,集群状态会变为red,表示可能要丢失该分片的数据了。
除了官方文档外,还有一些资料对于学习ES是有帮助的,这里列举如下:
- Elasticsearch in Action
- Elasticsearch可扩展的开源弹性搜索解决防范
- Mastering Elasticsearch 5.x - Third Edition
- 深入理解ElasticSearch
- Elasticsearch The Definitive Guide(中文Elasticsearch 权威指南),可以作为较全的参考,没有很好的组织结构
- https://www.jianshu.com/p/17ba43cbc3ee
Anatomy of an Elasticsearch Cluster: Part I