寫入吞吐

寫入吞吐決定 collector 每秒能消化多少事件。SQLite 的寫入效能主要受 fsync 頻率和 WAL checkpoint 影響。

單筆 INSERT

每筆 INSERT 獨立一個 transaction 時，每次 commit 都會 fsync。WAL mode 的 fsync 成本比 journal mode 低（append-only），但仍是寫入的主要瓶頸。

modernc.org/sqlite（pure Go）的效能約為 CGO driver（mattn/go-sqlite3）的 60-80%。上表數字基於 CGO driver，pure Go 需打八折。Go HTTP handler 的開銷（JSON 解碼、schema 驗證、goroutine 調度）再扣 10-20%。

批次 INSERT

一個 transaction 包裹多筆 INSERT，只做一次 fsync。Collector 接收 SDK 的 flush batch（一個 HTTP request 帶一批事件）天然適合批次寫入。

吞吐提升幅度和批次大小的關係：

提升來自 fsync 次數從「每筆一次」降到「每批一次」。超過 100 筆/tx 後邊際收益遞減。

實際預期

結合 pure Go driver、HTTP handler 開銷和批次寫入，不同環境下的預期吞吐：

和事件產生速率的對照

burst 和持續的差異在於：burst 是短暫的高峰（flush batch 到達後數秒內消化完），持續是長時間的穩定高流量。SQLite 的 WAL mode 對 burst 容忍度高（write lock 等待時間短），對持續高流量容忍度有限（write lock 等待累積）。

查詢延遲

查詢延遲決定 dashboard 的刷新體驗。SQLite 的查詢效能取決於索引覆蓋和掃描行數。

有索引的查詢

建議的索引（見 規模演進 的建議索引段）覆蓋 dashboard 的核心查詢模式。有索引時的預期延遲：

無索引的查詢

無索引時 SQLite 做全表掃描。掃描速度約 50-100 MB/sec（SSD）、10-30 MB/sec（HDD）。

超過 100 萬筆無索引查詢會超出 dashboard 可接受的刷新延遲 — 這是 day-one 就建索引的理由。

Dashboard 刷新頻率 vs 查詢延遲

Dashboard 的每個視圖有不同的刷新間隔和可接受延遲。查詢延遲超過可接受值時，dashboard 體驗變差（等待轉圈、資料過時）。

「需要預聚合」代表原始事件的聚合查詢超過可接受延遲，應該依賴分層保留策略中的 hourly_summary / daily_summary 表（見 規模演進 的分層保留段）。

資源消耗

記憶體

Raspberry Pi（1 GB RAM）上建議把 page cache 調小（PRAGMA cache_size = -512 = 512 KB），避免大結果集查詢（加 LIMIT），dashboard 刷新頻率降低。

CPU

磁碟

WAL 檔案通常 < 10 MB（auto-checkpoint 在 WAL 達到 1000 pages 時觸發）。分層保留策略下，原始事件只保留 7 天，長期佔用由聚合摘要表決定（遠小於原始事件）。

邊緣設備場景

Raspberry Pi、低配 VPS（1 核 / 1 GB RAM）、甚至 NAS 上跑 collector 時的特殊考量：

SD card 的隨機寫入：SD card 的隨機寫入 IOPS 極低（100-500 IOPS），WAL mode 的 checkpoint（把 WAL 內容合併回主資料庫檔案）可能卡住 1-5 秒。期間新的寫入等待 checkpoint 完成。建議調高 wal_autocheckpoint 的閾值（如 5000 pages），讓 checkpoint 頻率降低但每次時間更長 — 在非活躍時段（凌晨）手動觸發 PRAGMA wal_checkpoint(TRUNCATE)。

1 GB RAM：cache_size 調小（512 KB）、避免 SELECT * 不帶 LIMIT、GROUP BY 的結果集用 HAVING 條件過濾減少暫存。Dashboard 的長期聚合直接查 hourly_summary 表而非原始事件。

ARM CPU：pure Go SQLite driver（modernc.org/sqlite）在 ARM 上的效能差距可能比 x86 更大（pure Go 的 C-to-Go 翻譯在 ARM 的指令最佳化較少）。實測確認。

建議配置：邊緣設備上 collector 的 dashboard 刷新頻率從預設值降低（即時狀態卡 5 秒 → 30 秒，趨勢圖 30 秒 → 5 分鐘），降採樣 job 頻率從每小時改為每 6 小時。

實測方法指引

教學的預期數字是推導值，實際效能取決於使用者的硬體和 workload。Collector 提供內建的 benchmark 命令讓使用者在自己的環境實測。

寫入 benchmark

1# 單筆寫入：10000 筆，每筆獨立 transaction
2./collector benchmark write --events=10000 --batch=1 --storage=sqlite
3
4# 批次寫入：10000 筆，每 100 筆一個 transaction
5./collector benchmark write --events=10000 --batch=100 --storage=sqlite

輸出：total duration、events/sec、p50/p95/p99 latency per event。

查詢 benchmark

1# 先灌入測試資料
2./collector benchmark seed --events=100000 --storage=sqlite
3
4# 跑查詢 benchmark
5./collector benchmark query --type=error --group-by=name --storage=sqlite
6./collector benchmark query --session-id=random --storage=sqlite

