Azure Cosmos數據庫更新模式

我最近開始使用Cosmos DB作爲項目，我遇到了一些設計問題。從SQL背景來看，我知道相關數據應該嵌套在NoSQL數據庫的文檔中。這確實意味着文檔可能變得相當大。Azure Cosmos數據庫更新模式

由於不支持部分更新，因此當您要更新文檔上的單個屬性時，要實現哪種最佳設計模式？

我應該在閱讀整個文檔服務器端，更新值並將文檔寫回來以便執行更新嗎？如果文檔很大，如果所有的數據都嵌套，那麼這看起來有問題。

如果我採用製作許多小文檔和根據ID推斷關係的方法，我認爲這樣可以更好地解決讀/寫問題，但感覺就像我反對NoSQL的概念，實質上是我我正在構建一個關係數據庫。

感謝

2017-08-03 Ross

出色的問題。看起來好像社區也在問：https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6693091-be-able-to-do-partial-updates-on-document 這裏的含義是，'小文件/推斷關係'模式是現在走的路。看到白皮書或類似「小文件」的小文章會很可愛。 – Holf

請注意，Cosmos DB中文檔的限制爲2 MB，因此您不得不使用相對較小的文件。 – influent

鎖定和鎖定。如果部分更新成爲可能，那就是需要發生的事情。用鎖定保持寫入延遲時間爲15毫秒的SLA是一個困難的工程問題。

這似乎有問題，如果文件很大，如果你所有的數據都嵌套，這是不可避免的。

定義你的恐懼—燒燬請求單元，應用主機內存，入口/出口網絡流量？你相信這是一個問題，但你沒有說明具體的結果。我並不是說你錯了，或者懷疑部分更新方法的效率，我只是說這個論點很薄弱。

通常你想JOIN沒有在NoSQL，所以我完全與你在最後一段。

來源

2017-08-03 11:12:32 evilSnobu

感謝您的回覆。這不是一個真正的爭論，更多的是一個問題。我想所有你所定義的恐懼都是有效的，我只是從Cosmos DB的規模經驗的人那裏尋找建議。有人可以說「是的，你必須閱讀整個文檔，遍歷嵌套屬性中的列表，更新列表中的項目上的單個標誌並將整個文檔寫回」。如果這是「正確」的方式或推薦的方式來處理更新宇宙數據庫然後我很高興。 – Ross

每當你要創建一個文檔儘量考慮這一點：

是否文檔的部分需要單獨的訪問。如果是，則創建一個引用文檔，如果沒有，則創建一個嵌入文檔。

如果你想知道該怎麼選擇，我想你應該需要看看這個問題的MongoDB的，但是會幫助你Embedded vs Referenced Document

來源

2017-08-03 12:12:17 vikscool

Azure Cosmos數據庫更新模式

回答

相關問題