网罗Elasticsearch最佳实践,实际应用场景中常见错误要预知和避免,以最大化提升集群性能。
如果不定义Mapping,Elasticsearch会根据输入的数据,创建对应的Mapping,这看起来非常完美,但是Elasticsearch的动态Mapping并不总是精确的。
动态Mapping对于入门很有用
,但在某些时候您需要结合业务数据指定Mapping。
举例1:5.x版本之后,需要分词的字段需要设定text类型和对应的analyzer
;仅需要精确匹配的可直接设置为keyword类型。
举例2:长文本高亮需要在text类型的基础上,设置fast-vector-highlighter
高亮方式,高亮效率能提升20倍以上。
在某些聚合中,没有足够的内存来支持复杂的嵌套聚合,导致聚合结果超时甚至OOM
。
举例说明:
现有9亿条数据,45个索引,每条数据大小为2k左右 在查询时候,
首先要按照时间进行排序,然后做三次分组操作?
https://elasticsearch.cn/question/6323
群友讨论实际问题
聚合爆炸是计算问题,可能导致某些聚合的桶生成呈指数增长,并可能导致不受控制的内存使用。
Elasticsearch“terms”字段根据您的数据构建存储桶,但无法预测将提前创建多少存储桶。 对于由多个子聚合组成的父聚合,这可能会有问题。 组合每个子聚合中的唯一值可能会导致创建的桶数量大幅增加。
我们来看一个例子。
假设您有一个代表运动队的数据集。 如果你想特别关注那支球队的前10名球员和以及他们的支持球员,那么聚合将如下所示
1{
2"aggs" : {
3"play_aggs" : {
4"terms" : {
5"field" : "players",
6"size" : 10
7},
8"aggs" : {
9"other_aggs" : {
10"terms" : {
11"field" : "players",
12"size" : 5
13}
14}
15}
16}
17}
18}
聚合将返回前10名球员的列表以及每位顶级球员的前五名支持球员的列表 - 这样总共将返回50个值。这个看上去简单的查询可以轻而易举地消耗大量内存。
terms聚合可以显示为使用每个级别的桶的树。因此,以上聚合中每个顶级球员的桶将构成第一级,而另一个聚合中的每个支持球员的桶将构成第二级。因此,一个团队将生产n²桶
。想象一下,如果您拥有5亿个文档的数据集会发生什么
。
Collection Mode用于帮助控制子聚合的执行方式。聚合的默认Collection Mode称为深度优先,首先需要构建整个树,然后修剪边缘。虽然深度优先是大多数聚合的适当收集模式,但它不适用于上面的运动员聚合示例。因此,Elasticsearch允许您将特定聚合中的收集模式更改为更合适
的方式。
诸如上面的示例之类的规范应该使用广度优先收集模式
,该模式一次构建和修剪树一级以控制聚合爆炸。 此收集模式极大地帮助减少消耗的内存量并保持节点稳定。
1{
2"aggs" : {
3"play_aggs" : {
4"terms" : {
5"field" : "players",
6"size" : 10,
7"collect_mode" : "breadth_first"
8},
9"aggs" : {
10"other_aggs" : {
11"terms" : {
12"field" : "players",
13"size" : 5
14}
15}
16}
17}
18}
19}
推荐阅读:http://t.cn/RHndSgY
ES启动的默认群集名称称为elasticsearch。 如果群集中有许多节点,最好保持命名标志尽可能一致
,例如:
1cluster.name:app_es_production
2node.name:app_es_node_001
节点的恢复设置
也很重要。 假设群集中的某些节点由于故障而重新启动,并且某些节点在其他节点之后重启。 为了使所有这些节点之间的数据保持一致,我们必须运行一致性程序,以使所有集群保持一致状态。
举例1:只要10个数据或主节点已加入群集,即可恢复。
1gateway.recover_after_nodes:10
举例2:集群中期待启动节点达到20个以及时间超过7分钟后,集群重启或恢复。
1gateway.expected_nodes:20
2gateway.recover_after_time:7m
使用正确的配置,可能需要数小时的恢复缩减到只需要分钟级,极大提高工作效率。
minimum_master_nodes
对于群集稳定性非常重要。 它们有助于防止脑裂。
此设置的建议值为(N / 2)+ 1 , 其中N是候选主节点的节点数。
有了这个,如果你有10个可以保存数据并成为主数据的 候选主节点,那么该值将是6。
如果您有三个专用主节点和1,000个数据节点,则该值为两个(仅计算候选主节点):
discovery.zen.minimum_master_nodes:2
1“我需要多少存储空间、多大的内存?”是用户经常问自己的问题。
遗憾的是,没有固定的公式,但可以采取某些步骤来协助规划资源。
推荐方法:模拟实际用例。
步骤1:创建ES集群。
步骤2:使用与生产设置所需的数据速率几乎相同的数据。
步骤3:启动节点,用真实文档填充它们,然后推送填充数据到索引分片。
在模拟实际用例过程中了解资源利用率非常重要,因为它允许您为节点保留适当的RAM量,配置JVM堆空间并优化整个测试过程。
根据模拟结果,决定实际集群的内存、CPU、磁盘容量。
ES节点具有许多线程池,以便改进节点内线程的管理方式。 但是每个线程可以处理多少数据存在限制。 要跟踪此值,我们可以使用ES属性:
1threadpool.bulk.queue_size:2000
这会向ES通知分片中的请求数,当没有可用于处理请求的线程时,新请求可以在节点中排队等待执行。 如果任务数高于此值,您将获得RemoteTransportException。 该值越高,节点机器上所需的堆空间量就越大,并且JVM堆也将被消耗。
此外,你应该在代码的开发阶段做好异常处理。
注意:ES官网不建议修改此值。
Elasticsearch的使用过程中总会遇到这样、那样的问题,多总结、多思考,形成针对业务场景的有效的解决方案。
同时,也要多吸取国内外社区、论坛、博客中的精华,取长补短。
注意:网络文献一般没有涉及版本,老版本ES一些配置不一定适用于6.X最新版本,但,底层的技术永远不过时。
参考:
[1] http://t.cn/RRv9dw9
[2]http://t.cn/E2iBb3X
联系客服