mcpField
M
mongodb-qe-size-estimation

mongodb-qe-size-estimation

github.com/mongodbデータ・データベース192306 回インストール1 週間前に更新
リポジトリ

mongodb-qe-size-estimation について

暗号化フィールドの設定から、MongoDB Queryable Encryption による最大ストレージ影響を見積もるスキルです。質問形式で手動入力または暗号化スキーマを受け取り、計算内容を一時ファイルに記録します。

主な機能

  1. 01暗号化フィールドとクエリ型の検証
  2. 02手動入力または暗号化スキーマに対応
  3. 03ドキュメント数とフィールド情報の収集
  4. 04ストレージとメモリの見積もり
  5. 05計算内容を一時ファイルに保存

活用シーン

  1. 01Queryable Encryption 導入前のストレージ影響の見積もり
  2. 02暗号化スキーマのクエリ設定の確認
  3. 03フィールドごとの容量計算の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mongodb/agent-skills --skill mongodb-qe-size-estimation

インストール後、Claude Code で/mongodb-qe-size-estimationを入力して読み込まれたか確認します。

詳細

mongodb-qe-size-estimation

全般的な指示

  • 重要:サンプルデータを求めたり、受け取ったりしないでください。 QE は機密情報を保護するための暗号化機能です。サンプルデータを要求しないでください。提供された場合も、セキュリティ上の理由から受け取りを拒否してください。サンプルドキュメントは受け取れないことをユーザーに伝えてください。ただし、どのフィールドが暗号化されるか、クエリが可能かどうか、クエリ設定はどうなっているかを確認するために、暗号化スキーマを入力として受け取ることはできます。
  • (LLM Note: ) 形式の括弧書きは、LLM 用です。qe-sizing-calculations.md に保存したり、ユーザーに伝えたりしないでください。
  • トーン:簡潔にし、会話調にしないでください。手順で特に指示されていない限り、以前のやり取りの情報を繰り返さないでください。
  • 手順で指定された内容以外は、ファイルに書き込まないでください。
  • このスキルでは、必要な入力をすべて得るために質疑応答フローを使用します。ステップ 2~5 では、ユーザーが有効な入力を提供している限り、応答に入力の確認と次の質問の両方を含めてください。
  • ユーザーが複数の入力をまとめて送信し、処理を進めようとする場合があります。入力がフィールドとその設定に明確に対応していない場合は、確認を求めてください。それ以外の場合は、入力を検証し、有効であれば受け入れてください。
  • このスキルには現在、範囲クエリ用の計算式がありません。そのため、互換性のある BSON 型の「range」クエリ設定は受け入れますが、推定値には 0 を使用します。
定義
  • フィールド このスキルでは、「フィールド」は QE 対応コレクション内の MongoDB ドキュメントにある暗号化フィールドを指します。
  • エントリ インデックスのないフィールドの場合は、フィールド名を指します。1 つ以上のクエリタイプが有効になっているフィールドの場合は、フィールド名と有効なクエリタイプの組み合わせを指します。prefix クエリと suffix クエリの両方が有効になっているフィールドは、「Query Type」が「prefix and suffix」の単一のエントリになります。
  • インデックスなし クエリタイプが有効になっていないフィールドの状態を指します。暗号化スキーマを使用している場合は、「queries」キーがないことで示されます。
  • インデックスあり クエリが有効になっているフィールドの状態を指し、クエリタイプごとに異なります。equality クエリが有効になっているフィールドには、equality クエリ用のインデックスがあります。
検証

ユーザーの入力が手動入力か暗号化スキーマ経由かを問わず、以下に照らして検証してください。

暗号化フィールドは、クエリタイプが有効になっていない「インデックスなし」の状態にできます。BSON 型が object または array のフィールドは、インデックスなしの暗号化のみをサポートします。ただし、ほかの BSON 型もインデックスなしにできます。それ以外の場合、フィールドの BSON 型に応じて、次のクエリタイプが許可されます。

  • 「equality」:object、array、decimal、double 以外の任意の BSON 型
  • 「range」:int、long、date、decimal、double
  • 「prefix」、「suffix」、「substring」:string のみ

