Vendor / Platform 清單

實作時的常用選擇見 vendors — T1 收錄 PostgreSQL / MySQL / SQLite / MongoDB / DynamoDB / CockroachDB / Aurora，每個服務頁提供定位、適用場景、取捨、容量判準、案例對照與下一步路由。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

暫定分類

選型入口

資料庫選型的核心判斷是資料是否承擔正式狀態與一致性。當資料需要長期保存、支援查詢、被多個流程共同讀寫，並且需要交易保護時，應先評估 relational database 或 document database。

SQLite 適合單機服務、embedded app、測試資料庫與低操作成本場景；PostgreSQL 適合多使用者後端、複雜查詢、transaction、index 與長期 schema evolution。Migration 工具解決 schema 隨版本演進的問題；transaction boundary 解決多筆資料一起成功或失敗的問題；repository adapter 解決 application port 到具體 SQL 實作的轉換。

接近真實網路服務的例子包括訂單系統、會員系統、訂閱方案、付款紀錄與權限資料。這些資料都需要明確 source of truth，因此本模組會從資料模型、一致性、migration 與 repository adapter 邊界開始說明。

與語言教材的分工

語言教材處理 repository interface / protocol、取消與逾時、error wrapping、memory fake 與 contract test。Backend database 模組處理 SQL schema、migration tool、transaction isolation、connection pool 與資料庫錯誤語意。

跨模組端到端串聯（DB → cache → event → observability）見 0.15 跨模組 Checkout Episode。

章節列表

觀念網路補完方向

資料庫章節下一輪的核心責任是把正式狀態的演進路徑講完整。現有章節已經涵蓋 schema、transaction、repository adapter 與 migration playbook，但還需要補上 state ownership、query boundary、migration safety 與 reconciliation 之間的引用關係，讓讀者知道資料庫變更如何從設計、發布、觀測一路接到事故決策。

這些方向要寫成資料庫自己的敘事，避免把 04/06/08 的欄位直接搬進來。資料庫關心的是狀態能否正確演進；觀測、驗證與事故流程接收這個演進結果作為下游證據。

知識卡補強方向

資料庫模組的 knowledge card 缺口集中在「變更如何被驗證」與「資料如何被修復」。已有 schema migration、Expand / Contract、backfill 與 dual write 可作為第一批錨點。

下一批候選卡片包括 migration validation、read compatibility、cutover window、reconciliation、data repair runbook 與 fail-forward migration。這些卡片要先定義服務責任與使用時機，再讓 1.6 migration playbook 與後續實作文章引用。

Vendor 文章規格入口

資料庫 vendor 文章的下一輪重點是把 PostgreSQL / MySQL batch 經驗變成可重複使用的撰寫規格。後續寫 SQLite、MongoDB、DynamoDB、Aurora、Spanner、Cosmos DB 與 CockroachDB 前，先讀 資料庫 Vendor 文章撰寫規格；該文分清 vendor overview、deep article 與 migration playbook 的責任，並列出 PG / MySQL 回收出的橫向調整項。

實作探討入口

資料庫的第一條實作路徑已完成： 1.7 Schema Migration Rollout 證據實作示範。這篇以訂單資料表付款狀態欄位演進為例，說明 migration plan、validation query、rollback condition 與 incident decision route 如何一起成立。

這條路徑的前置引用是 1.2 schema design、1.3 transaction boundary、1.6 migration playbook、6.11 Migration Safety 與 4.20 Observability Evidence Package。完成後可依 Backend 學習路線 進入 02 cache migration。

資料庫路徑的 artifact 對齊重點是「先證明資料演進正確，再討論是否放行」。對 4.20 要交 Source/Time range/Query link/Owner/Data quality，並在 query 內容覆蓋 validation query、row count 差異與 replication lag；對 6.11 / 6.8 要交 Gate decision/Checks/Stop condition/Rollback window/Owner，呈現 expand/contract 分段結果；對 8.19 要交 Timestamp/Decision/Context/Evidence/Owner/Expected effect/Rollback condition，記錄 pause / rollback / fail-forward 的判斷與依據。

跨分類引用

• → infra 模組五：資料庫上 IaC：RDS 的 IaC 描述（subnet group、parameter group、連線管理、read replica）與部署順序
• → infra 模組五：Stateful 資源保護：multi-AZ、backup retention、deletion protection、PITR 的 IaC 設定

跨語言適配評估

資料庫使用方式會受語言的 connection pool、transaction scope、ORM 行為、錯誤處理與 migration 生態影響。同步 thread-based runtime 要控制 blocking query 與 pool 大小；async runtime 要確認 database client 是否真正非阻塞；輕量並發 runtime 要限制同時查詢數量，避免把大量 task 轉成資料庫連線壓力。強型別語言適合把 row mapping、schema 與錯誤分類型別化；動態語言則需要靠 migration、runtime validation、fixture 與 contract test 保護資料邊界。

實測日期：2026-07-01 環境：macOS Apple Silicon、Ollama 0.7.x、nomic-embed-text（768 維） Corpus：content/ 全量 2,738 個 markdown 檔、24,216 chunks 前置 demo：rag-demo（pickle、463 chunks）

讀法建議

本案例用 Go 重寫了 RAG storage 層，Go 實作細節佔不少篇幅。依你的背景選讀法：

• Python 開發者、想選自己專案的 storage 方案：先跳到「通用可複製流程」（語言無關的五步驟）→「四方案 benchmark」→「二次選型評估」（結論/理由/前提三層框架），這三段跨語言可遷移。Go 實作段（架構、效能優化）可 skim。
• Go 開發者、想做類似工具：從頭讀，每段都跟你相關。
• 只想看選型框架、不管實作：直接跳「二次選型評估」。

從 demo 到 production 的重寫動機

rag-demo 用 Python pickle 跑通了 RAG 概念驗證：71 篇 → 463 chunks → pickle 儲存 → cosine retrieval → Ollama 生成。概念層完全正確（4.1 的 retrieval + augmentation 骨架），但作為這個 blog 的日常工具有三個專案特有的限制：

1. 工具鏈語言不同：blog 的核心工具是 Go（lint / fmt / cards），加 Python dependency 讓其他維護者 clone 後多一步環境設定。Python 專案不會有這個問題 — pickle 綁 Python 對 Python 專案是優點而非缺點。
2. 只索引部分 corpus：rag-demo 只跑 content/llm/（71 篇），blog 全量有 2,738 篇、24 個 section。
3. Demo 定位：ingest.py / query.py 是教學程式碼，不是維護工具（沒有 status、沒有 section filter）。

這是一次完整重寫、不是漸進升級 — rag-demo 的 Python 程式碼不會被修改或遷移，而是用 Go 重新實作相同的 RAG pipeline（chunk → embed → store → search）、保留相同的概念架構。rag-demo 作為教學 demo 繼續存在。

升級目標：一個跟 mdtools 同級的 Go CLI 工具，能對全量 content 做語意搜尋，其他維護者 clone 後 go build 即可用。完整原始碼在 scripts/blogsearch/。

選型過程（對應 4.22 演化階梯 + 工程約束）

第一軸：規模判讀

全量 content 產生 24,216 chunks（原本估計 ~1,500）。按 4.22 判讀樹，24K 落在「10K-100K → HNSW 或 brute-force」區間。預估 vs 實際的 16 倍落差揭露一個教訓：估計 chunk 數不能用篇數乘以常數，要看每篇的實際長度跟 chunking 策略。

第二軸：工程約束（本專案特有）

以下四個 constraint 反映這個 blog 專案的偏好、不是通用判準。換一組 constraint 會篩出完全不同的方案 — Python 專案不會有「Go 單 binary」constraint、已有 Docker 的團隊不會排斥外部 server。讀者套用時應先列出自己專案的 constraint、不是照搬這張表。

剩餘選項：Go + flat file + brute-force。

第三軸：延遲容忍

CLI 工具、每天用幾次、不是 API server。< 500ms 可接受。

結論：選階段二（flat file），brute-force cosine。

實作架構

 1scripts/blogsearch/
 2├── main.go                     # CLI: ingest / query / status
 3├── cmd/
 4│   ├── ingest.go               # walk content/ → chunk → embed → store
 5│   ├── query.go                # load → embed query → cosine top-K → lazy load text
 6│   └── status.go               # index stats
 7└── internal/
 8    ├── chunk/chunk.go           # paragraph-aware markdown chunking
 9    ├── embed/embed.go           # Ollama HTTP API wrapper
10    ├── search/search.go         # brute-force cosine similarity
11    └── store/store.go           # 三檔案 binary store

日常使用

1# 語意搜尋
2./bin/blogsearch query "retry 策略"
3
4# 只搜特定 section
5./bin/blogsearch query -section backend "connection pool 設定"
6
7# 查 index 狀態
8./bin/blogsearch status

Storage 格式（三檔案分離）

1.blogsearch/
2├── vectors.bin    # float32 binary（70.9 MB）— bulk read + unsafe.Slice 零拷貝
3├── meta.json      # compact metadata 不含 text（7.3 MB）
4└── texts.bin      # length-prefixed chunk text（19.2 MB）— top-K 才 lazy load

分離 text 的設計理由：query 時只需要 vectors + metadata 做 cosine search（78 MB），top-K 結果才從 texts.bin 按 offset 讀取 5 筆 text。省掉 19 MB 的 JSON 解析。

效能優化歷程

初版：9.5 秒

初版用逐 4-byte Read 載入 vectors.bin（17.5M 次 f.Read(buf)），加上 27MB 的 index.json（含所有 chunk text）一次 JSON 解析。

優化版：0.34 秒（28x）

三項改動：

瓶頸分析：0.34 秒裡、embedding API call（Ollama）約 77ms、file I/O + JSON parse 約 200ms、cosine 計算約 50ms。cosine 計算只佔 15%。

通用可複製流程（抽掉 Go/blog）

本案例的 Go 實作細節（unsafe.Slice、os.ReadFile）是語言特定的、但背後的流程步驟跨語言通用：

1. Walk corpus：遞迴掃描目標目錄的所有文件（markdown / code / 任意文字）
2. Chunk：段落感知分割、soft token cap、保留語意邊界（原理見 4.1 Chunking）
3. Embed：對每個 chunk 呼叫 embedding API（本地 Ollama 或 cloud API），得到固定維度向量
4. Store：向量 + metadata + text 分離存檔（binary vectors / compact JSON / lazy-load text）
5. Search：embed query → brute-force cosine → top-K → lazy load text for display

