作者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/m.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