𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗼𝗺𝗽𝗮𝗰𝘁𝘀 𝘀𝗲𝗴𝗺𝗲𝗻𝘁𝘀 𝗱𝘂𝗿𝗶𝗻𝗴 𝗻𝗼𝗿𝗺𝗮𝗹 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀, ...

Milvus on X: "𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗼𝗺𝗽𝗮𝗰𝘁𝘀 𝘀𝗲𝗴𝗺𝗲𝗻𝘁𝘀 𝗱𝘂𝗿𝗶𝗻𝗴 𝗻𝗼𝗿𝗺𝗮𝗹 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀, 𝗯𝘂𝘁 𝘄𝗶𝘁𝗵𝗶𝗻 𝗰𝗲𝗿𝘁𝗮𝗶𝗻 𝗹𝗶𝗺𝗶𝘁𝘀. 𝗢𝗻𝗰𝗲 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝘀𝗲𝘁𝘁𝗹𝗲𝘀, 𝘁𝗵𝗲 𝗳𝗿𝗮𝗴𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗹𝗲𝗳𝘁 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗮𝘅𝗲𝘀 𝗲𝘃𝗲𝗿𝘆 𝗾𝘂𝗲𝗿𝘆. https://t.co/3gQzeuCPnL" / X

Milvus

@milvusio

𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗼𝗺𝗽𝗮𝗰𝘁𝘀 𝘀𝗲𝗴𝗺𝗲𝗻𝘁𝘀 𝗱𝘂𝗿𝗶𝗻𝗴 𝗻𝗼𝗿𝗺𝗮𝗹 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀, 𝗯𝘂𝘁 𝘄𝗶𝘁𝗵𝗶𝗻 𝗰𝗲𝗿𝘁𝗮𝗶𝗻 𝗹𝗶𝗺𝗶𝘁𝘀. 𝗢𝗻𝗰𝗲 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝘀𝗲𝘁𝘁𝗹𝗲𝘀, 𝘁𝗵𝗲 𝗳𝗿𝗮𝗴𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗹𝗲𝗳𝘁 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗮𝘅𝗲𝘀 𝗲𝘃𝗲𝗿𝘆 𝗾𝘂𝗲𝗿𝘆. 𝗔𝗱𝗱𝗿𝗲𝘀𝘀 𝗶𝘁 𝘄𝗶𝘁𝗵 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗖𝗼𝗺𝗽𝗮𝗰𝘁𝗶𝗼𝗻. During ingestion, Milvus writes data into segments and seals them as part of the ingestion path. Merging them aggressively at that point would compete with ingestion resources, so the system leaves them as they are. That is the right default while data is still changing. The problem: Milvus does not have your application-level signal that ingestion is complete. After a bulk load wraps up, a knowledge-base refresh completes, or a migration lands, those write-optimized segments stay in place. Search queries may continue to fan out across more sealed segments than necessary. 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗖𝗼𝗺𝗽𝗮𝗰𝘁𝗶𝗼𝗻 𝗶𝘀 𝗵𝗼𝘄 𝘆𝗼𝘂 𝗽𝗮𝘀𝘀 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗮 𝘀𝗶𝗴𝗻𝗮𝗹 𝗶𝘁 𝗰𝗮𝗻𝗻𝗼𝘁 𝗶𝗻𝗳𝗲𝗿 𝗼𝗻 𝗶𝘁𝘀 𝗼𝘄𝗻: 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝗵𝗮𝘀 𝘀𝗲𝘁𝘁𝗹𝗲𝗱, 𝗿𝗲𝘀𝗵𝗮𝗽𝗲 𝘁𝗵𝗲 𝗹𝗮𝘆𝗼𝘂𝘁 𝗳𝗼𝗿 𝗿𝗲𝗮𝗱𝘀. The tradeoff is explicit. In our benchmark, the merge and index rebuild used all 16 cores during the merge and rebuild in our single-node benchmark. On a cluster, you can isolate that cost on separate DataNode and QueryNode resources. On a single node, time it for a quiet window. 𝗪𝗵𝗲𝗻 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗳𝗶𝘁𝘀: • The collection has shifted from writes to reads • Search throughput is the bottleneck, not ingestion • You have a maintenance window or separated cluster resources • You can measure segment count before and after to confirm the gain 𝗪𝗵𝗲𝗻 𝗶𝘁 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁: • The collection still takes steady writes or updates • Resources are already tight with no room for the rebuild • You are in peak traffic with no quiet window 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗶𝘀 𝗶𝗻 𝗽𝘂𝗯𝗹𝗶𝗰 𝗽𝗿𝗲𝘃𝗶𝗲𝘄. 𝗥𝗲𝗮𝗱 𝗮𝗯𝗼𝘂𝘁 𝗼𝘂𝗿 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁 𝗵𝗲𝗿𝗲:

milvus.io/blog/force-mer…

3:30 PM · Jul 8, 2026

178

Views

2