※ 引述《FireLake (XXX)》之銘言：
: ※ 引述《JoeHorn (每天都在公司玩OLG)》之銘言：
: : 一個 DB connection 可以執行很多次 SQL statements，
: : 你舉的這個例子只需要 transaction，但是.. 可以用同一個 connection。
: : 更何況，很多程式語言有 connection pool 管理能力。
: : （因為可以用同一個 connection，以下我就不回了.. 因為都不是考量因素）
: 這部份完全沒有解釋performance上的問題，用不用 connection pool 都
: 一樣。
: 一個 DB connection 的確是可以執行好幾個SQL，但要注意到的是每執行
: 一個SQL就是一次從client到server的 round trip。重複使用同一個 DB
: connection 或是用 connetion pool 只能省下 login, authetication,
: 和一些 initialization 的時間，但是執行每一個 SQL，還是需要從 client/
: application 把 sql statement 或是 binding variable 的值傳到
: server/db (當已有curosr時)。此外，執行完後 server/db 還要把結果傳
: 回去。這不只是傳輸時間而已，處理每一個 SQL 時，database要花時間在
: 解析sql statement、處理cursor、binding variable、重新取得lock上面，
: 非常沒有效率。
: 用個簡單的例子，現在有10個SQL要執行，就叫做 SQL 1 到 SQL 10 好了，
: SQL 10 要依據 SQL 9 的結果，SQL 9 要依據SQL 8 的結果，以此類推。用
: stored procedure 只要一個 round trip，不用的話就要10次，這在效能上
: 有很大的差別，而且如果其中有幾個SQL要傳回大量的資料，不用 stored
: procedure 的效能會是最糟糕。
: 把 logic 放在 stored procedure 或是 application 各有利弊，但在
: performance 上，使用 stored procedure 有很大的優勢。
對一半
一般來說 performance 當然直接用 SP 比較好.
如你所說, 省了 round trip 就差很遠了.
問題在於 scalability.
DB 相比起 app server, scalability 不可同日而語.
你的系統可能用 SP, 應付一百人沒問題, 但要應付一
千人, DB 機器的 CPU, memory 都花在 biz logic 上,
你要找一部更強的 DB 並不是想那麼容易, 價錢也可以
嚇你一大跳.
同樣能應付一百人份量的複雜 SP 的 DB, 單用來作簡
單的CRUD operation, biz logic 移回 app server,
DB 應付一千人份量的 simple CRUD 說不定也綽綽有餘.
一般作為 transactional 類型的 application, 要應付
多一些 user, 差不多按比例加 app server 數類就行了.
(DB 可不是簡單加 server 就能應付更多 user)
當然不能一刀切. 有些大量資料的處理, 比如 batch
processing 之類, 把部份東西放回 SP 做也是蠻正常
的做法.
(這類單談 performance/scalability, multi-tier 對
於架構和設計上的好處就不說了)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.238.156.185