Elasticsearch：以 “Painless” 方式保护你的映射
2023年3月5日 | by mebius
Elasticsearch 是一个很棒的工具，可以从各种来源收集日志和指标。 它为我们提供了许多默认处理，以便提供最佳用户体验。 但是，在某些情况下，默认处理可能不是最佳的（尤其是在生产环境中）； 因此，今天我们将深入探讨避免 “映射污染” 的方法。
什么是“映射”，为什么会有污染？
与任何数据存储解决方案一样，必须有一个模式（schema）等效设置来说明如何处理数据字段（例如存储和处理/分析）； 此设置在 Elasticsearch 下称为 “映射（mapping）”。
与大多数不同，如果未指定，Elasticsearch 会为模式设置提供默认处理。 举个例子，当我们创建一个文档并引入一个全新的数据索引时，Elasticsearch 会尝试为我们猜测正确的字段映射。 是的~这是一个猜测！ 因此，在大多数情况下，我们会毫无问题地摄取该文档，并自动完成。 干杯~但是等等……
- 猜测的映射可能未优化（例如，任何整数字段都将映射到占用 64 位内存的数据类型 “long”，但是如果你的整数字段范围仅从 0~5 ……可能是 “byte” 或 “short” 就足够了，只需要 8 到 16 位内存）
- 有些字段对tgcode我们来说毫无意义，因此我们应该在摄取之前排除它们以免引入映射污染
如何避免映射污染—— Painless 脚本处理器方法
我们可以使用脚本处理器创建一个摄取管道，以在最终摄取发生之前删除目标字段。
用例：删除名称长度超过 15 个字符的字段。
也许我们的数据与随机生成的 UUID（超过 15 个字符长）下的一些元数据一起出现，并且不知何故我们永远不需要这些元数据。 因此，为避免映射污染，我们需要在一开始就排除此类字段。 以下是检查文档中可能字段长度的示例：
# pipeline to script and loop around all fields in a
# context
POST _ingest/pipeline/_simulate
{
"pipeline": {
"processors": [
{
"script": {
"source": """
boolean flag = false;
java.util.Set keys = ctx.keySet();
for (String key : keys) {
if (key.length()>15) {
flag = true;
}
}
ctx["has_long_fields"] = flag;
"""
}
}
]
},
"docs": [
{
"_source": {
"very_very_long_field": "balabalabalabalabala"
}
},
{
"_source": {
"age": 12
}
}
]
}上面的命令的响应为：
{
"docs": [
{
"doc": {
"_index": "_index",
"_id": "_id",
"_version": "-3",
"_source": {
"very_very_long_field": "balabalabalabalabala",
"has_long_fields": true
},
"_ingest": {
"timestamp": "2023-03-01T06:40:53.22560943Z"
}
}
},
{
"doc": {
"_index": "_index",
"_id": "_id",
"_version": "-3",
"_source": {
"has_long_fields": false,
"age": 12
},
"_ingest": {
"timestamp": "2023-03-01T06:40:53.225907596Z"
}
}
}
]
}我们可以清楚地看到 2 个测试文档的结果：第一个包含一个字段 very_very_long_field，结果为 true，而第二个只包含一个 age 字段，结果为 false。
这里的技巧是 ctx.keySet() 方法。 此方法返回一个 Set 接口，其中包含文档下可用的所有 “field-names”。 获得 Set 后，我们可以开始迭代它并应用我们的匹配逻辑。
一个棘手的事情是……这个集合还包含元数据字段，如 _index 和 _id，因此当我们应用一些字段匹配逻辑时，也要注意这些字段。
下一个示例将说明如何从我们的文档上下文中删除相应的字段：
# remove long fields...
POST _ingest/pipeline/_simulate
{
"pipeline": {
"processors": [
{
"script": {
"source": """
boolean flag = false;
java.util.Set keys = ctx.keySet();
java.util.List fields = new java.util.ArrayList();
for (String key : keys) {
if (!key.startsWith("_") && key.length() > 10) {
fields.add(key);
}
}
tgcode // look through and delete those long field(s)
if (fields.size() > 0) {
for (String field: fields) {
ctx.remove(field);
}
flag = true;
}
ctx["has_removed_long_fields"] = flag;
"""
}
}
]
},
"docs":[
{
"_source": {
"very_very_long_field": "balabalabalabalabala",
"another_long_field": "wakkakakakaka",
"age": 13,
"name": "Felis"
}
},
{
"_source": {
"desc": "dkjfdkjfkdjfkdfjk",
"address": "wakkakakakaka",
"age": 13,
"name": "Felis"
}
}
]
}上面命令的返回值为：
{
"docs": [
{
"doc": {
"_index": "_index",
"_id": "_id",
"_version": "-3",
"_source": {
"name": "Felis",
"age": 13,
"has_removed_long_fields": true
},
"_ingest": {
"timestamp": "2023-03-01T06:45:46.164088718Z"
}
}
},
{
"doc": {
"_index": "_index",
"_id": "_id",
"_version": "-3",
"_source": {
"name": "Felis",
"address": "wakkakakakaka",
"age": 13,
"desc": "dkjfdkjfkdjfkdfjk",
"has_removed_long_fields": false
},
"_ingest": {
"timestamp": "2023-03-01T06:45:46.164113593Z"
}
}
}
]
}魔法是 ctx.remove(“fieldname”)。 很简单不是吗？ 另请注意，我们对字段匹配逻辑 !key.startsWith(“_”) && key.length()>10应用了更精确的规则，因此不会考虑所有元字段（例如 _index）。
还引入了一个 ArrayList 来存储目标字段名称。 你可能会问为什么我们不在循环期间直接从文档上下文中删除该字段？ 原因是如果我们尝试这样做，则会爆发一个异常，描述对文档上下文的并发修改。 因此，我们需要延迟删除过程，并且此 ArrayList 会跟踪这些字段名称。
最后，还有另一种情况，我们的文档可能涉及多个级别/层次结构。 以下示例说明如何确定字段是 “leaf” 字段还是 “branch” 字段：
# remove the inner field
POST _ingest/pipeline/_simulate
{
"pipeline": {
"processors": [
{
"script": {
"source": """
java.util.Set keys = ctx.keySet();
java.util.ArrayList fields = new java.util.ArrayList();
for (String key : keys) {
// access the value; check the type
if (key.startsWith("_")) {
continue;
}
Object value = ctx[key];
if (value != null) {
// it is a MAP (equivalent to the "object" structure of a json field)
if (value instanceof java.util.Map) {
// inner fields loop
java.util.Map innerObj = (java.util.Map) value;
for (String innerKey: innerObj.keySet()) {
if (innerKey.length() > 10) {
//Debug.etgcodexplain("a long field >> "+innerKey);
fields.add(key+"."+innerKey);
}
}
} else {
if (key.length() > 10) {
fields.add(key);
}
}
}
}
if (fields.size()>0) {
for (String field:fields) {
// is it an inner field?
int idx = field.indexOf(".");
if (idx != -1) {
ctx[field.substring(0, idx)].remove(field.substring(idx+1));
} else {
ctx.remove(field);
}
}
}
"""
}
}
]
},
"docs": [
{
"_source": {
"age": 13,
"very_very_very_long_field": "to be removed",
"outer": {
"name": "Felix",
"very_very_long_field": "dkjfdkjfkdjfkdfjk"
}
}
}
]
}上面的响应为：
{
"docs": [
{
"doc": {
"_index": "_index",
"_id": "_id",
"_version": "-3",
"_source": {
"outer": {
"name": "Felix"
},
"age": 13
},
"_ingest": {
"timestamp": "2023-03-01T06:54:51.610568095Z"
}
}
}
]
}一个很长的代码……为了检查该字段是 “leaf” —— 普通字段还是 “branch” —— 另一层字段（例如对象）； 我们需要检查字段值的类型 java.util.Map 的值实例。
instanceof 方法有助于验证提供的值是否与特定的 Java 类类型匹配。
接下来，我们需要再次迭代 Set of inner-object fields 以应用我们的匹配规则。 使用 ArrayList 的相同技术将应用于跟踪目标字段名称，以便在稍后阶段删除。
最后，通过 ctx.remove(“fieldname”)删除字段。 但是这次，我们还需要检查这个字段是 leaf 还是 branch 字段。 对于 branch 字段，它将以 outer-object-name.inner-field-name 的格式出现。 我们需要先提取 outer-object-name 并在删除 inner-field-name 之前访问其上下文 -> ctx[field.substring(0, idx)].remove(field.substring (idx+1))
举个例子：outer.very_very_long_field
- idx(“.”分隔符所在的 index) = 5
- field.substring(0, idx) = “outer”
- field.substring(idx+1) = “very_very_long_field”
- 因此…… ctx[field.substring(0, idx)].remove(field.substring(idx+1)) = ctx[“outer”].remove(“very_very_long_field”)
干得好 ~ 这是避免贴图污染的 “Painless” 脚本方法。
如何避免映射污染—— 索引的动态设置方法
有时，我们可能不介意引入一个映射污染； 然而~我们不希望那些无意义的字段是可搜索或可聚合的。 只是我们让那些无意义的字段充当虚拟对象，你可以看到它们（在 _source 字段下可用）但永远无法对它们应用任何操作。 如果是这样的话……我们可以更改索引的动态设置。
PUT test_dynamic
{
"mappings": {
"dynamic": "false",
"properties": {
"name": {
"type": "text"
},
"address": {
"dynamic": "true",
"properties": {
"street": {
"type": "keyword"
}
}
},
"work": {
"dynamic": "strict",
"properties": {
"department": {
"type": "keyword"
},
"post": {
"type": "keyword"
}
}
}
}
}
}我们通过如下的方法来摄入一些数据：
# all good, everything matches the mapping
POST test_dynamic/_doc
{
"name": "peter parker",
"address": {
"street": "20 Ingram Street",
"state": "NYC"
},
"work": {
"department": "daily bugle"
}
}
# added a non-searchable "age" and a searchable field "address.post_code"
POST test_dynamic/_doc
{
"age": 45,
"name": "Edward Elijah",
"address": {
"post_code": "344013"
}
}很显然，在上面，age 不在之前的映射中定义。由于我们在映射中设置dynamic 为 false，age 这个字段将不能被用于搜索：
| dynamic | doc indexed? | fields searchable | fields indexed? | mapping updated? |
|---|---|---|---|---|
| true | Yes | Yes | Yes | Yes |
| runtime | Yes | Yes | No | No |
| false | Yes | No | No | No |
| strict | No |
GET test_dynamic/_search
{
"query": {
"match": {
"age": 45
}
}
}上面搜索的结果为空。有关动态映射的文章，请详细阅读文章 “Elasticsearch：Dynamic mapping”。
我们接着进行如下的搜索：
GET test_dynamic/_search
{
"query": {
"match": {
"address.post_code": "344013"
}
}
}上面的搜索显示的是一个文档：
"hits": [
{
"_index": "test_dynamic",
"_id": "Z2X8m4YBRPmzDW_iGJOb",
"_score": 0.2876821,
"_source": {
"age": 45,
"name": "Edward Elijah",
"address": {
"post_code": "344013"
}
}
}
]我们执行如下的命令：
# exception as work.salary is forbidden
POST test_dynamic/_doc
{
"age": 45,
"name": "Prince Tomas",
"address": {
"post_code": "344013"
},
"work": {
"salary": 10000000
}
}上面命令返回的结果为：
{
"error": {
"root_cause": [
{
"type": "strict_dynamic_mapping_exception",
"reason": "mapping set to strict, dynamic introduction of [salary] within [work] is not allowed"
}
],
"type": "strict_dynamic_mapping_exception",
"reason": "mapping set to strict, dynamic introduction of [salary] within [work] is not allowed"
},
"status": 400
}这是因为 work 字段的属性为 strict。我们不可以为这个字段添加任何新的属性。
如何避免映射污染 —— 通过预处理方法删除字段
这里讨论的最后一种方法是在传递给 Elasticsearch 之前删除无意义的字段……以及如何？ 嗯……自己写程序，对文档进行预处理~:)))))
这确实是一种有效的方法，但可能并不适合所有人； 因为需要一些编程知识。 有时，如果我们在传递给 Elasticsearch 之前对文档进行预处理，它可能会更加灵活，因为我们可以完全控制文档的修改（由于编程语言的功能）。
文章来源于互联网:Elasticsearch：以 “Painless” 方式保护你的映射