輸出：query duration、rows scanned、rows returned。

Production 觀察指標

部署後用 DevOps dashboard（見 DevOps Dashboard 設計）觀察 collector 自身的效能 metric：

• collector.storage.write_duration_ms：每次寫入的延遲。P95 超過 100ms 是瓶頸訊號。
• collector.storage.query_duration_ms：每次查詢的延遲。P95 超過 dashboard 刷新間隔是瓶頸訊號。
• collector.storage.db_size_bytes：資料庫大小。接近磁碟可用空間的 80% 時觸發 purge 或擴容。
• collector.storage.wal_size_bytes：WAL 檔案大小。持續 > 50 MB 代表 checkpoint 跟不上寫入速度。

下一步路由

• 切換到 PostgreSQL 的觸發條件 → 規模演進
• SQLite 和 PostgreSQL 的功能分層 → 功能分層與 Backend 選擇
• Ingestion 端的擴展設計 → Ingestion Scaling

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PG 在 OLTP 譜系的定位、本文聚焦 SQL features baseline — PG 早期就有的、MySQL 8.0 才補的、PG 仍領先的、給從 MySQL 評估 PG 的讀者 reference。

PG SQL 工程深度的歷史錨點

PG 在 SQL feature 上長期領先 MySQL：

• 2009 (PG 8.4)：CTE / window function / recursive query
• 2013 (PG 9.3)：lateral derived table / materialized view
• 2014 (PG 9.4)：JSONB / partial index 早就有 / GIN index
• 2015 (PG 9.5)：UPSERT (ON CONFLICT)
• 2017 (PG 10)：declarative partitioning / logical replication / multi-column statistics

MySQL 8.0（2018）才補 CTE / window / lateral / JSON_TABLE / hash join — PG 早 9 年起步。

對 從 MySQL 評估 PG 的讀者來說、PG 的 SQL 工程深度不只是「該有的都有」、更多是「PG 結構性領先的特性 + MySQL 8.0 補了哪些 + PG 仍領先哪些」。

跟 MySQL Modern SQL Features 對比視角：

• MySQL 8.0 視角：「我終於補齊 + 跟 PG 對比」
• PG 視角：「我長期領先 + MySQL 8.0 才追上某些、其他我仍領先」

PG 結構性領先特性（MySQL 沒對應 / 弱對應）

1. Materialized View

PG 9.3+ 內建 materialized view：

1CREATE MATERIALIZED VIEW orders_summary AS
2SELECT user_id, COUNT(*) AS order_count, SUM(amount) AS total
3FROM orders GROUP BY user_id;
4
5-- 手動 refresh
6REFRESH MATERIALIZED VIEW orders_summary;
7-- 或 concurrent refresh（PG 9.4+、不 lock read）
8REFRESH MATERIALIZED VIEW CONCURRENTLY orders_summary;

用途：

• 預計算複雜 aggregation、查詢時極快
• Concurrent refresh 不 lock read
• 可建 index on materialized view

MySQL 對應：沒原生 materialized view。常見替代：

• Trigger + summary table（手動維護）
• Application 層 caching layer
• 用 view + cache layer（不是 materialization）

MySQL 8.0+ 仍無原生 materialized view。

2. Partial Index

PG 預設支援 partial index — 對 滿足條件的 row 才建 index：

1-- 只對 active user 建 index
2CREATE INDEX idx_users_active_email ON users(email) WHERE status = 'active';
3
4-- Index size 比 full index 小很多、query 性能跟 full index 一樣
5SELECT * FROM users WHERE status = 'active' AND email = 'x@y.com';

用途：

• Soft-delete 場景：對 deleted_at IS NULL 建 partial index
• Hot subset 場景：對 status = 'pending' 等熱資料建 partial
• Index 大小 / 寫入成本大降

MySQL 對應：MySQL 沒原生 partial index。MySQL 8.0+ 有 functional index 但跟 partial 不同。MySQL 替代：

• Generated column + index（接近、但維護複雜）
• 或接受 full index cost

3. Foreign Data Wrapper (FDW)

PG FDW 讓 query 跨外部資料源：

 1CREATE EXTENSION postgres_fdw;
 2
 3CREATE SERVER remote_db FOREIGN DATA WRAPPER postgres_fdw
 4OPTIONS (host 'remote.example.com', dbname 'analytics');
 5
 6CREATE USER MAPPING FOR localuser SERVER remote_db
 7OPTIONS (user 'remoteuser', password '...');
 8
 9CREATE FOREIGN TABLE remote_orders (id INT, ...) SERVER remote_db OPTIONS (table_name 'orders');
10
11-- 在 local PG query remote table
12SELECT * FROM remote_orders WHERE id = 100;

支援 FDW：postgres_fdw / mysql_fdw / oracle_fdw / mongo_fdw / file_fdw / redis_fdw 等。

MySQL 對應：MySQL 8.0+ 有 FEDERATED engine（受限、不推薦）。實務上 MySQL 跨 DB query 用 application 層處理。