Python 實作同流程只是把第 4 步的 binary 檔換成 pickle / FAISS index / SQLite DB、第 5 步的 cosine 換成 numpy / FAISS / sqlite-vec query。Node.js / Rust 同理。

關鍵優化原則也跨語言：「分離向量與文字、query 時只載入向量、top-K 才載入文字」讓 I/O 量從 ~98MB 降到 ~78MB、JSON parse 從 27MB 降到 7MB。這個原則用什麼語言實作都有效。

四方案同 corpus Benchmark

用同一個 corpus（24,216 chunks、768 維、nomic-embed-text）比較四種 storage 方案。Benchmark 腳本在 scripts/blogsearch-bench/bench.py。

前置依賴

Benchmark 腳本讀 Go 工具產生的 index（.blogsearch/ 下的 vectors.bin + meta.json）。完整指令鏈：

1cd scripts/blogsearch && go build -o ../../bin/blogsearch .   # build Go 工具
2ollama serve &                                                  # 啟動 Ollama
3ollama pull nomic-embed-text                                    # pull embedding model
4./bin/blogsearch ingest -content content -out .blogsearch       # 建 index（~4 分鐘）
5uv run --with sqlite-vec --with faiss-cpu --with numpy \
6  scripts/blogsearch-bench/bench.py --index .blogsearch         # 跑 benchmark

若無 Go 環境，可用自己的 Python embedding 腳本產生相同格式的 vectors.bin（little-endian float32、n × dim 連續排列）+ meta.json（{"dim": 768, "count": n, "metas": [...]}），benchmark 腳本只讀這兩個檔案、不依賴 Go binary 本身。Corpus 格式無硬性要求，任何目錄下的 .md 檔案都可索引。

方法論

• Embedding：四方案共用同一組 embedding（從 Go index 載入），排除 embedding model 差異
• Query：同一句 query（“RAG storage 選型”），跑 5 次取 median
• Ingest 時間：只計 storage 操作（不含 embedding），Go 方案含 embedding 不可分離故標 —
• 環境：macOS Apple Silicon、Python 3.12、Go 1.25

結果

三個關鍵發現

延遲瓶頸在 I/O 和實作、不在演算法。Go flat file 的 151ms 裡、cosine 計算約 50ms、file I/O 約 100ms。FAISS flat 用 numpy BLAS 做同樣的 brute-force cosine、純計算 1.8ms — 計算層差約 28 倍（Go pure loop vs BLAS 向量化指令），加上 I/O 後端到端差 84 倍。

HNSW 的 query 加速在此規模 ROI 低。FAISS HNSW query 0.5ms vs flat 1.8ms、每次省 1.3ms。但 HNSW build 要 23.3s。每天查 100 次、要 179 天才回本 build 成本（23.3s ÷ 0.13s/天）。4.22 的判讀結論（「此規模 brute-force 夠用」）被數據驗證。

sqlite-vec 的 19ms 是「DB overhead 換功能」。比 FAISS flat 慢 10 倍、但多了 SQL metadata filter、transaction 保護、disk persistence。對「需要 filter 但不想維運 server」的場景有意義。

讀數據的注意事項

• Go 151ms 含 file I/O（每次 query 重載 78MB）；如果做 daemon mode（常駐、載入一次），query 會降到 ~50ms（純 cosine + overhead）
• FAISS 數字是 in-memory baseline（index 已載入），不含 index 檔案的載入時間
• sqlite-vec 數字含 disk I/O（每次 query 從 SQLite 讀取），是 persistent storage 的真實代價
• 四方案都不含 Ollama embedding call 時間（~77ms），實際端到端延遲要加上

二次選型評估：同結論、理由鏈翻轉

Benchmark 數據出來後，80 倍效能差距讓原始選型（Go + flat file）受到質疑：「是否該換 Python + FAISS 或 sqlite-vec？」重新用 WRAP 框架評估，結論相同（維持 Go），但理由鏈完全不同。

第一次選型的理由（事前）

「Go 工具鏈統一（mdtools 是 Go）+ 單 binary 分發（clone 後 go build 即可）。」

實測推翻的前提

第一次的理由鏈幾乎全數被推翻。如果只看理由，應該換方案。

第二次選型的理由（事後）

重新評估時加入三個第一次沒有的變數：

端到端延遲 vs in-memory benchmark。84 倍是端到端的數字（Go 151ms 含 I/O vs FAISS 1.8ms in-memory）。但 FAISS 從 disk 載入 index 也要 ~100-200ms，端到端差距縮小到 2 倍。sqlite-vec 是唯一不需要全量載入的方案（disk-based HNSW、端到端 19ms），差距從「84 倍」變成「8 倍」。

使用頻率決定 ROI。CLI 工具、每天 ~10 次手動 query。每次省 130ms（151 vs 19），一天省 1.3 秒。重寫投入 2-3 小時，回本時間 ≈ 19 年。注意這個計算對頻率極敏感：每天 100 次（如被整合進 MCP server 當 agent 工具）回本縮短到 1.9 年、每天 1000 次則 69 天。上方 HNSW ROI 也用每天 100 次計算 — 兩處頻率假設不同是因為比較對象不同（HNSW build 成本 vs 語言重寫成本），但讀者套到自己場景時應先確定自己的查詢頻率。

Ingest 瓶頸在 Ollama API、跟語言無關。~4 分鐘的 ingest 裡、embedding API call 佔 95% 以上。換 Python 不會改善 ingest 速度。

維持的理由是「痛點不存在」

維持 Go 的理由是改善的絕對收益太小、投入回不了本 — 151ms 對 CLI 使用模式不構成痛點，與「Go 好」或「工具鏈統一」無關。

這個翻轉的教學意義

正確的結論配錯誤的理由是脆弱的。第一次 WRAP 的結論（選 Go）在當時是對的，但理由鏈（工具鏈統一、< 10ms）被實測推翻後，如果不重新建立正確的理由鏈，下次環境變動（比如 blogsearch 從 CLI 變成 API server）就會用已失效的理由做出錯誤判斷。

判讀工具選型時，要區分三層：

1. 結論：選什麼方案
2. 理由：為什麼選（可能被推翻）
3. 前提：理由依賴的假設（規模、使用模式、效能數字）

前提變了、理由就要重建，即使結論沒變。寫進決策紀錄時，三層都要記 — 只記結論的話，下次重新評估時沒有判讀基礎。

區分「正當理由重建」跟「動機性推理」（先有結論再找理由）的判準：新理由是否在看到數據之前也能成立？本例的「130ms 對 CLI 不痛」在實測前也成立（CLI 使用模式本來就低頻），所以是正當重建。如果新理由只能在看到特定數字之後才講得通（如「151ms 剛好在 200ms 閾值內」——但閾值是事後設的），就是 post-hoc rationalization。

觸發換方案的訊號

Embedding model 選型（對應 4.12 constraint 優先序）

選 nomic-embed-text 的理由鏈：

1. Ollama 原生支援：ollama pull 一行、不需要額外 Python library 或 API key
2. 體積小：274 MB、跟 chat model 共用記憶體不打架
3. 已有驗證基線：rag-demo 用同一個模型跑過 463 chunks、retrieval 命中率確認可用
4. 768 維 sweet spot：24K chunks × 768 dim × 4 bytes = 70.9 MB，brute-force 可行

未來如果 CJK retrieval 品質不夠（目前可用但未做系統性評估），multilingual-e5-large 或 bge-m3 是備選。換模型只需改 embed.go 的 Model 變數 + 重新 blogsearch ingest（4.22 的「四層可替換」設計）。

CJK 混合 Chunking 觀察

Blog 內容是繁體中文 + 英文術語混合。Chunking 策略沿用 rag-demo 的 paragraph-aware split（空白行切段、soft token cap 400）。

Token 估算用 len(s) / 2 的 heuristic（CJK 字元多算一次）。不精確但 chunking 只需要粗略估算。跟 tokenizer 精確計算的差異在 ±20%、對 chunking 品質影響小於 chunk 邊界選擇的影響。

實際觀察：24,216 chunks 的 retrieval 品質在語意搜尋場景（「哪些文章跟 retry 有關」「RAG storage 選型」）表現良好。keyword 精確搜尋場景（「找 RFC 7807」）表現較弱 — 這是 embedding-only retrieval 的已知限制（見 4.1 的語意 vs 字面相似度對比），未來可加 BM25 做 hybrid search。

跟其他章節的對應

JSONL 的格式是每行一個 JSON 物件。作為匯出格式，核心優勢是工具鏈成熟 — grep 過濾、jq 結構化查詢、tail -f 即時監控，不需要 database client。

一天一檔

事件按日期分檔：events-2026-06-19.jsonl、events-2026-06-20.jsonl。每天零點（或 UTC 日期變更時）切換到新檔案。

一天一檔的好處：

時間範圍查詢直接對應到檔案。查「昨天的 error」只需要讀一個檔案，不需要掃描整個資料集。

保留策略按檔案操作。保留 30 天的資料 = 刪除 30 天前的檔案。不需要 database 的 TTL 機制或 partition pruning。

備份和搬移按檔案操作。rsync 一個目錄就完成備份；搬移特定日期的資料 = 搬移對應檔案。

一天一檔的風險是單日資料量過大時，單一檔案的 grep 查詢會變慢。自用工具場景下，單日事件量通常在數千到數萬筆，檔案大小在 MB 級，grep 查詢在秒級完成。當單日事件量超過百萬筆時，需要考慮演進到更適合的儲存方案（見 規模演進）。

Append-only 寫入

JSONL 的寫入模式是 append-only — 新事件追加到檔案尾端，已寫入的事件不修改。

Append-only 的操作特性：

寫入不需要鎖。os.OpenFile 用 O_APPEND flag 開啟，OS 保證每次 write 是 atomic 的（在 write size 不超過 PIPE_BUF 的前提下，Linux 上是 4096 bytes）。單一事件的 JSON 通常在這個限制內。

不會損壞既有資料。寫入失敗（磁碟滿、程序崩潰）最多造成最後一行不完整，不影響前面的行。恢復時刪除最後一行的不完整片段即可。

支援 tail -f 即時監控。tail -f events-2026-06-19.jsonl | jq . 即時顯示新寫入的事件，不需要額外的 streaming 機制。

Gzip 壓縮

歷史檔案（非當天的）用 gzip 壓縮。JSON 文字的壓縮率通常在 80-90%（10MB 壓縮到 1-2MB）。

壓縮策略：

當天的檔案不壓縮。保持 append-only 和 tail -f 的能力。

