Elastic Stack-Elasticsearch使用介绍(五)
一、前言
前4篇将Elasticsearch用法的API和原理方面东西介绍了一下,相信大家对Elasticsearch有了一定的认知,接下我们主要从索引的建立到后期的一些优化做一些介绍;
二、Mapping构建
之前介绍过Index就如同我们的数据库database,type相当于我们的表,而Mapping就是构建这些字段和索引关系的桥梁。数据库构建的时候我们要遵守三范式,那Mapping构建的时候我们要考虑那些因素?我认为要有以下几方面的考虑:
1.字段是什么类型;
对字段的类型做过介绍,考虑这个时候和数据库字段设置考虑问题基本一样;
2.是否需要被检索,也就是是否需要分词;
不需要检索的字段:index设置为false;不需要检索的字符类型直接设置成keyword类型;
需要检索的字段,可以通过index_options设定需要的存储分词的粒度,主要有以下四种参数docs 、 freqs 、 position 、 offsets,根据需要自行设定;
3.是否需要排序和聚合;
不需要排序或者聚合分析功能:doc_values设置为 false,fielddata设置为 false;
如果一个字段不需要检索、排序、聚合分析,则enabled设置为false;
4.是否需要另外的存储;
通过store 设定 true,即可存储该字段的原始内容,这里这个举个例子
以上就是我们建立Mapping时候需要考虑一些东西,接下来我们还有另外一个问题,数据库中表与表之间是有关联关系的,这个在Elasticsearch中是如何体现的?
在Elasticsearch中有两种方式可以去实现关联关系,
1.Nested Object(嵌套对象)
举个例子:
这个时候user字段会被映射成为object类型,这个时候JSON文档会被处理成为:
当我们查询的时候,就会意外出现的结果;
结果:
Elasticsearch针对这种情况提供Nested Object(嵌套对象)这个解决方案,
增加这一个步骤然后再按照上面步骤操作,就得到我们想要的结果;
当使用Nested Object内部是使用嵌套文档,当搜索first name为Alice和last name为White的时候就查询不到;
2.join
join数据类型是在同一个索引通过Parent和Child去指定父文档和子文档,然后形成1对多或者1对1的关系,举个例子:
我这个是5.0以上的版本,不是6.0的版本,这个我还是忘记说,大家注意下版本问题,我大概说下这个意思就是只指定my_join_field字段question的父级为answer;
接下来我们再加入2条父级文档:
接下来在加入2条子文档:
这里需要注意的问题是路由必须要指定,父级文档必须和自己文档在同一个分片上,另外就是指定join的文档和父id;
这个时候我们查看下我们形成的文档:
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
{ "took": 13, "timed_out": false, "_shards": { "total": 5, "successful": 5, "skipped": 0, "failed": 0 }, "hits": { "total": 4, "max_score": null, "hits": [ { "_index": "my_index", "_type": "doc", "_id": "1", "_score": null, "_source": { "text": "This is a question", "my_join_field": { "name": "question" } }, "sort": [ "1" ] }, { "_index": "my_index", "_type": "doc", "_id": "2", "_score": null, "_source": { "text": "This is a another question", "my_join_field": { "name": "question" } }, "sort": [ "2" ] }, { "_index": "my_index", "_type": "doc", "_id": "3", "_score": null, "_routing": "1", "_source": { "text": "This is an answer", "my_join_field": { "name": "answer", "parent": "1" } }, "sort": [ "3" ] }, { "_index": "my_index", "_type": "doc", "_id": "4", "_score": null, "_routing": "1", "_source": { "text": "This is another answer", "my_join_field": { "name": "answer", "parent": "1" } }, "sort": [ "4" ] } ] } }
看到结果我们就可以知道我们的1对多关系已经建立起来了,接下来我们按照父id来查询父id为1的文档:
这个地方还要提醒下,也是可以使用get的,只是使用神器的时候这样比较方便;
结果如下:
还可以使用has_child 返回包含某子文档的父文档,has_parent 返回包含某父文档的子文档这些就不写例子自己探索一下吧;
接下来做个对比:
注意:Mapping字段不要设置太多;
三、部分优化的意见
elasticsearch.yml中建议设定的参数:
之前集群搭建的时候大家肯定设置一些参数,另外上面你的介绍也设置了一些参数,我们也具体来说下在上生产环境之前到底要设置那些参数:
1.cluster.name集群名称;
2.node.name节点名称;
3.node.master是否是主节点;
4.node.data是否存放数据,主节点不建议存放数据;
5.discovery.zen.ping.unicast.hosts设置集群的其他节点;
6.network.host IP;
7.path.data and path.logs 存放记录和日志的目录,默认是在Elasticsearch目录下;
8.discovery.zen.minimum_master_nodes 集群挂掉以后选举主的个数;
JVM设置:
1.将最小堆大小(Xms)和最大堆大小(Xmx)设置为彼此相等,防止垃圾回收过于频繁;
2.将Xmx设置为不超过物理RAM的50%,以确保有足够的物理RAM用于内核文件系统缓存;
3.不要超过32GB,这是JVM优化的建议;
分片的设置:
建议阅读这篇文章;
读写优化:
写入的优化,这个参考下Elastic Stack-Elasticsearch使用介绍(三)这篇文章,这篇文章我介绍写入时候的一些步骤,我们优化的方向就是从这3个方向:
当然要贯彻多线程、批量写入这个不能变得方针,针对refresh、translog、flush这3个方面做优化:
1.refresh
每refresh一次都会生成一个segment,如果refresh频率过高,可能会照成segment包含的文档数是很少,生成很多的segment;
调整方向
增大refresh_interval,降低实时性,默认是1s,设置为-1直接禁止自动refresh;
增大缓存区的大小,参数为indices.memory.index_buffer_size(静态参数,在elasticsearch.yml中设定,该参数设置后必须重启节点),默认为10%;
2.translog
目标是降低translog写磁盘的频率,从而提高效率,但是这样就会有掉丢数据的风险;
调整方向
index.translog.durabiliy设置为asyn,index.translog.sync_interval设置写入时间的间隔,单位是秒,比如10s,那么translog会改为每10s写一次磁盘,这个时候如果宕机就会丢失数据;
index.translog.flush_threshold_size 默认为512MB,超过该大小时会触发一次flush;
3.合理设置节点和分片的个数,通过设置index.routing.allocation.total_shards_per_node 限定每个索引在每个节点上可分配的总主副分片的个数;
读取的优化:
1.合理设置分片数
通过测试一个分片性能,然后根据业务进行计算,设置合理的分片个数;怎么测试一个分片的性能?首先搭建与生产一样的环境,接下来设定一个单分片无副本的索引,然后进行写入数据测试 和查询数据,然后根据提供的监控指标进行监控压力测试的情况,这部分监控内容下一章进行讲解;压测工具可以使用esrally,参考下这篇文章;
2.优化查询语句
尽量使用Filter上下文,减少算分的场景,由于Filter有缓存机制,可以提升查询性能;
四、结束
接下来会开始说一说监控的问题,欢迎大家加群438836709,欢迎大家关注我公众号!