ビジネス設定ハッシュモードレベル1ハッシュレベル2ハッシュクエリ設定戻りヒット最適化設定メモリプール設定結合設定
V3.0より前のバージョンのHavenaskでは、クラスタ設定には、indexlibを使用してオフラインまたはリアルタイムでインデックスを構築し、インデックスをロードし、オンラインでデータを取得するときに必要な設定が含まれていました。この設定方法は複雑です。Havenask V3.0では、設定ロジックが簡素化されています。
indexlibを使用してオフラインでフルインデックスと増分インデックスを構築し、リアルタイムでインデックスを構築するときに使用される設定は、オフラインクラスタ設定ファイルに移動されます。ほとんどの場合、ファイル名はapp_cluster.jsonです。
indexlibインデックスをロードするために使用されるメソッドの設定は、テーブル設定ファイルに含まれています。ほとんどの場合、ファイル名はcluster_name +"_cluster.json"です。このファイル名とオフラインで構築するインデックスの設定ファイルは、フォルダパスによって区別されます。
オンラインでデータを取得するときに使用される設定は、ビジネス設定に含まれています。次のサンプルコードは、ビジネス設定の構造を示しています。
ビジネス設定構造
{
"cluster_config": {...}, // クラスタ設定
"aggregate_sampler_config" : {...}, // 集計サンプラー設定
"rankprofile_config" : {...}, // ランクプロファイル設定
"summary_profile_config" : {...}, // サマリープロファイル設定
"function_config", : {...}, // 関数設定
"searcher_cache_config" : {...}, // サーチキャッシュ設定
"service_degradation_config" : {...} // サービス低下設定}
cluster_config
cluster_config {
"hash_mode" : "", // ハッシュモード
"query_config" : "", // クエリ設定
"join_config" : "", // 結合設定
"return_hit_rewrite_threshold" : "", // 戻りヒット書き換えしきい値
"return_hit_rewrite_ratio" : "", // 戻りヒット書き換え比率
"table_name" : "", // テーブル名
"pool_trunk_size: : 10, // プールトランクサイズ
"pool_recycle_size_limit" : 20, // プールリサイクルサイズ制限}
ドキュメントに使用されるハッシュメソッドは、ドキュメントが属するパーティションを決定します。 hash_field：ハッシュ値の計算に使用されるフィールド。ほとんどの場合、主キーフィールドが使用されます。特別な場合は、inshopフィールドが使用されます。 hash_function：HASH、GALAXY_HASH、KINGSO_HASHハッシュメソッドがサポートされています。KINGSO_HASHメソッドでkingSoのハッシュ範囲を変更する場合は、KINGSO_HASH#range構文でメソッドを設定できます。この範囲は設定する必要があります。
例：
"hash_mode":
{
"hash_field" : "nid", // ハッシュフィールド
"hash_function" : "HASH" // ハッシュ関数
}上記のサンプルコードの値は、パーティション分割のためにHASHメソッドとnidフィールドを使用してハッシュ値が計算されることを示しています。
Havenaskエンジンのインデックスは、フルまたは増分インデックスとリアルタイムインデックスで構成されます。フルインデックスはビルドサービスシステムで構築されます。リアルタイムインデックスはサーチビルダーで構築されます。swiftシステムに対応するトピックのドキュメントは、フルインデックスとリアルタイムインデックスを構築するために必要です。ビルドサービスシステムのプロセッサは、インデックス化されたドキュメントを配布します。プロセッサは、hash_mode設定項目で指定されたフィールドをドキュメントから読み取り、ハッシュ関数を使用して0〜65535の範囲の値を取得し、swiftシステムに対応するトピックの範囲が[0、65535]であるパーティションに値を送信します。インデックスは論理的に0〜65535の範囲の2^16論理パーティションに分割されます。生成する物理パーティションの数を指定できます。エンジンは、連続する論理パーティションを物理パーティションに自動的にマッピングします。たとえば、2つの物理パーティションのインデックスを使用する場合、物理パーティションの論理パーティションの範囲は[0、32767]と[32768、65535]です。swiftシステムに対応するトピックのパーティションをサブスクライブして、必要なドキュメントを取得できます。システムは、オンラインクエリを実行するときに必要なhash_mode設定を読み取ります。次に、システムは指定された列をクエリします。 前のセクションで提供されている情報を理解していれば、レベル1ハッシュを使用できます。次のセクションでは、淘宝網ストアでの検索の例について説明します。hash_modeでは、hash_fieldは、販売者IDを指定するuser_idと同様の方法で使用されます。大規模販売者が所有する商品アイテムの数量は、小規模販売者が所有する商品アイテムの数量よりも多くなります。ビルドサービスシステムのプロセッサがインデックスを作成するとき、user_idの値はハッシュ値として計算されます。ホットデータは、次のシナリオで生成されます。1.プロセッサがハッシュ値を計算した後、大規模販売者のビルダーとマネージャーを実行するために必要な期間は、他のビルダーとマネージャーを実行するために必要な期間よりも長くなります。その結果、構築プロセスを完了するためにより長い期間が必要になります。2.インデックス作成結果がエンジンの異なる列にロードされると、列に設定されたインデックスは、他の列のインデックスよりも大きくなります。この場合、エンジンはすべての列のホットデータを処理するために必要なリソースの数を増やし、オンラインリソースが無駄になります。3.大規模販売者に対応する列がより頻繁にクエリされます。これにより、システムはクエリのホットデータを生成します。この場合、問題が発生します。たとえば、構築プロセスを完了するために必要な期間が長くなり、オンラインリソースが無駄になり、クエリのホットデータが生成されます。
レベル2ハッシュは、レベル1ハッシュに基づいています。レベル1ハッシュを使用してドキュメントを同じ列にハッシュした後、レベル2ハッシュを使用して、レベル2ハッシュフィールドに基づいてドキュメントを異なる列にハッシュできます。レベル2ハッシュのhash_fieldsをuser_idとnidに設定します。user_idは販売者IDを指定し、nidは商品IDを指定します。レベル1ハッシュは、販売者別に列をソートするために使用されます。大規模販売者の商品は、エンジンの列に配布されます。次に、レベル2ハッシュを使用して、商品IDに基づいて商品をハッシュします。このようにして、商品はエンジンの複数の列に配布されます。ハッシュは、ビルドサービスシステムのプロセッサによって実行されます。次の結果が発生します。構築フェーズとマージフェーズ中にホットデータが生成されるという問題は解決されます。ホットデータはエンジンの異なる列に生成されます。異なる列には少量のホットデータのみが含まれています。クエリ要求は異なる列に送信され、ホットデータの量が削減されます。このようにして、ハッシュは構築を高速化し、全体的なリソース使用率を向上させます。この機能は、Havenask V3.7.2以降でサポートされています。 autilには、レベル2リスト関数ROUTING_HASHが用意されています。次のサンプルコードは、関数の新しいhash_mode設定について説明しています。
"hash_mode" : // ハッシュモード
{
"hash_field" : "user_id", // ハッシュフィールド
"hash_fields" : ["user_id", "nid"], // ハッシュフィールド
"hash_function" : "ROUTING_HASH", // ハッシュ関数
"hash_params" : { // ハッシュパラメータ
"hash_func": "HASH", // ハッシュ関数
"routing_ratio":"0.25", // ルーティング比率
"hot_ranges":"512-1536;8000-10000", // ホット範囲
"hot_ranges_ratio":"0.25;0.5", // ホット範囲比率
"hot_values":"t1;t2", // ホット値
"hot_values_ratio":"0.3;0.4" // ホット値比率
}
}次のセクションでは、パラメータについて説明します。
hash_fieldとhash_fields：hash_fieldパラメータは引き続きサポートされています。hash_fieldsパラメータを設定しない場合、hash_fieldパラメータの値が自動的にデフォルト値として使用されます。hash_fieldsパラメータが設定されている場合、hash_fieldパラメータの値は有効になりませんが、それでもhash_fieldパラメータを設定する必要があります。
hash_functionは、HASH、GALAXY_HASH、KINGSO_HASHをサポートしています。ROUTING_HASHは、レベル2ハッシュとして追加されます。
hash_paramsパラメータは、ハッシュ関数を設定するために使用されます。このパラメータのタイプはmap<string、string>です。パラメータは、ハッシュ関数を作成するときに使用されます。たとえば、HASH、GALAXY_HASH、またはKINGSO_HASHを使用する場合、hash_paramsパラメータを設定する必要はありません。ROUTING_HASHを使用し、hash_paramsパラメータを設定しない場合、ROUTING_HASHは、デフォルトでHASHが使用されるのと同じ方法で使用されます。
ROUTING_HASHのhash_paramsパラメータは、次の設定項目をサポートしています。
hash_funcは、ROUTING_HASHで使用されるハッシュ関数を指定します。デフォルト値はHASHです。関数をテストするためにNUMBER_HASHを使用できます。
routing_ratioは、レベル2ハッシュの適用範囲を指定します。上記の構成では、内部レベル2ハッシュ値は次の式に基づいて計算されます。
(HASH(user_id) %65536 + floor(HAHS(nid)%65536 * routing_ratio) )%65536 // (HASH(user_id) %65536 + floor(HAHS(nid)%65536 * routing_ratio) )%65536hot_rangesは、ホットデータのハッシュ値を指定します。hot_ranges_ratioは、ハッシュ値の適用範囲を指定します。特定のホットデータのハッシュに異なる適用範囲を指定できます。ほとんどの場合、これらのパラメータは、ホットデータを含む物理列がわかっている場合に使用されます。これらのパラメータを使用するには、列のハッシュ値を0〜65535から取得する必要があります。
hot_valuesは、ホットデータの販売者を指定します。hot_values_ratioは、販売者の適用範囲を指定します。大規模販売者ごとに異なる適用範囲を指定できます。ほとんどの場合、これらのパラメータは、ホットデータの販売者の元の値がわかっている場合に使用されます。
注：hash_mode設定でハッシュ関数またはhash_paramsを変更すると、インデックスデータの配布方法が変更されます。次のいずれかの方法を使用して、クエリ結果を更新できます。
すべての列をクエリする場合は、フルインデックスを再作成し、クエリ結果サーチャー（QRS）設定を更新してクエリを実行します。
単一の列をクエリするか、レベル2ハッシュを実行する場合は、クラスタとフルインデックスを再作成します。QRSのハッシュ設定とインデックスで使用されるハッシュ設定が一致しない可能性があるため、完全なデータのクラスタとインデックスを再作成する必要があります。更新されたhash_mode設定が有効になる前にクエリされた列は無効です。
次のリストは、クエリ設定について説明しています。クエリのデフォルトのインデックス名を指定し、複数のキーワード間のデフォルトの関係をクエリし、複数項最適化を有効にするかどうかを指定します。
default_index
クエリのデフォルトのインデックス名。クエリのインデックス名を指定しない場合、インデックス名はインデックスからクエリされます。 たとえば、query=nid:1は、クエリのインデックス名がnidインデックスからクエリされることを指定します。query='mp3'は、クエリのインデックス名を指定しません。この場合、デフォルトのインデックスが使用されます。
default_operator
クエリする複数の単語間のデフォルトの関係。このパラメータを「AND」に設定すると、複数の単語のクエリ結果の共通部分が取得されます。たとえば、「query=a b」は「query=a AND b」として処理されます。トークナイザーがクエリ中に単一のフレーズを複数の用語に分割する場合、用語はdefault_operatorパラメータで指定された関係に基づいてクエリされます。
multi_term_optimize
multi_term_optimizeは、複数項クエリ最適化を有効にするかどうかを指定します。たとえば、システムは、a|bとa&bを、システムがデフォルトでa OR bとa AND bを処理するのと同じ方法で処理します。これらのクエリは、2回実行されるバイナリクエリです。QRSは、特に|または&を使用して多数の用語を連結する場合、クエリを処理するためのオーバーヘッドコストが高くなります。たとえば、このパラメータをtrueに設定した後、メイン検索のカスタマイズされたリコールクエリは、1回実行される複数項クエリに変更されます。opは、ORまたはANDロジックを識別するために使用されます。
例： "query_config" : // クエリ設定 {
"default_index" : "phrase", // デフォルトインデックス
"default_operator" : "AND", // デフォルト演算子
"multi_term_optimize" : true // 複数項最適化},
上記の例では、デフォルトクエリのインデックスはphrase、複数のキーワード間の関係はAND、複数項最適化はクエリを解決するために実行されます。
サーチャーがドキュメントをQRSにシリアル化するために使用する設定セットが最適化されています。デフォルトでは、QRSはサーチャーから必要なデータをクエリします。サーチャーは、startおよびhitパラメータで指定されたドキュメントを返す必要があります。サーチャーは、必要なドキュメントを返すためにドキュメントをソートします。startおよびhitパラメータで指定された多数のドキュメントが必要な場合、サーチャーでのシリアル化とQRSでのデシリアライゼーションには高いコストがかかります。複数の列からデータをクエリする場合、データが均等に分散され、サーチャーによって返されるレコード数が削減されると、クエリ結果には影響しません。サーチャーによって返されるレコード数が、次の式を使用して計算された結果よりも大きいことを確認してください。startおよびhitパラメータで指定されたレコード数×係数。クローラーサービスアーキテクチャまたはランクサービスアーキテクチャでは、多数のレコードがstartおよびhitパラメータで指定されます。この場合、multi_term_optimizeパラメータをtrueに設定できます。
return_hit_rewrite_threshold： startおよびhitパラメータで指定されたレコード数がこのしきい値よりも大きい場合、multi_term_optimizeパラメータをtrueに設定します。
return_hit_rewrite_ratio： サーチャーでは、ソートされたレコード数、シリアル化されたレコード数、および（start + hit）/ partitionの値に、ビジネス要件に基づいて1より大きい係数が乗算されます。 return_hit_rewrite_ratioパラメータの有効な値の範囲は1〜partition_countです。 inshopが単一の列にルーティングされるクエリなどのクエリでは、最適化操作は実行されません。
レコードが最適化された後、検索でシリアル化されたレコード数は、次の式に基づいて計算されます。（start + hit）/ partition_count×return_hit_rewrite_ratio。列数が多いほど、最適化が向上します。
pool_trunk_size
プールによって割り当てられるトランクのサイズ。単位：MB。デフォルト値：10 MB。
pool_recycle_size_limit
システムが占有スペースを再利用するトリガーとなるプールサイズ。単位：MB。デフォルト値：20 MB。
一般的なシナリオでのセカンダリテーブルの設定：商品情報に加えて、メンバー情報も保存する必要があります。セカンダリテーブルを使用しない場合、必要なメンバー情報を商品データに追加する必要があります。商品が同じメンバーに属している場合、各商品に関する同じメンバー情報を保存する必要があります。メンバー情報はオフラインで処理され、ストレージスペースを占有します。メンバー情報が更新されると、メンバーのすべての商品が更新されます。セカンダリテーブルを使用してこの問題を解決できます。商品テーブルとメンバーテーブルは個別にインデックス化されます。商品とメンバーに関する情報がオンラインで保存されると、メンバーテーブルの主キーを使用して必要なメンバー情報がクエリされます。member_idのフォワードインデックスは商品テーブルに保存され、フォワードインデックスのメカニズムはデータベースのメカニズムに似ています。この方法では、いくつかの最適化操作が実行され、操作の設定については、以下のセクションで詳しく説明します。メンバーテーブルは追加情報として保存されず、テーブルは個別に更新できます。メンバーテーブルのデータはクエリ条件として使用できません。メンバーテーブルのデータをフィルタリング、ソート、または表示することのみができます。また、クエリされたフィールドを商品テーブルに追加データとしてメンバーテーブルに保存し、その他の情報をセカンダリテーブルに保存することもできます。
join_infos 現在のクラスタで結合されるセカンダリテーブルに関する情報を記述します。
join_field セカンダリテーブルを結合するために使用されるフィールド。プライマリテーブルのjoin_fieldには、次の制限があります。 a。join_fieldパラメータの値は、セカンダリテーブルの結合フィールドの値と同じである必要があります。 b。join_fieldには、単一の値のみを含めることができます。 c。join_fieldは、INTEGERおよびSTRINGタイプのみをサポートします。 d。セカンダリテーブルの主キーインデックスフィールドは、join_fieldである必要があります。
join_cluster 結合するセカンダリテーブルのクラスタ名。
strong_join 強結合機能を有効にするかどうかを指定します。セカンダリテーブルの属性は、クエリに必要です。ドキュメントが結合に失敗するか、セカンダリテーブルの主キーインデックスが結合属性を使用してクエリに失敗します。この場合、強結合機能が有効になっていると、ドキュメントは破棄されます。強結合機能が無効になっている場合、結合に失敗しても、ドキュメントはデフォルトで保持されます。
use_join_cache 結合docidキャッシュ機能を有効にするかどうかを指定します。結合docidキャッシュは、プライマリテーブルdocidとセカンダリテーブルdocid間のマッピングを指定します。マッピングは特別な属性と見なすことができ、ユーザーが使用できます。マッピングは、セカンダリテーブルのパフォーマンスを最適化するために使用されます。この機能が有効になっている場合、セカンダリテーブルの主キーをクエリする必要はありません。キャッシュからセカンダリテーブルのdocidを取得できます。V2.8以降では、join_clusterパラメータで指定された各クラスタに対してuse_join_cacheパラメータを設定できます。
check_cluster_config cluster_nameパラメータで指定されたクラスタのパスで設定ファイルを読み取るかどうかを指定します。この機能が有効になっている場合、設定ファイルはcluster_nameパラメータで指定されたクラスタのパスで読み取られます。機能が無効になっている場合、設定ファイルは読み取られず、table_nameパラメータの値はcluster_nameパラメータの名前で自動的に埋められます。デフォルト値：true。
例：
"join_config" : { // 結合設定
"join_infos" : [ // 結合情報
{
"join_field" : "company_id", // 結合フィールド
"join_cluster" : "company", // 結合クラスタ
"strong_join" : true, // 強結合
"use_join_cache" : true, // 結合キャッシュの使用
"check_cluster_config": true // クラスタ設定の確認
}
]
},aggregate_sampler_config
aggregate_sampler_configは、統計に関連するパラメータを設定するために使用されます。一般的な統計とバッチ統計の統計モードがサポートされています。aggBatchModeは、オプションの設定を識別するために使用されます。デフォルトモードは一般的な統計です。
一般的な統計を使用する場合、クエリされた各レコードは1つのクエリ結果としてカウントされます。パラメータ設定には、次の要素が含まれています。
"aggregate_sampler_config" : // 集計サンプラー設定
{
"aggThreshold" : 0, // 集計しきい値
"sampleStep" : 1 // サンプルステップ
}aggThresholdは、カウントされるレコードの最大数を指定します。カウントされるレコード数がしきい値よりも少ない場合、すべてのレコードがサンプリングされます。カウントされるレコード数がしきい値以上の場合、sampleStepパラメータはサンプリングされるレコード数を決定します。
sampleStepは、サンプリングするレコード数を指定します。
aggBatchModeパラメータがtrueに設定されている場合、クエリされたすべてのレコードが一度にカウントされます。次のサンプルコードは、設定の例を示しています。
"aggregate_sampler_config" : { // 集計サンプラー設定
"aggBatchMode" : true, // バッチモード
"aggThreshold" : 1000, // 集計しきい値
"batchSampleMaxCount" : 1000 // バッチサンプル最大数
}バッチ統計
aggThresholdは、レコードの最大数を指定します。totalhitsパラメータの値がaggThresholdパラメータの値以下の場合、クエリされたすべてのレコードがカウントされます。
totalhitsパラメータの値がaggThresholdパラメータの値よりも大きい場合、batchSampleMaxCountパラメータの値がサンプリングされたレコードの最大数として使用されます。この場合、ステップサイズは次の式に基づいて計算されます。（totalhits + batchSampleMaxCount-1）/ batchSampleMaxCount。
densemap機能
"aggregate_sampler_config" : { // 集計サンプラー設定
"enableDenseMode" : false // 密モードの有効化
}enableDenseModeパラメータの有効な値は、trueとfalseです。このパラメータを使用して、ビジネスパフォーマンスを向上させることができます。ビジネス要件に基づいて、このパラメータをtrueまたはfalseに設定できます。ビジネスシナリオでさまざまな値を持つgroupkeyパラメータを測定する場合は、enableDenseModeパラメータをtrueに設定できます。この操作は、パフォーマンスの向上に役立ちます。デフォルト値はfalseです。
注：このパラメータをtrueに設定する前に、ストレステストを実行してください。
table_name
テーブルの名前。テーブル名は、サーチャーからテーブルスキーマを取得するために使用されます。
rankprofile_config
rankprofile_configは、スコアリングプラグインを設定するために使用されます。プラグインのパラメータはオプションです。主な設定項目は、soプラグインの名前とスコアプラグインの名前に関連しています。
modules.module_name プラグインに使用されるモジュールの名前。
modules.module_path プラグインの動的リンクライブラリの名前。
modeles.parameters soプラグインに渡されるユーザー定義パラメータ。
rankprofiles.rank_profile_name rank_profileファイルの名前。クエリステートメントで使用するrank_profileファイルの名前を指定できます。
rankprofiles.score_name soプラグインのスコアプラグイン名。
rankprofiles.total_rank_size スコアプラグインでスコア付けできるドキュメントの最大数。partition_countで除算された値は、単一のパーティションでスコア付けできるドキュメントの数として使用されます。
例：
"rankprofile_config" : { // ランクプロファイル設定
"modules" : [ // モジュール
{
"module_name" : "fake_scorer", // モジュール名
"module_path" : "libfakescorer.so", // モジュールパス
"parameters" : { // パラメータ
"key" : "value" // キー
}
}
],
"rankprofiles" : [ // ランクプロファイル
{
"rank_profile_name": "DefaultProfile", // ランクプロファイル名
"scorers" : [ // スコアラー
{
"scorer_name" : "FakeScorer", // スコアラー名
"module_name" : "fake_scorer", // モジュール名
"parameters" : { // パラメータ
"key" : "value" // キー
},
"rank_size" : "300" // ランクサイズ
}
],
"field_boost" : { // フィールドブースト
"phrase.title" : 1000, // フレーズ.タイトル
"phrase.body" : 100 // フレーズ.本文
}
}
]
}summary_profile_config
required_attribute_fields サマリー結果のsummary_schemaに含まれていない属性フィールド。ほとんどの場合、このフィールドはセカンダリテーブルで使用されます。これは、セカンダリテーブルのフィールドがプライマリテーブルのクエリ結果に返されることを示します。
modules.module_name プラグインに使用されるモジュールの名前。
modules.module_path プラグインの動的リンクライブラリの名前。
modules.parameters soプラグインに渡されるユーザー定義パラメータ。
summary_profiles.summary_profile_name summary_profileファイルの名前。クエリステートメントで使用するsummary_profileファイルの名前を指定できます。
summary_profiles.extractors サマリーエクストラクター処理チェーンの設定。サマリーが抽出されると、すべてのエクストラクターが順番に処理されます。
summary_profiles.parameters summary_profileファイルに渡されるユーザー定義パラメータ。
summary_profiles.field_configs 作成するサマリーのフィールド定義。
summary_profiles.max_summary_length highlight_prefix サマリーの長さやキーワードを強調表示するかどうかなどの項目。
例：
"summary_profile_config" : { // サマリープロファイル設定
"required_attribute_fields" : ["aux_field1", "aux_field2", "attr_field"], // 必須属性フィールド1
"modules" : [ // モジュール
{
"module_name" : "ha3_summary_eg", // モジュール名
"module_path" : "libha3_summary_eg.so", // モジュールパス
"parameters" : { // パラメータ
"key" : "value" // キー
}
}
],
"summary_profiles" : [ // サマリープロファイル
{
"summary_profile_name": "DefaultProfile", // サマリープロファイル名
"extractors" :[ // エクストラクター
{
"extractor_name" : "SmartSummaryExtractor", // エクストラクター名
"module_name" : "ha3_summary_eg", // モジュール名
"parameters" : { // パラメータ
"key": "value" // キー
}
},
{
"extractor_name" : "DefaultSumamryExtractor", // エクストラクター名
"module_name" : "", // モジュール名
"parameters" : {} // パラメータ
}
],
"field_configs" : { // フィールド設定
"TITLE" : { // タイトル
"max_snippet" : 1, // 最大スニペット
"max_summary_length" : 40, // 最大サマリー長
"highlight_prefix": "<font color=red>", // 強調表示プレフィックス
"highlight_suffix": "</font>", // 強調表示サフィックス
"snippet_delimiter": "..." // スニペット区切り文字
},
"BODY" : { // 本文
"max_snippet" : 2, // 最大スニペット
"max_summary_length" : 100, // 最大サマリー長
"highlight_prefix": "<font color=red>", // 強調表示プレフィックス
"highlight_suffix": "</font>", // 強調表示サフィックス
"snippet_delimiter": "..." // スニペット区切り文字
}
}
}
]
}function_config
function_configは、クラスタで使用されるfunction_expressionプラグインに関する情報を指定するために使用されます。function_configのパラメータはオプションです。次のサンプルコードは、パラメータについて説明しています。
"function_config" : // 関数設定
{
"modules" : [ // モジュール
{
"module_name" : "func_module_name", // モジュール名
"module_path" : "libfunction_expression_plugin.so", // モジュールパス
"parameters" : // パラメータ
{
"config_path" : "pluginsConf/one_function.json" // 設定パス
}
}
]
}searcher_cache_config
サーチャーキャッシュは、フェーズ1クエリの結果をキャッシュするために使用されます。
"searcher_cache_config" : // サーチキャッシュ設定
{
"max_size" : 1024, /* M byte */ // 最大サイズ
"max_item_num" : 200000, // 最大アイテム数
"inc_doc_limit" : 1000, // 増分ドキュメント制限
"inc_deletion_percent" : 1, // 増分削除率
"latency_limit" : 1, /* ms */ // 遅延制限
"min_allowed_cache_doc_num" : 0, // 最小許容キャッシュドキュメント数
"max_allowed_cache_doc_num" : 50000 // 最大許容キャッシュドキュメント数
}max_size max_sizeは、サーチャーキャッシュの最大メモリ容量を指定します。単位：メガバイト（MB）。デフォルト値：1024。
max_item_num max_item_numは、サーチャーキャッシュが初期化されたときのキャッシュ内のアイテム数を指定します。キャッシュの最下層はハッシュテーブルです。max_item_numパラメータは、ハッシュテーブルを初期化するために使用されます。キャッシュ内の実際のアイテム数は、エンジンの実行時の実際のアイテムサイズとメモリ容量の制限に基づいて決定されます。max_item_numパラメータの値は、キャッシュ内のハッシュテーブルを初期化するためだけに使用されます。ほとんどの場合、このパラメータは空のままにすることができます。デフォルト値は200000です。
inc_doc_limit 増分データが必要で、クエリでサーチャーキャッシュ内のデータが必要な場合、キャッシュ内のクエリ結果と増分データ内のクエリ結果が結合されて返されます。増分データ内のクエリ結果は、最後にクエリがキャッシュにアクセスした後に追加されたドキュメントです。増分データでクエリされたドキュメント数がinc_doc_limitパラメータの値よりも大きい場合、キャッシュ内の現在のクエリの結果は無効になります。この場合、次回クエリが実行されると、クエリ結果はキャッシュに再度入力されます。デフォルト値：1000。
inc_deletion_percent 増分データが削除されると、キャッシュ内の一部のクエリドキュメントが削除または更新される場合があります。キャッシュ内のクエリドキュメントの合計数における無効なドキュメントの割合がinc_deletion_percent％パラメータで指定された値を超えると、キャッシュ内のクエリドキュメントは無効になります。クエリはキャッシュミスとして処理されます。クエリが再実行され、クエリ結果がキャッシュに入力されます。デフォルト値：1。
latency_limit サーチャーキャッシュは、次の条件を満たすクエリの結果のみをキャッシュします。（rank_latency + rerank_latency）> latency_limit。キャッシュされたクエリのレイテンシが高い場合は、キャッシュを使用してパフォーマンスを効果的に向上させることができます。単位：ms。デフォルト値：1。
min_allowed_cache_doc_numおよびmax_allowed_cache_doc_num min_allowed_cache_doc_numパラメータは、キャッシュできるクエリドキュメントの最小数を指定します。デフォルト値：0。max_allowed_cache_doc_numパラメータは、キャッシュできるクエリドキュメントの最大数を指定します。デフォルト値：std :: numeric_limits <uint32_t> :: max（）に対して返される値。パラメータは、特別なシナリオで多数のドキュメントをキャッシュする必要がある場合に使用されます。
service_degradation_config
service_degradation_configは、サービス低下を設定するために使用されます。サービスでエラーが発生した場合、またはトラフィックの急増が発生した場合、このパラメータを使用してシステムの安定性を確保できます。次のサンプルコードは、service_degradation_configを設定する方法の例を示しています。
"service_degradation_config" : // サービス低下設定
{
" condition" : { // 条件
"worker_queue_size_degrade_threshold" : 100, // ワーカキューサイズ低下しきい値
"worker_queue_size_recover_threshold" : 10, // ワーカキューサイズ回復しきい値
"duration" : 1000 // 期間
},
"request" : { // リクエスト
"rank_size" : 5000, // ランクサイズ
"rerank_size" : 200 // 再ランクサイズ
}
}サービス低下を実装するには、サービス低下のチェック基準とサービス低下中に実行する操作に関連するパラメータを設定します。
チェック基準：現在のワーカーの作業キューの長さは、サービス低下を実行するかどうかを判断するために使用されます。作業キューの長さがdurationパラメータで指定された期間、worker_queue_size_degrade_thresholdパラメータの値以上である場合、サービスは低下状態になります。低下状態では、長さがdurationパラメータで指定された期間、worker_queue_size_recover_thresholdパラメータで指定された値よりも小さい場合、サービスは低下状態を終了します。durationパラメータの値はミリ秒単位です。サービスが低下状態にあるときにキューの長さがworker_queue_size_recover_thresholdパラメータの値よりも小さい場合、クエリは低下しません。このようにして、キューの長さはworker_queue_size_recover_thresholdパラメータの値に基づいて変動します。
サービス低下の対策：リクエストのrank_sizeおよびrerank_sizeパラメータの値のみを変更できます。rank_sizeは、おおよそソートされたドキュメントの数を指定します。rerank_sizeは、細かくソートされたドキュメントの数を指定します。rank_serviceアーキテクチャでは、rank_sizeパラメータのみが有効になります。
multi_call_config
次のサンプルコードは、V3.2.0より前のバージョンのHavenaskのフロー制御設定の例を示しています。V3.2.0以降のバージョンのHavenaskでは、フロー制御ロジックが大幅に変更され、anomaly_process_configフィールドがmulti_call_configフィールドに変更されています。
"multi_call_config" : { // マルチコール設定
"probe_percent" : 0.3, // プローブ率
"latency_upper_limit_percent" : 0.4, // 遅延上限率
"begin_degrade_latency" : 100, // 低下開始遅延
"full_degrade_latency" : 150, // 完全低下遅延
"et_trigger_percent" : 0.8, // 早期終了トリガー率
"et_wait_time_factor" : 5, // 早期終了待機時間係数
"et_min_wait_time" : 30, // 早期終了最小待機時間
"retry_trigger_percent" : 0.6, // 再試行トリガー率
"retry_wait_time_factor" : 3 // 再試行待機時間係数
}設定項目の詳細については、gigドキュメントを参照してください。次のセクションでは、V3.2.0より前のバージョンのHavenaskのmulti_call_configのパラメータについて説明します。 各クラスタのサービスの安定性を確保するための設定を行うことができます。次のコードは、サービスの安定性を確保するために使用できるパラメータ設定の例を示しています。
"anomaly_process_config" : // 異常処理設定
{
"flowControlEnabled" : true, // フロー制御有効
"earlyTerminationEnabled" : true, // 早期終了有効
"retryQueryEnabled" : true, // 再試行クエリ有効
"flowControl" : { // フロー制御
"sample_interval" : 100, // サンプル間隔
"min_sample_count" : 10, // 最小サンプル数
"heavy_load_arpc_error_ratio" : 0.5, // 高負荷ARPCエラー率
"light_load_arpc_error_ratio" : 0, // 低負荷ARPCエラー率
"max_flow_redirect" : 1, // 最大フローリダイレクト
"queue_size_threshold" : 5, // キューサイズしきい値
"flow_control_categories" : [1,2,3,4,5,6,7,8,9,10,11] // フロー制御カテゴリ
},
"detection" : { // 検出
"early_termination_trigger_result_percent" : 0.8, // 早期終了トリガー結果率
"early_termination_wait_time_factor" : 3, // 早期終了待機時間係数
"retry_query_trigger_result_percent" : 0.8, // 再試行クエリトリガー結果率
"retry_query_wait_time_factor" : 1 // 再試行クエリ待機時間係数
}
}flowControlEnabledは、フロー制御を有効にするかどうかを指定します。
earlyTerminationEnabledは、クエリプロセスを事前に終了するかどうかを指定します。
retryQueryEnabledは、クエリを再試行するかどうかを指定します。
flowControlは、フロー制御の設定を指定します。flowControlには、サーチャーのヘルスステータスを監視するために使用されるパラメータが含まれています。
ヘルスステータスが更新される間隔。単位：ms。
サンプリングする必要のあるクエリの最小数。このパラメータは、発生するARPCエラーの割合を決定するために使用されます。指定された間隔の後、最新のヘルスステータスを評価するのに十分なクエリがない場合は、クエリ数が十分になるまで待ちます。
ARPCクエリエラーの数がheavy_load_arpc_error_ratioパラメータの値よりも大きい場合、サーチャーのヘルスステータスを低下させる必要があります。
ARPCクエリエラーの数がlight_load_arpc_error_ratioパラメータの値よりも小さい場合、サーチャーのヘルスステータスを向上させる必要があります。
max_flow_redirectは、システムが見つけることができるバックアップサーチャーの最大数を指定します。列内のあるサーチャーがデータを処理できない場合、そのサーチャー内の一部のトラフィックは同じ列内の他のサーチャーに分散されます。同じ列内の複数のサーチャーノードから正常なサーチャーノードが見つからない場合、クエリリクエストは失われます。
queue_sizeは、各クエリがサーチャーノードから取得するサーチャーキューの長さを指定します。QRSまたはプロキシは、サーチャーキューの長さに従ってサーチャーのヘルスステータスを更新します。ヘルスステータスを変更する前に、条件を満たす必要があります。ヘルスステータスには11のレベルがあります。ヘルスステータスの各レベルの更新条件は異なります。この例では、queue_size_thresholdパラメータの値は5であり、ヘルスステータスが更新されるキューの長さに対応する配列はq = [5,10,15,20,25,30,35,40,45,50,55]です。サーチャーのヘルスステータスレベルは、次の条件が満たされたときに低下します。queue_size> = q [10-H_c + 1]。サーチャーのヘルスステータスレベルは、次の条件が満たされたときに上昇します。queue_size <q [10-H_c]。queue_size <q [10-H_c]では、H_cはサーチャーのヘルスステータスレベルが0 <= H_c <= 10の範囲内であることを指定します。
ヘルスステータスが更新されるキューの長さは、配列の高度な制御設定項目に対応しています。<10>は、線形展開に使用される単純な設定方法です。配列が設定されると、<10>は上書きされます。
early_termination_trigger_result_percentは、クエリを事前に終了する場合にドキュメント数が必要かどうかを指定します。たとえば、列10のデータがクエリされる前に列8の必要なデータが返された場合、クエリ結果は事前にチェックされます。
early_termination_wait_time_factorは、クエリが事前に終了されるまでの時間を指定します。システムがクエリを事前に終了するまでの待機時間はtです。3tの待機時間を指定しても、3t後にクエリが完了しない場合、システムはクエリを事前に終了し、結果を返します。このパラメータで指定された時間内にクエリが完了した場合、結果は期待どおりに返されます。tは、最初に期待されるドキュメントを返すために必要な時間です。
retry_query_trigger_result_percentは、システムがクエリ再試行が必要かどうかをチェックするときに必要なドキュメント数を指定します。たとえば、列10のデータがクエリされる前に列8の必要なデータが返された場合、システムはクエリ再試行が必要かどうかをチェックします。
クエリが再試行されるまでの時間を設定します。たとえば、クエリ再試行がトリガーされるまでの待機時間はTです。Tを待ってクエリ結果が不完全な場合、クエリリクエストは同じ列内の別のサーチャーに送信されます。このパラメータで指定された時間内にクエリが完了した場合、結果は期待どおりに返されます。tは、最初に期待されるドキュメントを返すために必要な時間です。
cava_config
cava_configは、Havenaskの高度な言語スクリプトを設定するために使用されます。Havenaskは、プラグインを作成できるようにcavaスクリプトを提供します。次のサンプルコードは、cava_configのパラメータ設定の例を示しています。
"cava_config" : { // cava設定
"enable" : true, // 有効化 (1)
"ha3_cava_conf" : "../binary/usr/local/etc/cava/config/cava_config.json", // cava設定ファイルパス (2)
"lib_path" : "cava/lib", // ライブラリパス (3)
"source_path" : "cava/src", // ソースパス (4)
"code_cache_path" : "cava/cache", // コードキャッシュパス (5)
"pool_trunk_size" : 10, //MB プールトランクサイズ (6)
"pool_recycle_size_limit" : 20, //MB プールリサイクルサイズ制限 (7)
"alloc_size_limit" : 40, //MB 割り当てサイズ制限 (8)
"init_size_limit" : 1024, //MB 初期サイズ制限 (9)
"module_cache_size" : 100000 // モジュールキャッシュサイズ (10)
}（1）cava機能を有効にするかどうかを指定します。
（2）cava言語。
（3）プラットフォームによって提供されるパブリックライブラリ。この値は、UPC言語を使用してコードをコンパイルする場合に有効になります。
（4）サービスプロバイダーのカスタムプラグイン。プラットフォームによって提供されるパブリックライブラリは、プラグインで再利用できます。この値は、UPC言語を使用してコードをコンパイルする場合に有効になります。
（5）事前にコードキャッシュにコンパイルされたプラグインコード。プラグインコードは常に有効であり、他のユーザーはコードを引用できません。
（6）cavaメモリプールのtrunk_sizeパラメータの値。デフォルト値：10 MB。デフォルト値は変更できません。
（7）cavaメモリプールのrecycle_sizeパラメータの値。デフォルト値：20 MB。デフォルト値は変更できません。
（8）cavaクエリレベルに割り当てることができる最大メモリ容量。
（9）cavaの最大メモリ容量。メモリ容量には、cavaクエリレベルに割り当てられたメモリリソースは含まれません。
（10）キャッシュクエリに渡されるソースコードブロックの最大数。しきい値を超えると、Least Recently Used（LRU）アルゴリズムが使用されます。
cavaに関する情報は、別のトピックで説明します。
turing_options_config
turing_options_configを使用して、グラフ関連の設定を上書きできます。次のセクションでは、turing_options_configの設定例を示します。
"turing_options_config":{ // チューリングオプション設定 "graph_config_path": “ssss”, // グラフのパス "dependency_table":["a","b"] // 依存関係テーブル }