[SQL ] 問投票系統資料庫規劃設計[MySQL]

[kerash (K.T)]

請問各位先進

今天我要規劃一個投票系統提供給有會員資格的訪客投票
想請問關於這樣的功能資料庫應該如何規劃比較恰當

網路上通常都是針對單一投票作教學
規劃出來的資料庫不外乎結構是

表1. 投票列表
      [紀錄目前有甚麼投票、投票時間 ..etc]

表2. 投票選項
      [選項對應投票列表的ID，以取得該投票有哪些選項]

表3. 票選結果
      [某某會員對某某投票所投下的選項]


個人認為對於投票數量較少的系統應該足以使用

但想知道對於較大型的投票系統，以FB民調來說

通常投票及選項皆很大量，而且調查量又多的狀況之下

這種規劃，投票選項跟結果很快就是幾十萬筆的數量以上

在需要查詢或統計的狀況下似乎不是很好(不是很確定)

因此想詢問關於這種系統，是否有較為恰當的設計方式
或者能夠較為有效利用資料庫的規劃

謝謝

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.32.186.193
→ kerash:或者希望介紹關於這類系統規劃的範本也行 >_<)\
推 LaPass:表的結構不會變，但是資料庫的SERVER會做cluster，update時
→ LaPass:更新到某台server去，之後由那台server把資料轉發到其他台
→ LaPass:mysql是聲稱用了cluster後可以處理一億筆的數據，你可以去
→ LaPass:看他們的說明書，有章專門講cluster的
→ kerash:了解，但在硬體設備的限制上，有時應該沒辦法達到需求
→ kerash:因此想以規劃的方向來思考，或者在新增時的處理是否能增加
→ kerash:使用的效率之類的結果
→ iFEELing:你要先估一下使用量 高負載跟低負載的系統架構長相差很多
→ iFEELing:低使用量用高負載的規劃去建 不是很划算
→ iFEELing:"同時"在線上的投票量多少? 投完多久內"一定"要算出結果
→ iFEELing:結果精確度"必要"要多少? 都會影響你整體系統的架構
→ iFEELing:一台DB 兩台DB 很多台DB 或是用HaDoop + NoSQL
→ iFEELing:是每投一票就要算票 還是每小時算 還是每天離峰算
→ iFEELing:這些都會影響到架構的長法 程式的寫法 機器的配法...
感謝說明，目前手邊這個以上面的規劃是綽綽有餘，
只是自己想知道有沒有更好的規劃方法(在有限硬體限制下)

若單純以租用虛擬主機的狀況下
同時處理的投票量大約1~20筆，可能在一定時間內會有定量的讀取量而已
這種負載而言應該是一般主機都能應付的條件

投票後刷新要立刻取得投票量，但不用做到即時更新票數(重整再取得即可)
這裡的精確度個人不是很懂意思~"~


其實我個人的問題是在於，如果投票系統不是短期使用，
而是長期且有穩定使用的狀況下，在上面這種規劃的資料庫結構
是不是會造成影響

例
我要即時從 N 筆投票中取得某個會員對某個投票所投的選項
在取得資料的效率及時間上是否可以因更好規畫而有所提升

PS
個人主要還是只對小型的網站做資料庫規劃，
較少以長期使用的情況做討論，所以想了解多一點
謝謝指導及指教
※ 編輯: kerash          來自: 114.32.186.193       (03/17 17:00)
→ iFEELing:精確度是指 你的票數是否要算到每票 或是取個大概
→ iFEELing:如果每分鐘有成千上百的票進來 是否需要每次都分毫不差
→ kerash:應該不會到瞬間這麼大量，準確率應該不會有甚麼問題@@
推 KC73:我覺得我會用 memcached + mysql