vlambda博客
学习文章列表

模板 在 Elasticsearch 中由它们的名称标识。所以，如果我们想删除名为 logstash 的模板，下面的代码可以做到：

curl -XDELETE localhost:9200/_template/logstash 

在这里，标识 也是按名称，我们可以按名称检索模板。在我们的例子中，它将是：

curl -XGET localhost:9200/_template/logstash 

在 Elasticsearch 中使用多个模板创建索引是一种非常常见的实践。您可能经常会问这样的问题，如果此类模板中存在冲突的设置/映射会发生什么？让我们看看这样一个场景。假设我们有两个定义如下的模板：

在这种情况下，名为 logstash-21-04-2015 和 logstash-server 的索引属于这两个模板。但是，模板 logstash1 和 logstash2 的设置有 number_of_shards 字段中的冲突。因此，弄清楚 Elasticsearch 将哪个模板应用于索引会很有趣。

如果多个模板匹配一个索引名称，所有匹配的模板设置将被合并以获取要创建的索引的设置。如果发生冲突，订单号将用于解决冲突。

如您所见，logstash1 模板已按 0 的顺序定义，而 logstash2 模板已按 1 的顺序定义。 order 字段的值越小，优先级越高。这意味着在发生冲突的情况下，logstash1 模板的优先级高于 logstash2，这意味着冲突的字段值将从具有更高优先级的索引中获取，其余字段将被合并。

现在，有时，要求创建的所有索引都应具有一组特定的映射/设置。

这可以通过创建适用于所有索引的索引模板变得简单。为此，我们可以将 template 字段定义为 *，这将使模板能够将其所有设置/映射应用于索引用任何名字。

此类索引模板的示例如下所示：

curl -XPUT localhost:9200/_template/forall -d '{
  "template": "*",
  "order": 2,
  "settings": {
    "number_of_shards": 3
  },
  "mappings": {
    "logs": {
      "_all": {
        "enabled": false
      }
    }
  }
}'

使用索引模板，我们还可以覆盖索引下类型的默认值。默认情况下，对于 所有索引类型，_all 将被启用。在许多情况下，这可能会浪费资源。在模板中，我们可以定义名称已知的类型的映射，以及将来自动创建的任何索引类型的默认值。

一个例子是：

curl -XPUT 'localhost:9200/data-index' -d '{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 0
  },
  "mappings": {
    "_default_": {
      "_all": {
        "enabled": false
      }
    },
    "type1": {
      "_all": {
        "enabled": true
      }
    }
  }
}'

在这里，我们有一个名为 data-index 的索引。假设索引data-index下有三种类型，分别命名为type1、type2< /code> 和 type3 以及对于 type1，我们需要启用 _all 字段。在前一种情况下，我们默认禁用 _all 字段。为了启用type1中的_all字段，我们单独提及并指定启用< /code> 为 true。

现在使用此设置，除了 type1 之外，_all 将对所有其他类型禁用。

在文档索引中，如果映射中未定义字段，则根据数据“猜测”该字段的类型。这很好用，但在许多情况下，我们可能需要覆盖此行为。最好的例子是自定义格式的时间字段。

当我们需要动态添加新变量时，动态模板用于动态映射。动态模板允许我们定义新生成的字段的映射。可以根据数据类型或字段名称将映射应用于新生成的字段。

这种动态模板的示例代码如下：

curl -XPUT 'localhost:9200/data-index' -d ' {
  "mappings": {
    "my_type": {
      "dynamic_templates": [
        {
          "customdate": {
            "match": "date_*",
            "match_mapping_type": "string",
            "mapping": {
              "type": "date",
              "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd"
            }
          }
        },
        {
          "customstring": {
            "match": "*",
            "match_mapping_type": "string",
            "mapping": {
              "type": "string",
              "analyzer": "my-analyzer"
            }
          }
        }
      ]
    }
  }
}'

在前面的示例代码中，我们为字符串字段定义了两个名为 customdate 和 customstring 的模板。

customdate 的作用是检查所有以 date_* 开头的字段。然后为匹配的字段提供映射类型 date，该映射类型定义了特定格式。这实际上是将 date_* 字段过滤为日期格式。

同样，在 customstring 模板中，match 是为 * 定义的，即是，所有字段，它会将映射应用于所有字段。映射可以为此目的使用任何分析器，甚至是我们创建的自定义分析器。

模板按出现的顺序进行检查。由于 customdate 被放在首位，带有 date_* 的字段首先被映射，然后，customstring 模板被选中。

