Tiny URL design
常見誤區：
- 流量一定巨大無比
- 流量大所以要用 NoSQL
- 一定要用 distributed system => 都需要經過思考＆討論！
4S 分析
Scenario:
- 長網址轉短網址
- 短網址查找長網址
Storage: 以 DAU = 100M 來看，假設每人有 0.1 個 (1) 需求，則流量為 100M * 0.1/86400 約 120 (average), peak 250。 (2) 的需求較多，假設為每個人都用，則 100M/86400 約為 1K, peak 2K, 那麼 cache + SQL 的設計可能就很足夠
硬碟的話， 平均來說，一條 100 bytes，則 100M * 0.1 * 100 約為 1G，那三年約用 1T
SQL ro NoSQL ?
- 複雜 query?
- transanction?
- Scalibility?
- 長到短網址的算法需求？
算法可用
- 隨機產生，再去搜尋是否有重複 (很實用！)
- Base62 生成 => 依賴 Sequential ID, SQL 在多台機器情況下很難去維持唯一的 id, 所以用 Base62 會有這個問題
Base62:
// base62 code
若基於 random, 則需要存一張 short, long 表，short、long 都要建立 index，才能互相查找對方。
若用 NoSQL，則需要兩張表，因為 NoSQL 一般不支持 multi-index
基於進制轉換的做法只能使用 SQL，因為要有全局不變的那個 id，
不過變成只要存 id 和長網址即可，因為短網址可以用 ID 算出來 =>
| id | longURL (index = true) |
|---|---|
Optimization:
短網址是一個讀多寫少的系統，馬上想到可以用 cache 優化，這邊為"資料讀取優化"
另一方面是"服務器訪問優化“，可以根據地理位置來優化:
部屬多台機器到不同地區，請求經過 DNS 解析後，根據 IP 發送到最近的服務器
而 server 間的訪問是可以優化的，經由 router，client <-> server 卻是比較難優化
(寧願台灣server訪問美國 server 也不要台灣 user 訪問美國 server)
最後是一些想法：
- S -> L 一定是一對一
- L -> S 可以一對多，多個又何妨？
- (S, L), (L, S) 都存也可以，全看需求
- 主要是不要廣播詢問，鐵定很慢