作者kerash (K.T)
看板Database
標題[SQL ] 問投票系統資料庫規劃設計[MySQL]
時間Sun Mar 17 11:54:56 2013
請問各位先進
今天我要規劃一個投票系統提供給有會員資格的訪客投票
想請問關於這樣的功能資料庫應該如何規劃比較恰當
網路上通常都是針對單一投票作教學
規劃出來的資料庫不外乎結構是
表1. 投票列表
[紀錄目前有甚麼投票、投票時間 ..etc]
表2. 投票選項
[選項對應投票列表的ID，以取得該投票有哪些選項]
表3. 票選結果
[某某會員對某某投票所投下的選項]
個人認為對於投票數量較少的系統應該足以使用
但想知道對於較大型的投票系統，以FB民調來說
通常投票及選項皆很大量，而且調查量又多的狀況之下
這種規劃，投票選項跟結果很快就是幾十萬筆的數量以上
在需要查詢或統計的狀況下似乎不是很好(不是很確定)
因此想詢問關於這種系統，是否有較為恰當的設計方式
或者能夠較為有效利用資料庫的規劃
謝謝
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.32.186.193
1F：→ kerash:或者希望介紹關於這類系統規劃的範本也行 >_<)\ 03/17 11:56
2F：推 LaPass:表的結構不會變，但是資料庫的SERVER會做cluster，update時 03/17 12:04
3F：→ LaPass:更新到某台server去，之後由那台server把資料轉發到其他台 03/17 12:05
4F：→ LaPass:mysql是聲稱用了cluster後可以處理一億筆的數據，你可以去 03/17 12:06
5F：→ LaPass:看他們的說明書，有章專門講cluster的 03/17 12:06
6F：→ kerash:了解，但在硬體設備的限制上，有時應該沒辦法達到需求 03/17 12:13
7F：→ kerash:因此想以規劃的方向來思考，或者在新增時的處理是否能增加 03/17 12:13
8F：→ kerash:使用的效率之類的結果 03/17 12:15
9F：→ iFEELing:你要先估一下使用量 高負載跟低負載的系統架構長相差很多 03/17 13:32
10F：→ iFEELing:低使用量用高負載的規劃去建 不是很划算 03/17 13:33
11F：→ iFEELing:"同時"在線上的投票量多少? 投完多久內"一定"要算出結果 03/17 13:34
12F：→ iFEELing:結果精確度"必要"要多少? 都會影響你整體系統的架構 03/17 13:36
13F：→ iFEELing:一台DB 兩台DB 很多台DB 或是用HaDoop + NoSQL 03/17 13:51
14F：→ iFEELing:是每投一票就要算票 還是每小時算 還是每天離峰算 03/17 13:51
15F：→ iFEELing:這些都會影響到架構的長法 程式的寫法 機器的配法... 03/17 13:53
感謝說明，目前手邊這個以上面的規劃是綽綽有餘，
只是自己想知道有沒有更好的規劃方法(在有限硬體限制下)
若單純以租用虛擬主機的狀況下
同時處理的投票量大約1~20筆，可能在一定時間內會有定量的讀取量而已
這種負載而言應該是一般主機都能應付的條件
投票後刷新要立刻取得投票量，但不用做到即時更新票數(重整再取得即可)
這裡的精確度個人不是很懂意思~"~
其實我個人的問題是在於，如果投票系統不是短期使用，
而是長期且有穩定使用的狀況下，在上面這種規劃的資料庫結構
是不是會造成影響
例
我要即時從 N 筆投票中取得某個會員對某個投票所投的選項
在取得資料的效率及時間上是否可以因更好規畫而有所提升
PS
個人主要還是只對小型的網站做資料庫規劃，
較少以長期使用的情況做討論，所以想了解多一點
謝謝指導及指教
※ 編輯: kerash 來自: 114.32.186.193 (03/17 17:00)
16F：→ iFEELing:精確度是指 你的票數是否要算到每票 或是取個大概 03/17 18:15
17F：→ iFEELing:如果每分鐘有成千上百的票進來 是否需要每次都分毫不差 03/17 18:17
18F：→ kerash:應該不會到瞬間這麼大量，準確率應該不會有甚麼問題@@ 03/17 20:31
19F：推 KC73:我覺得我會用 memcached + mysql 03/21 23:31