NOSQL設計，沒有反規範化？

我剛開始設計分佈式存儲數據庫的'模式'。NOSQL設計，沒有反規範化？

我一直在精神辯論多少去正常化。我知道如何做到這一點，以及爲什麼它會提高性能，如果非規範化匹配查詢以儘量減少從多個地方收集數據...

...但是，人們經常說，過早優化是不好的。關係型設計的優勢在於引用而不是嵌入重複數據：優雅，靈活，不用擔心保持重複數據的一致性等。

所以我現在想知道是否合理的策略是以非常相關的方式設計架構，根據需要使用應用程序層收集數據，並在需要時稍後更改。

如果流量成爲問題，我已經開始使用一種技術，可以通過一些設計更改（隔離，非規範化）來水平擴展。

好像它可能是其中最好的選擇：

開始與RDBMS，如果需要的話
開始採用分佈式存儲移動到分佈式存儲，全非規範化設計（規模就緒）
從關係設計的分佈式存儲開始，如果需要則進行非規範化+隔離

想法？

感謝

來源

2011-07-21 Harry Mexican

你有多大的信心會超出關係型數據存儲的容量？你認爲那個能力是什麼？你期望超過什麼維度的關係容量（數據量，交易率等）？如何鎖定數據設計？您沒有提到最重要的關係優勢之一 - 架構可延展性。 – dkretz

@le dorfier如果產品成功了，由於寫入次數的原因，它將以超過傳統方式捆綁在一起的3-4個強壯的mySQL服務器的容量。當然，總有一種方法可以讓mysql實例充當使用應用層智能的分佈式節點，但是noSQL解決方案似乎提供了其中一些功能，可以編寫更少的應用層代碼。模式延展性確實是一個問題： - （ –

我會選擇2，假設可擴展架構沒有真正嚴重的缺點。

如果您知道以後可能需要使用分佈式存儲，那麼您最好還是從一開始就使用類似於最終系統的東西，而不必處理多個模式版本。 NoSQL設計不一定比關係設計更復雜，但它們是不同的。許多NoSQL平臺現在已經足夠成熟，可以像SQL一樣方便地進行初始開發。

您可能還會發現，您不需要做任何過於複雜的事情來獲得水平縮放比例 - 典型關係數據庫中的許多連接都存在，因爲它不支持多個值或分層結構。

來源

2011-07-22 01:53:38

）NoSQL世界中的問題是保持您的非規範化「多值」和「結構化結構」更新，因爲您的公共值現在在每個記錄中都被重複使用 – Anentropic

如果您以系統方式並且知道所有重複項的位置，此外，我從來沒有提到任何關於重複值的東西，只是真正的子對象 - 只支持平坦表是SQL在某些情況下的一個重要限制 –

我覺得thaty過去的做法聽起來似乎很有道理，但我有一些意見。不再有關係型DBMS，所以我會建議使用OO設計而不是關係型。例如，如果我們擁有一對多關係，而擁有「擁有」語義 - 我們可以將雙方放在一個對象中並將其作爲一個對象存儲。我認爲這種方法在NOSQL中可以被認爲是「正常化」的。

來源

2011-07-21 12:48:43

你有沒有考慮過縮放你正確的規範化關係數據庫the old fashioned way？ NoSQL通過允許簡單或設計不佳的php/lamp應用程序通過用粗糙而有效的替換瓶頸來擴大聲譽。如果你有一個優雅的設計，你不需要需要 NoSQL擴展。

來源

2011-07-22 02:09:46 gordy

該鏈接僅描述了架構原理而不是實現。我猜你的意思是使用幾個獨立的RDBMS節點和應用程序層以分離數據的方式分離數據，使得它們可以獨立工作。使用noSQL做同樣的事情似乎更容易，因爲它已經有一些工具將多個節點視爲一個 - 結束分區被照顧。 –

NOSQL設計，沒有反規範化？

回答

相關問題