路由文件

當(dāng)應(yīng)用程序需要向 Elasticsearch 添加文檔時(shí)，它們首先要知道目標(biāo)索引是什么。在很多的應(yīng)用案例中，特別是針對(duì)時(shí)序數(shù)據(jù)，我們想把每個(gè)月的數(shù)據(jù)寫入到一個(gè)特定的索引中。一方面便于管理索引，另外一方面在將來搜索的時(shí)候可以按照每個(gè)月的索引來進(jìn)行搜索，這樣速度更快，更便捷。

當(dāng)你處于某種類型的文檔總是轉(zhuǎn)到特定索引的瑣碎情況時(shí)，這似乎很明顯，但當(dāng)你的索引名稱可能根據(jù)雜項(xiàng)參數(shù)（無論它們是否在你的系統(tǒng)外部 - 當(dāng)前例如日期 - 或者你嘗試存儲(chǔ)的文檔的固有屬性 - 大多數(shù)時(shí)候是文檔字段之一的值）。

當(dāng)發(fā)生最后一種情況時(shí)（我們指的是索引名稱可以變化的情況），在向 Elasticsearch 發(fā)出索引命令之前，你的應(yīng)用程序需要計(jì)算目標(biāo)索引的名稱。

此外 —— 即使一開始這看起來像是一種反模式 —— 你可以有多個(gè)應(yīng)用程序需要在索引中索引相同類型的文檔，這些文檔的名稱可能會(huì)發(fā)生變化。 現(xiàn)在你必須維護(hù)跨多個(gè)組件重復(fù)的索引名稱計(jì)算邏輯：就可維護(hù)性和敏捷性而言，這不是好消息。

Logstash —— Elastic Stack 的一個(gè)知名成員 —— 可以幫助集中這樣的邏輯，但代價(jià)是維護(hù)另一個(gè)正在運(yùn)行的軟件，這需要配置、知識(shí)等。

我們想要在本文中展示的是通過將索引名稱計(jì)算委托給 Elasticsearch 而不是我們的應(yīng)用程序來解決此問題的解決方案。

Date index name processor 介紹

該處理器的目的是通過使用日期數(shù)學(xué)索引名稱支持，根據(jù)文檔中的日期或時(shí)間戳字段將文檔指向基于正確時(shí)間的索引。

處理器根據(jù)提供的索引名稱前綴、正在處理的文檔中的日期或時(shí)間戳字段以及提供的日期舍入，使用日期數(shù)學(xué)索引名稱表達(dá)式設(shè)置 _index 元數(shù)據(jù)字段。

首先，此處理器從正在處理的文檔中的字段中獲取日期或時(shí)間戳。 或者，可以根據(jù)字段值應(yīng)如何解析為日期來配置日期格式。 然后這個(gè)日期、提供的索引名稱前綴和提供的日期舍入被格式化為日期數(shù)學(xué)索引名稱表達(dá)式。 此處還可以選擇日期格式指定日期應(yīng)如何格式化為日期數(shù)學(xué)索引名稱表達(dá)式。

將文檔指向每月索引的示例管道，該索引以基于 date1 字段中的日期的 my-index-prefix 開頭：

PUT _ingest/pipeline/monthlyindex
{
  "description": "monthly date-time index naming",
  "processors" : [
    {
      "date_index_name" : {
        "field" : "date1",
        "index_name_prefix" : "my-index-",
        "date_rounding" : "M"
      }
    }
  ]
}

使用該管道進(jìn)行索引請(qǐng)求：

PUT /my-index/_doc/1?pipeline=monthlyindex
{
  "date1" : "2016-04-25T12:02:01.789Z"
}

上面命令運(yùn)行的結(jié)果是：

{
  "_index": "my-index-2016-04-01",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

上面的請(qǐng)求不會(huì)將這個(gè)文檔索引到 my-index 索引中，而是索引到 my-index-2016-04-01 索引中，因?yàn)樗前丛氯≌摹?這是因?yàn)?date-index-name-processor 覆蓋了文檔的 _index 屬性。

要查看導(dǎo)致上述文檔被索引到 my-index-2016-04-01 中的實(shí)際索引請(qǐng)求中提供的索引的日期數(shù)學(xué)（date-math）值，我們可以使用模擬請(qǐng)求檢查處理器的效果。

