検索インデックス・フィルター処理のベスト・プラクティス

DSE Searchクエリーのベスト・プラクティス。

DataStaxでは、DSE Searchでクエリーを実行する際に以下のベスト・プラクティスに従うことを推奨しています。
  • CQLを使用して検索クエリーを実行します。

    クエリーによる削除を除き、CQLですべてのデータ操作を実行します。

  • クエリーに必要な型の条件を満たす、最もシンプルで適したSolr型を使用します。「スキーマ・フィールド型について」を参照してください。
  • パフォーマンスを向上させるには、可能であれば常に、Solrフィルター・クエリー(fq)を使用します。フィルター・クエリーの結果はキャッシュに格納されます。平均応答時間を分単位から秒単位に短縮できます。以下の例では、サイクリストの姓と名をクエリーします。
    '{"q":"*:*", "fq":"firstname:Alex AND lastname:FRAME"}'
    各fq名と値の文字列ペアは、fq配列のメンバーとして使用できます。fq名と値のペアは、ANDで区切られている場合と同様に処理されます。例を次に示します。
    '{"q":"*:*", "fq":["lastname:BELKOV", "nationality:Russia"]}'
    結果がメモリー・キャッシュに適合するようにクエリーを調整します。
  • 検索インデックスを作成する際、プロファイルを使用します。
  • インデックス作成中のノードにクエリーを実行するのは避けてください。

    DSE Searchは、クエリーに応答するために、検索インデックスの作成を実行していないノードをインデックス作成中のノードより高いランクに設定します。インデックス作成中のノード以外にクエリーを満たすノードがない場合、そのクエリーは失敗しませんが、部分的な結果のみを返す可能性があります。

  • パーティションの制限でsolr_queryが使用されるクエリーやパーティション制限や検索術後を含むクエリーなどの最適なCQL単一パス・クエリーについては、検索インデックス・スキーマでSELECT対象のカラムのインデックスは作成されません。
    デフォルトでは、自動生成によってすべてのカラムのインデックスが作成されます。フィールドは、インデックスが作成されないまま、単一パス・クエリーで返されるようにすることができます。たとえば、この文では、効率的で正確な単一パス・クエリーのために、カラムc3を除くすべてのインデックスが作成され、カラムc3に関する検索インデックス・スキーマが通知されます。
    CREATE SEARCH INDEX ON test_search.abc
    WITH COLUMNS * { indexed : true }, c3 { indexed : false }; 
  • クラスターでvnodeが構成されていない場合、クエリーが実行されたデータ・センター(DC)内のノード数がそのDCのレプリケーション係数(RF)の倍数に等しい場合にDSE Searchの分散クエリーは最も効果的です。
  • 以下のように、クエリーに使用する単語の数をあまり多くしないでください。
    SELECT request_id, store_id
    FROM store_search.transaction_search
    WHERE solr_query='{"q":"*:*","shards.failover":true,
      "shards.tolerant":false,"fq":"store_id:store1a
      store_id:store2b store_id:store2c ... store_id:store19987d"}';
    代わりに、単語フィルター・クエリーを使用します。
  • コレクションの更新がほとんどない状態でコレクションを書き込む場合、DataStaxではfrozen以外のコレクションにまたがるfrozenコレクションでクエリー・レイテンシーに対処することを推奨しています。
    たとえば、テキスト要素のシンプルなfrozenセットを以下に示します。
    CREATE TABLE foo (
      id text, values frozen<set<text>>, PRIMARY KEY (id)
    );
    
    CREATE TYPE name (
      first text, last text
    );
    UDTのfrozenリスト:
    CREATE TABLE tableWithList (
      id text, names frozen<list<frozen<name>>>, PRIMARY KEY (id)
    );
  • JSONクエリーの制限事項
    フェイルオーバーと部分的な結果のトレランスは同じJSONクエリーに共存できません。クエリーは、単一のパラメーターのみに対するトレランスの有効化をサポートしています。
    注: ディープ・ページングがオンの場合、shards.tolerantパラメータはサポートされません。