ElasticSearch 索引设计
概述
索引设计的重要性
主要是因为es的数据是通过_routing分配到各个分片上面的，所以本质上是不推荐去改变索引的分片数量的，因为这样都会对数据进行重新的移动。
还有就是索引只能新增字段，不能对字段进行修改和删除，缺乏灵活性，所以每次都只能通过_reindex重建索引了，还有就是一个分片的大小以及所以分片数量的多少严重影响到了索引的查询和写入性能，所以可想而知，设计一个好的索引能够减少后期的运维管理和提高不少性能，所以前期对索引的设计是相当的重要的。
基于时间的Index设计
这样设计的目的
如果数据都存储在一个Index中，很难进行扩展和调整，因为Elasticsearch中Index的某些设置在创建时就设定好了，是不能更改的，比如Primary Shard的个数。
而根据时间来切分Index，则可以实现一定的灵活性，既可以在数据量过大时及时调整Shard个数，也可以及时响应新的业务需求。
大多数业务场景下，客户对数据的请求都会命中在最近一段时间上，通过切分Index，可以尽可能的避免扫描不必要的数据，提高性能。
时间间隔
- 常见的间隔有小时、天、周和月：先考虑总共要存储多久的数据，然后选一个既不会产生大量Index又能够满足一定灵活性的间隔，比如你需要存储6个月的数据，那么一开始选择“周”这个间隔就会比较合适。
- 考虑业务增长速度：假如业务增长的特别快，比如上周产生了1亿数据，这周就增长到了10亿，那么就需要调低这个间隔来保证有足够的弹性能应对变化。
如何实现分割
创建新Index这件事，可以是客户端主动发起一个创建的请求，带上具体的Settings、Mappings等信息，但是可能会有一个时间错位，即有新数据写入时新的Index还没有建好，Elasticsearch提供了更优雅的方式来实现这个动作，即Index Template
分片设计
看上去只是一个数字而已，也许在很多场景下，即使不设定也不会有问题（ES7默认是1个主分片一个副本分片），但是如果不提前考虑，一旦出问题就可能导致系统性能下降、不可访问、甚至无法恢复，换句话说，即使使用默认值，也应该是通过足够的评估后作出的决定，而非拍脑袋定的。
限制分片大小
Elastic专家根据经验总结出来大家普遍认为30GB是个合适的上限值，实践中发现单个Shard过大（超过30GB）会导致系统不稳定。
其次，为什么不能超过30GB？主要是考虑Shard Relocate过程的负载，我们知道，如果Shard不均衡或者部分节点故障，Elasticsearch会做Shard Relocate，在这个过程中会搬移Shard，如果单个Shard过大，会导致CPU、IO负载过高进而影响系统性能与稳定性。
评估分片数量
在保证第一点的前提下，单个Index的Primary Shard个数不宜过多，否则相关的元信息与缓存会消耗过多的系统资源，这里的k，为一个较小的整数值，建议取值为1,2等，整数倍的关系可以让Shard更好地均匀分布，可以充分的将请求分散到不同节点上。
小索引设计
有些情况下，Index很小，也许只有几十、几百MB左右，那么就不用按照第二点来分配了，只分配1~2个Primary Shard是可以，不用纠结。
使用索引模板
Elasticsearch基于与索引名称匹配的通配符模式将模板应用于新索引，也就是说通过索引进行匹配，看看新建的索引是否符合索引模板，如果符合，就将索引模板的相关设置应用到新的索引，如果同时符合多个索引模板呢，这里需要对参数priority进行比较，这样会选择priority大的那个模板进行创建索引。
在创建索引模板时，如果匹配有包含的关系，或者相同，则必须设置priority为不同的值，否则会报错，索引模板也是只有在新创建的时候起到作用，修改索引模板对现有的索引没有影响，同样如果在索引中设置了一些设置或者mapping都会覆盖索引模板中相同的设置或者mapping
索引模板的用途
也就是说, 如果你需要每间隔一定的时间就建立一次索引，你只需要配置好索引模板，以后就可以直接使用这个模板中的设置，不用每次都设置settings和mappings.
创建索引模板
COPYPUT _index_template/logstash-village
{
"index_patterns": [
"logstash-village-*" // 可以通过"logstash-village-*"来适配创建的索引
],
"template": {
"settings": {
"number_of_shards": "3", //指定模板分片数量
"number_of_replicas": "2" //指定模板副本数量
},
"aliases": {
"logstash-village": {} //指定模板索引别名
},
"mappings": { //设置映射
"dynamic": "strict", //禁用动态映射
"properties": {
"@timestamp": {
"type": "date",
"format": "strict_date_optional_time||epoch_millis||yyyy-MM-dd HH:mm:ss"
},
"@version": {
"doc_values": false,
"index": "false",
"type": "integer"
},
"name": {
"type": "keyword"
},
"province": {
"type": "keyword"
},
"city": {
"type": "keyword"
},
"area": {
"type": "keyword"
},
"addr": {
"type": "text",
"analyzer": "ik_smart"
},
"location": {
"type": "geo_point"
},
"property_type": {
"type": "keyword"
},
"property_company": {
"type": "text",
"analyzer": "ik_smart"
},
"property_cost": {
"type": "float"
},
"floorage": {
"type": "float"
},
"houses": {
"type": "integer"
},
"built_year": {
"type": "integer"
},
"parkings": {
"type": "integer"
},
"volume": {
"type": "float"
},
"greening": {
"type": "float"
},
"producer": {
"type": "keyword"
},
"school": {
"type": "keyword"
},
"info": {
"type": "text",
"analyzer": "ik_smart"
}
}
}
}
}模板参数
映射配置
什么是映射
数据库建表的时候，我们DDL依据一般都会指定每个字段的存储类型，例如：varchar、int、datetime等，目的很明确，就是更精确的存储数据，防止数据类型格式混乱，在Elasticsearch中也是这样，创建索引的时候一般也需要指定索引的字段类型，这种方式称为映射（Mapping）
被动创建（动态映射）
动态映射规则
禁止动态映射
- 造成集群元数据一直变更，导致不稳定；
- 可能造成数据类型与实际类型不一致；
- true：支持动态扩展，新增数据有新的字段属性时，自动添加对于的mapping，数据写入成功
- false：不支持动态扩展，新增数据有新的字段属性时，直接忽略，数据写入成功
- strict：不支持动态扩展，新增数据有新的字段时，报错，数据写入失败
主动创建（显示映射）
所以很多时候我们需要对字段除了数据结构定义更多的限制的时候，动态映射创建的内容很可能不符合我们的需求，所以可以使用PUT {index}/mapping来更新指定索引的映射内容。
映射类型
准备工作
COPYPUT mapping_demo字符串类型
text
设置text类型以后，字段内容会被分词，在生成倒排索引以前，字符串会被分析器分成一个一个词项，text类型的字段不用于排序，很少用于聚合
keyword
如果字段需要进行过滤(比如查姓名是张三发布的博客)、排序、聚合，keyword类型的字段只能通过精确值搜索到，常常被用来过滤、排序和聚合
两者区别
也就是说如果字段是text类型，存入的数据会先进行分词，然后将分完词的词组存入索引，而keyword则不会进行分词，直接存储，这样划分数据更加节省内存。
使用案例
COPYPUT mapping_demo/_mapping
{
"properties": {
"name": {
"type": "keyword"
},
"city": {
"type": "text",
"analyzer": "ik_smart"
}
}
}COPYPUT mapping_demo/_doc/1
{
"name":"北京小区",
"city":"北京市昌平区回龙观街道"
}COPYGET mapping_demo/_search
{
"query": {
"term": {
"name": "北京小区"
}
}
}COPYGET mapping_demo/_search
{
"query": {
"term": {
"city": "北京市"
}
}
}数字类型
注意事项
- 在满足需求的情况下，优先使用范围小的字段，字段长度越小，索引和搜索的效率越高。
日期类型
JSON表示日期
- 格式化的日期字符串，比如：
"2015-01-01"or"2015/01/01 12:10:30" - 用数字表示的从新纪元开始的毫秒数
- 用数字表示的从新纪元开始的秒数（epoch_second）
ES如何处理日期
在ES的内部，时间会被转换为UTC时间（如果声明了时区）并使用从新纪元开始的毫秒数的长整形数字类型的进行存储，在日期字段上的查询，内部将会转换为使用长整形的毫秒进行范围查询，根据与字段关联的日期格式，聚合和存储字段的结果将转换回字符串
默认日期格式
COPY"strict_date_optional_time||epoch_millis" 这意味着它将会接收带时间戳的日期，它将遵守strict_date_optional_time限定的格式（yyyy-MM-dd'T'HH:mm:ss.SSSZ 或者 yyyy-MM-dd）或者毫秒数
日期格式示例
COPYPUT mapping_demo/_mapping
{
"properties": {
"datetime": {
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
}
}
}
# 添加数据
PUT mapping_demo/_doc/2
{
"name":"河北区",
"city":"河北省小区",
"datetime":"2022-02-21 11:35:42"
}日期类型参数
布尔类型
范围类型
类型范围
- integer_range
- float_range
- long_range
- double_range
- date_range
- ip_range
使用实例
COPYPUT mapping_demo/_mapping
{
"properties": {
"age_range": {
"type": "integer_range"
}
}
}
# 指定年龄范围，可以使用 gt、gte、lt、lte。
PUT mapping_demo/_doc/3
{
"name":"张三",
"age_range":{
"gt":20,
"lt":30
}
}分词器
什么是分词器
顾名思义，文本分析就是把全文本转换成一系列单词（term/token）的过程，也叫分词，在 ES 中，Analysis 是通过分词器（Analyzer） 来实现的，可使用 ES 内置的分析器或者按需定制化分析器。
举一个分词简单的例子：比如你输入 Mastering Elasticsearch，会自动帮你分成两个单词，一个是 mastering，另一个是 elasticsearch，可以看出单词也被转化成了小写的。
分词器构成
character filter
例如：去除文本中的html标签，或者将罗马数字转换成阿拉伯数字等，一个字符过滤器可以有零个或者多个
tokenizer
例如拆分英文，通过空格能将句子拆分成一个个的词，但是对于中文来说，无法使用这种方式来实现，在一个分词器中，有且只有一个tokenizeer
token filters
例如将所有英文单词小写，或者将英文中的停词a删除等，在token filters中，不允许将token(分出的词)的position或者offset改变，同时，在一个分词器中，可以有零个或者多个token filters。
分词顺序
同时 Analyzer 三个部分也是有顺序的，从图中可以看出，从上到下依次经过 Character Filters，Tokenizer 以及 Token Filters，这个顺序比较好理解，一个文本进来肯定要先对文本数据进行处理，再去分词，最后对分词的结果进行过滤。
测试分词
COPYPOST _analyze
{
"text":"<b>hello world<b>" # 输入的文本
"char_filter":["html_strip"], # 过滤html标签
"tokenizer":"keyword", #原样输出
}什么时候分词
创建索引：当索引文档字符类型为text时，在建立索引时将会对该字段进行分词。搜索：当对一个text类型的字段进行全文检索时，会对用户输入的文本进行分词。
创建索引时指定分词器
- 先判断字段是否有设置分词器，如果有，则使用字段属性上的分词器设置
- 如果设置了
analysis.analyzer.default，则使用该设置的分词器 - 如果上面两个都未设置，则使用默认的
standard分词器
字段指定分词器
COPYPUT my_index
{
"mappings": {
"properties": {
"info": {
"type": "text",
"analyzer": "ik_smart"
}
}
}
}设置默认分词器
COPYPUT my_index
{
"settings": {
"analysis": {
"analyzer": {
"default":{
"type":"simple"
}
}
}
}
}搜索时指定分词器
- 搜索时指定
analyzer参数 - 创建mapping时指定字段的
search_analyzer属性 - 创建索引时指定
setting的analysis.analyzer.default_search - 查看创建索引时字段指定的
analyzer属性 - 如果上面几种都未设置，则使用默认的
standard分词器。
指定analyzer
COPYGET my_index/_search
{
"query": {
"match": {
"message": {
"query": "Quick foxes",
"analyzer": "stop"
}
}
}
}指定字段analyzer
COPYPUT my_index
{
"mappings": {
"properties": {
"title":{
"type":"text",
"analyzer": "whitespace",
"search_analyzer": "simple"
}
}
}
}指定默认default_seach
COPYPUT my_index
{
"settings": {
"analysis": {
"analyzer": {
"default":{
"type":"simple"
},
"default_seach":{
"type":"whitespace"
}
}
}
}
}内置分词器
不同的 Analyzer 会有不同的分词结果，内置的分词器有以下几种，基本上内置的 Analyzer 包括 Language Analyzers 在内，对中文的分词都不够友好，中文分词需要安装其它 Analyzer
IK中文分词器
IKAnalyzer
从2006年12月推出1.0版开始，IKAnalyzer已经推出了3个大版本，在 2012 版本中，IK 实现了简单的分词歧义排除算法，标志着 IK 分词器从单纯的词典分词向模拟语义分词衍化
中文分词器算法
ik_smart
原始内容
COPY传智教育的教学质量是杠杠的测试分词
COPYGET _analyze
{
"analyzer": "ik_smart",
"text": "传智教育的教学质量是杠杠的"
}ik_max_word
原始内容
COPY传智教育的教学质量是杠杠的测试分词
COPYGET _analyze
{
"analyzer": "ik_max_word",
"text": "传智教育的教学质量是杠杠的"
}