I. 概要
MySQLではデータベース設計が非常に重要ですが、ESでもデータベース設計が非常に重要です。テーブル構造を作成するのと同じようにインデックスを作成しますが、インデックスの作成がうまくいかないと、後でさまざまな問題が発生します。
2. 指数設計の重要性
インデックスの作成後、インデックスのシャードは _split および _shrink インターフェイスを介してのみ 2 倍および削減できます。これは主に es データが _routing を介して各シャードに割り当てられるためであり、本質的に不可能です。変更することをお勧めします。インデックス シャードの数。これによりデータが再移動されるためです。インデックスはフィールドの追加のみが可能であり、フィールドの変更や削除はできないという事実もあります。柔軟性に欠けているため、インデックスは毎回 _reindex を通じてのみ再構築できます。また、シャードのサイズとシャードの数もありますインデックスのクエリや書き込みのパフォーマンスに重大な影響を与えるため、適切なインデックスを設計することで、その後の運用保守管理が軽減され、大幅なパフォーマンスの向上が期待できるため、インデックスの初期設計は非常に重要です。
3. 時間ベースのインデックス設計
1. 設計目的
インデックスを設計するときに最初に考慮すべきことは、時間に基づいてインデックスを分割すること、つまり、新しいインデックスを時々生成することです。実世界のデータは時間の経過とともに継続的に生成されるため、シャード管理では十分な柔軟性と優れたパフォーマンスを実現できます。
データがすべてインデックスに保存されている場合、Elasticsearch のインデックスの一部の設定 (プライマリ シャードの数など) は作成時に設定され、変更できないため、拡張や調整が困難になります。時間に応じてインデックスを分割することで、ある程度の柔軟性を実現でき、データ量が多すぎる場合にシャードの数を適時に調整できるだけでなく、新たなビジネス ニーズにもタイムリーに対応できます。ほとんどのビジネス シナリオでは、顧客のデータ要求は最新の期間に達します。インデックスを分割することで、不要なデータのスキャンを可能な限り回避し、パフォーマンスを向上させることができます。
2. 時間間隔
上記の分析によれば、当然短い方が柔軟に対応できますが、そうすると大量のIndexが生成され、各Indexがメタ情報を維持するためにリソースを消費してしまうため、柔軟性、リソース、パフォーマンスのバランスを取るために必要なため、トレードオフを検討してください。
一般的な間隔には、時間、日、週、月などがあります。まず、データが合計でどのくらいの期間保存されるかを検討し、次に、大量のインデックスが生成されず、ある程度の柔軟性を満たすことができる間隔を選択します。 6 か月分のデータを保存する必要がある場合は、最初に「週」の間隔を選択する方が適切です。ビジネスの成長率を考慮してください。たとえば、先週 1 億件のデータが生成され、今週 10 億件に増加したなど、ビジネスが非常に急速に成長している場合は、変化に対処するための十分な柔軟性を確保するために、この間隔を短くする必要があります。
3. 分離を達成する方法
分割動作はクライアント (データの書き込み側) によって開始されます。データは時間間隔とデータ生成時間に従って異なるインデックスに書き込まれます。区別しやすくするために、対応するタイムマークは次のようになります。インデックスの名前に追加されます。
新しいインデックスを作成するには、クライアントは特定の設定、マッピング、その他の情報を使用して作成リクエストをアクティブに開始できます。ただし、時間のずれが発生する可能性があります。つまり、新しいデータが書き込まれるときに新しいインデックスが構築されていない可能性があります。は、このアクションを実装するためのより洗練された方法、つまりインデックス テンプレートを提供します。
4. シャーディング設計
1. シャーディングの概念
いわゆるシャード設計とは、プライマリ シャードの数を設定する方法を指します。
おそらく多くのシナリオでは設定しなくても問題ないでしょうが (ES7 のデフォルトではプライマリ シャードとレプリカ シャードが 1 つずつ設定されています)、事前に考えておかないと, 一度何か問題が発生すると、システムのパフォーマンスが低下したり、アクセスできなくなったり、回復不能になったりする可能性があります。つまり、デフォルト値を使用する場合でも、顔に平手打ちするのではなく、十分な評価を行った上で決定する必要があります。
2. シャードサイズを制限する
1 つのシャードのストレージ サイズは 30 GB を超えません。
Elastic の専門家は経験に基づいて、一般に 30 GB が適切な上限であると誰もが信じていると結論付けていますが、実際には、単一のシャードが大きすぎる (30 GB を超える) とシステムが不安定になることが判明しています。次に、なぜ 30GB を超えられないのでしょうか? 主な理由は、シャード再配置プロセスの負荷を考慮することです。シャードのバランスが崩れているか、一部のノードに障害が発生した場合、Elasticsearch はシャード再配置を実行し、このプロセス中にシャードを移動します。単一のシャードが大きすぎる場合、 CPU と IO の負荷が高くなりすぎるため、システムのパフォーマンスと安定性に影響します。
3. シャードの数を評価する
単一インデックスのプライマリ シャードの数= k * データ ノードの数
最初の点を確保するという前提の下では、単一インデックスのプライマリ シャードの数が多すぎてはなりません。そうしないと、関連するメタ情報とキャッシュがシステム リソースを大量に消費します。ここでの k は小さな整数値であり、整数の倍数の関係により、シャードがより均等に分散され、リクエストをさまざまなノードに完全に分散できます。
4.小さなインデックスデザイン
非常に小さいインデックスの場合、プライマリ シャードは 1 ～ 2 つしか割り当てることができません。
場合によっては、インデックスは非常に小さく、おそらくわずか数十 MB または数百 MB であるため、2 番目のポイントに従ってインデックスを割り当てる必要はありません。プライマリ シャードは 1 ～ 2 つだけ割り当てても問題ありません。心配。
5. インデックステンプレートを使用する
1.コンセプト
すでに作成されているインデックスのパラメータ設定やインデックスマッピングをテンプレートとして保存することを意味し、新規インデックス作成時に使用するテンプレート名を指定することで、定義済みのテンプレートを直接再利用することができます。
Elasticsearch は、インデックス名に一致するワイルドカード パターンに基づいて、新しいインデックスにテンプレートを適用します。つまり、インデックスを照合して、新しいインデックスがインデックス テンプレートに準拠しているかどうかを確認します。準拠している場合は、インデックス テンプレートの関連設定を適用します。複数のインデックス テンプレートが同時に一致する場合は、ここでパラメータの優先順位を比較する必要があるため、優先順位の高いテンプレートがインデックスの作成に選択されます。インデックス テンプレートを作成するとき、一致に包含関係がある場合、または一致する場合は、優先順位を別の値に設定する必要があります。そうでない場合は、エラーが報告されます。インデックス テンプレートは、新しく作成された場合にのみ機能します。インデックスの変更テンプレートは既存のテンプレートに影響します。インデックスは影響しません。同様に、インデックスに一部の設定またはマッピングが設定されている場合、インデックス テンプレート内の同じ設定またはマッピングが上書きされます。
2. インデックステンプレートの目的
インデックス テンプレートは通常、時系列関連のインデックスで使用されます。
つまり、一定の間隔でインデックスを作成する必要がある場合は、インデックス テンプレートを構成するだけでよく、今後は毎回設定やマッピングを行う必要がなく、このテンプレートの設定を直接使用できます。
3. インデックステンプレートを作成する
PUT _index_template/logstash-village
{
"index_patterns": [
"logstash-village-*" // 可以通过"logstash-village-*"来适配创建的索引
],
"template": {
"settings": {
"number_of_shards": "3", //指定模板分片数量
"number_of_replicas": "2" //指定模板副本数量
},
"aliases": {
"logstash-village": {} //指定模板索引别名
},
"mappings": { //设置映射
"dynamic": "strict", //禁用动态映射
"properties": {
"@timestamp": {
"type": "date",
"format": "strict_date_optional_time||epoch_millis||yyyy-MM-dd HH:mm:ss"
},
"@version": {
"doc_values": false,
"index": "false",
"type": "integer"
},
"name": {
"type": "keyword"
},
"province": {
"type": "keyword"
},
"city": {
"type": "keyword"
},
"area": {
"type": "keyword"
},
"addr": {
"type": "text",
"analyzer": "ik_smart"
},
"location": {
"type": "geo_point"
},
"property_type": {
"type": "keyword"
},
"property_company": {
"type": "text",
"analyzer": "ik_smart"
},
"property_cost": {
"type": "float"
},
"floorage": {
"type": "float"
},
"houses": {
"type": "integer"
},
"built_year": {
"type": "integer"
},
"parkings": {
"type": "integer"
},
"volume": {
"type": "float"
},
"greening": {
"type": "float"
},
"producer": {
"type": "keyword"
},
"school": {
"type": "keyword"
},
"info": {
"type": "text",
"analyzer": "ik_smart"
}
}
}
}
}4. テンプレートパラメータ
以下に、インデックス テンプレートを作成するためのパラメーターをいくつか示します。
| パラメータ名 | パラメータの紹介 |
|---|---|
| インデックスパターン | 必要な構成。作成時にインデックス名を照合するために使用されるワイルドカード (*) 式の配列 |
| テンプレート | オプションの構成 (オプションでエイリアス、マッピング、または設定構成を含む) |
| 構成されている | オプションの構成。コンポーネント テンプレート名の順序付きリスト。コンポーネント テンプレートは指定された順序でマージされます。つまり、最後に指定されたコンポーネント テンプレートが最も高い優先順位を持ちます。 |
| 優先度 | 新しいインデックスを作成するときにインデックス テンプレートの優先順位を決定するオプションの構成。最も優先度の高いインデックス テンプレートを選択します。優先度が指定されていない場合、テンプレートは優先度 0 (最も低い優先度) とみなされます。 |
| バージョン | オプションの構成、外部管理インデックス テンプレートのバージョン番号 |
| _メタ | オプションの構成、インデックス テンプレートに関するオプションのユーザー メタデータは何でもかまいません |