検索速度の調整（Tune for search speed）

検索速度の調整

ファイルシステムキャッシュにメモリを割り当てる

Elasticsearchは検索を迅速に行うためにファイルシステムキャッシュに大きく依存しています。一般的に、利用可能なメモリの少なくとも半分をファイルシステムキャッシュに割り当てることを確認する必要があります。これにより、Elasticsearchはインデックスのホットな領域を物理メモリに保持できます。

Linuxで控えめなリードアヘッド値を使用してページキャッシュのスラッシングを避ける

検索は多くのランダムな読み取りI/Oを引き起こす可能性があります。基盤となるブロックデバイスのリードアヘッド値が高い場合、特にファイルがメモリマッピングを使用してアクセスされるときに、多くの不必要な読み取りI/Oが行われる可能性があります（ストレージタイプを参照）。

ほとんどのLinuxディストリビューションは、単一のプレーンデバイスに対して128KiBの妥当なリードアヘッド値を使用しますが、ソフトウェアRAID、LVM、またはdm-cryptを使用する場合、結果として得られるブロックデバイス（Elasticsearchのパスデータ）は非常に大きなリードアヘッド値（数MiBの範囲）を持つことがあります。これにより、通常、ページ（ファイルシステム）キャッシュのスラッシングが発生し、検索（または更新）のパフォーマンスに悪影響を及ぼします。

現在の値はKiBでlsblk -o NAME,RA,MOUNTPOINT,TYPE,SIZEを使用して確認できます。この値を変更する方法については、ディストリビューションのドキュメントを参照してください（たとえば、再起動を跨いで持続するためのudevルールを使用するか、blockdev —setraを一時設定として使用します）。リードアヘッドには128KiBの値を推奨します。

blockdevは512バイトセクターで値を期待し、lsblkはKiBで値を報告します。例として、/dev/nvme0n1のためにリードアヘッドを128KiBに一時的に設定するには、blockdev --setra 256 /dev/nvme0n1を指定します。

より高速なハードウェアを使用する

検索がI/Oに制約されている場合は、ファイルシステムキャッシュのサイズを増やす（上記を参照）か、より高速なストレージを使用することを検討してください。各検索は、複数のファイルにわたる順次およびランダムな読み取りの混合を含み、各シャードで同時に多くの検索が実行される可能性があるため、SSDドライブは回転ディスクよりもパフォーマンスが向上する傾向があります。

検索がCPUに制約されている場合は、より多くの高速CPUを使用することを検討してください。

ローカルストレージとリモートストレージ

直接接続された（ローカル）ストレージは、リモートストレージよりも一般的にパフォーマンスが良好です。これは、適切に構成するのが簡単で、通信オーバーヘッドを回避できるためです。

一部のリモートストレージは、特にElasticsearchが課すような負荷の下では非常にパフォーマンスが悪いです。しかし、慎重に調整すれば、リモートストレージを使用しても受け入れ可能なパフォーマンスを達成できることがあります。特定のストレージアーキテクチャにコミットする前に、現実的なワークロードでシステムをベンチマークして、調整パラメータの影響を確認してください。期待するパフォーマンスを達成できない場合は、ストレージシステムのベンダーと協力して問題を特定してください。

ドキュメントモデリング

ドキュメントは、検索時の操作ができるだけ安価になるようにモデル化する必要があります。

特に、結合は避けるべきです。 nestedはクエリを数倍遅くする可能性があり、親子関係はクエリを数百倍遅くする可能性があります。したがって、同じ質問が結合なしでドキュメントを非正規化することで回答できる場合、重要な速度向上が期待できます。

できるだけ少ないフィールドを検索する

query_stringまたはmulti_matchクエリがターゲットとするフィールドが多いほど、遅くなります。複数のフィールドにわたる検索速度を向上させる一般的な手法は、インデックス時にその値を単一のフィールドにコピーし、検索時にこのフィールドを使用することです。これは、ドキュメントのソースを変更することなく、マッピングのcopy-toディレクティブを使用して自動化できます。以下は、映画を含むインデックスの例で、映画の名前とプロットの両方をname_and_plotフィールドにインデックスすることで、クエリを最適化しています。

