我應該在DocumentDB中爲我的數據庫的每個條目創建一個單獨的文檔,還是應該創建單個文檔並創建一個包含所有元素的數組?我應該在Azure DocumentDB中創建更多文檔還是使用數組創建更少的文檔?
例如如果我有大約30k-40k的產品根據類別進行區分,那麼我應該製作30k文檔,每個產品,還是應該爲每個類別製作一個文檔並將產品添加到該類別文檔的陣列中?
我想知道性能和成本因素。
我應該在DocumentDB中爲我的數據庫的每個條目創建一個單獨的文檔,還是應該創建單個文檔並創建一個包含所有元素的數組?我應該在Azure DocumentDB中創建更多文檔還是使用數組創建更少的文檔?
例如如果我有大約30k-40k的產品根據類別進行區分,那麼我應該製作30k文檔,每個產品,還是應該爲每個類別製作一個文檔並將產品添加到該類別文檔的陣列中?
我想知道性能和成本因素。
有沒有「正確答案」的文件建模,成本和性能,因爲它是所有非常依賴於你的應用程序&數據,但是從客觀的角度來看:
當你有一個無界的數組,你會最終超過文檔的最大大小限制。然後你的數據模型將被打破。
此外,數組越大,您操作包含數組的文檔的成本越高(例如,更新以添加更多項目)。
比如說,如果你有40000級的產品(根據您的問題的描述):如果你在一個數組存儲這些,你需要每次查詢陣列,VS只需拔產品的文檔。另外:產品有多大(ID,說明,圖像鏈接等)?信息越大,它在文檔中消耗的存儲量就越多。
另外:作爲最大原稿尺寸爲2MB:如果你有40000級的產品,你只有有房每產品約50個字節。
如果,另一方面,你有一個產品對應一個文件,你可以很容易地查詢特定的產品。您可以擁有非常大的產品說明,而不必擔心超出最大文檔大小。您可以在另一個文檔(相對於一系列產品文檔)中擁有產品ID的數組(如果需要的話)。
至於對成本,效率,等你的問題:只有你能確定部分,通過位基準的(和每個刀片檢查RU成本/讀/查詢)。