日期切換時壓縮前一天的檔案。用 cron job 或 collector 啟動時檢查，把 events-2026-06-18.jsonl 壓縮為 events-2026-06-18.jsonl.gz。

查詢壓縮檔用 zgrep / zcat。zgrep "error" events-2026-06-18.jsonl.gz 不需要先解壓。

JSONL 備份的保留

JSONL 備份檔的保留策略和 SQLite 主要儲存的分層保留獨立 — JSONL 是最後的重建來源，保留期限可以比 SQLite 中的原始事件更長。

典型配置：JSONL 備份保留 30 天（即使 SQLite 中的原始事件只保留 7 天），提供 SQLite 損壞時的 30 天重建窗口。超過 30 天的 JSONL 壓縮檔用 cron job 清理：

1find /var/lib/collector/events/ -name "events-*.jsonl.gz" -mtime +30 -delete

主要儲存的查詢驅動分層保留策略見 規模演進。

匯出的實作注意

匯出使用 streaming — 從 storage 逐筆讀取、逐行寫出，記憶體使用和事件總量無關。300 萬筆事件（約 900MB JSONL）不需要整批載入記憶體。

匯出的 JSONL 檔案包含事件明文（已 redaction 的欄位除外）。匯出後的檔案不受 collector 的存取控制保護，注意存放位置和存取權限。

下一步路由

• Collector 的完整架構 → Collector 架構
• 查詢設計 → 查詢 API 設計
• 儲存撐不住時的演進 → 規模演進

bucket 的四道安全防線

一個 S3 bucket 在 IaC 裡至少要描述四個獨立資源，各自對應一道防線。Terraform 把它們拆成獨立資源是設計選擇 — 每道防線可以單獨 review、單獨調整、單獨追蹤變更歷史。

 1resource "aws_s3_bucket" "assets" {
 2  bucket = "acme-${var.env}-assets"
 3
 4  tags = { service = "cdn-origin", env = var.env }
 5}
 6
 7resource "aws_s3_bucket_versioning" "assets" {
 8  bucket = aws_s3_bucket.assets.id
 9  versioning_configuration { status = "Enabled" }
10}
11
12resource "aws_s3_bucket_server_side_encryption_configuration" "assets" {
13  bucket = aws_s3_bucket.assets.id
14  rule {
15    apply_server_side_encryption_by_default {
16      sse_algorithm = "aws:kms"
17    }
18  }
19}
20
21resource "aws_s3_bucket_public_access_block" "assets" {
22  bucket                  = aws_s3_bucket.assets.id
23  block_public_acls       = true
24  block_public_policy     = true
25  ignore_public_acls      = true
26  restrict_public_buckets = true
27}

versioning

versioning 讓物件的每次覆寫都保留前一版。誤覆寫時可以從版本歷史回退到前一個正確版本，誤刪時物件只是被標記為 delete marker、前一版仍然存在。這道防線對承載正式資料的 bucket 是必要的 — 沒有 versioning 的 bucket，一次誤操作就是資料永久遺失。

versioning 開啟後會累積歷史版本的儲存量。搭配生命週期規則設定 noncurrent_version_expiration 可以控制保留多少天的舊版本，避免儲存成本無限成長。這個天數是「保留能力」跟「儲存成本」的取捨 — 保留 30 天通常足以涵蓋發現問題到回退的時間差，受合規要求的資料則依規定延長。

server-side encryption

server_side_encryption 確保物件在 S3 落地時加密。aws:kms 使用 KMS 管理的金鑰，加密操作對應用程式透明 — 寫入時自動加密、讀取時自動解密，不需要改應用程式碼。選 aws:kms 而非 AES256（SSE-S3）的判斷依據是存取控制粒度：KMS 金鑰可以獨立設定 key policy，讓「誰能解密」這件事跟「誰能讀 bucket」分開管理，適合跨帳號或跨團隊的場景。

使用 KMS 加密的 bucket 在跨帳號存取時，目標帳號除了要有 bucket 的讀取權限，還需要 KMS key 的 kms:Decrypt 權限 — 少了這一步會拿到 AccessDenied，錯誤訊息通常指向 S3 權限而非 KMS，排查時容易走錯方向。

public access block

public_access_block 的四個布林全設 true，等於從 bucket 層級封死對外公開的可能。即使有人之後誤加了一條公開的 bucket policy 或 ACL，這個 block 也會擋住。它是一道兜底機制 — 擋的是設定錯誤，不是正常操作。

靜態掃描工具（checkov / tfsec）會標記缺少 public access block 的 bucket。這正是模組七：infra 走 PR 流程裡自動化護欄的典型攔截對象 — 漏設的 bucket 會在 PR 階段被擋下，而非部署到線上才發現。

定期用 CLI 掃一遍帳號內所有 bucket 的公開狀態，命中的每個 bucket 都要能回答「這個公開是故意的、理由是什麼」：

1aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | \
2  while read b; do
3    status=$(aws s3api get-public-access-block --bucket "$b" 2>/dev/null | \
4      jq -r '.PublicAccessBlockConfiguration | to_entries[] | select(.value==false) | .key')
5    [ -n "$status" ] && echo "$b: $status"
6  done

生命週期規則

儲存成本隨物件數量與保留時間線性成長。生命週期規則讓 IaC 描述「某類物件多久後搬到更便宜的儲存層、再多久後刪掉」，把成本控制變成可版本控制的設定。

 1resource "aws_s3_bucket_lifecycle_configuration" "assets" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  rule {
 5    id     = "archive-old-logs"
 6    status = "Enabled"
 7    filter { prefix = "logs/" }
 8
 9    transition {
10      days          = 30
11      storage_class = "GLACIER_IR"
12    }
13    expiration { days = 365 }
14  }
15
16  rule {
17    id     = "cleanup-old-versions"
18    status = "Enabled"
19    filter {}
20
21    noncurrent_version_expiration {
22      noncurrent_days = 30
23    }
24  }
25}

儲存層的取捨

S3 提供多個儲存層，各自在存取延遲與儲存單價之間取捨：

transition 規則的日數設定要回推自業務需求：log 在除錯期間需要即時讀取（Standard），超過 30 天後幾乎只在事故回顧時才翻（Glacier Instant Retrieval 或 Standard-IA），超過一年可以淘汰或移到更深的歸檔層。把這些規則寫進 IaC，「為什麼 logs 只留一年」就是一個能在 PR 上被討論的決定，而非某人在 Console 點了不知道大家知不知道的設定。

bucket policy 與跨帳號存取

bucket policy 描述誰能對這個 bucket 做什麼操作，是 bucket 層級的存取控制。它跟 IAM policy 的差別在施力點：IAM policy 貼在身分上、定義「這個身分能做什麼」；bucket policy 貼在資源上、定義「這個 bucket 允許誰來」。兩者同時生效 — 一個請求要同時被身分端和資源端允許才會放行（除非有顯式 deny）。

跨帳號存取是 bucket policy 最常見的使用場景。一個帳號的 S3 bucket 要讓另一個帳號的 IAM role 讀取，需要兩端同時授權：bucket policy 允許那個 role 的 ARN，對方帳號的 IAM policy 也允許對這個 bucket 操作。

 1resource "aws_s3_bucket_policy" "cross_account_read" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  policy = jsonencode({
 5    Version = "2012-10-17"
 6    Statement = [{
 7      Sid       = "AllowCrossAccountRead"
 8      Effect    = "Allow"
 9      Principal = { AWS = "arn:aws:iam::111222333444:role/data-reader" }
10      Action    = ["s3:GetObject", "s3:ListBucket"]
11      Resource = [
12        aws_s3_bucket.assets.arn,
13        "${aws_s3_bucket.assets.arn}/*"
14      ]
15    }]
16  })
17}

bucket policy 的常見陷阱是 Principal: "*" — 允許任何人存取。這跟 security group 的 0.0.0.0/0 是同一類風險。除了做為 CloudFront Origin Access Control（OAC）的配合設定，幾乎沒有合理場景需要把 Principal 設成 wildcard。checkov 的 CKV_AWS_70 規則專門攔這個。

把 bucket policy 寫進 IaC 的好處是每一條授權都有 PR 紀錄 — 誰在什麼時候加了一條跨帳號存取、為什麼加、reviewer 同意了沒有。散落在 Console 的 bucket policy 沒有這些追蹤，某天發現一條不認得的授權時，只能去翻 CloudTrail 猜它是什麼時候加的。

事件通知

S3 事件通知讓 bucket 在物件被建立、刪除或還原時，自動觸發下游處理 — 寫入後自動縮圖、上傳後自動掃毒、刪除後自動通知。這些觸發關係寫進 IaC，讓「這個 bucket 會觸發什麼」成為可查詢的事實，而非散落在 Console 的隱性接線。

 1resource "aws_s3_bucket_notification" "assets" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  lambda_function {
 5    lambda_function_arn = aws_lambda_function.thumbnail.arn
 6    events              = ["s3:ObjectCreated:*"]
 7    filter_prefix       = "uploads/"
 8    filter_suffix       = ".jpg"
 9  }
10}
11
12resource "aws_lambda_permission" "allow_s3" {
13  statement_id  = "AllowS3Invoke"
14  action        = "lambda:InvokeFunction"
15  function_name = aws_lambda_function.thumbnail.function_name
16  principal     = "s3.amazonaws.com"
17  source_arn    = aws_s3_bucket.assets.arn
18}

事件通知的兩個配置常被忽略。第一是權限：S3 要觸發 Lambda，Lambda 的 resource-based policy 必須允許 S3 呼叫它（上面的 aws_lambda_permission），少了這段 apply 會成功但事件不會觸發，除錯時不容易發現。第二是 filter：不設 prefix / suffix 的通知會對 bucket 裡每一個物件操作都觸發，包括生命週期搬遷產生的物件變動 — 流量遠超預期。用 filter 把觸發範圍收斂到需要處理的路徑與檔案類型。

事件通知也可以導向 SQS 或 SNS，適合需要非同步佇列處理或 fan-out 到多個消費者的場景。選擇依據是下游的消費模式：Lambda 適合輕量即時處理（毫秒級回應），SQS 適合需要 backpressure 和重試的批次處理，SNS 適合同一事件需要同時通知多個服務。

跨分類引用

• → 模組七：infra 走 PR 流程：checkov / tfsec 攔截缺少 public access block 或加密的 bucket
• → 模組八：治理好習慣：bucket 的 tagging 與成本歸因
• → 模組二：身分與憑證地基：bucket policy 與 IAM policy 的權限模型交集

待寫章節

