AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu

検索とベクトル検索のリソースの計画とサイズ設定

このページでは、KubernetesクラスターでMongoDB Searchおよびベクトル検索を提供するmongotポッドのサイズ設定方法について説明します。MongoDBSearchリソースのspec.clusters[].resourceRequirementsspec.clusters[].jvmFlags、およびspec.clusters[].persistenceの初期値を選択するため、またインデックスの増加に対応する永続ボリュームのキャパシティーを計画するためにこれを使用します。

mongot のサイズを決定する前に、実行する配置モデルとトポロジーを検討してください。

このページで参照されている各設定の完全なスキーマについては、「MongoDB Search とベクトル検索の設定」を参照してください。

割り当てる CPU とメモリの比率は、検索ワークロード プロファイルによって異なります。

ワークロード クラス
RAM 対 CPU 比
使用する場合

高 CPU

2:1

クエリのパフォーマンスが CPU に大きく依存する多目的の全文検索を実行します。

低 CPU

8:1

データボリュームが小さい場合は、ベクトル検索ワークロードを実行します。この場合は、純粋な CPU よりもメモリの方が重要になります。

ほとんどの一般的なユースケースでは、小または中程度の High-CPU 構成がバランスの取れた開始点となります。

予想されるベクトル データボリューム(低 CPU)または 1 秒あたりのクエリ(高 CPU)に応じて、mongot ポッドのサイズを設定します。

サイズ
低 CPU (ベクトル検索)
高 CPU (全文)

最大 10 GB のベクトル

20 から 40 QPS、軽いインデックスの作成

平均

10 GB から 50 GB のベクトル

80 から 160 QPS

50 GB 以上のベクトル

320 から 480 QPS、重いインデックスの作成

例えば、全文検索アプリケーションで 100 クエリ/秒を取り扱うことが予想される場合は、中高 CPU 構成から開始します。

spec.clusters[].resourceRequirementsmongot ポッドの CPU とメモリを設定します。requests フィールドはノード上のキャパシティーを予約し、limits フィールドはポッドが消費できる量に上限を設定します。

spec:
clusters:
- resourceRequirements:
requests:
cpu: "2"
memory: 4Gi
limits:
cpu: "3"
memory: 5Gi

spec.clusters[].resourceRequirements を省略すると、Kubernetes 演算子は次のデフォルトを使用します。

  • requests.cpu: 2

  • requests.memory: 4Gi

  • limits はありません。ノードの使用可能なリソースをすべてポッドで消費できます。

limits をワークロードに合わせて設定します。制限のないポッドはノードを飽和させ、他のワークロードに影響を与える可能性があります。

spec.clusters[].jvmFlags-Xms または -Xmx を指定しない場合、Kubernetes Operator は両方のフラグを spec.clusters[].resourceRequirements.requests.memory の半分に設定することで JVM ヒープを自動計算します。

ヒープを明示的に上書きするには、spec.clusters[].jvmFlags-Xms-Xmx を設定します。Kubernetes Operator は、提供されたフラグを変更せず、演算子によって計算されたフラグの後に追加します。

spec:
clusters:
- jvmFlags:
- -Xms2g
- -Xmx2g

mongot ポッドには、検索インデックスとベクトルインデックスを保持する固定ボリュームがあります。インデックスと再構築用のヘッドルームを保持するボリュームを計画します。

コレクションのサイズと、その結果となる検索インデックスのサイズは、常に相関するわけではありません。インデックスのサイズは、マップするフィールドと、インデックスで有効にする機能(オートコンプリートなど)によって異なります。ワークロードのインデックスサイズを見積もるには、次の手順で行います。

1

1 から 2 GB のデータを挿入するか、$out. を使用して小規模なコレクションを作成します。

2

本番で使用する予定のフィールド マッピングを使用して検索インデックスを作成します。

3

インデックスのサイズをコレクションのサイズと比較します。この比率から外挿して、プロダクション スケールでのインデックス サイズを見積もります。例えば、1 GB のコレクションが 250 MB のインデックス (比率 0.25:1) を生成する場合、12 GB のコレクションは約 3 GB のインデックスを生成します。

インデックスに必要なdouble のディスクスペースを割り当てます。余計なスペースにより、mongot に必要に応じてインデックスを再構築することができます。ディスク使用量が 90% に達すると、mongot は読み取り専用になります。

バイナリ数量接尾辞を使用して、spec.clusters[].persistence.single.storage でボリュームサイズを設定します。

spec:
clusters:
- persistence:
single:
storage: 60Gi
storageClass: local-nvme

spec.clusters[].persistence を省略すると、Kubernetes Operator はデフォルトで 16 GB のボリュームをプロビジョニングします。30 GB インデックスの場合は、インデックスの再構築のためにスペースを確保するため、spec.clusters[].persistence.single.storage60Gi に設定します。

spec.clusters[].persistence.single.storageClass内のボリュームについてはStorageClassを参照してください。以下のガイダンスを満たすクラスを選択してください:

  • ディスクの種類: 多目的 SSD バックのストレージを使用します。読み取りと書き込みの両方の IOPS は mongot のパフォーマンスにとって重要です。レプリケーションには新しいインデックス セグメントのディスク書き込みと、mongot が古いセグメントをより大きなセグメントにマージする際のディスク読み取りが含まれます。

  • 読み取り専用スレッショルド: ボリュームの使用率が90%に達すると、mongotは読み取り専用モードに切り替わり、書き込み操作を停止します。書き込みを再開するには、使用率を85%未満にするため、インデックスデータを削除します。

配置後、初期のサイジングが適切であるかを確認し、いつ増やすべきかを知るために、以下のしきい値をモニターしてください。

Resource
しきい値
アクション

CPU

80% を超える使用率が続いている

spec.clusters[].resourceRequirements.requestslimits の CPU を増やします。

メモリ

mongot_system_process_majorPageFaults_operations 1 秒あたり 1000 を超えて維持

spec.clusters[].resourceRequirements.requestsのメモリとspec.clusters[].jvmFlagsのJVMヒープを増やします。

Disk

90% を超える使用率

インデックスサイズを小さくして、使用量をスレッショル値未満にします。mongot はこのスレッショル値で読み取り専用になります。