作者keke0421 (zrae)
看板Database
标题[讨论] 大量update下，资料库设计的方式
时间Thu Jan 15 23:14:15 2015
各位大大好
最近设计资料库时遇到一些问题 想请问前辈
假设一个网站上面有50个功能，每个功能结束时会call一个api去update
一张资料表的栏位 及 select 动作。
若同时间约有10万人使用这50个功能，而且不用批次写入资料库的方式，
有比较好的设计方式？
我的想法是，将这一张资料表，在依功能拆成5~10张小表，
分散资料表被request的数量。
网路上有找到Partition Table的资讯，但无奈看不是很懂，
想请各位前辈有没有好的方式，关键字也可以ＱＱ
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 175.96.111.149
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Database/M.1421334858.A.E4B.html
1F：推 iamnotfat: 用户行为结束後, 为何还要select 给他? 这个overhead 01/16 10:44
2F：→ iamnotfat: 有点危险~ 01/16 10:44
3F：→ gname: 原po指的SELECT 应该是 UPDATE 完後使用者要看新的资料 01/16 13:23
4F：→ gname: 给原po: 你的系统可以同时间承载10万人连上来用吗? 01/16 13:25
5F：→ gname: 如果不行,那你何必去考量这个情况? 01/16 13:26
6F：→ konkonchou: 效能是个问题，deadlock也得考虑，AP加个排queue功能 01/16 15:36
7F：→ konkonchou: 或许牺牲一点点即时性但整体稳定会比较好一些 01/16 15:36
8F：推 wen001: 你的update与select可否再描述一下。例如是否update同一 01/17 21:51
9F：→ wen001: 笔row,还是有其他where条件值。 01/17 21:51
我有一个总表 去记录每个client对於某项任务的值
有一个任务条件表 去记录每个任务 达成的条件
例如 吃有一个任务是吃50碗饭
使用者吃完时
我会先去 更新总表内对於此任务的值 maybe 是 49
更新完後 我会去条件表抓此任务 完成的条件 在这个情况是50
若49 = 50 我就会通知使用者完成了
所以update的确是有where条件，条件是某个clientSn和任务Sn
select也是有where值的
而以上所说的是 指是对於单一使用者而言
而我们公司 伺服器的数量 的确可以乘载10万人以上 这是没问题的
只是 因为要达到 任务完成 就要马上通知使用者 该任务完成
我觉得这样会对总表有大量的update 以及对任务条件表 大量的select
是有想过用index的方式 或者将总表拆成小表
不过还是想问问有没有更好的方式
※ 编辑: keke0421 (36.230.134.221), 01/17/2015 23:43:50
10F：推 wen001: 你有client sn与任务sn 所以就不会存在同一笔row update 01/18 00:14
11F：→ wen001: 问题，lock问题没有程式干预就还好。你的问题在於可能会在 01/18 00:14
12F：→ wen001: 单一table的select产生大IO。 01/18 00:14
13F：推 wen001: 能尽量拆分table就尽量拆，wher 01/18 00:19
14F：→ wen001: e条件要考虑index,同一语句下若where条件太多先用子查询缩 01/18 00:19
15F：→ wen001: 小范围，记得同一sql语句 子查询会先载入在记忆体。 01/18 00:19
16F：推 wen001: partition概念有点像是用月份拆分不同减少IO。建议用程式 01/18 00:23
17F：→ wen001: 解决，开发阶段先别考虑partition。 01/18 00:23
18F：推 wen001: 加油，硬体上大陆有用一台AIX+够强的Storage撑整个中国的 01/18 00:33
19F：→ wen001: 春运，没理由台湾不行。 01/18 00:33
20F：推 wen001: 你说的index是必须存在的，但是index也是一个table,假设Ro 01/18 00:45
21F：→ wen001: w过多也是要把Table用陈旧资料的方式区分，最简单是用日 01/18 00:45
22F：→ wen001: 期月份年份区分。 01/18 00:45
23F：推 wen001: 看起你的问题瓶颈会在selectIO 01/18 00:55
24F：→ gname: 从你的叙述看起来任务条件表是拿来读的? 那何不进 cache ? 01/23 11:00