一、 目的

为了在软件生命周期内规范数据库相关的设计、开发、运维工作，便于不同团队之间的沟通及协调，制定此文档，以期在相关规范上达成共识和默契，提升相关环节的工作效率及系统的可维护性。同时好的规范，在执行的时候可以培养出好的习惯，好的习惯是软件质量的很好保证。

二、ElasticSearch操作管理规范

2.1、前言

Elasticsearch是一个实时的分布式搜索和分析引擎，它可以帮助我们用很快的速度去处理大规模数据，可以用于全文检索、结构化检索、推荐、分析以及统计聚合等多种场景。
Elasticsearch的数据存储在本地lucene文件，采用json的数据格式，同时提供了简单易用的restful接口。
本文主要结合之前在实际应用场景下的实践和探索结果，从业务场景，集群规划，数据规划，如何进行写入和查询调优，包括常见的问题出发。总结和梳理Elasticsearch在安平行业的最佳实践。

2.2、业务场景

2.2.1、数据特点

1. 从大量的日志型数据中，根据关键字搜索出相关的信息。需要把所有搜索结果过滤出来，便于进行二次分析（需要返回大量的查询结果，一般万级别以上）。
2. 从轨迹型数据中，根据关键信息搜索出相关的轨迹变化。需要对搜索过程中按照一定的字段进行聚合（需要返回的查询结果相对较小，对查询响应时间要求高）。
   从数据存储周期来看：大部分数据保存周期为3-6个月，部分数据保存1年以上，甚至永久保存。
   从业务场景来看：基本都属于写多查少的场景，或者写入和查询都多的场景。这就对ES集群的存储和查询能力有较高的要求。

2.2.2、ES在业务场景下的特点

 一次写入多次查询：ES适合一次写入多次查询的场景，支持update更新操作，但是如果需要进行索引mapping的更改，需要reindex重建或者新建索引，更改成本较大，所以在大部分场景下，数据写入之后不再更新。
 全文检索：ES的优势在于全文检索，模糊查询，适合需要从大量的数据中根据某些关键信息挖掘有价值的数据的场景。

2.3、【开发+DBA】集群规划

新业务接入，评估项

2.3.1 数据预处理

存在大量的重复数据或对数据进行一定的规则转换，需要前期对数据进行一定的预处理，然后再入库ES，常见的做法有下面几种：
 增加Kafka集群缓冲（数据时效性相对较低，一般在小时级），在数据写入之前增加Kafka消息队列进行数据缓冲，保证ES集群的写入压力较为平稳。
 通过redis、spark或者其他预处理程序，对数据进行清洗，去重等。

2.3.2 ES or ES+HBase

在进行集群规划时，必须要根据业务进行评估，是单独部署ES集群，还是部署ES+HBase集群。
 根据索引数据判断：如果原始数据在构建ES索引的过程中，发现大部分字段（超过70%）都是需要进行全文检索的，这时建议单独部署ES集群。否则建议采用ES+HBase方案，将索引数据存储在ES，原始数据存储在HBase。同时如果索引里面有大量的非结构化数据，如大的文本，图片，视频不建议存储在ES集群。
 根据查询场景判断：如果查询需要返回大量的结果，达到万级别的返回结果，建议使用HBase进行查询，ES适合返回TOP N的场景，在大数据量的返回场景下，性能较差。
ES+HBase架构如下：
通过文档ID和rowkey使ES和HBase相关联。

2.3.3如何确定集群的规模

开发事前预估标准参考，评估项目

2.3.3.1、【开发+DBA】初始集群大小

在部署一个新集群时，应该根据多方面的情况评估需要多大的集群规模来支撑业务，除了机器的性能，还要根据具体业务情况来评估初始集群大小，比如：

1. 数据总量，每天的增量；
2. 查询和搜索并发，QPS；

2.3.3.2、【开发+DBA】控制最大集群规模和数据总量

1. 节点总数不应该太多，一般来说，最大集群规模最好控制在ES的数据实例数在300个以内。在1000多实例的集群，在这种规模下，节点间的连接数和通信倍增，主节点管理压力很大，集群稳定性和性能下降明显。如果业务规模超过一个集群最大限制，建议根据业务进行集群拆分，多集群的性能要好于大集群。
2. 最大集群分片总数控制在5W以内，单分片大小控制在50GB左右，集群整体存储量控制在1PB以内。太多分片同样增加了主节点的管理负担，而且集群重启恢复时间会很长。
3. 超过需考虑外部存储，如Hadoop，对象归档

2.3.3.3、【开发】业务上的优化

1. 对重要且常用的查询项提前作分词，查询时指定分词项，提高查询效率，在大数据量的情况下尽量避免全文检索：
   a) 如通过logstash尽量解析拆分
   b) 开发人员、日志分析人员需要确认日志格式，确认日志格式和查询条件保持一致（分词）
   c) 对于标准化产品，无法对日志进行格式出输出，是否可以增加专职日志分析处理人员，通过流式方式在线处理后接入集群
2. “分库分表”
   a) 对于日志相对大的项目、系统，进行索引拆分
   b) 通过减小单索引大小，避免所有系统都集中同一个索引，从而提高查询效率

2.3.3.4、 【开发+DBA】硬件要求

如对性能有严格要求，且数据量较大的情况下；
搜索对CPU，内存，磁盘的性能要求都很高，要达到比较低的延迟就需要较好的硬件资源。从实际经验来看，ES的性能经常受限于IO瓶颈，所以建议配置更好的磁盘，如SSD盘。

2.3.4 【开发+DBA】如何确定集群的部署

2.3.4.1、内存的配置

