SQL文本字段VS平面文件VS NoSQL的文檔存儲

我計劃有涉及，我不希望指數（我只會讀出的數據，很少更新）文本字段的SQL事實表。我認爲這個表格可能會變得很大，主要是由於這個文本字段。我的數據庫中的其餘數據確實是關係型的，但是我相信如果我將指針存儲到平面文件（每個指針指向存儲在S3之類的不同文本文件中），則我可以輕鬆便宜地進行擴展，而不是使用文本字段。SQL文本字段VS平面文件VS NoSQL的文檔存儲

似乎越來越受歡迎的替代方案是完全基於NoSQL文檔的解決方案（例如CouchDB，MongoDB等）。我想知道什麼是折衷（可伸縮性/可靠性/安全性/性能/易用性/易用性維護/費用），只需使用SQL文本字段，指向平面文件的指針，還是在NoSQL文檔存儲的上下文中完全重新考慮整個系統？

來源

2011-12-05 user1080972

這是一個非常複雜的問題來回答。 *「非常大」的概念非常模糊。你是在談論TB級的數據還是數PB級的數據？增長率是多少？什麼查詢需要快速，什麼可以接受的慢？ –

這個特定的文本數據預計大約爲50TB。預計在峯值負載期間，每秒鐘的增長速度將達到500 kb左右。理想情況下，所有選擇語句都很快（它們將被預定義爲只有Web服務才能訪問數據庫），而插入和更新可能會慢得令人可以接受。 – user1080972

如果您想在32位系統上使用MongoDB，首先要考慮的是您只能存儲2GB的數據。 MongoDB生產商表示，問題很快就會得到解決，因爲大多數PC機都是64位的，所以他們不想改變他們的程序，讓32位PC機工作在2GB以上。至少這是我讀的。所以這是第一個問題，但我認爲CouchDB沒有這個問題。 – Aufziehvogel

最好的辦法是使用正常（非文本）數據的關係數據庫，並把大（文本）數據「別處」，可以處理大量的數據比關係數據庫可以更好。

首先，讓我們討論一下爲什麼它是一個壞建議保存在關係數據庫中大量數據：」

行大小變得更長，所以在與目標磁盤頁面讀取I/O要求排氣球
備份的大小，更重要的是，備份次放大到他們能削弱DBA任務，甚至會帶來系統離線點（然後備份被關閉，那麼磁盤發生故障，哎呀呀）
你通常不要不需要搜索文本，所以不應該有它在數據庫
關係數據庫和庫不需要/驅動器通常不擅長處理非常大的數據，處理它的方式往往是供應商特定的，因此任何解決方案非便攜式

你所選擇的「別處」是廣泛的，但包括：

大容量數據存儲軟件，如卡桑德拉，MongoDB的，等
NoSQL數據庫就像Lucene的
費爾評估系統

做什麼最簡單的方法，將工作 - 他們都是有效的，只要你做你的要求算了一筆賬：

峯值寫入性能
峯值讀取性能
長期存儲量

另一個提示：不要存儲任何東西關於正文關係數據庫。相反，使用關係數據庫行的id命名/索引文本。這樣，如果您更改實現，則不必重新調整數據模型。

來源

2013-12-30 14:03:22 Bohemian

SQL文本字段VS平面文件VS NoSQL的文檔存儲

回答

相關問題