POST _ingest/pipeline/_simulate
{
  "pipeline" :
  {
    "description": "monthly date-time index naming",
    "processors" : [
      {
        "date_index_name" : {
          "field" : "date1",
          "index_name_prefix" : "my-index-",
          "date_rounding" : "M"
        }
      }
    ]
  },
  "docs": [
    {
      "_source": {
        "date1": "2016-04-25T12:02:01.789Z"
      }
    }
  ]
}

上面命令返回結(jié)果：

{
  "docs": [
    {
      "doc": {
        "_index": "<my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>",
        "_id": "_id",
        "_version": "-3",
        "_source": {
          "date1": "2016-04-25T12:02:01.789Z"
        },
        "_ingest": {
          "timestamp": "2023-02-23T01:15:52.214364Z"
        }
      }
    }
  ]
}

以上示例顯示 _index 設(shè)置為 <my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>。 Elasticsearch 將其理解為 2016-04-01，如日期數(shù)學(xué)索引名稱文檔中所述。

日期索引名稱選項(xiàng)

以下是使用 date index name 的一些選項(xiàng)

使用案例 - 基于時(shí)間的時(shí)序索引

這是一個(gè)眾所周知的用例，通常在您要處理日志時(shí)發(fā)現(xiàn)。這個(gè)想法是索引文檔，索引的名稱由根名稱和根據(jù)日志事件的日期計(jì)算的值組成。 該日期實(shí)際上是你要索引的文檔的一個(gè)字段。

這不是本文的重點(diǎn)，但以這種方式索引文檔有幾個(gè)優(yōu)點(diǎn)，包括更容易的數(shù)據(jù)管理、啟用冷/暖架構(gòu)等。讓我們舉個(gè)例子。

假設(shè)我們必須處理來自多個(gè)來源的數(shù)據(jù) —— 例如物聯(lián)網(wǎng)。 我們的每個(gè)對(duì)象每分鐘都會(huì)向不同的后端發(fā)送一些數(shù)據(jù)（是的，這真的很可悲，但我們的對(duì)象不通過相同的網(wǎng)絡(luò)進(jìn)行通信，因此選擇通過多個(gè)系統(tǒng)來處理這個(gè)問題）。

對(duì)象發(fā)送的數(shù)據(jù)被轉(zhuǎn)換成如下所示的 JSON?文檔：

POST data/_doc?pipeline=compute-index-name
{
  "objectId": 1234,
  "manufacturer": "SHIELD",
  "payload": "some_data",
  "date": "2019-04-01T12:10:30.000Z"
}

我們有一個(gè)用于傳輸數(shù)據(jù)的對(duì)象的 UID、一個(gè)制造商 ID、一個(gè)有效負(fù)載部分和一個(gè)日期字段。

索引名稱計(jì)算

假設(shè)我們要將對(duì)象的數(shù)據(jù)存儲(chǔ)在名為 data-{YYYYMMDD} 的索引中，其中根名稱是數(shù)據(jù)后跟日期模式?；谏厦娴睦?，后端收到這個(gè)文檔應(yīng)該怎么辦呢？

首先它必須解析它以提取日期字段的值，然后它必須根據(jù)它在文檔中找到的日期計(jì)算目標(biāo)索引名稱。 最后，它向 Elasticsearch 向剛剛計(jì)算出名稱的索引發(fā)出索引請(qǐng)求。

document.date = "2019-04-01T12:10:30Z"
index.name = "data-" + "20190401"

在我們的例子中，我們有幾個(gè)后端必須知道如何計(jì)算索引名稱，因此必須知道索引的命名邏輯。

如果索引名的計(jì)算直接由 Elasticsearch 進(jìn)行，豈不是更聰明？

Ingest pipeline 的力量

從 Elasticsearch 的第 5 版開始，我們現(xiàn)在有了一種稱為攝取的節(jié)點(diǎn)。默認(rèn)情況下，集群的所有節(jié)點(diǎn)都具有 ingest 類型。這些節(jié)點(diǎn)有權(quán)在索引文檔之前執(zhí)行所謂的管道。 管道是一組處理器，每個(gè)處理器都可以以某種特定方式轉(zhuǎn)換輸入文檔。當(dāng)一個(gè)文檔被攝入到 Elasticsearch 集群時(shí)，它的工作流是這樣的。