ES不建议为JVM配置超过32GB的内存，超过32GB内存时，java内存指针压缩失效，浪费了一些内存，降低了CPU的性能，GC压力也比较大。同时在实际的物理机环境中测试发现，当内存在30GB以下，指针压缩才生效，因此推荐设置为30GB。
-xmx30g –xms30g
确保堆内存最小值（xms）与最大值（xmx）大小相同，防止程序在运行时动态改变堆内存大小，这是很耗系统资源的过程。
另外，需要留下一半的物理内存作为Lucene缓存使用。如果不按照此建议设置，将会影响索引与查询的性能。
例如：
如果系统为128GB物理内存，那么建议可以分配2个Elasticsearch实例（nodes）。每个实例分配64GB内存。

2.3.4.2、实例的部署

独立部署主节点（管理集群），即EsMaster，将主节点和数据节点分离部署，最少需要部署3个EsMaster，防止脑裂以及备份；
部署一定数量的协调节点（即不管理集群，也不存储数据，只用于请求转发和查询fectch阶段），即EsClient，配置EsClient可以提高集群的稳定性以及快速自愈能力。建议配置EsNode：EsClient的个数为3：1。
例如：
如果系统内存为256GB内存的物理机有53台，可以部署31个EsMaster，503=150个EsNode，50*1=50EsClient。

2.4、数据规划

2.4.1、为什么数据规划很重要

任何系统都有一套更为适用的规则或者其系统规格，前期的详细设计能为我们后期维护优化节约大量的精力。在我们实际的经验中，发现大部分问题（分片严重超规格，单个分片超大，索引mapping设置不合理等问题）都是由于数据的前期规划不够，大大增加了后期整改和优化的难度和成本。
在进行数据规划之前，首先要对数据有充分的了解，包括不限于：
 数据量有多大，包括总量，增量，以及未来的趋势？
 数据的生命之旅是怎么样的，即从写入到删除的过程？
 我们期望从数据里面挖掘出什么，即数据是用来做什么的？

2.4.2、合理的规格

常见的系统规格如下所示：

2.4.3、分片如何规划

每个分片都可以处理索引和查询请求，在设定分片数目时，可从以下几个方面考虑：
 建议单个分片的数据量最大不超过50GB，过大的分片会降低查询以及索引恢复的性能。
 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。
 为了提升数据可靠性，合理设置副本分片个数，至少设置为1，如果集群的存储空间足够，推荐设置为2。
 每个node可以支撑的shards个数是有限的，node是物理资源分配的对象，随着shards中数据的增大，shards中的数据在查询时被不断加载到内存，达到一定量时，将会把HeapSize耗尽，导致频繁GC，系统将不能正常工作。推荐1GB内存管理15个shard，以一个Elasticsearch实例内存最大31G为例，单实例管理的shard数保持在500以内。
 配置total_shards_per_node参数，让分片更加均匀的分布在各个实例上。表示限制每个实例上分布该该索引的分片最大个数，如2，即表示每个实例上最多分布2个该索引的分片。
 说明：total_shards_per_node参数值=索引总分片数/数据实例数（向上取整）。

2.4.4、数据结构如何规划

通常的使用场景中，一个集群内的业务数据一般分为几类，为了更加方便数据管理，通常会将相近的数据结构的数据归为一类。这时候建议使用索引模板规范索引的建立，不同类别的数据创建不同的索引模板。

2.4.4.1、【开发】索引模板

Elasticsearch提供一种叫“索引模板”方式，帮助用户在新创建索引时采用提前设定好的参数，简化创建过程。索引模板可以设置包括order、template、settings和mappings等部分设置灵活。索引模板仅在新创建索引时起作用，修改索引模板不对会现有已经创建的索引产生影响。索引模板设定后，会根据模板设定规则，在满足设定条件的时候起作用，如果创建的索引中已经指定索引模板设置的参数则索引模板不会起作用。
索引模板设置内容如下：

 order：模板优先级，最大值2147483647（JAVA Integer.MAX_VALUE - 1），Order值越大优先级越高，如果不设置则为0；
 template：模板匹配的名称方式，比如：“te*”表示匹配名称以“te”开头的索引，如果为“*”表示匹配所有的索引；
 settings：索引设置，一般定义的是索引的主分片、拷贝分片、刷新时间、自定义分析器等；
 mappings：索引中各个字段的映射定义，可以设置动态映射和自定义字段映射；
 aliases：设置索引别名。
注意：如果匹配到多个模板（和匹配规则无关，只要匹配到了就行，即匹配规则不影响模板的优先级），会将这些模板的设置进行合并，不同的优先级相同的设置属性优先使用优先级高的配置，如果相同的优先级相同的属性设置则优先使用最先创建的那个模板，其他的不相同的属性会合并到一起。

{ 
"order": 0, 
"template": "*", 
"settings": { 
"index": { 
"number_of_replicas":"1", 
"store.type":"niofs", 
"translog.durability":"async", 
"translog.flush_threshold_size":"3gb", 
"search.slowlog.threshold.query.warn": "10s", 
"search.slowlog.threshold.query.info": "5s", 
"search.slowlog.threshold.query.debug": "2s", 
"indexing.slowlog.threshold.index.warn": "10s", 
"indexing.slowlog.threshold.index.info": "5s", 
"indexing.slowlog.threshold.index.debug": "2s", 
"indexing.slowlog.source": "500" 
} 
} 
}

2.4.4.2、【开发】索引的创建

 为了减少索引数量并避免非常庞大的映射，请考虑将相同索引结构的数据存储在相同的索引中；
 避免将不相关的数据放在同一个索引中，以避免稀疏，将这些文件放在不同的索引中通常会更好；
 针对数据量比较大的索引，建议按周期进行分表，比如按天进行索引划分；
 建议提前创建好索引，不要自动创建索引，可以避免集群内出现一些杂乱的数据。可通过设置参数auto_