Python

resp = client.indices.create(
   index="movies",
   mappings={
   "properties": {
   "name_and_plot": {
   "type": "text"
   },
   "name": {
   "type": "text",
   "copy_to": "name_and_plot"
   },
   "plot": {
   "type": "text",
   "copy_to": "name_and_plot"
   }
   }
   },
)
print(resp)

Ruby

response = client.indices.create(
  index: 'movies',
  body: {
   mappings: {
   properties: {
   name_and_plot: {
   type: 'text'
   },
   name: {
   type: 'text',
   copy_to: 'name_and_plot'
   },
   plot: {
   type: 'text',
   copy_to: 'name_and_plot'
   }
   }
   }
  }
)
puts response

Js

const response = await client.indices.create({
  index: "movies",
  mappings: {
   properties: {
   name_and_plot: {
   type: "text",
   },
   name: {
   type: "text",
   copy_to: "name_and_plot",
   },
   plot: {
   type: "text",
   copy_to: "name_and_plot",
   },
   },
  },
});
console.log(response);

コンソール

PUT movies
{
  "mappings": {
   "properties": {
   "name_and_plot": {
   "type": "text"
   },
   "name": {
   "type": "text",
   "copy_to": "name_and_plot"
   },
   "plot": {
   "type": "text",
   "copy_to": "name_and_plot"
   }
   }
  }
}

データを事前インデックス化する

クエリのパターンを活用して、データのインデックス化方法を最適化する必要があります。たとえば、すべてのドキュメントにpriceフィールドがあり、ほとんどのクエリが固定リストの範囲でrange集約を実行する場合、この集約をインデックスに範囲を事前インデックス化してterms集約を使用することで、より高速にすることができます。

たとえば、ドキュメントが次のような場合：

Python

resp = client.index(
   index="index",
   id="1",
   document={
   "designation": "spoon",
   "price": 13
   },
)
print(resp)

Ruby

response = client.index(
  index: 'index',
  id: 1,
  body: {
   designation: 'spoon',
   price: 13
  }
)
puts response

Js

const response = await client.index({
  index: "index",
  id: 1,
  document: {
   designation: "spoon",
   price: 13,
  },
});
console.log(response);

コンソール

PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13
}

そして、検索リクエストが次のような場合：

Python

resp = client.search(
   index="index",
   aggs={
   "price_ranges": {
   "range": {
   "field": "price",
   "ranges": [
   {
   "to": 10
   },
   {
   "from": 10,
   "to": 100
   },
   {
   "from": 100
   }
   ]
   }
   }
   },
)
print(resp)

Ruby

response = client.search(
  index: 'index',
  body: {
   aggregations: {
   price_ranges: {
   range: {
   field: 'price',
   ranges: [
   {
   to: 10
   },
   {
   from: 10,
   to: 100
   },
   {
   from: 100
   }
   ]
   }
   }
   }
  }
)
puts response

Js

const response = await client.search({
  index: "index",
  aggs: {
   price_ranges: {
   range: {
   field: "price",
   ranges: [
   {
   to: 10,
   },
   {
   from: 10,
   to: 100,
   },
   {
   from: 100,
   },
   ],
   },
   },
  },
});
console.log(response);

コンソール

GET index/_search
{
  "aggs": {
   "price_ranges": {
   "range": {
   "field": "price",
   "ranges": [
   { "to": 10 },
   { "from": 10, "to": 100 },
   { "from": 100 }
   ]
   }
   }
  }
}

この場合、ドキュメントはインデックス時にprice_rangeフィールドで強化され、これはkeywordとしてマッピングされるべきです：

Python

resp = client.indices.create(
   index="index",
   mappings={
   "properties": {
   "price_range": {
   "type": "keyword"
   }
   }
   },
)
print(resp)
resp1 = client.index(
   index="index",
   id="1",
   document={
   "designation": "spoon",
   "price": 13,
   "price_range": "10-100"
   },
)
print(resp1)

Ruby

response = client.indices.create(
  index: 'index',
  body: {
   mappings: {
   properties: {
   price_range: {
   type: 'keyword'
   }
   }
   }
  }
)
puts response
response = client.index(
  index: 'index',
  id: 1,
  body: {
   designation: 'spoon',
   price: 13,
   price_range: '10-100'
  }
)
puts response