從上面，我們可以看出來，在文檔被寫入之前，它必須經(jīng)過 ingest node 進(jìn)行處理。我們可以通過 date index name processor 來獲得我們想要的 index 名稱，進(jìn)而寫入到我們想要的索引中去。?這里有用的是，管道不僅可以轉(zhuǎn)換文檔的固有數(shù)據(jù)，還可以修改文檔元數(shù)據(jù)，特別是它的 _index 屬性。

現(xiàn)在讓我們回到我們的例子。我們建議定義一個(gè)管道來完成這項(xiàng)工作，而不是將索引名稱計(jì)算委托給應(yīng)用程序。根據(jù)文檔，此處理器允許你定義包含日期的字段名稱、索引的根名稱（前綴）以及計(jì)算附加到此前綴的日期的舍入方法。

如果我們想將 IoT 數(shù)據(jù)添加到模式為 data-{YYYYMMDD} 的索引中，我們只需創(chuàng)建如下所示的管道：

PUT _ingest/pipeline/compute-index-name
{
  "description": "Set the document destination index by appending a prefix and its 'date' field",
  "processors": [
    {
      "date_index_name": {
        "field": "date",
        "index_name_prefix": "data-",
        "date_rounding": "d",
        "index_name_format": "yyyyMMdd"
      }
    }
  ]
}

一個(gè)索引 = 一個(gè)管道？

好的，現(xiàn)在我們知道如何定義一個(gè)管道來為特定的目標(biāo)索引建立一個(gè)名稱。 但是我們可以通過操縱文檔元數(shù)據(jù)來做更多的事情！

假設(shè)我們有不同類型的文檔，每個(gè)文檔都有一個(gè)日期字段，但需要在不同的索引中進(jìn)行索引。計(jì)算目標(biāo)索引名稱的邏輯對(duì)于每種文檔類型都是相同的，但使用上述策略將導(dǎo)致創(chuàng)建多個(gè)管道。

讓我們?cè)囍鲆恍└?jiǎn)單和可重用的東西。

回到我們的示例，我們現(xiàn)在有兩種文檔類型：一種需要在 adata-{YYYYMMDD} 索引（和以前一樣）中建立索引，另一種其目的地是名為 new_data-{YYYYMMDD} 的索引。

目標(biāo)為 new_data 的文檔具有以下結(jié)構(gòu)：

{
  "newObjectId": 1234,
  "source": "HYDRA",
  "payload": "some_data",
  "date": "2019-04-02T13:10:30.000Z"
}

該結(jié)構(gòu)與標(biāo)準(zhǔn) IoT 文檔略有不同，但重要的是日期字段存在于兩個(gè)映射中。

現(xiàn)在我們要定義一個(gè)管道來計(jì)算我們兩種文檔類型的目標(biāo)索引。 我們所要做的就是通過分析通過索引 API 發(fā)出的請(qǐng)求目的地來構(gòu)建目的地索引名稱。

PUT _ingest/pipeline/compute-index-name
{
  "description": "Set the document destination index by appending the requested index and its 'date' field",
  "processors": [
    {
      "date_index_name": {
        "field": "date",
        "index_name_prefix": "{{ _index }}-",
        "date_rounding": "d",
        "index_name_format": "yyyyMMdd"
      }
    }
  ]
}

請(qǐng)注意，索引名稱前綴現(xiàn)在位于名為_index 的索引元數(shù)據(jù)字段中。 通過使用這個(gè)字段，我們的管道現(xiàn)在是通用的并且可以與任何索引一起使用 —— 假設(shè)目標(biāo)索引是根據(jù)相同的規(guī)則計(jì)算的。

使用我們的 “路由” 管道

現(xiàn)在我們有了一個(gè)能夠根據(jù)文檔的日期字段計(jì)算目標(biāo)索引名稱的通用管道，讓我們看看如何讓 Elasticsearch 使用它。

我們可以通過兩種方式告訴 Elasticsearch 使用管道，讓我們?cè)u(píng)估一下。

