在NoSQL中存儲動態數據

我有我需要存儲非結構化數據但其餘數據是結構化和關係的場景。非結構化數據的類型的例子以下作爲解釋：在NoSQL中存儲動態數據

User Type 1: 

How do you blah blah : 5 fields 

User Type 2 : 

How do you blah blah : 3 fields 

User Type 3 : 

How do you blah blah : 7 fields

所有3種都問同樣的問題：「你如何等等等等」，但使用不同數量的字段的每個用戶類型回答它。並且可以有一個很多不同的用戶類型。

對於關係數據，我使用的是MySQL，但我對如何存儲這些非結構化數據有點困惑：在MySQL

使用NoSQL的

序列化爲JSON和商店
我的要求是高讀數，平均更新，平均插入&不刪除。不需要JOINS。我需要保證寫入&高可用性。如果我要選擇一個NoSQL，根據CAP定理它將是一個AP類型。我不會很快記錄數百萬條記錄。

我也計劃提供此數據在未來的文本搜索，但它並不需要是實時搜索，這樣我就可以一直使用索引Lucene的定期數據。但當然，基於文檔的NoSQL實現確實提供了這種開箱即用的功能。但是我已經在幾個地方看過人們有建議不要在MySQL中存儲JSON數據。但是添加一個NoSQL層可能會過度。

我該怎麼做&如果您建議我去NoSQL DB，我應該選擇哪一個？

編輯： 爲了澄清，我不需要從我存儲的數據中查詢特定的字段。如果我需要這些數據，那麼我將需要整個數據，而不是特定的領域。我確實需要全文搜索，我也可以使用Lucene在MySQL上完成搜索。

來源

2013-06-03 Varun Achar

你可以通過使用一個行ID和一個文本列來使它與MySQL一起工作，但是你不能查詢這些字段。你也可以考慮表繼承，但如果你有很多類型，這將是一個混亂。底線是你有充分的理由考慮替代解決方案，而不是彎曲關係數據庫。

因此，從您所說的話，我認爲這確實是一個很好的用例多語言持久性。據說，MySQL + NoSQL將增加應用程序的整體複雜性，因此您需要確保抽象兩個數據訪問層。

對於數據庫選擇，面向文檔的解決方案在查看數據（動態，獨立聚合）時看起來非常合適。我會研究MongoDB或CouchDB，即使第二種選擇似乎更合適（AP, Master/master, Lucene integration...）。

編輯：查看評論。

來源

2013-06-03 10:39:07 LMeyer

通過表繼承你的意思是[交界表]（http://en.wikipedia.org/wiki/Junction_table）？ –

@Varun不，我的意思是表繼承：http://www.agiledata.org/essays/mappingObjects.html#MapEachClassToTable。你可以有一個普通的基本用戶表，並在其他子用戶類型表中具有特定的字段。但這只是一個假設，也許我誤解了整個用戶類型的事情。 – LMeyer

沒有..表繼承是不可能的，因爲有很多用戶類型，他們將繼續添加，因爲我們擴大。因此，爲他們每個人創建一個單獨的表是不可行的。 –

我最近在一個大量使用SQL Server，MySQL和Mongo的平臺上工作。我們存儲的數據分佈在這三個數據庫系統中。

這讓我只有一種數據庫技術。

我會建議從經驗做一個文本字段和存儲JSON在那裏。您無法直接查詢該字段，但可以在可以查詢的文本字段旁邊創建靜態字段。

將另一個系統引入混合是絕對不平凡的。

一些原因：

沒有爲文檔建模較高的學習曲線。你不規範化，你將數據非規範化 - 這樣做是一門藝術。
配置好CouchDB和MongoDB集羣后，我可以告訴你這不是一件容易的事情 - 尤其是當你轉向生產時。
通過數據庫技術查詢肯定不是微不足道的。

我只會引入一個單獨的NoSQL解決方案作爲最後的手段。

來源

2013-06-03 16:22:15 ryan1234

如果我繼續使用MySQL，會引入一些複雜性，因爲我會介紹Lucene進行全文搜索。如果NoSQL是問題的正確解決方案，那麼我不介意學習曲線。但它是正確的解決方案嗎？這就是我想知道的。 –

如果您不介意部署的學習曲線和額外的痛苦，那麼請查看彈性搜索。可以用作數據存儲和搜索引擎（它也構建在Lucene上）。一石二鳥可能會殺死兩隻鳥。當然，在文檔數據庫中存儲異構數據更容易。 – ryan1234

在NoSQL中存儲動態數據

回答

相關問題