Vespaで集約を高速化する方法は？

Question

インデックスには60M個のドキュメントがあります。 4ノードのクラスタでホストされます。

構成がドキュメント上の集計に最適化されていることを確認します。

これはサンプルクエリです：

select * from sources * where (sddocname contains ([{"implicitTransforms": false}]"tweet")) | all(group(n_tA_c) each(output(count() as(count)))); 

フィールドn_tA_cは、文字列の配列が含まれています。

 { 
      "fields": { 
       "add_gsOrd": 63829, 
       "documentid": "id:firehose:tweet::815347045032742912", 
       "foC": 467, 
       "frC": 315, 
       "g": 0, 
       "ln": "en", 
       "m": "ya just wants some fried rice", 
       "mTp": 2, 
       "n_c_p": [], 
       "n_tA_c": [       
        "fried", 
        "rice" 
       ], 
       "n_tA_s": [], 
       "n_tA_tC": [], 
       "sN": "long_delaney1", 
       "sT_dlC": 0, 
       "sT_fC": 0, 
       "sT_lAT": 0, 
       "sT_qC": 0, 
       "sT_r": 0.0, 
       "sT_rC": 467, 
       "sT_rpC": 0, 
       "sT_rtC": 0, 
       "sT_vC": 0, 
       "sddocname": "tweet", 
       "t": 1483228858608, 
       "u": 377606303, 
       "v": "false" 
      }, 
      "id": "id:firehose:tweet::815347045032742912", 
      "relevance": 0.0, 
      "source": "content-root-cluster" 
     } 

n_tA_cモード高速検索、簡単な用語集約クエリは20代に戻ってこない

field n_tA_c type array<string> { 
     indexing: summary | attribute 
     attribute: fast-search 
    } 

を持つ属性である：これはサンプル文書です。タイムアウト。この待ち時間を短縮するために必要な追加のチェックリストは何ですか？

$ curl 'http://localhost:8080/search/?yql=select%20*%20from%20sources%20*%20where%20(sddocname%20contains%20(%5B%7B%22implicitTransforms%22%3A%20false%7D%5D%22tweet%22))%20%7C%20all(group(n_tA_c)%20each(output(count()%20as(count))))%3B' | python -m json.tool 
     % Total % Received % Xferd Average Speed Time Time  Time Current 
            Dload Upload Total Spent Left Speed 
    100 270 100 270 0  0  13  0 0:00:20 0:00:20 --:--:-- 67 
    { 
     "root": { 
      "children": [ 
       { 
        "continuation": { 
         "this": "" 
        }, 
        "id": "group:root:0", 
        "relevance": 1.0 
       } 
      ], 
      "errors": [ 
       { 
        "code": 12, 
        "message": "Timeout while waiting for sc0.num0", 
        "source": "content-root-cluster", 
        "summary": "Timed out" 
       } 
      ], 
      "fields": { 
       "totalCount": 0 
      }, 
      "id": "toplevel", 
      "relevance": 1.0 
     } 
    } 

これらのノードは、AWSが大きな箱をi3.4xです。（16個のコア、120ギガバイト）私は私が愚かな何かが足りないかもしれません

を。

Answer 1

グループ化の式にmax（x）の制限が含まれていないため、すべてのユニークな値とcount（）を求めています。これは非常にCPUとネットワークの集中的なタスクです。例えば

all(group(n_tA_c) max(10) each(output(count() as(count))));

一般的なコメント：他のあるエンジンのようなベスパで 高いメモリ圧力に入ることなく、あなたは、インデックスと検索データをできるように無効に十分なメモリと例えばスワップを持つことが重要です。

ドキュメントタイプごとに使用するメモリ容量は、いくつかの要因に依存しますが、ノードあたりの属性とドキュメント数で定義されるフィールドの数は重要です。冗長性と検索可能なコピー数も大きな役割を果たします。

コーパス全体をグループ化することはメモリ集中型（メモリ帯域幅の読み取り属性値）、CPU集中型、ネットワーク集中型です（ファンアウトが高い場合はhttp://docs.vespa.ai/documentation/grouping.htmlの精度を参照してください）。ノード）。

Answer 2

他の回答やその他のドキュメントのヘルプで、会話から集計を作成する際に注意が必要なチェックポイントを要約します。

• 必要なバケットサイズのグループには、常にmax(x)を追加します。データが複数のコンテンツノードに分散されている場合、この結果は不正確になります。精度を高めるには、必要に応じて精度を調整するためにprecision(x)も使用する必要があります。
• アグリゲーションバケットとヒットなしが必要な場合は、yqlにlimit 0を渡します。これは、コンテナに返される要約を読み込むステップを保存します。
• フィルタリング/アグリゲーションしている属性フィールドは、モードfast-searchになります。さもなければインデックスのようなBツリーではなく、横断されなければならない。
• クエリで&ranking=unrankedのドキュメントの一定スコアを確保してください。
• groupingSessionCache有効にする：http://docs.vespa.ai/documentation/reference/search-api-reference.html#groupingSessionCache
• サイジング無対の待ち時間のトレードオフのためのコンテンツノードを。ドキュメントのmax-hitsによって記載されているように：http://docs.vespa.ai/documentation/performance/sizing-search.html
• メモリーがボトルネックである場合、属性のフラッシュストラテジ構成を見ることができます。 http://docs.vespa.ai/documentation/proton.html#proton-maintenance-jobs
• CPUがボトルネックの場合は、並列性を高める。すべてのコアがSearcherで使用されていることを確認します。 http://docs.vespa.ai/documentation/content/setup-proton-tuning.html#requestthreads-persearch。 service.xmlにでそのための変更点：

<persearch>16</persearch>

スレッドpersearchデフォルトでは、変更の上1.

では、クエリがタイムアウトする前に、結果に返されることを確実にしました。しかし、ベスパは一次目標との集約のために作られていないことを学びました。書き込みと検索のレイテンシは、同一のハードウェアで同じスケールのESよりはるかに少ない。しかし、集約（特に多値文字列フィールドの場合）は、CPU集約型で、同じ集約クエリのESと比較して待ち時間が長くなります。