对于基于时间的数据，最近的指数使用更频繁或更相关。换句话说，在给定时间，数据流将使用基于天、周或月的特定索引。该索引将成为所有新文档的目标，并且大多数 查询也将命中相同的索引。因此，为包含我们大量使用的索引的节点分配最佳资源是一个好主意。

这种方法的问题在于，Elasticsearch 很难识别我们为频繁使用的索引分配了哪个节点。为了让 Elasticsearch 了解哪个节点，我们可以在节点启动或启动时为其指定标签。这可以在 Elasticsearch 的配置文件中定义，如下所示：

./bin/elasticsearch –node.memory 16G

这里，memory 是任意键；我们可以给它任何我们想要的名字。这些键值对充当一组节点的标识符。因此，我们可以根据 best_node 键的不同值对不同的节点进行分组。具有相同内存值的所有节点都属于一组。使用这种方法，我们可以根据硬件手动对机器进行分组。

假设我们有名为 logstash-02-07-2015 和 logstash-02-06-2015 的索引。假设第一个索引是我们当前的索引，我们需要分配具有最佳资源索引的节点。在这里，第二个索引 logstash-02-06-2015 是一个旧索引，我们暂时不会大量使用它。

以下是我们如何让 Elasticsearch 理解相同：

PUT / logstash-02-07-2015
{
  "settings": {
    "index.routing.allocation.include.memory ": "16G"
  }
}

在前面的 代码中，对于索引的创建，我们指定数据流到节点 具有 best_node" : 16G" 标签，这是我们最好的资源。

我们看到了如何将数据移动到最佳节点；现在，正如我们之前提到的，旧数据可能不太有用，我们可以看到旧索引如何移动到资源较少或中等资源的节点。

首先，定义节点的标签（这里，资源较少）：

./bin/elasticsearch –node.memory 8G

然后，在我们的示例中，旧索引是 logstash-02-06-2015。现在更新该索引的设置，如下所示：

POST / logstash-02-06-2015/_settings
{
     "index.routing.allocation.include.memory" : "8G"
} 

现在，索引 logstash-02-06-2015 被移动到匹配 memory" : "8G" 标签的节点. 这样，当前的索引，即写重读和重读被分配给有的机器。

下图显示了分片分配中发生的情况的图形表示：

在时间数据索引中，将完成对先前索引的写入，并且大部分 是只读的。因此，将这些索引的多个段转换为单个段是有意义的。单个段具有资源利用率和性能的优势。优化单个段上的索引是一个好主意，但是，如果它是一个文档仍在流动的索引，那么这是一个坏主意。

现在，我们可以使用以下 HTTP 请求运行强制合并操作：

POST / logstash-02-06-2015/_optimize?max_num_segments=1 

如您所见，我们在前面的代码中使用了优化 API (_optimize)。优化 API 将强制分片将其段与我们分配给 max_num_segments 的数字合并。

在这种情况下，我们将要使用的最大段数定义为 1。一般的做法是将最大段数设置为1，因为这样会使用更少的资源，而且搜索操作也会快很多。

会有非常旧的索引存储基于时间的数据，如果它们被 removed 来自我们的生态系统，以便我们可以利用它们占用的磁盘空间。这些索引可以单独保存在共享磁盘或其他一些第三方长期存储服务中，以备将来访问它们时使用。拥有此类备份的优点是数据永远不会真正丢失，因为我们可以从我们拥有的备份中恢复这些索引。

Elasticsearch 为前面提到的目的提供了快照恢​​复 API。让我们看看如何创建快照。

PUT/_snapshot/index_backup
{
  "type": "fs",
  "settings": {
    "compress": "true",
    "location": "/mount/backups"
  }
}

PUT /_snapshot/backup_s3
{
  "type": "s3",
  "settings": {
    "bucket": "s3_backup",
    "region": "eu-west-1"
  }
}

当我们创建 快照时，默认情况下，它会备份集群中所有启动和运行的索引。在某些情况下，这种行为可能不太好，因为我们需要备份特定索引。这可以通过以下命令完成：

PUT /_snapshot/index_backup/snap01
{
  "indices": "logstash-20-06-2015,logstash-20-05-2015",
  "ignore_unavailable": "true"
}

在这里，快照 snap01 将包含索引 logstash-20-06-2015 和 logstash-20-05-2015。

ignore_unavailable 参数设置为 true 时，将在创建快照时忽略索引/索引的不可用性。

索引的打开或关闭也可以使用curator来完成。这方面的一个例子是：

curator  --host <IP> close   --timestring '%Y-%M-%D' --prefix "logstash-"  --older-than  10 --time-unit days

在这里，我们将关闭所有超过 10 天的索引，这样它们就不会占用太多的硬件资源。