string フィールドでは、「prefix」と「suffix」の両方を有効にできます。この場合、「queries」は 2 つのオブジェクトを含む配列にできます。1 つのフィールドに複数のクエリタイプのインデックスを設定できる有効なケースは、これだけです。

これ以外の BSON 型とクエリタイプの組み合わせは許可されません。

「suffixPreview」などの「preview」クエリタイプは受け入れないでください。これらは該当するクエリタイプの以前の Public Preview リリースに由来するため、GA バージョンのサイズ計算式は適用できません。

ユーザーの入力が上記のルールに違反している場合は、拒否してください。ユーザーが BSON 型を指定していない場合は、各フィールドでクエリタイプが未設定、有効なクエリタイプが 1 つだけ、または(prefix と suffix の)2 つだけであることのみを確認してください。検証エラーを列挙し、許可される組み合わせを示してから、ユーザーが有効な入力を提供するまで先に進まないでください。

手順

1. 作業ディレクトリの準備

OS の一時ディレクトリ($TMPDIR。未設定の場合は /tmp)に、空の qe-sizing-calculations.md ファイルを作成します。その場所に qe-sizing-calculations.md ファイルがすでに存在する場合は、ユーザーにその旨を伝え、削除して新しい計算用のファイルを作成してよいか確認してください。

2. 目的と入力方法を伝える

次のように伝えます。「このスキルは、コレクションで Queryable Encryption を有効にした場合のストレージへの最大影響を計算します。計算を確認したり、フィールドごとの数値を確認したりする場合は、値が ファイルに保存されます。暗号化フィールドに対するプレフィックス、サフィックス、部分文字列クエリには MongoDB 9.0 が必要で、それ以前のバージョンではサポートされていないことに注意してください。

すべての値は最悪のケースを想定しています。実際には、ストレージやメモリへの影響がこれより小さくなる場合があります。

フィールド情報を手動で入力しますか、それとも暗号化スキーマファイルを使いますか?」

ユーザーが暗号化スキーマを選択した場合は、貼り付けた内容またはファイルパスのいずれかでスキーマを提示するよう依頼し、JSON 形式であることを前提とします。このスキルの「Validation」セクションに従ってスキーマを検証します。スキーマが有効で、「range」クエリが有効になっているフィールドを含む場合、それらのフィールドは計算できないため、影響を 0 として推定することをユーザーに伝えます。

3. ドキュメント数を取得する

コレクション内で暗号化フィールドを持つドキュメントの数をユーザーに尋ねます。不明な場合は、コレクション内のドキュメントの合計数を安全なデフォルト値とします。この値を qe-sizing-calculations.md に次のように保存します。

N:

4. エントリ数を取得する

  • ユーザーが手動入力を選んだ場合は、クエリを有効にせずに暗号化するフィールドの数を尋ねます。
  • ユーザーが暗号化スキーマを選んだ場合は、クエリが有効になっていない暗号化フィールドの数を数えます。

この値を qe-sizing-calculations.md に次のように保存します。

numUnindexed:

  • ユーザーが手動入力を選んだ場合は、クエリが有効になっている暗号化フィールドの数を尋ねます。
  • ユーザーが暗号化スキーマを選んだ場合は、クエリが有効になっているフィールドの数を数えます。

この値を qe-sizing-calculations.md に次のように保存します。

numIndexed:

numUnindexed と numIndexed の合計を qe-sizing-calculations.md に次のように保存します。

numEntries:

5. フィールドごとの入力を取得する

qe-sizing-calculations.md に次の見出しを書き込みます。

== FIELD VALUES ==============================================================

情報を取得したら、該当しない行を省略して、次の形式で qe-sizing-calculations.md に書き込みます。インデックス化されていないフィールドの場合は、Query Type を省略します。

