影响因子分析

Elasticsearch组件的索引和查询性能主要受到物理资源（内存、磁盘、CPU、网络）和逻辑资源（数据类型、数据长度、分词类别）的影响。

物理资源

影响因子如：

• 内存：内存大小会影响到写入数据的速度、缓存的多少。
• 磁盘：磁盘的性能影响到索引数据写入磁盘的速度。
• CPU：CPU的性能影响到分词的速度、处理倒排索引的速度等。
• 网络：影响到分布式索引和查询消息处理的速度。

逻辑资源

影响因子如：

• 数据类型：字符串、整型、浮点型，不同的数据类型对资源的消耗程度不同。
• 数据长度：字段的大小对资源的消耗程度不同。
• 分词类别：采用不同的分词器对资源的消耗程度不同。
• shard个数划分：根据数据量的不同应当对index赋予不同的shard个数。

物理资源规划

频繁的请求下，Elasticsearch对内存、CPU、网络与磁盘的性能有较高的要求，一般情况下，建议Elasticsearch独占这些物理资源，尽量不与其他耗资源的组件合布。

磁盘使用必须使用SAS盘，不建议使用SATA盘进行存储。

内存配置

FusionInsight Elasticsearch单节点（node）默认分配的HeapSize为4GB，若机器内存的50%>实例数*31G，设置为31G，否则设置为机器内存的50%/实例数。资源允许的情况下，单个实例可以分配的最大HeapSize不要超过31GB。

另外，需要留下一半的物理内存作为Lucene缓存使用。如果不按照此建议设置，将会影响索引与查询的性能。

示例

• 如果系统为128GB物理内存，那么建议留下64GB预留给Lucene缓存，剩下的64GB可以分配2个Elasticsearch节点（nodes）。每个节点分配31GB内存。
• 如果系统为256GB物理内存，安装上面的计算实际上我们可以设置4个EsNode但是不建议安装4个。 说明： 256G及以上内存的机器只建议安装3个EsNode实例。虽然内存满足要求，但是由于受CPU核数的限制集群性能不会有太大提升。多余的内存Lucene也会全部利用了。

磁盘挂载

Elasticsearch单索引数据目前可以较优支持到TB级别，数据量庞大，建议Elasticsearch按照实例（nodes）进行单独挂盘。

示例

用户某个物理机上分配了两个Elasticsearch nodes，分别是EsNode1和EsNode2，一个实例对应写一个固定磁盘。需要为这两个实例挂载两个磁盘，挂载目录分别为“/srv/BigData/elasticsearch/esnode1/”和“/srv/BigData/elasticsearch/esnode2/”。

说明：

• 磁盘类型不同，性能也相差巨大。如：SSD读写速度大约是SAS盘的50倍，而SAS盘读写速度可以达到SATA盘的2倍以上。
• Elasticsearch的总实例数在500以上时，EsMaster必须使用SSD盘，且EsMaster可使用的CPU资源要大于等于32核。

shard个数规划

一个index可以被分为多个shards，从而分布到不同的物理机上。Shard的划分结果也会影响索引和查询速度。

每个分片都可以处理数据写入和查询请求，在设置索引分片数时，可从以下几个方面考虑：

• 每个shard包含的数据条数越多，查询性能会降低（建议1亿条左右，最多建议不超过4亿）。
• 建议单个分片保存的数据量在20GB左右，最大不超过30GB。
• 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。一般来说，预计存储的数据量越大，应当分配的shard越多，分布式查询的优势越明显。如果确认某个index的数据量非常少（如一年不到1GB），那么过多的分配shard，反而可能不如单shard的性能好
• 为了提升数据可靠性，合理设置副本分片个数，至少设置为1，如果集群的存储空间足够，推荐设置为2。
• 每个node可以支撑的shards个数是有限的，node是物理资源分配的对象，随着shards中数据的增大，shards中的数据在查询时被不断加载到内存，达到一定量时，将会把HeapSize耗尽，导致频繁GC，系统将不能正常工作。推荐1GB内存管理15个shard，以一个Elasticsearch实例内存最大31G为例，单实例管理的shard数保持在500以内。
• 当Elasticsearch集群实例数大于500时，请确保Elasticsearch集群的总shard数小于等于50000个。过多的shard数会导致EsMaster压力过大，Elasticsearch集群不稳定。

shard个数规划

一个index可以被分为多个shards，从而分布到不同的物理机上。Shard的划分结果也会影响索引和查询速度。

每个分片都可以处理数据写入和查询请求，在设置索引分片数时，可从以下几个方面考虑：

• 每个shard包含的数据条数越多，查询性能会降低（建议1亿条左右，最多建议不超过4亿）。
• 建议单个分片保存的数据量在20GB左右，最大不超过30GB。
• 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。一般来说，预计存储的数据量越大，应当分配的shard越多，分布式查询的优势越明显。如果确认某个index的数据量非常少（如一年不到1GB），那么过多的分配shard，反而可能不如单shard的性能好
• 为了提升数据可靠性，合理设置副本分片个数，至少设置为1，如果集群的存储空间足够，推荐设置为2。
• 每个node可以支撑的shards个数是有限的，node是物理资源分配的对象，随着shards中数据的增大，shards中的数据在查询时被不断加载到内存，达到一定量时，将会把HeapSize耗尽，导致频繁GC，系统将不能正常工作。推荐1GB内存管理15个shard，以一个Elasticsearch实例内存最大31G为例，单实例管理的shard数保持在500以内。
• 当Elasticsearch集群实例数大于500时，请确保Elasticsearch集群的总shard数小于等于50000个。过多的shard数会导致EsMaster压力过大，Elasticsearch集群不稳定。