• Collector 架構（HTTP endpoint → JSON Schema 驗證 → 儲存 → 查詢 → rule engine）
• JSONL 匯出與備份格式（匯出格式、gzip 壓縮、備份保留）
• 查詢 API 設計（CLI grep 友好 vs HTTP 查詢 endpoint）
• Rule engine 設計（條件 → 動作 → 模板）
• 規模演進：可插拔 Storage Backend（SQLite 預設 / PostgreSQL 觸發）
• 功能分層與 Backend 選擇（SQLite 層 vs PostgreSQL 層的功能邊界）
• SQLite Backend 效能基準（寫入吞吐 / 查詢延遲 / 資源消耗的量化預期）
• Ingestion Scaling（四層防線 — SDK 取樣 → Collector 背壓 → 水平擴展 → Queue 解耦）
• 查詢消費模式（Debug / Alerting / 產品決策 / 安全審計 / 效能監控）
• DevOps Dashboard 設計
• Developer Dashboard 設計
• 中台 Dashboard 設計
• Container 部署設計（SQLite 在 container 中的 I/O 考量、volume mount、graceful shutdown）
• 讀寫分離與查詢擴展（讀寫競爭辨識、Read Replica、預聚合、CQRS 判讀訊號）
• 端到端資料完整性（資料損失地圖、完整性指標、被自己 SDK DDoS 的防護）
• Error Fingerprint 與去重分群（fingerprint 演算法、message normalization、error_groups 表）

跨分類引用

• → backend 01 資料庫：PostgreSQL backend 的資料庫設計、State Ownership 與 Query Boundary
• → backend 04 觀測查詢設計：觀測領域的讀取路徑設計、CQRS 特化應用
• → backend 09 效能容量：高併發寫入 / 大資料查詢的效能挑戰
• → DevOps 流量管控：背壓、rate limit、熔斷的基礎概念
• → DevOps 突發流量：突發流量分類、降級策略、queue 緩衝
• → 斷網環境的監控：Collector 在斷網環境的部署方式——endpoint 改指 self-hosted backend、SDK 的 offline buffer 更重要
• 實作 repo：tarrragon/monitor 的 collector/ + docs/challenges/（撞牆記錄）

上核心服務的順序

核心服務的部署順序由依賴方向決定：被依賴的先建，依賴別人的後建。網路與身分是幾乎所有上層服務的共同前置 — 資料庫要放進私有 subnet、運算要套用 IAM role 才能讀 S3、load balancer 要掛在公開 subnet 並引用 security group。這些底層平面若還沒成形，上層資源會在 apply 時因為找不到 subnet ID 或 role ARN 而失敗，或更糟，建在預設 VPC 裡繞過了所有隔離設計。

把順序交給 IaC 工具的依賴圖自動推導，比人工排序可靠。當運算資源的定義引用了 subnet 與 security group 的資源屬性，Terraform 會解析出「subnet 先於運算」的邊，apply 時自動排程。人工維護一份「先做 A 再做 B」的清單會隨資源增加而失準，依賴圖則隨程式碼本身演進。

順序失控的早期徵兆是：某個上層資源的定義裡寫了一串 hardcode 的 subnet ID 或 VPC ID，代表它沒有透過依賴圖連到底層平面。底層一旦重建、ID 改變，上層不會自動跟上，state 與雲端現實之間的不一致（即 drift）就此產生。把硬編碼的 ID 換成對底層資源屬性或 data source 的引用，順序才會回到工具掌控之內。

各類服務怎麼描述

四類核心服務承擔不同責任，IaC 描述它們時關注的屬性也不同。共通原則是：描述服務的「身分與接線」，而非把每個執行期參數都塞進程式碼。

資料庫（RDS） 是這層裡最需要謹慎描述的資源，因為它持有無法重建的狀態。IaC 定義它的 instance class、引擎版本、所在的 subnet group（決定它落在哪些私有 subnet）、套用的 parameter group 與 security group。連線端點不要硬編碼，改用資源 output 暴露給上層運算引用。

1resource "aws_db_instance" "primary" {
2  identifier             = "app-prod-primary"
3  engine                 = "postgres"
4  engine_version         = "16.3"
5  instance_class         = "db.r6g.large"
6  db_subnet_group_name   = aws_db_subnet_group.private.name
7  vpc_security_group_ids = [aws_security_group.db.id]
8}

運算（ECS / EKS） 描述的是業務程式碼的執行載體。重點屬性是它跑在哪些 subnet、套用哪個 task / pod 的 IAM role、掛到哪個 load balancer 的 target group，以及與容器映像版本解耦 — 映像 tag 通常由 CI/CD 在部署期注入，不寫死在 infra 程式碼裡。這層只描述「運算容量與接線」，實際跑什麼版本由部署流程決定，這個邊界讓 infra 變更與應用發布各走各的節奏。

ECS 與 EKS 在這裡被併寫，但兩者的維運模型不同、存在實際選型：ECS 是受管的容器編排，控制平面由雲商代管、心智負擔低，接線概念貼近 AWS 原生資源；EKS 是受管的 Kubernetes，換來跨雲可攜的生態與更細的編排控制，代價是要承擔 Kubernetes 自身的運維面（升級、附加元件、RBAC）。團隊已有 Kubernetes 能力或需要其生態時 EKS 的成本才划算，否則 ECS 的低負擔通常是預設起點。IaC 描述的接線骨架相近，差異主要落在編排層的資源類型。

運算到資料庫之間還有一段常被略過的接線：連線管理。無狀態運算水平擴張時，每個實例各自開連線，容易把資料庫的連線數打滿 — 出現「擴運算反而拖垮 DB」的訊號時，要引入連線池或受管的連線代理（如 RDS Proxy），把連線收斂後再進資料庫，這層也可寫進 IaC 並輸出端點給運算引用。當讀流量遠大於寫、且能容忍副本的複寫延遲時，read replica 是把讀請求導離主庫的下一步，運算端依讀寫分流引用不同端點。

儲存（S3） 描述的是 bucket 的存在、命名、加密設定、版本控制與存取政策。bucket 本身幾乎沒有重建代價意義上的狀態問題 — 困難在它「裝的東西」。空 bucket 可隨時重建，裝了正式資料的 bucket 與 RDS 一樣不可隨意 destroy。描述時把加密、public access block、生命週期規則寫進去，這些是安全與成本的預設防線。

入口（ALB） 描述流量進入系統的第一站。它定義 listener（監聽哪些 port 與協定）、target group（流量導向哪些運算後端）、health check 條件與 TLS 憑證。ALB 本身是 stateless 的 — 重建一個 load balancer 不會遺失資料，但會換掉它的 DNS 名稱，所以對外服務通常在它前面再掛一層穩定的 DNS 記錄。健康檢查的路徑與閾值是這裡最常被忽略的判讀點：閾值太寬鬆會把壞掉的後端留在輪替裡，太嚴格會在部署瞬間誤判健康的新實例。HTTPS listener 引用的 TLS 憑證也屬於這層的接線 — 憑證由 ACM 簽發與自動續期，IaC 用憑證資源描述它（涵蓋網域與驗證方式），再把憑證 ARN 接到 listener 上，讓「憑證存在、續期、掛載」整條鏈都進版本控制，而非在 Console 手動上傳一份會過期沒人盯的憑證。

stateful 資源的特殊處理

stateful 資源的 IaC 描述要把「保護狀態」當成第一類需求，而非事後補上的選項。RDS 是典型 — 它的高可用、備份與還原能力全都能、也應該用程式碼描述，這樣保護策略本身就進入版本控制與審查流程，而非散落在某人手動點過的 Console 設定裡。

multi-AZ 用一個布林屬性開啟，背後是 RDS 在另一個可用區維護同步副本。它解的是可用性：主庫故障時 failover 到 standby，但這個切換有秒級到一兩分鐘的窗口而非零停機，期間連線會中斷重連。要先界定它的邊界，才不會把它當成超出職責的工具。standby 副本是熱備不可讀，所以 multi-AZ 不提供讀取擴展 — 要分攤讀流量得另開 read replica 或改用 multi-AZ cluster 形態。它也不防邏輯損壞：誤刪一張表或一筆錯誤的批次更新會同步複製到 standby，這類風險由 backup 與時間點還原（PITR）負責，與 multi-AZ 的可用性職責正交，兩者要分別配置。

backup 用保留天數與備份視窗描述，RDS 依此每日自動快照並保留交易日誌以支援還原到任意時間點。自動備份的保留上限是 35 天，更長的留存要靠手動快照或匯出到 S3 自行管理。下方 backup_retention_period 取 14 是以 RPO 與合規要求反推的結果 — 一般營運場景 14 天足以涵蓋「發現問題到決定還原」的時間差，受監理或需要更長追溯窗口的服務則往 30 天甚至接上手動快照保險。手動快照用獨立資源描述，常見於重大變更前的保險點。

1resource "aws_db_instance" "primary" {
2  multi_az                   = true
3  backup_retention_period    = 14
4  backup_window              = "03:00-04:00"
5  deletion_protection        = true
6  skip_final_snapshot        = false
7  final_snapshot_identifier  = "app-prod-final"
8}

該在 review 攔下的訊號是：正式環境的 stateful 資源若 backup_retention_period 為 0 或 deletion_protection 為 false，代表狀態保護沒有寫進程式碼。把這些屬性視為正式資料庫的硬性下限，而非可調的偏好。

stateful 與 stateless 的差異怎麼影響操作

stateful 與 stateless 資源的根本差別在重建代價，這個差別會傳導到刪除保護與 drift 風險的處理方式。stateless 資源（ECS service、ALB、無狀態運算）重建只是換一組新實例，幾分鐘內恢復、沒有資料損失，所以它們可以被頻繁地 destroy 與 recreate，是 IaC 最擅長的對象。

stateful 資源（RDS、裝了資料的 S3、持久化 volume）重建意味著資料遺失或漫長的還原，代價可能是數小時的停機與不可逆的損失。這個差別帶來三個操作後果。第一，刪除保護是必要的：stateful 資源開啟 deletion protection，讓「不小心 destroy」需要先顯式關閉保護這一步，多一道人為確認。第二，state drift 的容忍度不同：stateless 資源的 drift 可以靠重建抹平，stateful 資源的 drift（例如有人手動改了 parameter group）要謹慎處理，因為 IaC 的「修正回程式碼狀態」動作可能觸發重啟或重建。第三，變更的審查強度不同：改動 stateful 資源的 plan 輸出要逐行看，特別警惕任何顯示為 replace（先刪後建）而非 update in-place 的項目 — 對資料庫而言這通常代表資料會被丟棄。

