国外网站流量查询,门户网站建设工具,可以做司法考试题的网站,营销型网站设计特点作者#xff1a;来自 Elastic Stef Nestor Elasticsearch 7.10 使配置数据生命周期变得不再那么复杂。在这篇博文中#xff0c;我将介绍一些变化、如何使用它们以及一些最佳实践。
数据生命周期可以包含很多阶段#xff0c;因此我们将涉及#xff1a;
将集群划分为层来自 Elastic Stef Nestor Elasticsearch 7.10 使配置数据生命周期变得不再那么复杂。在这篇博文中我将介绍一些变化、如何使用它们以及一些最佳实践。
数据生命周期可以包含很多阶段因此我们将涉及
将集群划分为层hot、warm、cold确保新数据到达正确的位置。在索引生命周期管理 (index lifecycle management - ILM) 中使用这些层在层之间迁移数据。使用 Elastic 可搜索快照Elastic searchable snapshots增加冷层内的数据密度。将所有内容与数据如何流经层的真实示例结合起来。 放弃属性加入节点角色
处理时间序列数据时一个常见用例是将集群拓扑分成不同的层。这些层被命名为 hot 层新数据被提取和查询、warm 层中期数据被保存和查询和 cold 层数据通常被保存很长时间查询频率较低。
用户通常会使用不同的硬件配置这些层以便将最强大、最昂贵的硬件用于 hot 层而将较便宜、存储密度更高的硬件用于 warm 层或 cold 层。
在 7.10 之前配置不同节点层的最常见方法之一是使用节点属性因此用户可以配置以下内容
# On hot nodes
node.attr.node_type: hot# On warm nodes
node.attr.node_type: warm # On cold nodes:
node.attr.node_type: cold
然后可以将这些与集群和索引级别分配参数一起使用。例如可以使用以下命令创建索引
PUT /myindex
{ settings: { index.routing.allocation.include.node_type: hot }
}
这创建了一个分配给热节点的索引。
让我们来看看新的做事方式。 正式化流程
在 7.10 中这种类型的配置已经正式化我们现在拥有与 hot 、warm 和 cold 层以及另一个层我们将介绍相对应的特定角色。这意味着我们无需添加 node.attr.node_type 属性而是可以将 data_hot、data_warm 或 data_cold 节点角色之一添加到 node.roles 设置中
# On hot nodes
node.roles: [data_hot] # On warm nodes
node.roles: [data_warm] # On cold nodes
node.roles: [data_cold]
记得将你可能需要的任何其他角色添加到列表中例如对于较小的集群数据节点可能如下所示
node.roles: [master, ingest, ml, data_hot, data_content]
本文后面将进一步解释 data_content 角色。 注意你可能想知道现有数据角色发生了什么。好吧数据角色的作用就像已指定所有层一样因此它同时成为 hot 层、warm 层和 cold 层的一部分。这意味着已升级到 7.10 或更高版本但未使用 node.roles 设置指定自定义节点角色的节点是每个数据层的一部分。 在层级间移动数据
设置这些角色后可以使用与之前相同的集群和索引级分配过滤器在集群间移动数据
cluster.routing.allocation.require._tiercluster.routing.allocation.include._tiercluster.routing.allocation.exclude._tierindex.routing.allocation.require._tierindex.routing.allocation.include._tierindex.routing.allocation.exclude._tier
还有一个新参数其行为与常规的包含include、排除exclude和需要require过滤略有不同。这是 _tier_preference 索引级设置index.routing.allocation.include._tier_preference。
要了解其工作原理让我们看一个例子
PUT /myindex
{ settings: { index.routing.allocation.include._tier_preference: data_cold,data_warm,data_hot }
}
此代码段创建一个索引该索引优先位于 cold 层然后是 warm 层最后是 hot 层。
如果集群不包含冷节点则必须将其分配给 warm 节点。 如果集群中没有 warm 节点则必须将其分配给 hot 节点。 此配置允许策略或模板设置首选项而不必担心每个层都是集群的一部分 - 它可以指定其首选层。
要确切了解此新设置的行为方式请查看此流程图 节点属性node attributes和正式化数据层角色formalized data tier roles之间还有最后一个区别 —— 索引在最初创建时分配的位置。这里有一个简单的规则它决定了索引最初放在何处 任何作为数据流一部分的索引在创建时都会自动添加 “index.routing.allocation.include._tier_preference: data_hot” 设置。 这意味着所有数据流支持索引将默认分配在热 (data_hot) 节点上。
对于不属于数据流的索引 任何不属于数据流的索引在创建时都会自动添加 “index.routing.allocation.include._tier_preference: data_content” 设置。 这两个设置都可以被覆盖。只需将 _tier_preference 索引设置为 null或在创建期间设置任何其他索引级分配过滤设置即可。
但请稍等这个新的 data_content 角色是什么让我们考虑另一种不适合生命周期模型的数据不适合时间序列模型的数据。 不符合时间序列的数据
某些数据被编入索引然后仅被查询但在概念上没有年龄或时间戳。这包括企业搜索数据、电子商务数据或用户信息数据库。
对于此类数据有一个特定角色data_content 角色。此角色的配置与其他角色一样使用 node.roles 设置。
值得一提的是这些角色都不是互斥的因此如果你希望非时间序列数据和 hot 数据位于同一节点上你可以像这样配置节点
# This node can hold either hot tier data, or content tier data
node.roles: [data_hot, data_content]
而且你可能已经猜到了现有的默认数据角色也是 content 层的一部分。这意味着数据角色与将 data_hot、data_warm、data_cold 和 data_content 角色添加到 node.roles 设置相同。
如上一节所述Elasticsearch 确定时间序列数据和非时间序列数据的方式是该索引是否属于数据流。
最佳实践确保你的集群始终至少有一个 data_hot 节点和一个 data_content 节点即使它们是同一个节点。如果没有这两个节点角色则无法分配不同类型的索引。
现在我们了解了所有不同的层级并配置了一些让我们看看 ILM 如何利用这些层级。 数据层世界中的 ILM
与旧的基于属性的分配相比单独配置层并没有太大变化。但是现在我们有了内置且一致的方式来识别 Elasticsearch 中的层ILM 可以利用这些设置在层之间自动迁移数据。
在 7.10 之前可以使用以下策略完成分层配置
{ phases : { hot : { actions : { rollover : { max_age : 30d, max_size : 50gb } } }, warm : { min_age : 45d, actions : { allocate : { include : { node_type : warm } }, forcemerge : { max_num_segments : 1 } } }, cold : { min_age : 60d, actions : { allocate : { include : { node_type : cold } } } }, delete : { min_age : 90d, actions : { delete : { } } } }
}
此策略依赖于索引模板将数据分配到热层然后在每个 ILM 阶段内使用“分配”操作更新 node_type 以移动数据。 但在 7.10 中有更好的方法
由于 Elasticsearch 现在能够优先选择特定层因此 ILM 可以通过在进入新阶段时自动设置 index.routing.allocation.include._tier_preference 来利用此偏好。以下是使用与上述相同策略的示例但删除了分配步骤
{ phases : { hot : { actions : { rollover : { max_age : 30d, max_size : 50gb } } }, warm : { min_age : 45d, actions : { forcemerge : { max_num_segments : 1 } } }, cold : { min_age : 60d, actions : { } }, delete : { min_age : 90d, actions : { delete : { } } } }
}
当使用此策略创建新数据流时最初首选项将设置为 index.routing.allocation.include._tier_preference: data_hot。
当索引进入 warm 阶段时设置将更新为 index.routing.allocation.include._tier_preference: data_warm,data_hot。
进入 cold 阶段后它将更新为 index.routing.allocation.include._tier_preference: data_cold,data_warm,data_hot然后索引最终将在删除阶段被删除。
此自动迁移不适用于 hot 阶段因为它在索引创建时自动管理。
当集群拓扑也包含该层的节点时此自动迁移允许数据位置自动匹配当前 ILM 阶段。
此行为会自动应用但有两个注意事项
如果 migrate: {enabled: false} action 添加到阶段的操作列表中则自动迁移不会生效。如果 ILM 阶段操作包含设置 include、require 或 exclude 过滤器的分配步骤则自动迁移不会生效。
这两个阶段都不会自动迁移数据
warm: { actions: { migrate: { enabled: false } }
}
或者
warm: { actions: { allocate: { include: { node_type: warm } } }
}
最佳实践在集群拓扑中采用了新角色后请确保从使用节点属性依赖默认数据层迁移的 ILM 策略中删除任何先前的分配操作。 使用可搜索快照将数据保存更长时间
创建和维护数据的生命周期可让你控制新数据与旧数据的硬件属性和性能特征。
但你的集群实际上可以容纳多少数据
这个问题的答案几乎总是决定数据的保留期限因为磁盘空间有限必须从集群中删除最旧的数据以腾出空间容纳新数据。这需要在保留洞察和监管原因所需的数据量之间取得微妙的平衡而不会耗尽集群磁盘资源或为集群磁盘资源支付过多费用。
但如果我们可以将数据保存更长时间而对集群资源的影响却很小那会怎样
这正是可搜索快照可以提供帮助的地方。7.10 版引入的可搜索快照允许 Elasticsearch 在集群本地保留一份数据副本而另一份副本充当副本则驻留在快照存储库中。这意味着不需要副本因为任何本地副本的丢失都可以从存储库快照中自动本地恢复。
我们也可以在 ILM 中使用此功能当索引达到冷阶段时自动将其转换为可搜索的快照使可存储的数据密度加倍因为不需要副本来实现冗余。 使用此功能非常简单只需使用 searchable_snapshot 操作配置冷阶段即可
cold: { min_age: 90d, actions: { searchable_snapshot: { snapshot_repository : backing_repo } }
}
在内部当达到此操作时Elasticsearch 将
强制将索引合并到单个段在 backing_repo 存储库中创建索引的新快照以新名称将索引挂载为可搜索快照支持的索引将原始索引交换为可搜索快照支持的索引
瞧我们现在不再需要本地副本因为我们有一个快照可以在数据的主要副本丢失时使用。 注意如果你是 Elastic Cloud 用户你甚至可以在可搜索快照操作配置中使用已配置的 “found-snapshots” 存储库或配置你自己的单独存储库。 整合所有部分
数据生命周期的数据层配置包含许多不同的移动部分以构成一个有效的生命周期。让我们将这些部分整合成一个有效的示例。
首先我们需要一些节点。在此示例中我们将使用四个节点分别表示为 a、b、c 和 d
NodeA
node.name: node-a-hot
node.roles: [master, data_hot, data_content, ingest]
NodeB:
node.name: node-b-hot
node.roles: [master, data_hot, data_content, ingest]
NodeC:
node.name: node-c-cold
node.roles: [master, data_cold, ingest]
NodeD:
node.name: node-d-cold
node.roles: [master, data_cold, ingest]
集群启动后我们来配置一个快照存储库
PUT /_snapshot/my-repository
{ type: fs, settings: { location: my-backup-location }
}
并添加我们的 ILM 策略利用一些常见的操作和新的 searchable_snapshot 操作
PUT /_ilm/policy/my-data-lifecycle
{policy : { phases : { hot : { actions : { rollover : { max_size : 50gb, max_age : 3d } } }, warm : { min_age : 5d, actions : { shrink : { number_of_shards : 1 } } }, cold : { min_age : 7d, actions : { searchable_snapshot : { snapshot_repository : my-repository } } }, delete : { min_age : 365d, actions : { delete : { } } } } }
}
还有一个先决条件索引模板index template以便索引可以是数据流并自动使用我们之前创建的 ILM 策略。确保每个节点至少有两个以容纳副本或者将 index.number_of_replicas 设置为 0 以进行测试。
PUT /_index_template/my-lifecycle-template
{ index_patterns: [test-index], data_stream :{}, template: { settings: { index.lifecycle.name: my-data-lifecycle, index.number_of_shards: 2 } }
}
现在可以通过将文档直接索引到测试索引数据流来将数据发送到这个新索引
POST /test-index/_doc?op_typecreate
{ message: test document, timestamp: 2020-01-12
}
现在随着更多数据的发送它将自动从集群中的热节点移动到 cold 节点最终进入可搜索的快照并在一年后最终被删除。 开始使用 Elastic Cloud
我们希望从技术角度介绍数据层对你有所帮助。请试用这些功能并在我们的讨论论坛中告诉我们你对它们的喜好
你还可以通过 Elastic Cloud 的 14 天免费试用版试用这些测试版功能。敬请期待 7.11届时我们的数据层功能将全面推出。 原文Elasticsearch data lifecycle management with data tiers | Elastic Blog
