這禮拜繼續讀 <System Design Interview- An insider’s guide> 第二章。這章很短，不過帶出一個很重要的概念－數字估算。
Chapter 2: 粗略的估算
在了解系統設計的基礎架構思路後，下一步我們便需要了解，依照這個思路所架構的系統，它的能耐、效能表現究竟如何。
我們必須要先知道有哪些常見的系統效能指標，並且知道該怎麼粗略的去估算它們。在取得這項能力之前，這本書推薦了一些必須熟悉的基礎常識，這有助於我們在估算系統效能指標上可以更駕輕就熟。
以下我就用 top-down 的方式來 recap 這些概念（會跟原文順序相反），並再補充一點細節。
1. 常見的系統效能指標
- QPS（Query Per Second）:
- 描述資料庫或是搜尋引擎的每秒鐘查詢數量。
- QPS 峰值:
- 一般情況下，QPS peek 會等於 QPS * 2。
- 儲存空間：
- 儲存各種數據，包含document, media, logging等，的空間。會以 bytes 為單位。
- 可能指特定檔案儲存空間，也可能指整體儲存空間。
- 伺服器數量：
- 用於不同目的的伺服器總數量，包含Web server, DB server, document server, mail server 等。
- 可能指特定類型伺服器數量，也可能指總共伺服器數量。
2. 必須熟悉的基礎知識
(1) Table of metrics
Quantity related metrics
在軟體領域，通常我們會用 2 的次方來定義這些單位（因為我們使用 byte 為單位存儲）；在電子通訊或是物理學領域，通常則會使用 10 的次方來定義這些單位。
- kilo: = 210 ~= 103
- mega = 220 ~= 106
- giga = 230 ~= 109
- tera = 240 ~= 1012
- peta = 250 ~= 1015
- exa = 260 ~= 1018
- zetta = 270 ~= 1021
- yotta = 280 ~= 1024
Speed related metrics
- milli: = 10-3
- micro: = 10-6
- nano: = 10-9
- pico: = 10-12
- femto: = 10-15
- atto: = 10-18
- zepto: = 10-21
- yocto: = 10-24
在軟體領域中，由於容量通常以 byte 為儲存單位，因此容量單位習慣使用 2 為基底的乘數，方便二進制系統的溝通；而由於速度通常是看每秒多少個bit，因此習慣以 10 為基底的乘數，可以更直接簡單的反應單位時間內的傳輸位元數量。
(2) 幾個延遲相關的數字
書中介紹了 13 個常用的延遲相關數字，由 Google 的 Jeff Dean 在 2010 年提出：
| Operation | Time (ns) | Time (us) | Time (ms) | Notes |
|---|---|---|---|---|
| L1 cache reference | 0.5 | |||
| Branch mispredict | 5 | |||
| L2 cache reference | 7 | 14x L1 cache | ||
| Mutex lock/unlock | 25 | |||
| Main memory reference | 100 | 20x L2 cache, 200x L1 cache | ||
| Compress 1K bytes with Zippy | 3,000 | 3 | ||
| Send 1K bytes over 1 Gbps network | 10,000 | 10 | ||
| Read 4K randomly from SSD | 150,000 | 150 | ~1GB/sec SSD | |
| Read 1 MB sequentially from memory | 250,000 | 250 | ||
| Round trip within same datacenter | 500,000 | 500 | ||
| Read 1 MB sequentially from SSD | 1,000,000 | 1,000 | 1 | |
| Disk seek | 10,000,000 | 10,000 | 10 | 20x datacenter roundtrip |
| Read 1 MB sequentially from disk | 20,000,000 | 20,000 | 20 | 80x memory, 20X SSD |
| Send packet CA->Netherlands->CA | 150,000,000 | 150,000 | 150 |
主要要記的就是這 13 個指標，另外書中有提到一些需要記得的延伸內容：
- 記憶體查詢速度快、disk 慢
- 簡單壓縮法（zippy）速度很快
- (其他過於基本暫略)
(3) SLA
SLA (Service Level Agreement, 又稱服務等級協議)，是 service provider（eg: AWS, Google）常使用的術語，定義了 service 提供的服務等級。
SLA 通常會以 99.9% 為正常基準，小數點後的 9 越多，代表服務等級越好。甚至 9 的數量可以換算成系統停機時間。
比如書中有提到，正常水準 99.9 %的每天停機時間為 14.4分鐘，99.9999%的每天停機時間為 86.4 毫秒。
3. 範例：估算 Twitter 的 QPS
實際在做系統效能指標估算時，必須謹記三點：
- 把你的假設與思路寫下來：你要用哪些數字計算這些指標？記下他們，方便釐清也方便日後參考。
- 標記單位：你使用的這些數字是什麼單位？寫下來，才不會搞混。
- 善用近似法、四捨五入：盡量用簡單乾淨的數字做計算比較方便，不求精確程度。比如題目給說每秒 query 數是 197，可以近似為 200。
假設系統 Twitter:
- 每月有 3 億活躍用戶
- 每天有 50% 的用戶使用 Twitter
- 用戶平均每天發 2 則推文
要估算 QPS:
- QPS = 每日推文總數 / 一天的秒數
- 每日推文總數 = 3 * 108 * 50% * 2 = 3 * 108 則
- 推文 QPS = 3 * 108 / (24 * 3600 秒) ~= 3500
這邊要注意的是，每月 3 億用戶是假設每天流量都是 3 億，整個月都是如此。所以不用把 3 億除以30。
Conclusion
這章實際帶系統效能估算只有帶了 QPS 跟 儲存空間，感覺 server 數量也是一個很重要的指標，可能需要額外思考如何計算。
不過透過這章的介紹，我也瞭解了必須熟記很多容量與速度單位的重要性，以及哪些效能指標是重要的，在估算時可以謹記三點讓自己估算時可以更清楚。