實務上把這個差別寫進流程：stateful 資源的變更走更嚴格的 PR review 與分階段套用，這部分的自動化護欄在「模組七：infra 走 PR 流程與自動化護欄」展開。

服務之間的依賴怎麼表達

服務間依賴用 output 與 data source 表達，讓引用關係成為程式碼裡可追蹤的邊，而非靠人記憶的隱性約定。同一個 state 內，直接引用資源屬性即可建立依賴 — 運算資源引用資料庫的端點 output，IaC 自動推導出「資料庫先於運算」，也讓端點變更時上層自動取得新值。

1output "db_endpoint" {
2  value = aws_db_instance.primary.endpoint
3}

跨 state（例如網路地基與核心服務分屬不同 Terraform state，呼應「模組四：環境分離與模組化」的拆分）時，下游用 data source 唯讀地讀取上游已建立的資源。下游查詢上游的 VPC 與 subnet，取得 ID 來放置自己的資源，而不複製貼上硬編碼的值。

1data "aws_vpc" "main" {
2  tags = { Name = "app-prod" }
3}

兩種方式的取捨在耦合與隔離之間。同 state 引用最直接、依賴圖最完整，但 state 越大、單次 apply 的爆炸半徑越大。跨 state 的 data source 把爆炸半徑切小、讓網路地基能獨立演進，代價是依賴關係跨越了 state 邊界、需要約定上游一定先 apply。判讀訊號是：若一份核心服務程式碼裡出現大量寫死的 ID，通常代表該用 data source 而沒用 — 這是日後上游重建時 drift 與 broken reference 的來源。把硬編碼的引用換成 data source，依賴關係才會在程式碼裡顯性化、可被工具與 review 看見。

服務都接上後，下一個關注點是讓它們可被觀測 — log 與 metric 與服務同生命週期建立，這部分在「模組六：可觀測性與 log 同生命週期」展開。

章節文章

跨分類引用

• → backend 模組五：部署平台：PaaS / container 平台跑在這層之上
• → devops 實務指南：這些服務上線後的運行期維運

本章整理 storage layer 的工程設計空間：什麼規模用什麼儲存、什麼訊號觸發升級、index 怎麼建怎麼更新、schema 怎麼設計、dependency chain 怎麼影響選型。全篇以一個約 2,700 篇 markdown（24K chunks）、Go 工具鏈的個人技術 blog 作為 running example（從 pickle demo 升級到 production 工具的過程）；Go-specific 的約束見「工程約束」段，Python 專案的路徑在各階段標示。

本章目標

本章涵蓋：

1. RAG pipeline 的四個可替換層、判斷當前瓶頸落在哪一層。
2. Corpus 規模跟使用模式對應的 storage backend 選擇。
3. Index 的 build / update / rebuild 生命週期設計。
4. ANN index 策略（HNSW / IVF / brute-force）的適用邊界。
5. Storage 選型的 dependency 約束（語言生態、build chain、環境管理）。

RAG pipeline 的四個可替換層

RAG 不是一個 monolithic 系統。從 query 進來到 augmented prompt 送進 LLM，經過四個獨立可替換的層：

四層各自演化、各自有不同的升級時機。Chunking 跟 embedding model 影響 retrieval 品質（找到的東西對不對）；storage backend 跟 retrieval algorithm 影響 retrieval 效能（找的速度跟規模上限）。

常見的認知混淆是把「RAG」跟「vector database」綁在一起。這個綁定在 production 規模可能合理（10M chunks 不用 vector DB 很難做），但在小規模場景會導致過度工程 — 1500 個 chunks 用 Pinecone 就像用 PostgreSQL 存 10 筆 config。

Storage backend 的演化階梯

Storage backend 的選擇是規模驅動的工程決策。每個階段都能做 RAG，差別在效能、持久性、query 能力。以下規模閾值基於 768 維 embedding、單機常見配置的經驗判斷，切點依向量維度與硬體規格移動；實測數字（如 20 chunks/sec）另行標示：

階段一：In-memory（pickle / Python list）

把所有 chunk embeddings 載入記憶體，brute-force 算 cosine similarity。

1適用規模：< 10K chunks
2延遲：cosine 計算 < 2ms（numpy BLAS、in-memory）；file-based 實作加 I/O 載入時間
3持久性：pickle 檔、每次啟動重載
4優點：零 dependency、程式碼 < 50 行、debug 容易
5限制：記憶體受限、無 metadata filter、無 incremental update

本 blog 的 rag-demo 就在這個階段：71 篇 markdown、463 chunks、pickle 儲存、22 秒索引、query < 10ms。概念驗證完全夠用。

階段二：Flat file（binary embedding store）

把 embeddings 存成 binary 格式（而非 Python pickle），配 JSON metadata index。跟階段一的差異是 language-agnostic persistence — 不綁定 Python 的 pickle 格式、Go / Rust / Node 都能讀。

1適用規模：< 10K chunks
2延遲：cosine 計算 < 2ms；加 file I/O 載入（70MB vectors ≈ 150ms Go / < 50ms mmap）
3持久性：binary file + metadata JSON、可 rebuild
4優點：跨語言、單檔案部署、不需要 DB server
5限制：brute-force O(n)、metadata filter 靠程式碼、schema 演化需 rebuild（換 embedding 模型要重建整個 index）、無 transaction 保護（binary 損毀靠 rebuild 復原）、每次 query 重載 file 是效能瓶頸

Running example 的 blog 選了這個方案。驅動選擇的是工具鏈約束：該 blog 的核心工具是 Go（單 binary 分發的 lint / fmt 工具），用 pickle 就綁定 Python runtime、其他維護者 clone 後多一步環境設定（同規模下效能無差異）。Binary flat file 讓 Go 工具直接讀寫、維持單 binary 分發。Python 專案留在 pickle 完全合理，規模到 10K 再跳階段三 FAISS 更自然。

階段三：Embedded library（FAISS / HNSWLib / Annoy）

引入 ANN（Approximate Nearest Neighbor）index，查詢從 O(n) 變成 O(log n)。

1適用規模：10K - 100K chunks
2延遲：< 5ms（HNSW sublinear）
3持久性：index 檔案、可 rebuild
4優點：不需要 server、嵌入應用 process
5限制：需要安裝 library（FAISS 有平台相依的 wheel）、index build 較慢

升級訊號：brute-force latency 開始感覺到（> 50ms）、或 corpus 大到記憶體載入太慢。1M chunks × 768 dim × 4 bytes = 3GB，載入開始有感。

階段三½：Piggyback 既有 DB（pgvector / Redis vector）

已有 PostgreSQL 或 Redis 的專案有一條跳板路徑：直接在既有 DB 加向量能力、不引入新 server。

1適用規模：10K - 1M chunks（pgvector）、10K - 500K（Redis vector）
2延遲：< 10ms（HNSW、同 DB process）
3持久性：DB 管理、有 transaction / WAL / backup
4優點：不增 server、SQL metadata filter 原生支援、既有維運流程直接沿用
5限制：DB 本身要夠大（向量索引佔額外記憶體）、效能跟 DB 負載共享

升級訊號：已有 Postgres / Redis、需要 metadata filtering、但不想維運獨立 vector DB server。pgvector 讓「有 SQL 能力 + 有向量搜尋」在同一個 DB 完成；Redis vector（RediSearch）適合已有 Redis 且延遲敏感的場景。

這條路徑跟階段四的差異：階段四（Qdrant / Weaviate）是專用 vector DB、向量搜尋效能更高、但多一個 server 維運。Piggyback 路徑犧牲一些向量搜尋效能、換來零新增 server 的維運簡化。選擇取決於「向量搜尋是核心能力（階段四）、還是輔助功能（piggyback）」。

階段四：Self-hosted vector database（Qdrant / Weaviate / Milvus）

獨立 server process，專精向量搜尋，支援 metadata filtering、incremental update、backup、replication。

1適用規模：100K - 10M chunks
2延遲：< 10ms（HNSW + 網路 overhead）
3持久性：server 管理、disk-based
4優點：metadata filter（SQL-like）、REST/gRPC API、可水平擴展
5限制：需要維運 server、佔用資源、增加系統複雜度

升級訊號：需要 metadata filtering（「只搜 report/ 下的卡片」且頻率高）、需要多 process 並發 query、需要 incremental update 而非全量 rebuild。

典型場景是十人以上的團隊共用 RAG 知識庫：多人同時 query、文件隨 sprint 密集更新、需要按 project / team / access level 做 metadata filter。單人或小團隊的 side project 通常停在階段二或三就夠。回退路徑是「關掉 server、退回 embedded library」— 向量跟 metadata 仍在、只是失去 incremental update 跟 REST API。

階段五：Hosted SaaS（Pinecone / Weaviate Cloud / Qdrant Cloud）

由 vendor 管理的 vector database，免維運。

1適用規模：> 10M chunks、或不想維運
2延遲：10-50ms（加上網路 round trip）
3持久性：vendor 管理
4優點：免維運、自動擴展、SLA
5限制：cost、vendor lock-in、資料離開本地

升級訊號：corpus 超過單機記憶體（10M+ chunks 的 HNSW index 含 graph overhead 可達數十 GB）、或團隊沒有 infra 維運能力。

典型場景是跨國 SaaS 產品的 knowledge base：文件數百萬、多語言、需要 geo-distributed 部署。此規模下 self-hosted 的維運成本（on-call、capacity planning、backup）可能高於 SaaS 訂閱。風險是 vendor lock-in — 切換 vendor 要 re-index 全量資料、migration 成本跟 corpus 大小成正比。回退計畫是保留 ingest pipeline 的 vendor-agnostic 部分（chunking + embedding），只替換 storage layer。

階梯的核心判讀

每階段的升級都帶來新的 dependency 跟維護成本。判讀「該不該升級」看三個訊號：

1. 目前這個階段有具體痛點嗎？ 沒有就不升級。
2. 升級解的是效能瓶頸還是功能缺口？ 效能瓶頸先量測再決定；功能缺口（如 metadata filter）看使用頻率。
3. 升級引入的 dependency 成本能接受嗎？ 單人 blog 加一個 server process 的維護成本跟十人團隊不同。

常見路徑速查：Python 小型 side project 留在 pickle（階段一），規模到 10K 再上 FAISS（階段三）；Go 專案跳階段二（flat file）避免 Python dependency；已有 Postgres 的專案直接評估 pgvector（階段三½）；已有 Docker 的團隊直接評估階段四（vector DB container）。