Index API 調(diào)用

第一個(gè) —— 也是直接的解決方案——是使用 Index API 的管道參數(shù)。

換句話說：每次你想索引一個(gè)文檔，你必須告訴 Elasticsearch 要使用的管道。

POST data/_doc?pipeline=compute-index-name
{
  "objectId": 1234,
  "manufacturer": "SHIELD",
  "payload": "some_data",
  "date": "2019-04-01T12:10:30.000Z"
}

現(xiàn)在，每次我們通過指示 compute-index-name 管道將文檔添加到索引中時(shí)，該文檔將被添加到正確的基于時(shí)間的索引中。 在此示例中，目標(biāo)索引將為 data-20190401 。

我們提供給 Index API 的 data 索引名稱呢？ 它可以被看作是一個(gè)假索引：它只是用來執(zhí)行 API 調(diào)用并且是真正目標(biāo)索引的根，它不一定存在！

默認(rèn)管道：引入 “虛擬索引”

索引默認(rèn)管道（default pipeline）是使用管道的另一種有用方式：當(dāng)你創(chuàng)建索引時(shí)，有一個(gè)名為 index.default_pipeline 的設(shè)置可以設(shè)置為管道的名稱，只要你將文檔添加到相應(yīng)的索引就會(huì)執(zhí)行該管道并且沒有管道被添加到 API 調(diào)用中。 你還可以在索引文檔時(shí)使用特殊管道名稱?_none 來繞過此默認(rèn)索引。 通過使用此功能，你可以定義我稱之為 “虛擬索引” 的內(nèi)容，并將其與默認(rèn)管道相關(guān)聯(lián)，該默認(rèn)管道將充當(dāng)我們上面看到的路由管道。

讓我們將其應(yīng)用到我們的示例中。

我們假設(shè)我們的通用路由管道 compute-index-name 已經(jīng)創(chuàng)建。 我們現(xiàn)在可以創(chuàng)建一個(gè)名為 data 的索引，它將使用此管道作為其默認(rèn)管道。

PUT data
{
  "settings" : {
    "index" : {
      "number_of_shards" : 3, 
      "number_of_replicas" : 1,
      "default_pipeline" : "compute-index-name"
    }
  }
}

現(xiàn)在，每次我們要求 Elasticsearch 為數(shù)據(jù)索引中的文檔編制索引時(shí)，計(jì)算索引名稱管道將負(fù)責(zé)該文檔的實(shí)際路由。 因此，數(shù)據(jù)索引中永遠(yuǎn)不會(huì)有單個(gè)文檔被索引，但我們將調(diào)用管道的責(zé)任完全委托給 Elasticsearch。

運(yùn)行完上面的命令后，我們來嘗試寫入一個(gè)文檔：

POST data/_doc
{
  "objectId": 1234,
  "manufacturer": "SHIELD",
  "payload": "some_data",
  "date": "2019-04-01T12:10:30.000Z"
}

上面的命令返回的結(jié)果是：

{
  "_index": "data-20190401",
  "_id": "2DMGfIYBaog4blQ55Qr7",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 1,
  "_primary_term": 1
}

結(jié)論

我們剛剛在這里看到了如何利用 Elasticsearch 中的管道功能根據(jù)文檔的固有屬性來路由文檔。Ingest pipeline 不僅僅可以替代 Logstash 過濾器：你可以定義復(fù)雜的管道，使用多個(gè)處理器（一個(gè)特定的處理器甚至允許你調(diào)用另一個(gè)管道）、條件等。有關(guān) ingest pipeline 的更多文章，請(qǐng)參閱 “Elastic：開發(fā)者上手指南” 文章中的 “Ingest pipeline” 章節(jié)。

在我看來，本文末尾看到的 “虛擬索引” 非常有趣。 包含創(chuàng)建這樣一個(gè)并非真正的索引的索引只是為了創(chuàng)建路由管道的入口點(diǎn)的功能甚至可以成為 Elasticsearch 的一個(gè)新的和有用的功能，為什么不呢？文章來源地址http://www.zghlxwxcb.cn/news/detail-406287.html

到了這里，關(guān)于Elasticsearch：使用 pipelines 路由文檔到想要的 Elasticsearch 索引中去的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！