在軟件開發中，我們選擇的技術棧往往帶有一些固有的設計邊界。對于 MongoDB 而言，其最著名的邊界之一便是 BSON 文檔最大 16MB 的大小限制。在大多數場景下，這個限制是綽綽有余的，它鼓勵開發者設計更為精簡和規范的數據模型。然而，在某些特定業務場景下，單個邏輯實體的數據量自然增長并最終觸及這個上限，就成了一個棘手的問題。本文將分享一次處理此類問題的完整過程，從一個有隱患的初始設計，到一個健壯、可擴展的最終方案。
最初的困境：一個“定時炸彈”式的數據模型
問題的起源是一個看似合理的數據模型。系統中存在一個核心實體，其文檔結構中包含了一個用于聚合數據的集合字段。例如，一個用于記錄和合并分析結果的文檔，其結構可以被簡化為如下形式：
// 初始數據模型
public class ParentDocument {private ObjectId id;private String name;// 該字段用于持續聚合數據，是問題的根源private List<DataObject> aggregatedData;
}
其業務邏輯是，當新的數據片段產生時，系統會讀取整個 ParentDocument，將新的數據片段與 aggregatedData 列表在內存中合并，然后將包含完整新列表的 ParentDocument 整個保存回數據庫。在系統初期，數據量不大，這種“讀取-修改-寫回”的模式運行良好，邏輯清晰且易于實現。
然而，這個方案的弊端是致命的。隨著業務的持續運行，aggregatedData 列表不斷膨脹。每一次合并都使得文檔的體積越來越大，像一個被不斷吹氣的氣球，最終必然會達到其物理極限。當某次合并后的文檔總體積超過 16MB 時，MongoDB 的驅動程序在嘗試保存時會立即拋出 BsonMaximumSizeExceededException 異常，導致整個業務流程中斷。這個問題就像一顆預先埋下的定時炸彈，它的爆炸只是時間問題。
報錯：
error=Payload document size is larger than maximum of 16777216.
org.bson.BsonMaximumSizeExceededException: Payload document size is larger than maximum of 16777216.at com.mongodb.internal.connection.BsonWriterHelper.writePayload(BsonWriterHelper.java:68)at com.mongodb.internal.connection.CommandMessage.encodeMessageBodyWithMetadata(CommandMessage.java:162)at com.mongodb.internal.connection.RequestMessage.encode(RequestMessage.java:138)at com.mongodb.internal.connection.CommandMessage.encode(CommandMessage.java:59)at com.mongodb.internal.connection.InternalStreamConnection.sendAndReceive(InternalStreamConnection.java:268)at com.mongodb.internal.connection.UsageTrackingInternalConnection.sendAndReceive(UsageTrackingInternalConnection.java:100)at com.mongodb.internal.connection.DefaultConnectionPool$PooledConnection.sendAndReceive(DefaultConnectionPool.java:490)at com.mongodb.internal.connection.CommandProtocolImpl.execute(CommandProtocolImpl.java:71)at com.mongodb.internal.connection.DefaultServer$DefaultServerProtocolExecutor.execute(DefaultServer.java:253)at com.mongodb.internal.connection.DefaultServerConnection.executeProtocol(DefaultServerConnection.java:202)at com.mongodb.internal.connection.DefaultServerConnection.command(DefaultServerConnection.java:118)at com.mongodb.internal.operation.MixedBulkWriteOperation.executeCommand(MixedBulkWriteOperation.java:431)at com.mongodb.internal.operation.MixedBulkWriteOperation.executeBulkWriteBatch(MixedBulkWriteOperation.java:251)at com.mongodb.internal.operation.MixedBulkWriteOperation.access$700(MixedBulkWriteOperation.java:76)at com.mongodb.internal.operation.MixedBulkWriteOperation$1.call(MixedBulkWriteOperation.java:194)at com.mongodb.internal.operation.MixedBulkWriteOperation$1.call(MixedBulkWriteOperation.java:185)at com.mongodb.internal.operation.OperationHelper.withReleasableConnection(OperationHelper.java:621)at com.mongodb.internal.operation.MixedBulkWriteOperation.execute(MixedBulkWriteOperation.java:185)at com.mongodb.internal.operation.MixedBulkWriteOperation.execute(MixedBulkWriteOperation.java:76)at com.mongodb.client.internal.MongoClientDelegate$DelegateOperationExecutor.execute(MongoClientDelegate.java:187)at com.mongodb.client.internal.MongoCollectionImpl.executeSingleWriteRequest(MongoCollectionImpl.java:1009)at com.mongodb.client.internal.MongoCollectionImpl.executeInsertOne(MongoCollectionImpl.java:470)at com.mongodb.client.internal.MongoCollectionImpl.insertOne(MongoCollectionImpl.java:453)at com.mongodb.client.internal.MongoCollectionImpl.insertOne(MongoCollectionImpl.java:447)
解決方案的演進：從內嵌聚合到引用分塊
要解決這個問題，核心思想必須從“如何將一個大文檔存進去”轉變為“如何將一個邏輯上的大實體拆分成多個物理上的小文檔”。我們最終采用的方案是“文檔引用分塊”。
這個方案的第一步是重構數據模型。我們將聚合數據從主文檔中剝離出來，存放到一個專門的“數據塊”集合中。主文檔僅保留對這些數據塊的引用。
// 重構后的主文檔模型
public class ParentDocument {private ObjectId id;private String name;// 存儲指向數據塊文檔的ID列表private List<ObjectId> chunkIds;
}// 新增的數據塊文檔模型
@Document(collection = "dataChunks")
public class ChunkDocument {private ObjectId id;// 每個塊包含一部分數據private List<DataObject> dataSlice;
}
伴隨著數據模型的演進，核心的存取邏輯也需要重構。
在寫入數據時，我們在服務層引入了分塊邏輯。當需要保存一個聚合了大量數據的邏輯實體時，代碼不再直接構建一個巨大的 ParentDocument。取而代之的是：
判斷大小：評估待保存的總數據量是否超過預設的安全閾值。
執行分塊：如果超過閾值，則在內存中將龐大的數據列表分割成多個較小的列表。
持久化塊：遍歷這些小列表，將每一個都包裝成一個
ChunkDocument并存入dataChunks集合。保存引用：收集所有新創建的
ChunkDocument的_id，將這個ObjectId列表存入ParentDocument的chunkIds字段中，同時清空其內嵌的數據字段。更新清理：在更新一個已存在的
ParentDocument時，先根據其舊的chunkIds刪除所有關聯的舊數據塊，避免產生孤立的垃圾數據。
讀取數據的邏輯則確保了這種底層變化對上層業務的透明性。當業務需要獲取一個完整的 ParentDocument 實體時，數據服務層的邏輯如下：
獲取主文檔：首先根據ID獲取
ParentDocument。檢查分塊：判斷其
chunkIds字段是否有效。按需重組：如果
chunkIds存在，則根據ID列表到dataChunks集合中查詢出所有的關聯數據塊。隨后，在內存中將所有dataSlice合并成一個完整的數據列表。返回完整視圖：將重組后的完整數據列表設置到
ParentDocument實例的對應字段上（通常是一個非持久化的瞬態字段），再將其轉換為業務DTO（數據傳輸對象）返回。
通過這種方式，無論底層數據是否被分塊，上層業務邏輯得到的永遠是一個數據完整的、與原始設計中一致的邏輯實體。這不僅解決了16MB的限制，也保證了方案的向后兼容性和對其他業務模塊的最小侵入性。
替代方案的思考：為何不是 GridFS？
在探討解決方案時，我們自然會想到 MongoDB 官方提供的大文件存儲方案——GridFS。GridFS 能將任意大小的文件分割成默認255KB的塊進行存儲，非常適合存放圖片、視頻或大型二進制文件。
然而，經過審慎評估，我們認為 GridFS 并不適用于我們當前的業務場景。主要原因在于我們的數據特性和操作模式：
首先，我們的“大文件”并非一個不可分割的二進制“大對象”（BLOB），而是一個由成千上萬個獨立結構化對象（DataObject）組成的集合。我們需要對這個集合進行頻繁的、增量式的合并操作。
若采用 GridFS，每次合并都需要將整個幾十甚至上百兆的邏輯對象從 GridFS 下載到內存，反序列化成一個巨大的列表，與新數據合并后，再將這個全新的、更大的對象序列化并重新上傳到 GridFS，最后刪除舊的 GridFS 文件。這種“整體讀-整體寫”的操作模式對于我們增量更新的場景而言，性能開銷和資源消耗是無法接受的。
其次，GridFS 的設計初衷是文件存儲，我們無法對存儲在其中的內容進行查詢。而我們的“引用分塊”方案，每一個數據塊本身仍然是一個標準的 MongoDB 文檔，保留了未來對部分數據集進行直接查詢的可能性。
最后，引入 GridFS 會導致數據訪問模式的根本性改變，從操作文檔對象變為操作文件流（InputStream），這將對現有的數據服務層、業務邏輯乃至DTO產生巨大的沖擊，與我們期望的“最小化、高內聚”的重構目標背道而馳。
總結
面對看似難以逾越的技術邊界，選擇最“官方”或最“強大”的工具未必是最佳答案。通過深入分析業務數據的結構特性和操作模式，我們最終選擇的“文檔引用分塊”方案，雖然需要自行實現分塊和重組邏輯，但它以一種高度兼容且對業務侵入最小的方式，優雅地解決了16MB的文檔大小限制。這個過程也再次印證了一個樸素的道理：最合適的方案，永遠源于對問題本質的深刻理解。
![[css]旋轉流光效果](http://pic.xiahunao.cn/[css]旋轉流光效果)
