1、アプリケーションのシナリオ

リアルタイムデータは、ビジネス・ニーズ、Elasticsearchインデックスに異なるカフカコネクタの直接援助の一部によると、カフカをストリーミングします。
他の一部は、最初のクラスタリング、分類を行う必要は、重合度の分類結果がクラスタリングESクラスタを格納しています。以下に示すように：
アクセス層、データ処理層、データ記憶層、界面層：積層構造ビジネス・システムに分けることができます。
そこで質問がありますか？
我々はこれまで重合分析結果をより速く、より効率的な検索を実現する方法、重合凝集（データ処理層）の結果に基づいて検索および分析動作を実現する必要がありますか？

2、プログラム選択

オプション1：
唯一の指標の確立、aggs_index。
重合の結果は、重合物質フィールドに続く文書のそれぞれに各データに関連しながら、インデックスを指定したESのデータ処理層に格納されています。次の図に示すように：

プログラムの概略図

オプション2：
aggs_indexとaggs_detail_index：2つのインデックスを作成します。
これには：
1）aggs_indexストアイベントリスト情報。
それに関連した物品情報aggs_detail_indexストアイベントの2）含有量。
下図のように：

スキームII概略図

3、プログラムの比較

オプション1つの利点：保存収納スペース、唯一の文書番号を関連店舗、データストレージのない重複はありません。
スキームの欠点：取得は、重合を遅らせる、パフォーマンスは標準ではありません。
後続のすべての操作は、IDを横断するのに必要なプログラムは、パイルを取得し、その後、分析操作を重合し、取得します。

次のように動作例は、（これよりも実際の複合体）である：
最初のステップ：イベントID、IDリストは、関連記事を取得する;
ステップ：関連記事、検索および凝集操作に基づいてIDリストを。

POST  aggs_index/_search
{
  "_source": {
  "includes":[
    "title",
"abstract",
"publish_time",
"author"
    ]},
  "query":{
    "terms":{
      "_id":"["789b4cb872be00a04560d95bf13ec8f42c",
      "792d9610b03676dc5644c2ff4db372dec4",
"817f5cff3dd0ec3564d45615f940cb7437",
"....."]
    }
  }
}

步骤2当id数量很多时，会有如下的错误提示：

{
  "error": {
    "root_cause": [
      {
        "type": "too_many_clauses",
        "reason": "too_many_clauses:
        maxClauseCount is set to 1024"
      },

。。。

方案二优点：分开存储，便于一个索引中进行检索、聚合分析操作。
空间换时间，极大的提升检索效率、聚合速度。
方案二缺点：同样的数据，多存储了一份。
其对应的检索操作如下：

POST  aggs_index/_search
{
  "_source": {
  "includes":[
    "title",
"abstract",
"publish_time",
"author"
    ]},
  "query":{
    "term":{
      "topic_id":"WIAEgRbI0k9s1D2JrXPC"
    }
  }
}

是真的吗？
用事实说话：
以下响应时间的单位为：ms。
方案一要在N个（N接近10）索引，每个索引近千万级别的数据中检索。

两方案对比