物件儲存（S3 那類）刻意用效能換耐久、規模與低成本。它不是檔案系統——扁平命名空間、RESTful API、物件不可變、寫一次讀多次。
🧠 Core Ideas
TIP
三種儲存分層記：區塊＝裸磁碟區塊（最彈性、給 DB/VM 榨效能）；檔案＝目錄樹（通用共享）；物件＝扁平 + REST API（海量冷資料、備份封存）。往上一層抽象、往下一層效能。
- 物件儲存把資料當扁平的 object放，沒有目錄階層，用 RESTful API 存取。
- 針對相對「冷」的資料，犧牲效能換高耐久 + 巨大規模 + 低成本。
- 存取模式是寫一次、讀多次（研究顯示約 95% 是讀）。
⚖️ Tradeoffs
三種儲存怎麼選
- 區塊：成本高、效能最高、強一致；給資料庫、VM 這種要直接管區塊榨效能的。
- 檔案：目錄樹 + 標準協定（NFS/SMB），組織內共享檔案的通用解。
- 物件：可擴展性巨大、成本最低、效能低至中；二進位/非結構化資料、封存備份。
物件儲存的關鍵特性
- 物件不可變：只能刪除或用新版本整個取代，不能原地增量改。
- 本質是個 KV store：物件 URI 是 key、物件資料是 value。
- 術語：Bucket（全域唯一的邏輯容器）、Object（payload + metadata）、Versioning（bucket 層級開啟，救回誤刪/覆寫）、以 URI 唯一識別、用 SLA 承諾耐久與可用（如 11 個 9 耐久）。
metadata 與 data 分離（像 UNIX inode）
- 設計哲學仿 UNIX 檔案系統：檔名/位置放 inode、資料放別處。
- 物件儲存把它拆成 metadata store（記物件 ID → 位置）與 data store（真正的位元組），兩者分開擴展。
🔑 Takeaways
- 物件儲存 = 扁平 + REST + 不可變 + 寫一次讀多次，拿效能換耐久/規模/成本。
- 選型記三層：要效能給 DB → 區塊；要共享檔案 → 檔案；要海量冷資料 → 物件。
- 底層是 KV（URI→資料）+ metadata / data 分離，才撐得起 PB 級與巨量物件。
No notes yet — jot your takeaways or Q&A here.