在本文中, 我将介绍在分片分配时的一些权衡以及不同设置带来的性能影响. 如果想搞清晰你的分片策略以及如何优化,请继续往下阅读.
分片分配是个很重要的概念, 很多用户对如何分片都有所疑惑, 当然是为了让分配更合理. 在生产环境中, 随着数据集的增长, 不合理的分配策略可能会给系统的扩展带来严重的问题.
同时, 这方面的文档介绍也非常少. 很多用户只想要明确的答案而不仅仅一个数字范围, 甚至都不关心随意的设置可能带来的问题.
当然,我也有一些答案. 不过先要看看它的定义和描述, 然后通过几个通用的案例来分别给出我们的建议.
如果你刚接触ElasticSearch, 那么弄清楚它的几个术语和核心概念是非常必要的.
(如果你已经有ES的相关经验, 可以跳过这部分)
假设ElasticSearch集群的部署结构如下:
通过该图, 记住下面的几个定义:
集群(cluster):由一个或多个节点组成, 并通过集群名称与其他集群进行区分
节点(node):单个ElasticSearch实例. 通常一个节点运行在一个隔离的容器或虚拟机中
索引(index):在ES中, 索引是一组文档的集合
分片(shard):因为ES是个分布式的搜索引擎, 所以索引通常都会分解成不同部分, 而这些分布在不同节点的数据就是分片. ES自动管理和组织分片, 并在必要的时候对分片数据进行再平衡分配, 所以用户基本上不用担心分片的处理细节，一个分片默认最大文档数量是20亿.
副本(replica):ES默认为一个索引创建5个主分片, 并分别为其创建一个副本分片. 也就是说每个索引都由5个主分片成本, 而每个主分片都相应的有一个copy.
对于分布式搜索引擎来说, 分片及副本的分配将是高可用及快速搜索响应的设计核心.主分片与副本都能处理查询请求, 它们的唯一区别在于只有主分片才能处理索引请求.
在上图示例中, 我们的ElasticSearch集群有两个节点, 并使用了默认的分片配置. ES自动把这5个主分片分配到2个节点上, 而它们分别对应的副本则在完全不同的节点上. 对,就这是分布式的概念.
请记住, 索引的 number_of_shards 参数只对当前索引有效而不是对整个集群生效.对每个索引来讲, 该参数定义了当前索引的主分片数(而不是集群中所有的主分片数).
本文中不会对ElasticSearch的副本做详细阐述. 如果想单独了解可参考 这篇文章 .
副本对搜索性能非常重要, 同时用户也可在任何时候添加或删除副本. 正如 另篇文章 所述, 额外的副本能给你带来更大的容量, 更高的呑吐能力及更强的故障恢复能力.
当在ElasticSearch集群中配置好你的索引后, 你要明白在集群运行中你无法调整分片设置. 既便以后你发现需要调整分片数量, 你也只能新建创建并对数据进行重新索引(reindex)(虽然reindex会比较耗时, 但至少能保证你不会停机).
主分片的配置与硬盘分区很类似, 在对一块空的硬盘空间进行分区时, 会要求用户先进行数据备份, 然后配置新的分区, 最后把数据写到新的分区上.
分配分片时主要考虑的你的数据集的增长趋势.
我们也经常会看到一些不必要的过度分片场景. 从ES社区用户对这个热门主题(分片配置)的分享数据来看, 用户可能认为过度分配是个绝对安全的策略(这里讲的过度分配是指对特定数据集, 为每个索引分配了超出当前数据量(文档数)所需要的分片数).
Elastic 在早期确实鼓吹过这种做法, 然后很多用户做的更为极端--例如分配1000个分片. 事实上, Elastic目前对此持有 更谨慎的态度 .
要知道, 你分配的每个分片都是有额外的成本的:
我们的客户通常认为随着业务的增长, 他们的数据量也会相应的增加, 所以很有必要为此做长期规划. 很多用户相信他们将会遇到暴发性增长(尽管大多数甚至都没有遇到过峰值), 当然也希望避免重新分片并减少可能的停机时间.
如果你真的担心数据的快速增长, 我们建议你多关心这条限制: ElasticSearch推荐的最大JVM堆空间 是30~32G, 所以把你的分片最大容量限制为30GB, 然后再对分片数量做合理估算. 例如, 你认为你的数据能达到200GB, 我们推荐你最多分配7到8个分片.
总之, 不要现在就为你可能在三年后才能达到的10TB数据做过多分配. 如果真到那一天, 你也会很早感知到性能变化的.
尽管本部分并未详细讨论副本分片, 但我们推荐你保持适度的副本数并随时可做相应的增加. 如果你正在部署一个新的环境, 也许你可以参考我们的 基于副本的集群 的设计.这个集群有三个节点组成, 每个分片只分配了副本. 不过随着需求变化, 你可以轻易的调整副本数量.
对大数据集, 我们非常鼓励你为索引多分配些分片--当然也要在合理范围内. 上面讲到的每个分片最好不超过30GB的原则依然使用.
不过, 你最好还是能描述出每个节点上只放一个索引分片的必要性. 在开始阶段, 一个好的方案是根据你的节点数量按照1.5~3倍的原则来创建分片. 例如,如果你有3个节点, 则推荐你创建的分片数最多不超过9(3x3)个.
随着数据量的增加,如果你通过 集群状态API 发现了问题,或者遭遇了性能退化,则只需要增加额外的节点即可. ES会自动帮你完成分片在不同节点上的分布平衡.
再强调一次, 虽然这里我们暂未涉及副本节点的介绍, 但上面的指导原则依然使用: 是否有必要在每个节点上只分配一个索引的分片. 另外, 如果给每个分片分配1个副本, 你所需的节点数将加倍. 如果需要为每个分片分配2个副本, 则需要3倍的节点数. 更多详情可以参考 基于副本的集群 .
不知道你是否有基于日期的索引需求, 并且对索引数据的搜索场景非常少. 也许这些索引量将达到成百上千, 但每个索引的数据量只有1GB甚至更小. 对于这种类似场景, 我建议你只需要为索引分配1个分片.
如果使用ES的默认配置(5个分片), 并且使用Logstash按天生成索引, 那么6个月下来, 你拥有的分片数将达到890个. 再多的话, 你的集群将难以工作--除非你提供了更多(例如15个或更多)的节点.
想一下, 大部分的Logstash用户并不会频繁的进行搜索, 甚至每分钟都不会有一次查询. 所以这种场景, 推荐更为经济使用的设置. 在这种场景下, 搜索性能并不是第一要素, 所以并不需要很多副本. 维护单个副本用于数据冗余已经足够. 不过数据被不断载入到内存的比例相应也会变高.
如果你的索引只需要一个分片, 那么使用Logstash的配置可以在3节点的集群中维持运行6个月. 当然你至少需要使用4GB的内存, 不过建议使用8GB, 因为在多数据云平台中使用8GB内存会有明显的网速以及更少的资源共享.
再次声明, 数据分片也是要有相应资源消耗,并且需要持续投入.
当索引拥有较多分片时, 为了组装查询结果, ES必须单独查询每个分片(当然并行的方式)并对结果进行合并. 所以高性能IO设备(SSDs)和多核处理器无疑对分片性能会有巨大帮助. 尽管如此, 你还是要多关心数据本身的大小,更新频率以及未来的状态. 在分片分配上并没有绝对的答案, 只希望你能从本文的讨论中受益.
添加分片：
修改副本：
此文的原文为 https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index
Elasticsearch船只具有良好的默认值，并且只需要很少的配置。可以在运行的集群上使用集群更新设置API更改大多数设置。
配置文件应该包含特定于节点的设置(例如node.name和路径)，或者节点为了能够加入集群而需要的设置，例如 cluster.name 和 network.host 。
Elasticsearch有三个配置文件:
这些文件位于config目录中，其默认位置取决于安装是来自存档分发版(tar.gz或zip)还是包分发版(Debian或RPM包)。
对于存档发行版，config目录位置默认为 $ES_HOME/config 。配置目录的位置可以通过 ES_PATH_CONF 环境变量改变，如下所示:
或者，您可以通过命令行或shell配置文件导出ES_PATH_CONF环境变量。
对于包分发，配置目录位置默认为 /etc/elasticsearch 。配置目录的位置也可以通过 ES_PATH_CONF 环境变量更改，但是请注意，仅在shell中设置是不够的。相反，这个变量来源于 /etc/default/elasticsearch (用于Debian包)和 /etc/sysconfig/elasticsearch (用于RPM包)。您需要相应地在其中一个文件中编辑 ES_PATH_CONF=/etc/elasticsearch 条目，以更改配置目录的位置。
配置格式为YAML。下面是更改数据和日志目录路径的示例:
设置也可以扁平化如下:
在YAML中，你可以将非标量值格式化为序列:
虽然不太常见，但你也可以将非标量值格式化为数组:
使用${…}符号将被替换为环境变量的值。例如:
环境变量的值必须是简单字符串。使用逗号分隔的字符串来提供Elasticsearch将解析为列表的值。例如，Elasticsearch将以下字符串分割为 ${HOSTNAME} 环境变量的值列表
集群和节点设置可以根据配置方式进行分类:
您可以使用 集群更新设置API 在运行的集群上配置和更新动态设置。您还可以使用 elasticsearch.yml 在未启动或关闭的节点上本地配置动态设置。
使用集群更新设置API进行的更新可以是持久的(跨集群重启应用)，也可以是短暂的(在集群重启后重置)。您还可以通过使用API为临时或持久设置赋值为空来重置它们。
如果您使用多个方法配置相同的设置，Elasticsearch将按照以下优先顺序应用这些设置:
例如，您可以应用瞬变设置来覆盖持久设置或 elasticsearch.yml 设置。然而，对 elasticsearch.yml 的更改,不会覆盖已定义的瞬态或持久设置。
最好使用集群更新设置API设置动态的集群范围设置，并使用 elasticsearch.yml 仅用于本地配置。使用集群更新设置API可以确保所有节点上的设置是相同的。如果您不小心在 elasticsearch.yml 中配置了不同的设置。在不同的节点上，很难注意到差异。
静态设置只能在未启动或关闭的节点上使用 elasticsearch.yml 进行配置。
必须在集群中的每个相关节点上设置静态设置
Elasticsearch开始时只需要很少的配置，但是在生产环境中使用集群之前，有很多方面需要考虑:
Elasticsearch将创建索引的数据写入索引，将数据流写入数据目录。Elasticsearch将自己的应用程序日志(其中包含关于集群运行状况和 *** 作的信息)写入日志目录
对于macOS .tar.gz、Linux .tar.gz和Windows .zip安装，数据和日志默认是 $ES_HOME 的子目录。但是，在升级过程中， $ES_HOME 中的文件有被删除的风险
In production, we strongly recommend you set the path.data and path.logs in elasticsearch.yml to locations outside of $ES_HOME . Docker , Debian , RPM , macOS Homebrew , and Windows .msi installations write data and log to locations outside of $ES_HOME by default.
To avoid errors, only Elasticsearch should open files in the path.data directory. Exclude the path.data directory from other services that may open and lock its files, such as antivirus or backup programs.
Supported path.data and path.logs values vary by platform
只有当一个节点与集群中的所有其他节点共享 cluster.name 时，该节点才能加入集群。默认名称是 elasticsearch ，但是您应该将其更改为描述集群用途的适当名称。
不要在不同的环境中重用相同的集群名称。否则，节点可能会加入错误的集群
Elasticsearch使用 node.name 作为Elasticsearch特定实例的人类可读标识符。这个名称包含在许多api的响应中。当Elasticsearch启动时，节点名默认为机器的主机名，但是可以在 elasticsearch.yml 中显式配置
缺省情况下，Elasticsearch只绑定到 127.0.0.1 和 [::1] 等环回地址。这对于在单个服务器上运行一个或多个节点的集群进行开发和测试已经足够了，但是 d性生产集群 必须包含其他服务器上的节点。有许多 网络设置 ，但通常你只需要配置 network.host :
当你为 network.host 提供值时。Elasticsearch假定您正在从开发模式转向生产模式，并将一些系统启动检查从警告升级到异常。看看 开发和生产模式 之间的区别。
在投入生产之前，配置两个重要的发现和集群形成设置，以便集群中的节点能够相互发现并选择一个主节点。
Elasticsearch可以开箱即用，无需任何网络配置，它将绑定到可用的环回地址，并扫描本地端口 9300 到 9305 ，以便与运行在同一服务器上的其他节点连接。这种行为提供了一种无需进行任何配置的自动集群体验。
当您希望与其他主机上的节点形成集群时，使用 静态 discovery.seed_hosts 设置. This setting provides a list of other nodes in the cluster that are master-eligible and likely to be live and contactable to seed the discovery process .
此设置接受集群中所有符合主节点的地址的YAML序列或数组。每个地址可以是一个IP地址，也可以是通过DNS解析为一个或多个IP地址的主机名。
当您第一次启动Elasticsearch集群时， 集群引导 步骤将确定在第一次选举中计票的符合主资格的节点集。在 开发模式 下，如果没有配置发现设置，这个步骤将由节点自己自动执行。
因为自动引导 本身就不安全 ,，所以在生产模式下启动新集群时，必须显式列出符合主资格的节点，这些节点的投票应该在第一次选举中计算。您可以使用集群设置此列表。 initial_master_nodes 设置。
在集群第一次成功形成之后，删除每个节点配置中的 Initial_master_nodes 设置。在重新启动集群或向现有集群添加新节点时，不要使用此设置。
通过节点的 node.name 标识初始主节点, 该节点默认为主节点的主机名。请确保 cluster.initial_master_nodes 值 与 node.name 完全匹配如果您使用完全限定的域名(FQDN)，例如master-node-a.example.com作为您的节点名，那么您必须在此列表中使用FQDN。相反，如果node.name是没有任何尾随限定符的裸主机名，您也必须省cluster.initial_master_nodes中的尾随限定符如果您使用完全限定的域名(FQDN)，例如 master-node-a.example.com 作为您的节点名, 那么您必须在此列表中使用FQDN。相反，如果f node.name 是没有任何尾随限定符的裸主机名，您也必须省略 cluster.initial_master_nodes 中的尾随限定符。
请参见 bootstrapping a cluster 以及 发现和集群形成设置 .
默认情况下，Elasticsearch会根据节点的 角色 和总内存自动设置JVM堆大小。对于大多数生产环境，我们建议使用默认大小。
自动堆大小需要 bundled JDK ，如果使用自定义JRE位置，则需要Java 14或更高版本的JRE。
如果需要，您可以通过手动 设置JVM堆大小 来覆盖默认大小
默认情况下，Elasticsearch将JVM配置为将堆内存溢出异常转储到默认数据目录。在RPM和Debian软件包中，数据目录是/var/lib/elasticsearch。在Linux、MacOS和Windows发行版上，数据目录位于Elasticsearch安装的根目录下。
如果此路径不适合接收堆转储，请修改 -XX:HeapDumpPath=…jvm.options
默认情况下，Elasticsearch启用垃圾收集(GC)日志。这些是在jvm中配置的 jvm.options 并输出到与Elasticsearch日志相同的默认位置。默认配置每64mb轮换一次日志，最多可以消耗2gb的磁盘空间。
您可以使用 JEP 158: Unified JVM Logging 中描述的命令行选项重新配置JVM日志。除非您更改了默认jvm。选项文件，Elasticsearch默认配置将应用于您自己的设置之外。要禁用默认配置，首先通过提供 -Xlog:disable 选项禁用日志记录，然后提供您自己的命令行选项。这将禁用所有JVM日志记录，因此一定要检查可用选项并启用所需的所有内容。
要查看原始JEP中未包含的其他选项，请参见使用 JVM统一日志框架启用日志记录 .
Change the default GC log output location to /opt/my-app/gc.log by creating $ES_HOME/config/jvm.options.d/gc.options with some sample options:
Configure an Elasticsearch Docker container to send GC debug logs to standard error ( stderr ). This lets the container orchestrator handle the output. If using the ES_JAVA_OPTS environment variable, specify:
默认情况下，Elasticsearch使用启动脚本直接在系统临时目录下创建的私有临时目录。
在某些Linux发行版上，如果最近没有访问过/tmp中的文件和目录，系统实用程序将清除它们。如果需要临时目录的特性长时间不使用，那么在Elasticsearch运行时，这种行为会导致私有临时目录被删除。如果随后使用需要此目录的特性，则删除私有临时目录会导致问题。
如果您使用.deb或.rpm包安装Elasticsearch，并在systemd下运行它，那么Elasticsearch使用的私有临时目录将被排除在定期清理之外。
如果您打算在Linux或MacOS上长时间运行.tar.gz发行版，请考虑为Elasticsearch创建一个专用的临时目录，该目录不在将旧文件和目录清除的路径下。这个目录应该设置权限，以便只有作为Elasticsearch运行的用户才能访问它。然后，在启动Elasticsearch之前，设置$ES_TMPDIR环境变量指向这个目录。
默认情况下，Elasticsearch将JVM配置为将致命错误日志写入默认日志目录。对于 RPM 和 Debian 软件包, 这个目录是 /var/log/elasticsearch . On Linux and MacOS and Windows 发行版, logs 目录位于Elasticsearch安装根目录下。
这些日志是JVM遇到致命错误(例如分段错误)时产生的。如果此路径不适合接收日志，请修改 -XX:ErrorFile=... 在 jvm.options 条目。
在灾难中，快照可以防止数据永久丢失。快照生命周期管理是对集群进行定期备份的最简单方法。有关更多信息，请参见备份集群。
在灾难中, 快照 可以防止数据永久丢失. 快照生命周期管理 是对集群进行定期备份的最简单方法. 有关更多信息, 请参见 备份集群 。
备份集群的唯一可靠和受支持的方法是使用快照。您不能通过复制Elasticsearch集群节点的数据目录来备份该集群。不支持从文件系统级备份恢复任何数据的方法。如果试图从这样的备份恢复集群，可能会出现损坏、丢失文件或其他数据不一致的报告，或者看起来已经成功地悄无声息地丢失了一些数据。
有些设置是敏感的，仅依靠文件系统权限来保护它们的值是不够的。对于这个用例，Elasticsearch提供了一个密钥存储库和 elasticsearch -keystore 工具 来管理密钥存储库中的设置。
只有重新启动Elasticsearch后，对keystore的所有修改才会生效。
这些设置就像elasticsearch中的常规设置一样。Yml配置文件，需要在集群中的每个节点上指定。目前，所有安全设置都是特定于节点的设置，在每个节点上必须具有相同的值。
Just like the settings values in elasticsearch.yml , 对密钥存储库内容的更改不会自动应用到运行的Elasticsearch节点。重新读取设置需要重新启动节点。但是，某些安全设置被标记为 可重新加载 。. Such settings can be re-read and applied on a running node .
所有安全设置的值(无论是否可重新加载)必须在所有集群节点上相同。在进行所需的安全设置更改后，使用 bin/elasticsearch-keystore add 命令, call:
keystore-password : 用于加密Elasticsearch密钥库的密码
此API在每个集群节点上解密并重新读取整个密钥存储库，但只应用可重新加载的安全设置。对其他设置的更改直到下次重启才会生效。一旦调用返回，重新加载就完成了，这意味着依赖于这些设置的所有内部数据结构都已更改。所有的设置都应该从一开始就具有新值。
当更改多个可重新加载的安全设置时，在每个集群节点上修改所有安全设置，然后发出 reload_secure_settings 调用，而不是在每次修改后重新加载。
有可重新加载的安全设置:
1)修改启动脚本参数在启动脚本中，增加如下参数
%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy -Dweblogic.threadpool.MinPoolSize=100 -Dweblogic.threadpool.MaxPoolSize=500 %PROXY_SETTINGS% %SERVER_CLASS%
2)修改config.xml
在config.xml中，增加如下参数
<server><name>AdminServer</name><self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min><self-tuning-thread-pool-size-max>500</self-tuning-thread-pool-size-max><listen-port>7923</listen-port><listen-address></listen-address></server>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）