<ユーザーが提示した名前、または暗号化スキーマから取得したドット記法の「path」値> Query Type: <equality、range、prefix、suffix、substring、または「prefix and suffix」> mlen: <Query Type が substring の場合に含めます。2~50 の整数(両端を含む)> lb: <Query Type が「prefix」、「suffix」、または「substring」の場合に含めます。prefix と suffix のクエリでは 1 以上の整数、substring クエリでは 2 以上の整数> ub: <Query Type が「prefix」、「suffix」、または「substring」の場合に含めます。prefix と suffix のクエリでは 1 以上の整数、substring クエリでは 2~6 の整数> lb_prefix: <Query Type が「prefix and suffix」の場合に含めます。1 以上の整数> ub_prefix: <Query Type が「prefix and suffix」の場合に含めます。1 以上の整数> lb_suffix: <Query Type が「prefix and suffix」の場合に含めます。1 以上の整数> ub_suffix: <Query Type が「prefix and suffix」の場合に含めます。1 以上の整数> v: <Query Type が range の場合は省略し、それ以外の場合は含めます。フィールドの暗号化前の値の平均バイト長を表す整数>

  • ユーザーが暗号化スキーマを指定した場合は、次の処理を一度だけ行います。

    • インデックス化されていないフィールドごとに、qe-sizing-calculations.md にエントリーを1つ追加します。「Query Type」の行は省略してください。
    • フィールドで prefix クエリと suffix クエリの両方が有効になっている場合は、順序にかかわらず、「Query Type」に「prefix and suffix」と記入します。
    • クエリが有効になっているフィールドごとにエントリーを1つ追加します。各「queries」オブジェクトのキーは、次のようにフィールド値に対応させ、記載のないキーはすべて省略します。
      • strMaxLength(substring のみ)-> mlen
      • strMinQueryLength -> フィールドにクエリタイプが1つだけある場合は lb。フィールドで prefix クエリと suffix クエリの両方が有効になっている場合、prefix クエリの strMinQueryLength は lb_prefix、suffix クエリの strMinQueryLength は lb_suffix とします。
      • strMaxQueryLength -> フィールドにクエリタイプが1つだけある場合は ub。フィールドで prefix クエリと suffix クエリの両方が有効になっている場合、prefix クエリの strMaxQueryLength は ub_prefix、suffix クエリの strMaxQueryLength は ub_suffix とします。
  • ユーザーが暗号化スキーマを指定しなかった場合は、フィールドごとに次の処理を行います。

    • ユーザーがフィールドの BSON 型を指定した場合に限り、許可されているクエリタイプに対して BSON 型を検証します。それ以外の場合は、フィールドの BSON 型を尋ねたり、検証したりしないでください。
    • フィールド名と、そのフィールドがインデックス化されていないか、クエリが有効になっているかを尋ねます(LLM メモ:クエリタイプがある場合、有効な選択肢は「equality」、「range」、「prefix」、「suffix」、「substring」、「prefix and suffix」です。それ以外の値や組み合わせは拒否してください。ユーザーが「range」を指定した場合は、計算式がないことを警告してください)。
    • prefix クエリと suffix クエリの両方が有効なフィールドについて、ユーザーが下限値と上限値をそれぞれ1つだけ指定した場合、その下限値を lb_prefix と lb_suffix の両方に、その上限値を ub_prefix と ub_suffix の両方に使用します。
    • 入力を検証します。

フィールドごとに次の処理を行います。

以下のリストを確認し、まだ入力されていない値をユーザーに尋ねます。すべての値を qe-sizing-calculations.md ファイルに記入します。

