2013-01-04 42 views
2

我有一個建立問題調查系統的需求。 簡單地說,它需要問題,預定義答案和用戶的答案記錄。針對複雜數據結構的Sql表或Mongo文檔結構設計

  • 問題需要問題ID,問題文本
  • 解答需要解答ID,答覆文件
  • 用戶的答案記錄需要記錄ID,用戶ID,問題ID,答案編號,日期,操作系統,IP ,瀏覽器信息,是生活

對於用戶記錄,我需要保持所有的歷史,這就是爲什麼我需要一個「是活的」列。所以每個用戶只有最新的答案是真實的。當用戶再次回答相同的問題時,該用戶的所有存在答案記錄都將成爲歷史記錄(即live = false)。

似乎簡單的結構。但是當我得到超過10萬個問題時,超過100萬個用戶,並且每個問題的每個用戶有超過20個答案記錄,那麼記錄超過100,000 * 1,000,000 * 20 = 2,000,000,000,000條記錄。那麼它就成了一個大問題。

我還需要描述我需要如何使用這些數據。我需要提供另一個系統,它可以通過定義一個問題答案標準來使用用戶的記錄來定位一組用戶。例如:

  1. (Q1=A1 && Q2=A3 && Q3=A5 && (Q4=A8 || Q5=A9))標準1
  2. (Q1!=A1 && Q2=A3)標準2
  3. (Q4=A8 || Q5!=A9)標準3

後我定義的標準:

  1. 我需要提供一個API來獲得所有符合條件的用戶ID(api1)
  2. 我需要提供一個API來獲取用戶所有評估標記(api2)

api需要快速而且生動。而且API會被頻繁地調用。

因此,想象一下當一張表中有200,000,000,000條記錄時。 api調用將非常緩慢,甚至可能會導致數據庫崩潰。

所以,我有一些解決方案,它是不好的,我只是列出這裏,所以我們可以討論:

  1. 每個問題都得到了一個表來保存所有用戶記錄這個問題。
  2. 每位用戶都有一張表來保存該用戶的所有問題記錄。
  3. 1和2都

但我可以看到有解決辦法不是很好,高效。所以想在這裏討論一下。什麼樣的技術無關緊要(sql,nosql,hadoop等)

請把你的想法放在這裏。由於

回答

2

我會只用一個「用戶」收集存儲在回答陣列,MongoDB的嘗試:

{userId: 1, 
name: "nick", 
..., 
"answers": [ 
    { questionId:1, 
     answerId: 1, 
     date: Date(...), 
     ..., 
     isLive: 1}, 
    { questionId:1 
     answerId: 2, 
     date: Date(...), 
     ..., 
     isLive: 0} 
] 
} 

然後我會在屬性「answers.isLive」使用Multikey Index以確保「高速接入生活「的答案。

「answers.questionId」和「answers.answerId」上的另一個多鍵索引應確保高性能檢索符合您標準的數據。

像你這樣的號碼,我會從一開始就考慮您的收藏sharding