作者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