Js

const response = await client.indices.create({
  index: "index",
  mappings: {
   properties: {
   price_range: {
   type: "keyword",
   },
   },
  },
});
console.log(response);
const response1 = await client.index({
  index: "index",
  id: 1,
  document: {
   designation: "spoon",
   price: 13,
   price_range: "10-100",
  },
});
console.log(response1);

コンソール

PUT index
{
  "mappings": {
   "properties": {
   "price_range": {
   "type": "keyword"
   }
   }
  }
}
PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13,
  "price_range": "10-100"
}

そして、検索リクエストはこの新しいフィールドを集約することができ、priceフィールドで[range]集約を実行する必要はありません。

Python

resp = client.search(
   index="index",
   aggs={
   "price_ranges": {
   "terms": {
   "field": "price_range"
   }
   }
   },
)
print(resp)

Ruby

response = client.search(
  index: 'index',
  body: {
   aggregations: {
   price_ranges: {
   terms: {
   field: 'price_range'
   }
   }
   }
  }
)
puts response

Js

const response = await client.search({
  index: "index",
  aggs: {
   price_ranges: {
   terms: {
   field: "price_range",
   },
   },
  },
});
console.log(response);

コンソール

GET index/_search
{
  "aggs": {
   "price_ranges": {
   "terms": {
   "field": "price_range"
   }
   }
  }
}

識別子をキーワードとしてマッピングすることを検討する