4. JSONB + GIN Index（PG 結構性優勢）

PG JSONB 是 binary 儲存 + 可 直接 GIN index：

 1CREATE TABLE products (
 2    id SERIAL PRIMARY KEY,
 3    metadata JSONB
 4);
 5
 6-- GIN index over JSONB
 7CREATE INDEX idx_products_metadata ON products USING GIN (metadata);
 8
 9-- 快 query
10SELECT * FROM products WHERE metadata @> '{"category": "shoes"}';
11SELECT * FROM products WHERE metadata @? '$.variants[*].price > 100';

MySQL 對應：MySQL 8.0 JSON_TABLE 是 SQL standard、但 index 必須 generated column workaround（不能 GIN index over JSON）。

詳見 MySQL Modern SQL Features JSON_TABLE vs PG JSONB 對比段。

5. Range Types + Exclusion Constraints

PG range types + exclusion constraints 防止 時間範圍重疊：

 1CREATE TABLE reservations (
 2    id SERIAL PRIMARY KEY,
 3    room_id INT,
 4    during TSRANGE,
 5    EXCLUDE USING GIST (room_id WITH =, during WITH &&)
 6);
 7
 8-- INSERT 重疊 booking 自動 reject
 9INSERT INTO reservations (room_id, during)
10VALUES (1, '[2026-05-19 10:00, 2026-05-19 12:00)');
11INSERT INTO reservations (room_id, during)
12VALUES (1, '[2026-05-19 11:00, 2026-05-19 13:00)');
13-- ERROR: conflicting key value violates exclusion constraint

MySQL 對應：完全沒對應、必須 application 層 enforce。

6. CHECK Constraint + Domain Type

PG CHECK constraint 真執行（MySQL 8.0 才補）+ user-defined DOMAIN：

1CREATE DOMAIN positive_int AS INT CHECK (VALUE > 0);
2CREATE TABLE orders (
3    id SERIAL PRIMARY KEY,
4    quantity positive_int NOT NULL,
5    amount DECIMAL CHECK (amount >= 0)
6);

MySQL 對應：8.0+ 有 CHECK constraint enforcement（5.7 可寫但不執行）。沒 user-defined DOMAIN。

7. Extension Ecosystem

PG extension 是 結構優勢：

• pg_partman：自動 partition lifecycle
• pg_repack：online table rewrite
• pg_stat_statements：query stats
• pgvector：vector similarity search
• pg_cron：scheduled job
• PostGIS：GIS
• TimescaleDB：time-series
• Citus：sharding

MySQL 對應：MySQL plugin 機制有、生態遠遠不如。詳見 PG Extension Ecosystem 篇（待寫）。

MySQL 8.0 補齊的 PG 既有特性

MySQL 8.0 是 補齊 9 年 SQL standard 落後、不是 新領先 PG。

PG 仍領先的特性

對應「MySQL 8.0 補了 → PG 仍沒輸」的視角。以下 14 條中、production 影響最大 的是 Materialized view / Partial index / JSONB GIN / Full-text search 跟 Range / Exclusion constraints（schema-level expressiveness）；次要但常用 的是 Multi-column statistics 跟 Procedural language；非典型但 niche 重要 的是 User-defined DOMAIN / Generic table inheritance（讀者不必然知道、但 ORM 跟 schema migration 工具會用）：

對「從 MySQL 評估 PG」的讀者

讀者通常從 MySQL 8.0 過來、問題是 「PG 比 MySQL 強在哪、弱在哪」：

PG 比 MySQL 強

• SQL 工程深度：上面列的 7 個結構優勢
• Extension ecosystem：pgvector / TimescaleDB / Citus / pg_partman 等
• Optimizer：planner 對複雜 query 更成熟
• Concurrency model：MVCC + 少 lock（MVCC + Lock Model）

PG 比 MySQL 弱

• Replication 機制簡潔度：MySQL GTID 比 PG WAL + replication slot 配置簡單（Replication Topology）
• Sharding ecosystem：Vitess / PlanetScale 比 Citus 規模驗證高
• Operational tooling 廣度：pt-toolkit / gh-ost / Orchestrator 等
• VACUUM 維護：PG MVCC 必須 VACUUM、autovacuum 配錯議題多（Autovacuum Tuning）

選 PG 的核心 driver

對 SQL 工程深度、extension、複雜 query / OLAP-style workload 的場景、PG 仍是首選。對純簡單 OLTP + 大規模 sharding、MySQL + Vitess 仍 competitive。

跟其他模組整合

• MVCC + Lock Model：PG MVCC 是 SQL feature 的並行控制基礎
• Query Optimization：PG planner 對 window / CTE / hash join 成熟
• Citus Distributed：extension 之一、體現 extension 生態
• Autovacuum Tuning：MVCC 代價、跟 SQL feature 並行控制相關

相關連結

• PostgreSQL vendor overview
• PG MVCC + Lock Model（concurrency 基礎）
• PG Query Optimization（planner 成熟度）
• PG Citus Distributed（extension example）
• PG Autovacuum Tuning（MVCC 維護）
• MySQL Modern SQL Features（sibling、反向視角）
• 官方：PostgreSQL Features