為什麼選型這麼難#

儲存產品幾十種，「哪個對」沒有絕對答案。本章把選型決策結構化：

1. 先理清業務需求
2. 對應到資料模型 + 存取模式
3. 過濾候選技術
4. 用評估維度比較
5. 配合運維能力做最終決定

第 1 步：問對的問題#

選型前要回答的問題：

最後一條最常被忽略 ── 但是最重要。一個團隊不會用的技術再先進也是失敗。

第 2 步：資料模型與存取模式#

資料模型對選型決定性極大：

不要硬把所有資料塞到單一儲存。電商完整架構通常有 5~10 種儲存共存。

第 3 步：訪問模式決定細節#

兩個都用 RDBMS，需求差異會導致設計差異：

場景 A: 訂單查詢
  - 「我的訂單列表」── user_id + date 範圍
  - 「訂單詳情」── order_id 單筆

  → 設計：以 user_id 分片，order_id 編碼 user_id，主鍵 (user_id, order_id)

場景 B: 商品查詢
  - 「商品詳情」── product_id 單筆，QPS 極高
  - 「分類列表」── category_id + 排序

  → 設計：products 表加 cache 層，category 走 ES

儲存選型不只選哪個 DB，還要設計怎麼用它。

第 4 步：評估維度#

當候選收斂到 2~3 個，從這些維度比較：

性能#

不只看 marketing 數字 ── 跑你自己的 benchmark。每個系統都有 sweet spot 與 weak spot。

一致性#

電商：賬戶必 Strong；商品 cache 可 Eventual；訂單視業務切。

可用性#

雲端商用通常 SLA 99.99%。自建要對等需要重複工程。

擴展性#

運維#

雲端託管在這個維度幾乎全勝（每個都不用自己擔）。

成本#

生態與社群#

冷門技術可能技術上更好，但人才難找、社群差、Stack Overflow 沒人答 ── 真實成本很高。

在線業務的選型矩陣#

線上業務（OLTP）的常見決策：

結構化 + 強事務#

首選：MySQL（成熟、社群、SDK 全）
備選：PostgreSQL（功能更豐、JSON 強）

需要極端擴展：TiDB / CockroachDB / Spanner（NewSQL）
雲端 native：Aurora / AlloyDB / TiDB Cloud

KV / Cache#

快、單純：Redis
高可用：Redis Cluster
持久 + 雲託管：DynamoDB / Bigtable

媒體 / 大檔#

公雲：S3 / OSS / COS
自建大規模：MinIO、Ceph

半結構化#

純文檔：MongoDB
與 RDBMS 混存：PostgreSQL JSONB

全文 / 搜尋#

首選：Elasticsearch（OpenSearch）
輕量：Meilisearch、Typesense
規模極大：Solr Cloud、Vespa

訊息#

吞吐第一：Kafka
功能豐富：Pulsar、RocketMQ
輕量：RabbitMQ、NATS

時序 / metrics#

監控：Prometheus
大量 IoT：InfluxDB、TimescaleDB
日誌：Loki + Grafana

分析系統的選型#

OLAP 場景另一套：

                            選型流程

           是否需要 ad-hoc 跨多源查詢？
           ┌────────────┴──────────────┐
           是                          否
            │                            │
        Trino / Presto                  資料量？
                                           │
                              ┌────────────┼─────────────┐
                              小（GB）       中（TB）        大（PB）
                                │             │              │
                       PostgreSQL       ClickHouse      ClickHouse
                       (純粹單機OLTP+OLAP)              + S3 lake
                                                        Spark / Trino offline

並考慮：

• 時序 / 時間維度極重 → Druid 比 ClickHouse 更貼合
• 單純報表 + 簡單 → Snowflake / BigQuery（運維 0）
• 與 Hadoop 生態整合 → Hive / Iceberg

反模式#

選型時的常見錯誤：

1. 「大廠用什麼我用什麼」：忽略了規模差異與團隊能力
2. 「最新最潮」：早期版本踩雷頻繁
3. 「全用 MySQL / 全用 MongoDB」：硬塞所有需求進單一儲存
4. 「分庫分表先做了再說」：過早分片，後續難回頭
5. 「先解決現在問題」：3 個月後資料量爆漲再痛苦遷移
6. 「雲廠商一定貴」：自建運維 + 人力可能更貴

一個完整電商的儲存組合#

實際電商可能同時用：

+----------+--------+-----------+---------------------+
| 系統      | 主儲存  | 快取      | 同步去向            |
+----------+--------+-----------+---------------------+
| 用戶      | MySQL  | Redis     | -                   |
| 商品      | MySQL  | Redis     | ES（搜尋）          |
|          | + Mongo|           | CDN（圖片從 OSS）  |
| 訂單      | MySQL  | -         | Kafka → ClickHouse  |
|          | (分片) |           |                     |
| 購物車    | Redis  | -         | MySQL（持久化）     |
| 賬戶      | MySQL  | -         | -                   |
| 庫存      | MySQL  | Redis     | -                   |
| 評論      | MySQL  | -         | ES                  |
| 行為日誌  | -      | -         | Kafka → CK + S3     |
| 圖片      | OSS    | -         | CDN                 |
| 影片      | OSS    | -         | CDN                 |
+----------+--------+-----------+---------------------+

10 種儲存、各司其職。這不是過度工程 ── 是務實設計。

小結#

選型決策樹：

1. 業務需求 → 資料模型 + 訪問模式
2. 候選技術過濾（資料模型對應 + 規模對應）
3. 評估維度比較：
   - 性能 / 一致性 / 可用性 / 擴展性
   - 運維 / 成本 / 生態
4. 配合團隊能力做最終決定
5. POC：跑你自己的 workload，不要信 marketing

最重要：沒有最好的儲存，只有最合適的儲存。電商的成熟系統幾乎都是「對的工具放對的位置」。

下兩章看兩個值得單獨展開的「未來方向」：NewSQL 與 LSM-Tree。