mlen: (LLM メモ:スキーマが指定されておらず、Query Type が substring の場合に限り記入)最大長。文字列の許容最大長です。 lb: (LLM メモ:スキーマが指定されておらず、Query Type が「prefix」、「suffix」、または「substring」の場合に限り記入)下限。検索可能な文字数の最小値です。 ub: (LLM メモ:スキーマが指定されておらず、Query Type が「prefix」、「suffix」、または「substring」の場合に限り記入)上限。検索可能な文字数の最大値です。 lb_prefix: (LLM メモ:スキーマが指定されておらず、Query Type が「prefix and suffix」の場合に限り記入)prefix クエリの下限。検索可能な文字数の最小値です。 ub_prefix: (LLM メモ:スキーマが指定されておらず、Query Type が「prefix and suffix」の場合に限り記入)prefix クエリの上限。検索可能な文字数の最大値です。 lb_suffix: (LLM メモ:スキーマが指定されておらず、Query Type が「prefix and suffix」の場合に限り記入)suffix クエリの下限。検索可能な文字数の最小値です。 ub_suffix: (LLM メモ:スキーマが指定されておらず、Query Type が「prefix and suffix」の場合に限り記入)suffix クエリの上限。検索可能な文字数の最大値です。 v: (LLM メモ:Query Type が range の場合はスキップしてください。これ以外の場合はフィールドごとに1つ必要です。)フィールドの暗号化されていない値の平均バイト長です。ユーザーが文字数を指定した場合は、同等の値として受け入れてください。

このステップの冒頭にある書式例に照らして値を検証します。lb ≤ ub ≤ mlen(mlen がある場合)を検証します。lb_prefix ≤ ub_prefix と lb_suffix ≤ ub_suffix(該当する場合)を検証します。値が許容範囲外の場合は、その値を拒否し、ユーザーに伝えてください。有効な値が得られるまで先に進まないでください。

mlen < v の場合は、フィールド値全体をクエリできないことをユーザーに警告します。ただし、有効な値として受け入れてください。

qe-sizing-calculations.md のエントリー数が numEntries に達するまで繰り返します。

6. 数式と結果を qe-sizing-calculations.md に追加する

この手順では、中間ステップを含む計算情報をファイルに追加します。

qe-sizing-calculations.md の各エントリーについて、次の作業を行います。

  1. qe-sizing-calculations.md の FIELD VALUES セクションにある既存の各エントリーに、次の行を追加します。問題が連鎖的に発生するのを防ぐため、数式のテンプレートは正確にコピーすることが重要です。計算を実行する際は、利用可能な数式解析ツールを使い、演算の順序が正しいことを確認してください。
  • Query Type がないフィールドの場合:

    T: 0 Document Storage (bytes): <計算を実行:71 + ceil((v+6)/16) * 16>

  • Query Type が "equality" のフィールドの場合:

    T: 1 Document Storage (bytes): <計算を実行:1.2 * (255 * T + 122 + ceil((v + 6) / 16) * 16)>

  • Query Type が "range" のフィールドの場合、現在は数式がないため、値を 0 として記録します:

    T: 0 Document Storage (bytes): 0

  • Query Type が "prefix" または "suffix" のフィールドの場合:

    T formula: T = 1 + (ub - lb + 1) T calculation: <T の数式テンプレートにフィールドの値をすべて代入します。ただし、計算は実行しません> T: <"T calculation" の計算を実行し、結果をここに記入> Document Storage (bytes): <計算を実行:1.2 * (255 * T + 122 + ceil((v + 6) / 16) * 16)>

  • Query Type が "prefix and suffix" のフィールドの場合:

    T formula: T = 1 + (ub_prefix - lb_prefix + 1) + (ub_suffix - lb_suffix + 1) T calculation: <T の数式テンプレートにフィールドの値をすべて代入します。ただし、計算は実行しません> T: <"T calculation" の計算を実行し、結果をここに記入> Document Storage (bytes): <計算を実行:1.2 * (255 * T + 122 + ceil((v + 6) / 16) * 16)>

  • Query Type が "substring" のフィールドの場合:

    T formula: T = 1 + (ub - lb + 1) * (2 * mlen + 2 - ub - lb) / 2 T calculation: <T の数式テンプレートにフィールドの値をすべて代入します。ただし、計算は実行しません> T: <"T calculation" の計算を実行し、結果をここに記入> Document Storage (bytes): <計算を実行:1.2 * (255 * T + 122 + ceil((v + 6) / 16) * 16)>

  1. 追加した情報について、正しい T の数式または固定値と、T calculation の正しい値が使われていることを、サイレント監査で確認してから次に進みます。