常見誤解：「FAISS 跟 Pinecone 選哪個」— 兩者差在規模量級（FAISS 是嵌入式 library、適合 < 100K；Pinecone 是 hosted SaaS、適合 > 10M 或免維運），不是同層級的互斥選項。

同 corpus 實測比較

以下是同一個 corpus（24,216 chunks、768 維、nomic-embed-text）在四種 storage 方案的實測結果（2026-07 macOS Apple Silicon）：

這張表揭露三個容易被理論估計遮蓋的事實：

延遲的瓶頸在 I/O 和實作、不在演算法。Go flat file 的 151ms 裡，cosine 計算約 50ms、其餘約 100ms 是檔案載入（70MB vectors + 7MB metadata）。FAISS flat 用 numpy BLAS 做同樣的 brute-force cosine，純計算只要 1.8ms — 計算層差約 28 倍（Go pure loop vs BLAS 向量化指令），加上 I/O 差異後端到端差 84 倍。

HNSW 的 query 加速在此規模 ROI 低，但原因要看對。FAISS HNSW query 0.5ms vs flat 1.8ms，每次查詢省 1.3ms；但 HNSW build 要 23.3s。如果每天查 100 次，要 179 天才回本 build 成本。在 10 萬+ chunks 規模這個比例會翻轉。

sqlite-vec 的 19ms 是「DB overhead 換功能」的真實代價。比 FAISS flat 慢 10 倍，但多了 SQL metadata filter、transaction 保護、disk persistence — 不需要另起 server。這個 trade-off 在「需要 filter 但不想維運 server」的場景有意義。

ANN index 策略

Storage backend 到了階段三以上，需要選 ANN（Approximate Nearest Neighbor）index 策略。Vector database 卡列了三種主流演算法，本段補充工程判讀。

Brute-force（exhaustive search）

對 query vector 跟所有 stored vectors 算 cosine similarity，取 top-K。

1時間複雜度：O(n × d)（n = chunk 數、d = 向量維度）
2精確度：100%（exact nearest neighbor）
3記憶體：n × d × 4 bytes（float32）
4適用：< 10K chunks

1500 chunks × 768 dim 的 brute-force，現代 CPU 做一次 cosine similarity sweep 大約 1-5ms。在這個規模，HNSW 的建 index 時間（秒級）反而比它省下的查詢時間（毫秒級）長。

HNSW（Hierarchical Navigable Small World）

建多層隨機圖，查詢時從稀疏高層往密集低層跳，sublinear 找到近似最近鄰。

1時間複雜度：O(log n × d)
2精確度：95-99%（approximate、可調 ef_search 參數換精度）
3記憶體：n × d × 4 bytes + graph overhead（通常 1.2-1.5x）
4Build 時間：O(n × log n)、比 brute-force 慢
5適用：10K - 10M chunks、記憶體充足

HNSW 是目前 vector DB 的主流 index。工程取捨在兩個參數：ef_construction（build 精度、越高越慢但 graph 品質越好）跟 ef_search（query 精度、越高越慢但 recall 越高）。多數 vector DB 的預設值已經針對「recall > 95%」調過。

IVF（Inverted File Index）

先把向量 K-means 分群，query 時只搜最近的幾個群。

1時間複雜度：O(n/k × d)（k = 群數、nprobe = 搜幾個群）
2精確度：依 nprobe、通常 90-98%
3記憶體：可以 disk-based（比 HNSW 省）
4Build 時間：K-means 收斂需要時間
5適用：> 1M chunks、記憶體受限、可接受較低 recall

IVF 在超大規模（10M+）的 disk-based 場景有優勢，實務常配 product quantization（PQ）壓縮向量換記憶體。PQ / scalar quantization 跟 index 演算法（HNSW / IVF）正交 — 是記憶體受限時的壓縮手段，可疊加在任一 index 上。消費級場景通常不需要 quantization。

判讀流程

1Corpus 規模？
2├── < 10K chunks   → Brute-force（此規模無需再評估）
3├── 10K - 100K     → HNSW（如果記憶體夠）或 brute-force（如果 latency 可接受）
4├── 100K - 10M     → HNSW（主流）
5└── > 10M          → IVF 或 HNSW + sharding

規模是第一軸。兩個修正軸在同規模下改變選擇：

• Dependency constraint（見「工程約束」段）：規模小但工具鏈排除某些 storage（如 Go 專案排除 CGo dependency）→ 從可行選項中選。
• Metadata filter 需求：規模小但高頻需要按 section / tag 過濾 → 跳過 embedded library、直接評估 vector DB 或 code filter。

一個常見的過度工程信號：corpus 只有幾千筆但花時間調 HNSW 的 ef_construction。實測數據（24K chunks）：FAISS HNSW query 0.5ms vs flat 1.8ms、每次省 1.3ms，但 HNSW build 要 23.3s。每天查 100 次要 179 天回本 build 成本（23.3s ÷ 0.13s/天）。此規模的 brute-force 絕對延遲已在感知閾值下，HNSW 的優化收益趨近零。

判讀流程之外還有一個容易忽略的變數：實作語言的計算效能差異。同一個 brute-force cosine，numpy BLAS 做 24K × 768 只要 1.8ms，Go pure cosine 做同樣運算約需 50-80ms（不含 I/O）。選 storage 方案時如果估「brute-force < 10ms」、前提是用了向量化計算的 library；pure Go / pure Python loop 會慢一到兩個數量級。

Index 生命週期

Index 的 build / update / rebuild 流程影響日常維護成本。

Full rebuild

每次從 corpus 全量重建 index：walk 所有檔案 → chunk → embed → store。

1適用：corpus 小（< 10K chunks）、更新頻率低（每週幾次）
2優點：邏輯最簡單、index 跟 corpus 保證一致
3成本：依 corpus 規模線性成長（本地 Ollama sequential embedding 約 100 chunks/sec、24K chunks ≈ 4 分鐘）

Running example 的 blog 選 full rebuild：2,738 篇 markdown 產生 24K chunks，全量 ingest 在本地 Ollama 約 4 分鐘。每天變動 0-3 篇，rebuild 頻率跟 git push 對齊就夠。

Incremental update

只處理有變動的檔案：偵測 diff → 刪除舊 chunks → 重新 chunk + embed 變動檔 → 插入新 chunks。

1適用：corpus 大（> 10K chunks）、更新頻繁
2優點：只處理 delta、省 embedding API cost
3複雜度：需要 chunk ID 穩定（file path + chunk offset）、刪除 orphan

Incremental update 的工程難點是 chunk ID 穩定性。如果 chunking 策略對同一個檔案的切法會因為上游內容變動而改變（例如段落感知 chunking，加一段就改變後續所有 chunk 邊界），「只更新變動的 chunk」就需要 diff 整個 chunk 序列，邏輯接近全量重建。

判讀「該不該做 incremental」：

• Embedding 是 cost 瓶頸嗎？本地 Ollama 的 embedding 幾乎免費（約 50ms/chunk、sequential）；cloud API（OpenAI text-embedding-3-small 約 $0.02/1M tokens、Cohere 類似）按 token 計費、corpus 大時差異顯著。
• 全量 rebuild 的時間能接受嗎？1500 chunks 在本地約 60-90 秒可以接受；15 萬 chunks 約 2 小時可能不行。
• 能容忍短暫不一致嗎？Full rebuild 期間 index 可能是舊版；incremental update 隨改隨更新。

Rebuild trigger

不管 full 或 incremental，都要決定「什麼觸發 rebuild」：

Trigger 跟團隊協作模式對齊：單人用手動；多人但 review cycle 長（每天幾次 push）用 Git hook 或 CI/CD；開發中密集寫作想即時看 retrieval 結果用 file watcher。Git hook 跟 CI/CD 的差異在 rebuild 跑在本地（hook）還是 server（CI）— 本地 rebuild 快（< 2 分鐘）就用 hook、慢就推到 CI 避免 push 卡住。

本 blog 目前用手動 trigger — 維護者在寫新文章、需要查相關內容時跑 blogsearch ingest，日常使用頻率不高、不需要即時同步。

Schema 設計

每個 chunk 存的不只向量。至少有三類資料需要管理：

 1chunk = {
 2    vector:   float32[768],       // embedding
 3    text:     string,             // 原始文字（generation 用）
 4    metadata: {                   // filtering + 溯源
 5        source:    string,        // 來源檔案路徑
 6        section:   string,        // 所屬 section（llm/ / backend/ / report/）
 7        title:     string,        // 文章標題
 8        date:      string,        // 文章日期
 9        tags:      []string,      // 文章 tags
10        chunk_idx: int,           // 該檔案內的第幾個 chunk
11    }
12}

Metadata filter 的設計取捨

Metadata filter 是「在向量相似度之外加條件」：例如「只搜 report/ 下的卡片」「只搜 2026 年之後的文章」。

兩種實作路線：

Code filter：先做 brute-force / ANN 取 top-N（N 大於最終需要的 K），再用程式碼 filter metadata，取 top-K。

1優點：不需要 DB、flat file 就能做
2限制：filter 比例高時（如 90% 被 filter 掉）需要取很大的 N
3適用：filter 條件少、filter 比例低（< 50%）

DB filter：在 vector DB 的 query 語法中直接加 metadata condition（如 Qdrant 的 must filter）。

1優點：filter 在 index 層執行、效率高
2限制：需要 vector DB、schema 要先定好
3適用：filter 條件多、filter 比例高、query 頻繁

本 blog 選 code filter：section 只有幾個值（llm / backend / report / work-log），filter 比例低，brute-force top-20 再 filter 到 top-5 就夠。

Hybrid search 的 schema 考量

4.1 RAG 原理介紹了 hybrid search（BM25 關鍵字精確匹配 + embedding 語意相似度的加權合併），在 storage 層的 schema 影響是：需要同時存原始文字（給 BM25）跟向量（給 embedding search）。

• In-memory / flat file：BM25 自己實作（或用 library），原始文字本來就存了。
• Vector DB：多數支援 hybrid search（Qdrant 有 full-text index、Weaviate 有 BM25 + vector 合併查詢）。
• SQLite-vec + FTS5：SQLite 原生支援 full-text search（FTS5），配 sqlite-vec 可以在同一個 DB 做 hybrid search。

判讀「要不要 hybrid」：先只用 embedding search，retrieval 品質不夠再加 BM25。多數場景 embedding-only 已經夠用；keyword 精確匹配需求高的場景（如搜特定 error message、RFC 編號）才需要 BM25 補。

