フォース・マージ・コンパクションCompatible with Milvus 3.0.x
強制マージは、クエリのパフォーマンスとストレージの効率を向上させるために、小さくて断片化されたセグメントを、より少なくて大きなセグメントに統合するように設計されています。このガイドでは、強制マージ圧縮の使用方法を説明します。
この機能はパブリック・プレビューです。本番環境では使用しないでください。
概要
標準的なコンパクションでは、多対一のマージによってセグメント・サイズを設定されたmaxSize の近くに維持しますが、それでも、制限を超えないとそれ以上マージできない中間のサイズの断片が残ることがあります。たとえば、下図のように、コレクションに 2 MB のセグメントが 5 つあり、maxSize が 3 MB の場合、2 つのセグメントをマージすると制限を超えるため、標準のコンパクションではセグメント数をこれ以上減らすことができず、断片化されたレイアウトが残ります。
Force merge はtarget_size パラメータを追加し、可能な限り厳しい許容範囲内でセグメントを希望のサイズに再編成します。下図のように、指定されたtarget_size が 4 MB の場合、5 つの 2 MB の小さなセグメントをより少ない大きなセグメントにマージすることができます。これは過剰なセグメント数を減らし、デフォルトのmaxSize 設定よりも大きなターゲットをサポートし、ターゲットが非常に大きい場合、システムは現在のハードウェアとQueryNodeトポロジーに対して実用的な出力サイズとセグメント数を選択することができます。
どのコンパクション方法を使用するかについては、FAQを参照してください。
R8eow3kaqhktokblcmocnvxmnee
強制マージコンパクションは、既存の CompactionAPIをtarget_size 。これは完全な下位互換性があります。target_size を使用しない既存のコンパクション呼び出しは、従来どおり動作します。
強制マージは非同期に動作します。検索操作やクエリ操作をブロックすることはありませんが、実行中に I/O やメモリのリソースを消費します。
強制マージコンパクションの使用
前提条件
Milvusバージョン3.0以降
PyMilvus 3.0以降
グローバル設定
以下の設定パラメータは強制併合の動作を制御します。Milvusの設定ファイルまたは環境変数で設定してください。
dataCoord:
segment:
maxSize: 512 # Default segment max size (MB).
# Used when target_size is 0 or omitted.
compaction:
maxFullSegmentThreshold: 100
# When segment count exceeds this threshold,
# a faster greedy algorithm is used instead
# of the standard merge algorithm.
forceMerge:
datanodeMemoryFactor: 4.0
# DataNode memory divided by this factor
# determines the the largest segment
# size the system can allow.
querynodeMemoryFactor: 4.0
# Minimum QueryNode memory divided by this
# factor. Used in automatic size calculation
# to ensure merged segments can be loaded.
パラメータ |
デフォルト値 |
説明 |
|---|---|---|
|
512 |
デフォルトのセグメント最大サイズ(MB)。 |
|
100 |
アルゴリズム選択のためのセグメント数のしきい値。セグメント数がこの値を超えると、Milvusはより高速な貪欲アルゴリズムを使用してマージ計画を行います。
|
|
4.0 |
DataNodeのメモリをこの係数で割って、システムが許容する最大のセグメントサイズを計算します。
|
|
4.0 |
QueryNodeの最小メモリをこの係数で割ります。自動サイズ計算 (
|
上記の変更をMilvusクラスタに適用するには、HelmによるMilvusの設定およびMilvus OperatorsによるMilvusの設定の手順に従ってください。
強制マージコンパクションのトリガ
強制マージコンパクションをトリガするには、target_size パラメータを指定してcompact() を呼び出します。パラメータの詳細については、以下のパラメータリファレンスを参照してください。
3つのフォース マージ コンパクション モードが利用可能です：
compact("my_collection", target_size=?)
│
├─ Mode 1: target_size = 0 (or omitted)
│ Uses config maxSize (default 512 MB)
│ Equivalent to standard compaction
│
├─ Mode 2: target_size = 2048
│ Merges segments to ~2 GB each
│ Must be >= config maxSize
│
└─ Mode 3: target_size = max_int64
Auto-calculates optimal size based on
segment distribution and node memory
以下に、各フォース・マージ・カンパクション・モードの使用例を示す。
デフォルト（標準コンパクション）
from pymilvus import MilvusClient
client = MilvusClient(
uri="http://localhost:19530",
token="root:Milvus"
)
# Standard compaction — uses config maxSize (default 512 MB)
job_id = client.compact("target_collection")
明示的ターゲットサイズ
# Merge segments to approximately 2 GB each
job_id = client.compact(
"target_collection",
target_size="2048" # The unit is MB
)
自動サイズ計算
# Let Milvus determine the optimal segment size
max_int64 = (1 << 63) - 1
job_id = client.compact(
"target_collection",
target_size=max_int64
)
パラメータ参照
以下の表は、パラメータについて説明したものです。
パラメータ |
タイプ |
説明 |
|---|---|---|
|
str |
必須。コンパクトにするコレクションの名前。 |
|
int |
オプション。MB 単位のターゲット・セグメント・サイズ。パラメータ値には3つのオプションがあります：
|
指定されたtarget_size が設定されたdataCoord.segment.maxSize より小さい場合、リクエストはエラーで拒否される。
コンパクションの進行状況の確認
強制マージ コンパクションは非同期で実行されます。返されたジョブ ID を使用して進行状況を確認します：
# Check compaction state
state = client.get_compaction_state(job_id)
print(f"State: {state}")
ベストプラクティス
本番環境では強制マージ コンパクションを使用しないでください。
ほとんどの場合、自動サイズ計算モードを使用してください。
target_sizeをmax_int64に設定すると、Milvus がセグメント分布とノードリソースを分析して最適なサイズを決定します。特定のサイズ決定要件がない限り、この方法が推奨されます。パフォーマンスのトレードオフを考慮してください。強制マージコンパクションはリソースを大量に消費します。セグメントデータを読み取り、マージし、書き換えます。クエリーレイテンシーへの影響を最小にするため、トラフィックの少ない時間帯にスケジュールしてください。
その前後でセグメント数を監視する。
get_compaction_state()およびlist_persistent_segmentsを使用して、コンパクションによって予想よりも少ない、より大きなセグメントが生成されたことを確認します。
よくある質問
Force Merge は標準的なコンパクションとどう違うのですか？
これら 2 種類のコンパクション操作は目的が異なります。
標準的なコンパクション（targetSize=0 または省略）は、最善の努力による漸進的なクリーンアップ・パスです。
強制マージ (targetSize>0) は、コレクションレベルの再パッキングパスで、より少ない、より大きな、ターゲットに近いセグメントを作成します。
標準的なコンパクションはタスクごとに m → 1 となるが、フォースマージはグループ化された入力全体で m → n となる。これが、標準的なコンパクションでは解決できないセグメントレイアウトを、フォースマージで解決できる理由です。次の表は、2 種類のオペレーションを比較したものである。
寸法 |
標準コンパクション（デフォルト） |
フォース・マージ |
|---|---|---|
APIトリガー |
targetSize=0（または未設定）、Major/L0フラグなし |
ターゲットサイズ>0 (MB) |
主な目標 |
明らかなフラグメントのインクリメンタルなクリーンアップ。 |
検索とバランスのためのコレクション全体の統合 |
セグメントサイズのソース |
固定dataCoord.segment.maxSize (サーバ設定) |
ユーザーのtargetSize、その後maxSafeSizeで安全クランプ |
パラメータの有効性 |
ユーザーサイズのチューニングなし |
ユーザ targetSize は >= dataCoord.segment.maxSize でなければならない。 |
安全上限 |
コンフィグキャップのみ |
maxSafeSize = min(QueryNode mem, DataNode mem) / memory_factor (スタンドアロン非プーリング：さらに半分になる) |
マージ形状 |
m → 1タスクあたり、出力 <= configMaxSize |
m → n, 出力がtargetSizeの近く |
中分割の挙動 |
永久にスタックする可能性あり（例えば、2つの60%セグメントを合法的に1つの120%セグメントにすることはできない） |
リパック＋分割が機能。「60%でスタック」パターンはない |
コレクションをフラットにする能力 |
限定的。繰り返し実行しても、多くのミディアムセグメントが残る可能性がある。 |
セグメント数を減らし、充実度を高めるように設計されている。 |
トポロジーの認識 |
なし |
あり。QueryNode/レプリカ/シャードレイアウトを使用。 |
リードパス並列性チューニング |
なし |
有効な場合、queryNodeCount / (replica × shards)を使用して出力数を調整する。 |
典型的な使用例 |
書き込み/削除後の毎日の高負荷クリーンアップ |
ベンチマーク準備、検索最適化、負荷並列アライメント |
スコープ |
コレクション全体のリパックを期待しない |
コレクションレベルのリパック結果を意図 |
選択の指針
低リスクでインクリメンタルなクリーンアップには標準的なコンパクションを選択する。
強制マージを選択するのは、検索や読み込みの動作に合わせて、コレクションをより少ない、より大きなセグメントに再形成したい場合です。
強制マージはクラスタリングコンパクションとどう違うのですか？
クラスタリングコンパクション(is_clustering=True) は、クラスタリングキーに基づいてセグメント内のデータを再編成し、検索の枝刈りを改善します。強制マージ (target_size=N) は、データの分布を変えずにセグメントサイズを最適化します。最初にクラスタリングコンパクションを実行してデータを整理し、次に Force Merge を実行して結果のセグメントを統合します。
クエリ実行中のコレクションに対して Force Merge を実行できますか？
はい。Force Merge は非同期に実行され、クエリーをブロックしません。しかし、DataNode とディスク I/O リソースを消費するため、コンパクション中にクエリの待ち時間が増加する可能性があります。最良の結果を得るには、トラフィックの少ない時間帯に Force Merge をスケジュールしてください。
target_size を maxSize より小さく設定するとどうなりますか？
リクエストはエラーで拒否されます。ターゲット・サイズは設定されたdataCoord.segment.maxSize 以上でなければなりません。