如果NoSQL是無計劃的，那麼它對於大規模更新怎麼樣？

我在一個模式中思考一個問題，「人」有一個國家，在RDBMS中，我可以製作兩張表，一個給人，另一個給國家，並且做一個關鍵連接兩個...如果我想改變一個國家的名稱，然後我只是在「國家」表中更改它，並且人們獲得了這個新的價值......但是我想如果我在一個像MongoDB這樣的關鍵/文檔中做這個，我只需要一個文檔，「這裏面將有國家的價值，如：如果NoSQL是無計劃的，那麼它對於大規模更新怎麼樣？

{name:"Tiago", 
Country: "Brazil"}

現在，如果我想改變這一切‘巴西’到‘巴西’，我將不得不尋找ALL人，其中國家等於」巴西「然後更新？所以，它不會比RDBMS更慢？

來源

2011-09-29 tiagomac

與您需要訪問數據的所有用例相比，使用哪個百分比會改變鍵值對的值。您可能會更改鍵和值之間的關聯，但更改值本身？可能很少見。 – MeBigFatGuy

有一個基準/文章暗示它（MongoDB，並非所有NoSQL都是平等的）*對這種更新有好處？考慮在解規範化的SQL數據庫中也應該這樣做。 – 2011-09-29 00:56:44

你可能有國家代碼和另一個國家代碼和名稱的文件。 – bryanmac

沒有人回答;該技術將取決於發動機;正如你所說的，「NoSQL」數據庫並不都是一樣的。

在CouchDB;您（通常）通過視圖訪問所有數據，並且您可以在視圖中輕鬆更改此類內容;最重要的是，由於視圖是簡單的JavaScript，因此您可以很容易地表達任何類型的轉換。不利的一面是，CouchDB中的所有視圖與SQL數據庫中的物化視圖基本相同;並且當您第一次嘗試訪問這樣的值時，只要需要重建整個視圖，響應時間就會很長;如果這是很多要重寫的數據，那需要一段時間。

在AppScale或GoogleAppEngine中，您必須直接更改實體;唯一真正有效的方法是系統地觸摸可能較大的一組數據，即使用任務隊列，並且系統地查詢與「巴西」匹配的實體，直到它不返回任何行。有時候真正的查詢會返回兩個值的混合。

在所有情況下;分佈式文檔數據庫的優勢在於一種假設，即某些類型的操作是計算密集型的;但是引擎本身的設計仍然可用，即使這些類型的操作正在進行中。這主要是數據庫爲滿足上限定理而進行的權衡的結果。

來源

2011-09-29 01:20:22 SingleNegationElimination

如果NoSQL是無計劃的，那麼它對於大規模更新怎麼樣？

回答

相關問題