隨便試著寫一下考卷 賺個P幣 ※ 引述《taliao (雲淡風清)》之銘言： : 有趣的問題，來一些激盪吧～ : Q: 你怎麼知道 CRUD 分別吃多少系統資源？需要多少 IOPS / CPU? : Q: 承上，要如何知道 CURD 吃了哪些資源？ : Q: 承上，怎麼解開這些資源的分配問題？ 其實這題超難回答。實務上會分為 Script 所吃的資源跟儲存對象所吃的資源。 Script 來說 Python/Ruby/Node.js 等每個 Process 都會吃到 CPU + 記憶體 儲存對象除了 CPU 跟記憶體之外也會吃到 Disk I/O。 當你做 Create 的動作時，Script 端會需要用 CPU 跟記憶體去運算邏輯 把插入的指令傳給資料庫，資料庫除了 CPU 運算，以及將資料寫入磁碟的 I/O 外 還會視資料庫的索引跟快取優化去做其他優化的記憶體/磁碟 I/O 運算 因此一個準確的 IOPS/CPU 不太容易得出，但是我們可以透過系統監測 透過實質的 CPU、記憶體、I/O 使用率去得到系統大致的運轉狀態 並使用資料庫系統的 EXPLAIN 得知儲存上的瓶頸點 : Q: 1 個連線的 CRUD、10 個連線的 CRUD、100 個的 CRUD ..... 類推， : 他們的架構是怎樣？ 很簡單的 CRUD 1 個連線 1個實體 =============== DB 實務上的 CRUD 架構 Load balancer -- A XX個實體 == 連線 Pool == DB with sharding -- B XX個實體 == 連線 Pool == -- C XX個實體 == 連線 Pool == -- D XX個實體 == 連線 Pool == : Q: CRUD 的對象是 RDBMS? NoSQL? Block Storage? Cache? Buffer? : Q: 承上: CRUD 的對象怎麼選？我只會 MySQL 啦，都往裡面塞就是了 ..... 這題每個人答案應該都不一樣，以下是我個人見解。 Block Storage 跟 Buffer 我不知道他想表達什麼，先 Skip QQ RDBMS 解決問題的方式是透過表格與關聯，複雜的查詢可以透過 JOIN 關聯解決。 通常適用於大多數的使用情境，但需要定義固定 Schema 是一個考量點。 NoSQL 要視其使用的資料結構和分散式儲存的策略來選擇 嚴格說來某些 Cache (e.g. Redis) 甚至都可以算是一種 NoSQL 了 你需要儲存簡單的資料結構就可以塞在 Redis 你需要一個給我 JSON 內容我就可以塞進去的儲存空間就可以用 MongoDB : Q: 前端怎麼知道 CRUD 瓶頸在哪？ 最爛的答案：開發者工具，看哪一個 Request 吃掉最多秒數...... : Q: CRUD 的操作對象，不管是 RDBMS, NoSQL, Storage, Cache， : 瞬間流量衝進來怎麼處理？會遇到什麼問題？ : Q: 線上的系統 CRUD 出問題了，怎麼知道哪裡出問題？ 就像連假高速公路塞車一樣，一超出設計極限，哪邊就會炸掉 這個時候就要找出系統的瓶頸點，試著去一個一個解決問題 首先你 Script 的執行實體夠不夠多？不夠的話就會塞在最前面 這個時候的症狀是你的 QPS (等待人數) 很多，但你的櫃台開不夠多所以塞住 這個時候就要打一個 Process Manager 讓它 Spawn 好幾個實體進去 如果櫃台都開很多了，結果每一個櫃台處理業務的時候都後台當住 這個時候就要思考 Storage 上是不是有瓶頸點 首先，在 DB 跟 Script 之間要不要做 Connection Pool 再來，你有沒有優化資料庫的 Query？哪些 Query 特別慢？ EXPLAIN 出來發現哪裏有問題？要怎麼打 Index 或著重新設計結構來優化？ : Q: 當現有的架構要拆分的時候 (microservices)，你的 CRUD 還是 CRUD? 我的猜測：嚴格說來還是 CRUD 只是本來單一架構中不同資料的互動，會變成不同微服務之間的溝通 : Q: 當系統是分散式的時候，CRUD ... 要怎麼辦？ 我不知道怎麼回答 QQ : Q: 你的 CRUD 考慮的是 ACID or BASE? 還是這啥？ ACID 是傳統 RDBMS 為了資料安全性做的保障 BASE 是 NoSQL 為了犧牲一部份保障換取更高效率或擴張性做的妥協 願不願意接受這個妥協要視服務本身的特性而定 如果你的資料量非常大，而且可以接受幾微秒的資料不一致性，那 BASE 就可以了 : Q: 寫十年的 CRUD 然後都做一樣的事情？那中年一定失業。 : 但是可以處理瞬間百萬 qps 的 CRUD，你中年一定很忙。 : 下一系列的 Q : Q: 哪裡有百萬 qps 的系統啊？qps 是啥？ : Q: 當有的時候，你準備好了嗎？ : Q: 台灣沒有百萬的 qps 啊，國外有，你準備好了嗎？ : Q: golang 很屌，可處理百萬 qps，是這樣？node.js 不行？C# 不行？ : Q: 買一台 2048 core 的機器就可以搞定了，需要說那麼多嗎？ ..... : .... 其實我覺得任何程式語言處理百萬 QPS，技術上只要機器夠大就可以 但是你了不了解這個程式語言的特性，它能做什麼，怎麼優化它 才是一個長期而且可能沒有盡頭的學問 如果你的框架很大，如何優化記憶體使用？ 你的程式語言是編譯的還是直譯的？如果是直譯，直譯器有沒有 JIT？ 記憶體如何管理/需不需要 GC？如何偵測 Memory Leak？ 這些問題的答案會隨你用的程式語言跟框架而不同 而同樣的機器可以應付多少 Request per sec 也隨技術上花了多少力氣而不同 --- 大概是這樣，鞭小力一點 QQ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.168.79.225 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1527961025.A.BC9.html