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;

这个时候我们查看下我们形成的文档:

{
    "took": ,
    "timed_out": false,
    "_shards": {
        "total": ,
        "successful": ,
        "skipped": ,
        "failed":
    },
    "hits": {
        "total": ,
        "max_score": null,
        "hits": [
            {
                "_index": "my_index",
                "_type": "doc",
                "_id": "",
                "_score": null,
                "_source": {
                    "text": "This is a question",
                    "my_join_field": {
                        "name": "question"
                    }
                },
                "sort": [
                    ""
                ]
            },
            {
                "_index": "my_index",
                "_type": "doc",
                "_id": "",
                "_score": null,
                "_source": {
                    "text": "This is a another question",
                    "my_join_field": {
                        "name": "question"
                    }
                },
                "sort": [
                    ""
                ]
            },
            {
                "_index": "my_index",
                "_type": "doc",
                "_id": "",
                "_score": null,
                "_routing": "",
                "_source": {
                    "text": "This is an answer",
                    "my_join_field": {
                        "name": "answer",
                        "parent": ""
                    }
                },
                "sort": [
                    ""
                ]
            },
            {
                "_index": "my_index",
                "_type": "doc",
                "_id": "",
                "_score": null,
                "_routing": "",
                "_source": {
                    "text": "This is another answer",
                    "my_join_field": {
                        "name": "answer",
                        "parent": ""
                    }
                },
                "sort": [
                    ""
                ]
            }
        ]
    }
}

看到结果我们就可以知道我们的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，欢迎大家关注我公众号！