工程約束：dependency chain 與 build system

Storage 選型不只看功能跟效能，還受工程約束影響 — 包括 dependency chain 跟實作語言的計算效能。以下用 Go 專案示範這兩類 constraint 的思考方式；Python / Docker / 前端專案的 constraint 不同、結論見「不同專案的 constraint 不同」段。

Case study：Go 專案為什麼不選 SQLite-vec

SQLite-vec 是 SQLite 的 C extension，提供向量搜尋能力。功能上完全符合需求。但在 Go 生態裡，CGo（Go 呼叫 C 程式碼的橋接機制）引入額外代價：

選 mattn/go-sqlite3 意味著：

• 其他維護者 clone 後需要裝 C compiler（macOS 要 Xcode CLI tools、Linux 要 gcc）
• CI/CD 需要配 CGo 環境
• 單 binary 分發的優勢消失（動態連結 libc）

這些代價在大團隊可能值得，但對一個個人 blog 的工具來說，dependency chain 的複雜度超過功能收益。

判讀 dependency 約束的反射

每個 storage 選項都帶一條 dependency chain。評估時要問：

1. 新維護者 clone 後要裝什麼？ pip install / go build / docker pull / apt install？
2. CI 要加什麼？ C compiler / Python runtime / Docker image？
3. 哪些平台要支援？ macOS / Linux / Windows？交叉編譯需求？
4. runtime dependency 還是 build-time dependency？ Runtime（要 server 跑著）的維護成本遠高於 build-time（build 完就不需要了）。

本 blog 的 constraint 是：Go 單 binary、clone 後 go build 即可、不需要外部 server。這個 constraint 排除了 CGo dependency 跟任何 server-based 方案，把選項收窄到 flat file。代價是 Go pure cosine + file I/O 讓 query 延遲（151ms）比 Python FAISS（1.8ms）慢 80 倍 — 對 CLI 工具可接受，對高頻 API server 則是致命瓶頸。選型時把 dependency chain 跟計算效能一起評估，避免「dependency 輕但效能差」或「效能好但 dependency 重」的單軸判斷。

不同專案的 constraint 不同

這個 constraint 是本 blog 的特定情境。其他專案的 constraint 可能完全不同：

• Python 生態的專案：pip install 是標準流程，但 FAISS 的 CPU/GPU wheel 有平台相依（M1 Mac 需要 faiss-cpu 特定版本、glibc 版本影響 Linux wheel），不是完全零 constraint。
• 已有 Docker 的專案：加一個 Qdrant container 看似 docker-compose.yml 多三行，但要考慮 image 體積（數百 MB）、記憶體分配、冷啟動時間、以及 CI 環境是否支援 Docker-in-Docker。
• 前端專案：WebAssembly 版 HNSW 可行但受 bundle size 跟瀏覽器記憶體上限約束，跟 backend storage 的 constraint 型態完全不同。

Storage 選型沒有「最佳方案」— 只有在特定 constraint 下的最適方案。

何時過時 / 何時不過時

不會過時的部分：

• RAG pipeline 的四層可替換結構。
• Storage 升級的判讀訊號（規模驅動、痛點驅動、不是技術驅動）。
• Index 生命週期的 full rebuild vs incremental update 取捨。
• Dependency chain 作為選型約束的思考框架。
• ANN 策略的複雜度分析（brute-force O(n) vs HNSW O(log n) vs IVF O(n/k)）。

會變的部分：

• 具體 vector DB 的市場格局（Pinecone / Qdrant / Weaviate 的功能差異會持續變動）。
• ANN library 的實作效能（新演算法可能比 HNSW 更好）。
• 語言生態的 binding 成熟度（Go 的 SQLite-vec 純 Go binding 可能出現）。
• 具體規模閾值（隨硬體進步、「brute-force 可行」的上限會提高）。

跟其他章節的關係

下一步

本章整理的是跨場景的 storage 工程原則。Running example 的 blog 基於這些原則選了「Go + flat file + brute-force」方案，完整實作過程（選型→重寫→效能優化→四方案 benchmark→二次選型評估）見 Case Study：Blog 語意搜尋從 pickle 到 production。

想看 retrieval 品質不夠時的增強手段（query rewriting / HyDE / multi-step），回到 4.2 RAG 檢索增強。想看 embedding 模型怎麼選（含工程 constraint 如何先砍選項再比品質）、怎麼判讀 MTEB 分數，回到 4.12 Embedding model 內部。

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 storage-level 設計的實作層教學。覆蓋 quorum-based replication 的工程含義、「韌性即性能」frame 為什麼成立、OLTP workload 在 storage 設計下的讀寫雙峰錯位、跟容量規劃的判讀槓桿。

問題情境

典型觸發場景：團隊從 RDS PostgreSQL / 自管 PostgreSQL 遷到 Aurora、看到「跨 AZ replication lag 從秒級降到毫秒級」、但讀文件「quorum」「4-of-6」「分散式 storage」訊息密集、不知道哪些設計決策要相信、哪些是 marketing 詞。

讀者常見的具體疑問：

• 「為什麼 Aurora 寫入比 RDS 還低、不是該因為跨 AZ network round-trip 而變慢？」
• 「Storage layer 跟 compute layer 分離具體怎麼影響 backup、failover 跟 read replica？」
• 「6 個 storage node 失去 2 個還能寫嗎？失去 3 個呢？」
• 「Aurora 文件講『韌性』跟『性能』都用 storage 設計解釋、是同一件事還是兩件事？」

進一步問題：傳統工程文化把可靠性跟性能視為對立 — HA 投資（跨 AZ replication、failover 演練）通常被當成性能成本、不被視為性能來源。Aurora 設計反這個直覺、但讀者需要看到具體機制才能信。Standard Chartered case 揭露這個 frame 在受監管銀行業務（要求兩者同時達標）的價值；DraftKings 揭露具體數字（讀 < 1ms、寫 6ms）。

核心機制：quorum-based 分散式 log

Aurora storage 的 first-class concept 是 quorum 寫入 + 6-way 跨 AZ replication。傳統 PostgreSQL primary 把 storage 跟 CPU / RAM 綁定、storage 擴容要換 instance、replication 在 compute 層做（streaming replication、logical replication）。Aurora 把 storage 拉到分散式 log service、6 個 storage node 各自獨立、application 看到的仍是 single primary SQL。

Storage layout：每個 storage segment 跨 3 AZ × 2 node、共 6 個 storage node。一個 cluster 的 storage 被切成多個 10GB segment、每個 segment 6-way 複製。

Quorum 設定：

• Write quorum：4-of-6（4 個 storage node 確認寫入才算 commit）— 容忍 1 AZ 失效 + 1 node 失效仍能寫
• Read quorum：3-of-6（讀 3 個 node 取最新版本）— 比 write 小、降低 read latency
• 算術不對稱：寫嚴讀鬆是設計選擇、不是 marketing — durability 由寫端保證、讀端可以放寬

Write path 跟傳統 PostgreSQL 的差異：

• PostgreSQL primary：寫 WAL 到 local disk + dirty page flush + 透過 streaming replication 推到 replica
• Aurora compute node：只送 redo log records 到 storage、不送整個 page；storage node 自己 apply redo log 重建 page、自己 checkpoint、自己 backup
• 工程含義：compute node 寫量小、CPU 不被 dirty page flush 佔用、寫入路徑變短

「韌性即性能」frame（9.C14 Standard Chartered 揭露）：

Aurora 把 HA 從 application-level（Patroni promotion + WAL catch-up）下推到 storage-level。設計含義是：storage 投資（6-way 跨 AZ replication）自動成為 read replica 的容量基底 — read replica 不需要 catch-up WAL、直接從共享 storage 讀、HA 預算同步轉成讀分流預算。

對 Standard Chartered 受監管銀行業務這代表：合規要求的 RPO / RTO 不能放棄、但業務也要求每秒 4000 TPS、兩者必須同時達成。傳統路徑要分別投資 HA（複雜的 streaming replication topology）跟性能（read replica catch-up tuning）、且兩個投資互相干擾。Aurora 讓 同一份 storage 投資 同時提供兩件事 — case「判讀」段第 2 點原話：「Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 韌性即性能 的目標」。

對應 knowledge card：quorum、replication-lag。

跟通用 quorum 概念差在哪：Aurora quorum 是 storage-level（不是 application-level Cassandra 風格）、application 看到 single primary SQL、不用感知 quorum；vs Cassandra application 要選 consistency level（ONE / QUORUM / ALL）。

OLTP workload shape：讀寫雙峰錯位

Aurora 設計的工程含義在 application 層落地時、要看 workload 形狀。9.C4 DraftKings 揭露一個 OLTP 容量規劃的典型 pattern。

DraftKings 揭露的雙峰錯位（case「觀察」段最後一行原文）：「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時是讀爆量（balance query）、payout event 時是寫爆量（ledger write）、兩個峰不在同一時刻。

工程含義：

• 讀寫資源規劃要分開、不能用「峰值總 TPS」單一數字規劃容量
• 讀峰拉 read replica 容量、寫峰靠 primary instance class 跟 commit batching、兩條路徑獨立預配
• 預估 headroom 也要分開：讀的 headroom 可以靠 auto-scale replica 接、寫的 headroom 要靠 primary 提前升 instance class（不能 auto-scale）

Application-level boundary：雙峰錯位是 application 層 拆讀寫 datasource 的決策訊號、storage layer 本身不解。Aurora 共享 storage 提供 lag 上限可預測（10-30ms）— 這是 read replica 變成「production-grade 可用」的前提、但讀寫分流要 application 端拆 read / write data source 才能落地。Storage 設計給的是「可預測的 lag 上限」、不是「自動讀寫分離」。

跨 case 對照：

9.C28 FanDuel 揭露另一種雙峰 — 直播 + 投注 兩種服務 同時峰、不是同服務讀寫錯位。這兩種雙峰類型要分清楚：

• 同服務讀寫錯位（DraftKings）：解法是 read / write data source 拆分、共享 Aurora cluster
• 跨服務雙峰（FanDuel）：解法是不同服務各自獨立擴容、betting 走 Aurora、streaming 走 CDN

雙峰類型不同、容量規劃策略不同。

Step-by-step 配置 / 觀測

Aurora storage 是 cluster-level、不暴露 segment-level config。讀者能影響的維度是 instance class、storage type、backup retention 跟 monitoring。

Cluster 建立：