7. インデックスストレージ、合計ディスクストレージ、メモリを計算する

これらの値はコレクション単位で、すべてのエントリーの合計として計算します。

qe-sizing-calculations.md ファイルの末尾に、次の行をサイレントに記述します。

== COLLECTION-LEVEL TOTALS ==================================================== N: <ファイルの先頭にある N の値を、このセクションにもコピーして参照しやすくします> T_Total: <すべての T 値の合計> Index Storage (bytes): <計算を実行:1.2 * (67 * T_Total + 640)> Total Disk Storage (bytes): <計算を実行:N * (Index Storage + (すべての Document Storage 値の合計))> Memory (bytes): <計算を実行:N * (52 * T_Total + 17)>

8. 結果を合計して結論を報告する

次の内容を出力し、単位も含めてください。

Total Disk Storage Impact: <qe-sizing-calculations.md の Total Disk Storage 値を、10 進 GB(1000³ bytes)に変換> Required Memory: <qe-sizing-calculations.md の Memory 値を、2 進 GiB(1024³ bytes)に変換> Fields by Impact (descending): <qe-sizing-calculations.md のすべてのフィールドを T の降順に並べ、次の形式で一覧表示:Name (<Query Type または unindexed のいずれか>): T>

暗号化スキーマまたは手動入力に range クエリが有効なフィールドが含まれている場合は、それらのフィールドを一覧表示し、影響が計算されていないことをユーザーに伝えてください。

9. 結果の解釈

アドバイスを提示します。フィールドで部分文字列クエリを許可する必要があるとユーザーが主張している場合に、別のクエリタイプを提案するなど、ユーザーが明示的に拒否したアドバイスは提供しないでください。問題点のみを指摘し、すべてのチェックに合格している項目には言及しないでください。値を特定の数値に変更することを提案する場合は、そのクエリタイプ用の Step 6 T 数式テンプレートに提案値を入力し、利用可能な数学ツールで計算して、その結果のみを引用してください。

  • (LLM への注意:部分文字列クエリが有効なフィールドの数が floor(50 million/N) より大きい場合にのみ、このチェックを実行してください。正確な計算を行うため、利用可能な数式解析ツールを使用してください。)部分文字列クエリが可能なフィールドの数を、次の値以下に制限するようユーザーに伝えてください:floor(50 million/)。5,000 万件を超えるドキュメントを含むコレクションでは、部分文字列クエリを使用しないよう伝えてください。
  • (LLM への注意:部分文字列クエリが可能なフィールドが1つ以上ある場合にのみ、このチェックを実行してください。)部分文字列インデックス付きフィールドが、代わりにプレフィックスクエリやサフィックスクエリに適している可能性があるかを確認し、その旨をユーザーに提案してください。たとえば、暗号化された「name」フィールドに対するクエリでは、部分文字列クエリの代わりにプレフィックスクエリを使用できることがよくあります。ただし、ハイフンでつながれた姓などのケースには不都合が生じる可能性があります。
  • (LLM への注意:これらの提案がユーザーの入力に当てはまり、変更後の値が許容範囲を超えない場合にのみ提案してください。)lb を上げる、ub を下げる、または mlen の値を下げることを検討するようユーザーに伝えてください。

また、qe-sizing-calculations.md ファイルのパスをユーザーに伝え、データを確認するか、一時ファイルを削除するか尋ねてください。一時ファイルには暗号化されたフィールドの名前と、平文の平均長が含まれていることを伝え、作業が終わったら削除するよう念を押してください。

コメント