Re: [閒聊] 開發一定要用MVC架構 ?

看板Soft_Job (軟體人)作者 (mapleone)時間11年前 (2013/07/02 23:29), 編輯推噓11(11013)
留言24則, 12人參與, 最新討論串9/9 (看更多)
※ 引述《iFEELing (ing)》之銘言: : DB Server 的資源很貴的 : 明明提供一堆 AP server 在那邊等著算資料 : 結果一整櫃的機器畫完 UI 之後就在IDLE : 然後大家來搶 DB server 的 cpu 算商業邏輯 : 然後原本 DB 要做的 sort / merge / hash 等不到 CPU 在那邊 WAIT .... : 要你是 DBA 你火不火? DB 和 AP 的資源一直都是爭論不休的焦點 我曾經遇過和 IFEELing 正好相反地狀況 DB 資源超級珍貴, select 只准 join 最多兩個表格, 最好自己把資料拉回 AP 處理。 PS. 明明 DB 和 AP 就在同一台機器上,這麼做有意義嗎? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 36.231.78.66

07/02 23:35, , 1F
同一台實體機器可以切不同資源 如VM或LPAR
07/02 23:35, 1F

07/02 23:35, , 2F
即使在同一個OS 也是有NICE之類的可以調 雖然效用嘛.....
07/02 23:35, 2F

07/02 23:38, , 3F
join真的是耗費很多資源 特別是很多個上百萬筆的一起
07/02 23:38, 3F
額外插個疑問。 小弟我不是 DBA ,對資料庫的觀念只有大學時代上過的一門資料庫管理系統概論 假設有兩個 Table A 和 B, Table A 有 N 筆紀錄,Table B 有 M 筆紀錄, N 和 M 都是百萬以上。 假設我的條件只從 Table A 取 x 筆資料, Table B 取 y 筆資料。 x 和 y 都小於 100 也就是 Select * from A join B on ... where ... 資料庫到底會做出多少筆資料的 Join 呢? (1) x * y (2) N * M (3) 其他 從我遙遠的記憶中,老師曾經教過 worst case 是 N * M,然後再用 where 條件 篩選。但那已經是十年前的課程內容 現在的商業資料庫真的還會做出 N * M 這種結果嗎?

07/03 00:18, , 4F
想知道+1
07/03 00:18, 4F
※ 編輯: mapleone 來自: 36.231.72.218 (07/03 00:23)

07/03 00:37, , 5F
inner join 不會那麼瞎啦。你可以跑SQL看依下執行時間阿
07/03 00:37, 5F

07/03 01:36, , 6F
如果 join 的相關欄位沒 index, 應該會變 N + M
07/03 01:36, 6F

07/03 02:45, , 7F
有索引很快的...
07/03 02:45, 7F

07/03 07:21, , 8F
mssql可以看實際執行計畫,其他不知不過應該也有吧?
07/03 07:21, 8F

07/03 07:33, , 9F
因為我們當 PG 的人通常沒有進入 DB 的權限,所以也看不
07/03 07:33, 9F

07/03 07:33, , 10F
到執行計畫。
07/03 07:33, 10F
※ 編輯: mapleone 來自: 111.248.3.242 (07/03 09:35)

07/03 10:49, , 11F
我們有測試用db,裡面是正式機某一時間的snapshot,所以可以
07/03 10:49, 11F

07/03 10:49, , 12F
07/03 10:49, 12F

07/03 10:55, , 13F
有建索引的話,是 log N x log M,這麼大的資料本該建索引
07/03 10:55, 13F

07/03 10:57, , 14F
寫錯.... 是 log N + x * log M @.@
07/03 10:57, 14F

07/03 10:59, , 15F
不過這要看 where 是否可以直接使用索引而定
07/03 10:59, 15F

07/03 11:59, , 16F
所以要有反正規化設計,資料表拆的太多,就得一直join
07/03 11:59, 16F

07/03 11:59, , 17F
當然index的建立與正確的使用where也很重要
07/03 11:59, 17F

07/04 00:30, , 18F
不管是不同一台機器,這樣做資源是可以靈活調動的,最
07/04 00:30, 18F

07/04 00:30, , 19F
後看瓶頸在那,就可以獨立硬體
07/04 00:30, 19F

07/04 00:38, , 20F
join 資料的使用是呈等比級數上升,當然盡量必免,一般
07/04 00:38, 20F

07/04 00:38, , 21F
人在使用比較不會去考慮,當然要限制,除非了解狀況的人
07/04 00:38, 21F

07/04 00:38, , 22F
,若在程式上做,做法比較靈活
07/04 00:38, 22F

07/04 01:20, , 23F
關聯式資料庫的話 worst case應該是N+M
07/04 01:20, 23F

07/04 01:21, , 24F
但是group by下錯語法會變成N*M的樣子
07/04 01:21, 24F
文章代碼(AID): #1Hql784X (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1Hql784X (Soft_Job)