すべての数値データをnumericフィールドデータ型としてマッピングする必要はありません。Elasticsearchは、[integerやlongのような数値フィールドをrangeクエリ用に最適化します。しかし、keywordフィールドはtermや他のterm-levelクエリに適しています。

ISBNや製品IDのような識別子は、rangeクエリで使用されることはほとんどありません。しかし、これらはしばしばterm-levelクエリを使用して取得されます。

数値識別子をkeywordとしてマッピングすることを検討してください：

• 識別子データをrangeクエリを使用して検索する予定がない場合。
• 高速な取得が重要です。termクエリは、keywordフィールドでの検索がtermフィールドでの数値フィールドの検索よりも速いことがよくあります。

どちらを使用するか不明な場合は、multi-fieldを使用して、データをkeyword および 数値データ型としてマッピングできます。

スクリプトを避ける

可能であれば、scriptベースのソート、集約内のスクリプト、およびscript_scoreクエリの使用を避けてください。スクリプト、キャッシュ、および検索速度を参照してください。

丸めた日付を検索する

リードアヘッドを使用する日付フィールドに対するクエリは、マッチする範囲が常に変わるため、通常はキャッシュ可能ではありません。しかし、丸めた日付に切り替えることは、ユーザーエクスペリエンスの観点からしばしば受け入れられ、クエリキャッシュをより良く活用する利点があります。

たとえば、以下のクエリ：

Python

resp = client.index(
   index="index",
   id="1",
   document={
   "my_date": "2016-05-11T16:30:55.328Z"
   },
)
print(resp)
resp1 = client.search(
   index="index",
   query={
   "constant_score": {
   "filter": {
   "range": {
   "my_date": {
   "gte": "now-1h",
   "lte": "now"
   }
   }
   }
   }
   },
)
print(resp1)

Ruby

response = client.index(
  index: 'index',
  id: 1,
  body: {
   my_date: '2016-05-11T16:30:55.328Z'
  }
)
puts response
response = client.search(
  index: 'index',
  body: {
   query: {
   constant_score: {
   filter: {
   range: {
   my_date: {
   gte: 'now-1h',
   lte: 'now'
   }
   }
   }
   }
   }
  }
)
puts response

Js

const response = await client.index({
  index: "index",
  id: 1,
  document: {
   my_date: "2016-05-11T16:30:55.328Z",
  },
});
console.log(response);
const response1 = await client.search({
  index: "index",
  query: {
   constant_score: {
   filter: {
   range: {
   my_date: {
   gte: "now-1h",
   lte: "now",
   },
   },
   },
   },
  },
});
console.log(response1);

コンソール

PUT index/_doc/1
{
  "my_date": "2016-05-11T16:30:55.328Z"
}
GET index/_search
{
  "query": {
   "constant_score": {
   "filter": {
   "range": {
   "my_date": {
   "gte": "now-1h",
   "lte": "now"
   }
   }
   }
   }
  }
}

次のクエリに置き換えることができます：

Python

resp = client.search(
   index="index",
   query={
   "constant_score": {
   "filter": {
   "range": {
   "my_date": {
   "gte": "now-1h/m",
   "lte": "now/m"
   }
   }
   }
   }
   },
)
print(resp)

Ruby

response = client.search(
  index: 'index',
  body: {
   query: {
   constant_score: {
   filter: {
   range: {
   my_date: {
   gte: 'now-1h/m',
   lte: 'now/m'
   }
   }
   }
   }
   }
  }
)
puts response

Js

const response = await client.search({
  index: "index",
  query: {
   constant_score: {
   filter: {
   range: {
   my_date: {
   gte: "now-1h/m",
   lte: "now/m",
   },
   },
   },
   },
  },
});
console.log(response);

コンソール

GET index/_search
{
  "query": {
   "constant_score": {
   "filter": {
   "range": {
   "my_date": {
   "gte": "now-1h/m",
   "lte": "now/m"
   }
   }
   }
   }
  }
}

この場合、私たちは分を丸めました。したがって、現在の時間が16:31:29の場合、範囲クエリはmy_dateフィールドの値が15:31:00と16:31:59の間にあるすべてにマッチします。そして、複数のユーザーが同じ分にこの範囲を含むクエリを実行すると、クエリキャッシュが少し速度を上げるのに役立つ可能性があります。丸めに使用される間隔が長いほど、クエリキャッシュがより多くの助けを提供できますが、あまりにも攻撃的な丸めはユーザーエクスペリエンスを損なう可能性があることに注意してください。

範囲を大きなキャッシュ可能な部分と小さなキャッシュ不可の部分に分割して、クエリキャッシュを活用しようとすることは魅力的かもしれませんが、以下のように：

Python

resp = client.search(
   index="index",
   query={
   "constant_score": {
   "filter": {
   "bool": {
   "should": [
   {
   "range": {
   "my_date": {
   "gte": "now-1h",
   "lte": "now-1h/m"
   }
   }
   },
   {
   "range": {
   "my_date": {
   "gt": "now-1h/m",
   "lt": "now/m"
   }
   }
   },
   {
   "range": {
   "my_date": {
   "gte": "now/m",
   "lte": "now"
   }
   }
   }
   ]
   }
   }
   }
   },
)
print(resp)

Ruby

response = client.search(
  index: 'index',
  body: {
   query: {
   constant_score: {
   filter: {
   bool: {
   should: [
   {
   range: {
   my_date: {
   gte: 'now-1h',
   lte: 'now-1h/m'
   }
   }
   },
   {
   range: {
   my_date: {
   gt: 'now-1h/m',
   lt: 'now/m'
   }
   }
   },
   {
   range: {
   my_date: {
   gte: 'now/m',
   lte: 'now'
   }
   }
   }
   ]
   }
   }
   }
   }
  }
)
puts response

Js

const response = await client.search({
  index: "index",
  query: {
   constant_score: {
   filter: {
   bool: {
   should: [
   {
   range: {
   my_date: {
   gte: "now-1h",
   lte: "now-1h/m",
   },
   },
   },
   {
   range: {
   my_date: {
   gt: "now-1h/m",
   lt: "now/m",
   },
   },
   },
   {
   range: {
   my_date: {
   gte: "now/m",
   lte: "now",
   },
   },
   },
   ],
   },
   },
   },
  },
});
console.log(response);

コンソール

GET index/_search
{
  "query": {
   "constant_score": {
   "filter": {
   "bool": {
   "should": [
   {
   "range": {
   "my_date": {
   "gte": "now-1h",
   "lte": "now-1h/m"
   }
   }
   },
   {
   "range": {
   "my_date": {
   "gt": "now-1h/m",
   "lt": "now/m"
   }
   }
   },
   {
   "range": {
   "my_date": {
   "gte": "now/m",
   "lte": "now"
   }
   }
   }
   ]
   }
   }
   }
  }
}

しかし、そのような実践は、boolクエリによって導入されるオーバーヘッドが、クエリキャッシュのより良い活用からの節約を打ち消す可能性があるため、場合によってはクエリを遅くする可能性があります。

読み取り専用インデックスの強制マージ

読み取り専用のインデックスは、単一セグメントにマージされることから利益を得る可能性があります。これは通常、時間ベースのインデックスに当てはまります：現在の時間枠のインデックスのみが新しいドキュメントを受け取っており、古いインデックスは読み取り専用です。強制的に単一セグメントにマージされたシャードは、検索を実行するためによりシンプルで効率的なデータ構造を使用できます。

まだ書き込みを行っているインデックスや、将来的に再度書き込む予定のインデックスを強制的にマージしないでください。代わりに、自動バックグラウンドマージプロセスに依存して、インデックスがスムーズに動作するように必要に応じてマージを実行させてください。強制的にマージされたインデックスに書き込みを続けると、そのパフォーマンスが大幅に悪化する可能性があります。

検索速度の調整

Python

resp = client.indices.create(
   index="index",
   mappings={
   "properties": {
   "foo": {
   "type": "keyword",
   "eager_global_ordinals": True
   }
   }
   },
)
print(resp)

Ruby

response = client.indices.create(
  index: 'index',
  body: {
   mappings: {
   properties: {
   foo: {
   type: 'keyword',
   eager_global_ordinals: true
   }
   }
   }
  }
)
puts response

Js

const response = await client.indices.create({
  index: "index",
  mappings: {
   properties: {
   foo: {
   type: "keyword",
   eager_global_ordinals: true,
   },
   },
  },
});
console.log(response);

コンソール

PUT index
{
  "mappings": {
   "properties": {
   "foo": {
   "type": "keyword",
   "eager_global_ordinals": true
   }
   }
  }
}

ファイルシステムキャッシュをウォームアップする

Elasticsearchを実行しているマシンが再起動されると、ファイルシステムキャッシュは空になります。そのため、オペレーティングシステムがインデックスのホットな領域をメモリにロードするまでに時間がかかります。これにより、検索操作が迅速になります。オペレーティングシステムに、ファイル拡張子に応じてどのファイルを積極的にメモリにロードするかを明示的に指示することができます（index.store.preload設定を使用）。

あまりにも多くのインデックスやファイルに対してファイルシステムキャッシュにデータを積極的にロードすると、ファイルシステムキャッシュがすべてのデータを保持するのに十分大きくない場合、検索が遅くなります。注意して使用してください。

インデックスソートを使用して結合を高速化する

インデックスソートは、わずかに遅いインデックス化のコストで結合を高速化するのに役立ちます。詳細については、インデックスソートのドキュメントを参照してください。

キャッシュ利用を最適化するためにプレファレンスを使用する

検索パフォーマンスを向上させるために役立つ複数のキャッシュがあります。たとえば、ファイルシステムキャッシュ、リクエストキャッシュ、またはクエリキャッシュなどです。しかし、これらのキャッシュはすべてノードレベルで管理されているため、同じリクエストを連続して2回実行し、1つ以上のレプリカを持ち、ラウンドロビン（デフォルトのルーティングアルゴリズム）を使用すると、これらの2つのリクエストは異なるシャードコピーに送信され、ノードレベルのキャッシュが役立たなくなります。

検索アプリケーションのユーザーが、インデックスの狭いサブセットを分析するために、たとえば、似たようなリクエストを次々に実行することが一般的であるため、現在のユーザーまたはセッションを識別するプレファレンス値を使用することで、キャッシュの使用を最適化できる可能性があります。

レプリカはスループットに役立つかもしれませんが、常にそうではありません

レジリエンシーを改善するだけでなく、レプリカはスループットを改善するのにも役立ちます。たとえば、単一シャードインデックスと3つのノードがある場合、すべてのノードが利用されるようにするために、レプリカの数を2に設定する必要があります。

次に、2シャードインデックスと2ノードがあると仮定します。1つのケースでは、レプリカの数は0であり、各ノードが単一のシャードを保持します。2番目のケースでは、レプリカの数は1であり、各ノードが2つのシャードを持っています。検索パフォーマンスの観点から、どのセットアップが最もパフォーマンスが良いでしょうか？通常、ノードあたりのシャード数が少ないセットアップの方がパフォーマンスが良いです。その理由は、各シャードに対して利用可能なファイルシステムキャッシュの割合が大きくなり、ファイルシステムキャッシュがElasticsearchのパフォーマンス要因の1つである可能性が高いからです。同時に、レプリカを持たないセットアップは、単一ノードの障害が発生した場合に失敗の影響を受けるため、スループットと可用性の間にはトレードオフがあります。

では、適切なレプリカの数は何ですか？ノードがnum_nodesのクラスターがあり、num_primariesのプライマリシャードが合計であり、同時にmax_failuresノードの障害に対処できるようにしたい場合、適切なレプリカの数はmax(max_failures, ceil(num_nodes / num_primaries) - 1)です。

検索プロファイラーでクエリを調整する

プロファイルAPIは、クエリと集約の各コンポーネントがリクエストを処理するのにかかる時間にどのように影響するかについての詳細情報を提供します。

Kibanaの[https://www.elastic.co/guide/en/kibana/8.15/xpack-profiler.html]は、プロファイル結果を簡単にナビゲートして分析し、パフォーマンスを改善し、負荷を軽減するためにクエリを調整する方法についての洞察を提供します。

プロファイルAPI自体はクエリにかなりのオーバーヘッドを追加するため、この情報はさまざまなクエリコンポーネントの相対的なコストを理解するために最も適しています。実際の処理時間の信頼できる測定値を提供するものではありません。

index_phrasesを使用してフレーズクエリを高速化する

textフィールドには、2シングルをインデックス化するindex_phrasesオプションがあり、スロップのないフレーズクエリを実行するためにクエリパーサーによって自動的に活用されます。ユースケースに多くのフレーズクエリを実行することが含まれる場合、これによりクエリが大幅に高速化される可能性があります。

index_prefixesを使用してプレフィックスクエリを高速化する

textフィールドには、すべての用語のプレフィックスをインデックス化するindex_prefixesオプションがあり、プレフィックスクエリを実行するためにクエリパーサーによって自動的に活用されます。ユースケースに多くのプレフィックスクエリを実行することが含まれる場合、これによりクエリが大幅に高速化される可能性があります。

フィルタリングを高速化するためにconstant_keywordを使用する

フィルタのコストは、主に一致するドキュメントの数の関数であるという一般的なルールがあります。サイクルを含むインデックスがあると仮定します。自転車の数が多く、cycle_type: bicycleでフィルタを実行する多くの検索があります。この非常に一般的なフィルタは、残念ながらほとんどのドキュメントに一致するため、非常にコストがかかります。このフィルタを実行しない簡単な方法があります：自転車を独自のインデックスに移動し、このインデックスを検索することで自転車をフィルタリングします。

残念ながら、これによりクライアント側のロジックが複雑になる可能性がありますが、constant_keywordが役立ちます。自転車を含むインデックスでcycle_typeをconstant_keywordとして値bicycleでマッピングすることで、クライアントはモノリシックインデックスで実行していたのと同じクエリを実行し続けることができ、Elasticsearchはcycle_typeのフィルタを無視して自転車インデックスで適切な処理を行います。値がbicycleの場合はヒットを返さず、そうでない場合はヒットを返します。

マッピングは次のようになります：

Python

resp = client.indices.create(
   index="bicycles",
   mappings={
   "properties": {
   "cycle_type": {
   "type": "constant_keyword",
   "value": "bicycle"
   },
   "name": {
   "type": "text"
   }
   }
   },
)
print(resp)
resp1 = client.indices.create(
   index="other_cycles",
   mappings={
   "properties": {
   "cycle_type": {
   "type": "keyword"
   },
   "name": {
   "type": "text"
   }
   }
   },
)
print(resp1)

Ruby

response = client.indices.create(
  index: 'bicycles',
  body: {
   mappings: {
   properties: {
   cycle_type: {
   type: 'constant_keyword',
   value: 'bicycle'
   },
   name: {
   type: 'text'
   }
   }
   }
  }
)
puts response
response = client.indices.create(
  index: 'other_cycles',
  body: {
   mappings: {
   properties: {
   cycle_type: {
   type: 'keyword'
   },
   name: {
   type: 'text'
   }
   }
   }
  }
)
puts response

Js

const response = await client.indices.create({
  index: "bicycles",
  mappings: {
   properties: {
   cycle_type: {
   type: "constant_keyword",
   value: "bicycle",
   },
   name: {
   type: "text",
   },
   },
  },
});
console.log(response);
const response1 = await client.indices.create({
  index: "other_cycles",
  mappings: {
   properties: {
   cycle_type: {
   type: "keyword",
   },
   name: {
   type: "text",
   },
   },
  },
});
console.log(response1);

コンソール

PUT bicycles
{
  "mappings": {
   "properties": {
   "cycle_type": {
   "type": "constant_keyword",
   "value": "bicycle"
   },
   "name": {
   "type": "text"
   }
   }
  }
}
PUT other_cycles
{
  "mappings": {
   "properties": {
   "cycle_type": {
   "type": "keyword"
   },
   "name": {
   "type": "text"
   }
   }
  }
}

インデックスを2つに分割しています：1つは自転車のみを含み、もう1つは他のサイクル（ユニサイクル、トライサイクルなど）を含みます。検索時には、両方のインデックスを検索する必要がありますが、クエリを変更する必要はありません。

Python

resp = client.search(
   index="bicycles,other_cycles",
   query={
   "bool": {
   "must": {
   "match": {
   "description": "dutch"
   }
   },
   "filter": {
   "term": {
   "cycle_type": "bicycle"
   }
   }
   }
   },
)
print(resp)

Ruby

response = client.search(
  index: 'bicycles,other_cycles',
  body: {
   query: {
   bool: {
   must: {
   match: {
   description: 'dutch'
   }
   },
   filter: {
   term: {
   cycle_type: 'bicycle'
   }
   }
   }
   }
  }
)
puts response

Js

const response = await client.search({
  index: "bicycles,other_cycles",
  query: {
   bool: {
   must: {
   match: {
   description: "dutch",
   },
   },
   filter: {
   term: {
   cycle_type: "bicycle",
   },
   },
   },
  },
});
console.log(response);

コンソール

GET bicycles,other_cycles/_search
{
  "query": {
   "bool": {
   "must": {
   "match": {
   "description": "dutch"
   }
   },
   "filter": {
   "term": {
   "cycle_type": "bicycle"
   }
   }
   }
  }
}

#### Python
``````python
resp = client.search(
   index="bicycles,other_cycles",
   query={
   "match": {
   "description": "dutch"
   }
   },
)
print(resp)
`

Ruby

response = client.search(
  index: 'bicycles,other_cycles',
  body: {
   query: {
   match: {
   description: 'dutch'
   }
   }
  }
)
puts response

Js

const response = await client.search({
  index: "bicycles,other_cycles",
  query: {
   match: {
   description: "dutch",
   },
  },
});
console.log(response);

コンソール

GET bicycles,other_cycles/_search
{
  "query": {
   "match": {
   "description": "dutch"
   }
  }
}

other_cyclesインデックスでは、Elasticsearchはbicycleがcycle_typeフィールドの用語辞書に存在しないことをすぐに把握し、ヒットなしの検索応答を返します。

これは、一般的な値を専用のインデックスに配置することでクエリを安価にする強力な方法です。このアイデアは、複数のフィールドにわたって組み合わせることもできます。たとえば、各サイクルの色を追跡し、bicyclesインデックスが黒い自転車の大多数を持つ場合、bicycles-blackとbicycles-other-colorsインデックスに分割することができます。

この最適化にはconstant_keywordは厳密には必要ありません。フィルタに基づいて関連するインデックスにクエリをルーティングするためにクライアント側のロジックを更新することも可能です。しかし、constant_keywordはそれを透過的にし、検索リクエストをインデックスのトポロジーから切り離すことを可能にし、非常に少ないオーバーヘッドで実現します。