[討論] 大量update下,資料庫設計的方式

看板Database (資料庫)作者 (zrae)時間9年前 (2015/01/15 23:14), 9年前編輯推噓8(8016)
留言24則, 4人參與, 最新討論串1/1
各位大大好 最近設計資料庫時遇到一些問題 想請問前輩 假設一個網站上面有50個功能,每個功能結束時會call一個api去update 一張資料表的欄位 及 select 動作。 若同時間約有10萬人使用這50個功能,而且不用批次寫入資料庫的方式, 有比較好的設計方式? 我的想法是,將這一張資料表,在依功能拆成5~10張小表, 分散資料表被request的數量。 網路上有找到Partition Table的資訊,但無奈看不是很懂, 想請各位前輩有沒有好的方式,關鍵字也可以QQ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.96.111.149 ※ 文章網址: https://www.ptt.cc/bbs/Database/M.1421334858.A.E4B.html

01/16 10:44, , 1F
用戶行為結束後, 為何還要select 給他? 這個overhead
01/16 10:44, 1F

01/16 10:44, , 2F
有點危險~
01/16 10:44, 2F

01/16 13:23, , 3F
原po指的SELECT 應該是 UPDATE 完後使用者要看新的資料
01/16 13:23, 3F

01/16 13:25, , 4F
給原po: 你的系統可以同時間承載10萬人連上來用嗎?
01/16 13:25, 4F

01/16 13:26, , 5F
如果不行,那你何必去考量這個情況?
01/16 13:26, 5F

01/16 15:36, , 6F
效能是個問題,deadlock也得考慮,AP加個排queue功能
01/16 15:36, 6F

01/16 15:36, , 7F
或許犧牲一點點即時性但整體穩定會比較好一些
01/16 15:36, 7F

01/17 21:51, , 8F
你的update與select可否再描述一下。例如是否update同一
01/17 21:51, 8F

01/17 21:51, , 9F
筆row,還是有其他where條件值。
01/17 21:51, 9F
我有一個總表 去記錄每個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

01/18 00:14, , 10F
你有client sn與任務sn 所以就不會存在同一筆row update
01/18 00:14, 10F

01/18 00:14, , 11F
問題,lock問題沒有程式干預就還好。你的問題在於可能會在
01/18 00:14, 11F

01/18 00:14, , 12F
單一table的select產生大IO。
01/18 00:14, 12F

01/18 00:19, , 13F
能盡量拆分table就儘量拆,wher
01/18 00:19, 13F

01/18 00:19, , 14F
e條件要考慮index,同一語句下若where條件太多先用子查詢縮
01/18 00:19, 14F

01/18 00:19, , 15F
小範圍,記得同一sql語句 子查詢會先載入在記憶體。
01/18 00:19, 15F

01/18 00:23, , 16F
partition概念有點像是用月份拆分不同減少IO。建議用程式
01/18 00:23, 16F

01/18 00:23, , 17F
解決,開發階段先別考慮partition。
01/18 00:23, 17F

01/18 00:33, , 18F
加油,硬體上大陸有用一台AIX+夠強的Storage撐整個中國的
01/18 00:33, 18F

01/18 00:33, , 19F
春運,沒理由臺灣不行。
01/18 00:33, 19F

01/18 00:45, , 20F
你說的index是必須存在的,但是index也是一個table,假設Ro
01/18 00:45, 20F

01/18 00:45, , 21F
w過多也是要把Table用陳舊資料的方式區分,最簡單是用日
01/18 00:45, 21F

01/18 00:45, , 22F
期月份年份區分。
01/18 00:45, 22F

01/18 00:55, , 23F
看起你的問題瓶頸會在selectIO
01/18 00:55, 23F

01/23 11:00, , 24F
從你的敘述看起來任務條件表是拿來讀的? 那何不進 cache ?
01/23 11:00, 24F
文章代碼(AID): #1KjzbAvB (Database)
文章代碼(AID): #1KjzbAvB (Database)