1aws rds create-db-cluster \
2  --db-cluster-identifier my-cluster \
3  --engine aurora-postgresql \
4  --engine-version 15.5 \
5  --master-username admin \
6  --master-user-password "$(aws secretsmanager get-secret-value --secret-id db-password --query SecretString --output text)" \
7  --storage-type aurora-iopt1 \
8  --backup-retention-period 7

關鍵欄位：

• --storage-type aurora-iopt1：Aurora I/O-Optimized、月費高 30% 但無 I/O 收費；write-heavy + scan-heavy workload 才划算
• --storage-type aurora（預設）：Standard storage、按 I/O 計費；read-light workload 划算
• --backup-retention-period 7：1-35 天、影響 PITR 範圍

觀測 storage 狀態：

1aws rds describe-db-clusters \
2  --db-cluster-identifier my-cluster \
3  --query 'DBClusters[0].{StorageType:StorageType,AllocatedStorage:AllocatedStorage,Status:Status}'

CloudWatch metric（cluster-level）：

1VolumeBytesUsed           # 當前 storage 用量、接近 128 TB 上限要警告
2VolumeReadIOPs            # storage 層讀 IOPS、判斷 I/O-Optimized ROI
3VolumeWriteIOPs           # storage 層寫 IOPS、跟 compute 層 WriteIOPS 對照
4AuroraVolumeBytesLeftTotal # 剩餘可用 storage

Performance Insights wait event：

1db.IO.aurora_redo_log_flush   # quorum write 等待訊號、p99 > 10ms 要看
2db.IO.aurora_storage_xx       # storage layer I/O 細節

驗證點：

• 寫入 latency p99：PostgreSQL primary 1-3ms vs Aurora 3-6ms、跨 AZ network round-trip 是物理下界
• Read latency p99：Aurora < 1ms（從共享 storage 讀、不跨 AZ）
• Storage autoscale event：128 TB 上限前自動 grow per 10GB

Rollback boundary：Aurora storage 是 cluster-level、無法回滾 storage 設計；唯一 rollback 是切回 RDS / 自管（走 migration playbook、不是配置層 rollback）。

故障模式 / 邊界 case

Case 1：誤以為 Aurora 寫入一定比 PostgreSQL primary 快

徵兆：團隊期待 Aurora 寫入比自管 PostgreSQL 快、實測 p99 寫入 latency 沒明顯改善、甚至小 row + 單筆 commit 場景 Aurora 反而慢。

原因：跨 AZ network round-trip 是 3-5ms 物理下界、4-of-6 quorum 至少要等 4 個 storage node ack、單筆小寫場景 local SSD primary 仍有 latency 優勢。Aurora 的寫入優勢在 壓力下 才顯現 — write throughput 高峰時 PostgreSQL primary 受限於 dirty page flush + WAL fsync + replica catch-up、Aurora 的 storage layer 各自獨立處理 redo log apply。

數字口徑：「跨 AZ round-trip 3-5ms」屬通用工程估算（光速下界 + AWS 區內 AZ 物理距離）、case 未直接量化、實際值依 region / AZ pair / instance 類型而異、要看 AWS 官方 latency table 或自家 benchmark 校正。下方 DraftKings 6ms 寫入是 case 揭露的 production reference、可作為對照基線。

修：

• benchmark 要跑壓力測試、不能只測單筆 latency
• 寫入 latency 不是 Aurora 的核心賣點、是 可預測的 read replica lag + 韌性 才是
• DraftKings 6ms 寫入是 production reference：跨 AZ quorum 的物理下界、不是 Aurora 慢

Case 2：AZ-level outage 期間寫入 latency spike

徵兆：1 個 AZ 失效後、寫入 p99 從 6ms spike 到 30-50ms、application timeout 增加。

原因：失去 1 AZ 後 quorum 仍成立（4-of-6 → 用剩 4 個 node 寫）、但 storage node fault 期間需要等 timeout 才確認；單一 storage node 額外 fault 會把寫推到 timeout。Aurora 在 AZ outage 期間 能寫、但不是 性能不變。

修：

• 監測 AuroraVolumeBytesLeftTotal 跟 storage IOPS 分布、AZ outage 期間自動切到剩餘 AZ
• application 端做 retry + circuit breaker、不要假設寫入永遠 6ms
• 確認 cluster 至少跨 3 AZ deploy、單 AZ outage 才有 quorum 餘地

Case 3：I/O-Optimized 費用誤判

徵兆：team 看 Aurora I/O-Optimized「無 I/O 收費」直接切過去、月帳變高 25%、沒看到 ROI。

原因：Standard storage 按 I/O 收費、I/O-Optimized 月費比 Standard 高 30%。只有 write-heavy + scan-heavy workload（I/O 月費接近 instance 費用）才划算；read-light + write-light workload 反而吃虧。

修：

• 先量測 baseline I/O：VolumeReadIOPs + VolumeWriteIOPs × $0.20 per million I/O vs Standard 月費
• I/O 費用 > instance 費用 30% 才切 I/O-Optimized
• DraftKings 用 I/O-Optimized 是因為金融帳本 write-heavy + balance query scan-heavy、ROI 明顯

Case 4：Storage autoscale 假設

徵兆：TRUNCATE / DROP 大表釋放 50% storage、但下月帳單沒回落。

原因：Aurora storage 自動 grow、但 不自動 shrink。已分配的 storage 持續計費、TRUNCATE / DROP 只釋放 logical space、physical storage 仍占用。要 shrink 必須走 logical migration（dump / restore 到新 cluster）。

修：

• 大量 DROP 操作前先評估是否值得做 logical migration
• 用 partition + DETACH 而非 DROP TABLE、partition 可以單獨 archive
• 接受 storage 用量是 peak watermark 而非 current usage

Case 5：Replication lag 誤解

徵兆：read replica lag 10-30ms 看起來夠快、application 假設 read-after-write consistency、用戶下注後立刻查 balance 偶發看到舊資料。

原因：10-30ms 是 typical、heavy write + slow query 期間可能秒級。Aurora 共享 storage 設計讓 lag 可預測（不會像 PostgreSQL streaming replication unbounded）、但 可預測 不等於 zero。Read-after-write 場景仍需要 application 端處理。

修：

• 用戶寫操作後 N 秒內走 primary（N 由 lag p99 決定、典型 100ms）
• Aurora 提供 session pinning：寫完同 session 短期內走 primary
• 不能假設「Aurora replication lag 小到可以忽略」、要看 application 容忍度

容量與觀測

核心 metric：

1VolumeBytesUsed           # storage 用量、128 TB 上限預警
2AuroraReplicaLag          # replica lag、判斷讀寫分流可行性
3db.IO.aurora_redo_log_flush # quorum write 等待、storage 瓶頸訊號

Production reference number（9.C4 DraftKings 揭露、case「觀察」段表格）：

這個 production reference 取代用「typical 3-5ms」籠統說法。讀寫 6x 差距是 OLTP 容量規劃槓桿 baseline — 寫延遲是 quorum 4-of-6 + 跨 AZ network round-trip 的物理下界、不是 storage 設計能再壓低。引用時要明示是 DraftKings production reference、不是 Aurora marketing。

容量上限：

• 128 TB / cluster（超過要拆 cluster、見 Aurora read replica scaling fleet 治理 SSoT）
• 15 read replica / region（Aurora read replica scaling 展開）
• Storage 自動 grow per 10GB

跨 region replication：Aurora Global Database 用 AuroraGlobalDBReplicationLag 監測、< 1 秒 typical。

回路徑：4.20 Observability Evidence Package 抽 CloudWatch evidence、9.5 瓶頸定位流程 判斷 storage-bound vs compute-bound。

Netflix +75% 效能改善的根因

9.C23 Netflix consolidation 案例揭露 storage 設計的具體效能含義。Netflix 把多套 RDBMS（PostgreSQL / MySQL / Oracle）統一到 Aurora、拿到 up to 75% 效能改善、-28% 成本。

+75% 的根因：

• 傳統 PostgreSQL primary 寫 WAL + dirty page flush + 透過 streaming replication 推到 replica
• Compute 大量 CPU 用在 dirty page flush + replication encoding、不是用在 query processing
• Aurora compute 只送 redo log records、storage 自己 apply page、自己 checkpoint
• → 同樣 instance class 下、Aurora compute 能處理更多 query

這不是 marketing 的「分散式儲存讓效能提升」籠統說法、而是具體的 compute 不再 flush dirty page。

scope warning（必明示、case 自帶警示原話）：

「effective 75% improvement 是跨多 workload 的最大改善幅度、不是『每個 workload 都 +75%』。實際每個 workload 改善幅度從 10% 到 75% 不等」（case「需要警惕」段第 1 點）。

引用 Netflix 時不能把 75% 套到單一 workload — 容量規劃要看自家 workload 形狀（write-heavy / read-heavy / scan-heavy）、預估改善幅度範圍而非單一數字。

Fleet 治理（cross-link、不展開）

Production scale 不是「單一巨型 Aurora cluster」而是 fleet of clusters — 5 case 揭露同一 frame：

• DraftKings 200 個獨立 cluster（按業務切分）
• Netflix 多 cluster（微服務私有 store）
• Standard Chartered 7 個 cluster（受監管市場 boundary）

跨 case 合成的 fleet 拓樸 3 條 driver（business sharding / microservice ownership / 合規市場 boundary）跟「何時拆 cluster vs 加 replica」的判讀順序、SSoT 在 Aurora read replica scaling 邊界段。Storage 設計本身不解 fleet 邊界決策 — Aurora 解 single-cluster scaling（quorum / 共享 storage / 共享 backup）、但「拆幾個 cluster」是業務拓樸決策。

邊界與整合 / 下一步

Sibling deep articles：

• Aurora cross-AZ failover RTO — storage 設計如何加速 failover（replica 不需要 catch-up）
• Aurora read replica scaling — 共享 storage 為什麼能養 15 replica + fleet 治理 SSoT
• Aurora Global Database — 跨 region storage replication 設計

Migration playbook：

• PostgreSQL / MySQL → Aurora — storage 設計差是 operational redesign 的核心 driver

1.x 章節互引：

• 1.3 Transaction Boundary — quorum 寫入 vs single-primary transaction 邊界
• 1.11 全球分散式 OLTP — Aurora storage 是 single-region scaling、不是 distributed SQL

何時不用本文：single-region OLTP 用 RDS 仍足夠、storage architecture 細節不影響容量規劃時可跳過、看 Aurora vendor overview 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Quorum 卡片 — 概念基底
• Replication Lag 卡片 — 對照通用 replication lag 模型
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora storage architecture