爲什麼關係數據庫不適合非結構化數據？

Question

我一直在研究NoSQL數據庫，並且出現一個常見的主題是關係數據庫不適合存儲非結構化數據。例如：

不幸的是，關係數據庫使用的嚴格定義，基於模式...是一個貧窮的適合於非結構化和半結構化數據 [source]

我有一個很難理解這是爲什麼。例如，如果我想在關係數據庫中存儲圖像或一些原始文本，我能不能將它作爲文本類型存儲（例如，在單個列表或鍵值表中）？

Answer 1

我最喜歡的非結構化數據的例子不適合關係數據庫，它是計算機硬件部分數據庫。

想象一下，你有一個銷售計算機硬件的網上商店。你的產品數據庫將如何看待？

每個產品都有一個name，price和vendor。但CPU有clock rate，cache size和# of cores，顯示器有size和resolution，RAM模塊有capacity，硬盤驅動器也有capacity（這不能與RAM模塊相比較）。

如何將這些數據存儲在關係數據庫中？

• 您可以創建一個非常寬的表有數百場的任何可能的屬性有些產品可能有，但對於大多數的產品大部分這些領域將是NULL。
• 你可以有一個單獨的表爲每個產品類別
• 你可以有它的所有屬性映射到值的列product，property和value一個巨大的表（但你用什麼類型value當某些屬性是數字和其他不是？）

所有三個選項都是有效的，但他們都沒有真正令人滿意。

但是，當你有一個沒有嚴格模式的面向文檔的數據庫時，它會變得簡單得多，因爲每個條目可以有任何一組可以具有任何類型值的屬性。

Answer 2

我不認爲這個問題應該是非結構化與非結構化數據。這關係到大量數據的性能。我有一些嘗試將SQL數據庫轉換爲非結構化數據存儲的經驗。就我而言，我有一堆需要進入表格的動態（JSON）對象。我使用的是SQL，因爲這些對象通過父子關係（即自聯接）相互關聯。它適用於約5,000個對象的測試數據集。

使用SQL

然而，我的生產數據庫中包含的數據3GB價值（約1萬個對象，給予或採取）。我花了數週時間來構建和優化我的sql連接和查詢。我能夠實現大約10ms的最大性能，從樹中的選定位置返回幾個節點。然後，我遇到了奇怪的查詢性能問題，只能通過重新構造索引和/或刪除和重新創建存儲過程來解決。我花了很多時間來維護該死的SQL數據庫，因爲我正在編寫我的應用程序的其餘部分。不好。 （哦，我應該提到，我有大約3年的SQL服務器實踐經驗，所以我絕不是新的遊戲）。

使用Couchbase

快進18個月。我現在使用Couchbase（一個流行的nosql數據庫）。通過使用視圖和map/reduce，我能夠從CB獲得相同的功能。我花了一個星期讓我的CB部署正常運行。查詢查詢延時小於毫秒。最終用戶注意到性能的急劇增加。

底線

如果你有大量的數據，你會捉襟見肘找到的情況下SQL會附近的NoSQL數據庫架構的性能的任何地方，不管如何結構化或者是非結構化的數據。

Answer 3

這個問題似乎是基於兩個或三個誤解。不幸的是，它們在時尚的NoSQL產品愛好者中都很常見。

首先信息（不是「數據」）從來沒有真正的非結構化。結構是我們查看數據以查看信息的透鏡。結構是數據有用的原因。其次，這些數據（文檔，圖像，混合內容）的通常引用的例子是以關係形式存儲的非常合適的候選。

第三，SQL！=關係。 NoSQL產品的基本原理是需要替代SQL。這是毋庸置疑的。不幸的是，NoSQL的提倡者傾向於將他們的想法基於一種誤解，即SQL DBMS的問題和侷限性是數據關係模型中固有的問題。這不是真的。一個強有力的例子可以說是最好的一種NoSQL數據庫管理系統將是一個關係之一。