このページでは、KubernetesクラスターでMongoDB Searchおよびベクトル検索を提供するmongotポッドのサイズ設定方法について説明します。MongoDBSearchリソースのspec.clusters[].resourceRequirements、spec.clusters[].jvmFlags、およびspec.clusters[].persistenceの初期値を選択するため、またインデックスの増加に対応する永続ボリュームのキャパシティーを計画するためにこれを使用します。
mongot のサイズを決定する前に、実行する配置モデルとトポロジーを検討してください。
MongoDB Search 配置モデルについては、MongoDB Search アーキテクチャーを参照してください。
ベクトル検索配置モデルについては、MongoDB ベクトル検索アーキテクチャを参照してください。
このページで参照されている各設定の完全なスキーマについては、「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 構成から開始します。
CPU とメモリを構成する
spec.clusters[].resourceRequirements で mongot ポッドの CPU とメモリを設定します。requests フィールドはノード上のキャパシティーを予約し、limits フィールドはポッドが消費できる量に上限を設定します。
spec: clusters: - resourceRequirements: requests: cpu: "2" memory: 4Gi limits: cpu: "3" memory: 5Gi
spec.clusters[].resourceRequirements を省略すると、Kubernetes 演算子は次のデフォルトを使用します。
requests.cpu:2requests.memory:4Gilimitsはありません。ノードの使用可能なリソースをすべてポッドで消費できます。
limits をワークロードに合わせて設定します。制限のないポッドはノードを飽和させ、他のワークロードに影響を与える可能性があります。
JVM ヒープの構成
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 から 2 GB のデータを挿入するか、$out. を使用して小規模なコレクションを作成します。
配置する永続ボリュームのサイズ
インデックスに必要な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.storage を 60Gi に設定します。
ストレージクラスを選択する
spec.clusters[].persistence.single.storageClass内のボリュームについてはStorageClassを参照してください。以下のガイダンスを満たすクラスを選択してください:
ディスクの種類: 多目的 SSD バックのストレージを使用します。読み取りと書き込みの両方の IOPS は
mongotのパフォーマンスにとって重要です。レプリケーションには新しいインデックス セグメントのディスク書き込みと、mongotが古いセグメントをより大きなセグメントにマージする際のディスク読み取りが含まれます。読み取り専用スレッショルド: ボリュームの使用率が90%に達すると、
mongotは読み取り専用モードに切り替わり、書き込み操作を停止します。書き込みを再開するには、使用率を85%未満にするため、インデックスデータを削除します。
リソース使用状況のモニター
配置後、初期のサイジングが適切であるかを確認し、いつ増やすべきかを知るために、以下のしきい値をモニターしてください。
Resource | しきい値 | アクション |
|---|---|---|
CPU | 80% を超える使用率が続いている |
|
メモリ |
|
|
Disk | 90% を超える使用率 | インデックスサイズを小さくして、使用量をスレッショル値未満にします。 |