簡介
並非所有資料都適合關聯式資料庫。照片、影片、日誌、指標、搜尋索引——每種類型的資料都需要正確的儲存引擎。本文探討了專用儲存系統。
1. 物件存儲
1.1 什麼是物件儲存？
Traditional File System: Object Storage:
/home/ ┌─────────────────────┐
/images/ │ Flat Namespace │
/2024/ │ │
/01/ │ key → object (blob) │
photo.jpg │ key → object (blob) │
│ key → object (blob) │
Hierarchical └─────────────────────┘
Directories, inodes Flat, HTTP API
Mount required REST access
1.2 S3 相容架構
Client: PUT /bucket/images/photo.jpg
│
▼
┌──────────────┐
│ API Gateway │ ← REST: GET, PUT, DELETE, LIST
└──────┬───────┘
▼
┌──────────────┐
│ Metadata │ ← Key → location mapping
│ Service │ ← ACL, versioning, lifecycle
└──────┬───────┘
▼
┌──────────────────────────────────┐
│ Data Layer (Distributed) │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Node 1│ │Node 2│ │Node 3│ │ ← 3x replication
│ └──────┘ └──────┘ └──────┘ │
└──────────────────────────────────┘
1.3 用例
| 使用案例 | 範例 |
|---|---|
| 靜態資產 | 圖片、CSS、JS → CDN 起源 |
| 備份 | 資料庫轉儲、日誌存檔 |
| 資料湖儲存 | 用於分析的原始資料 |
| 媒體 | 影片、音訊檔案 |
| 機器學習工件 | 模型檔案、訓練資料集 |
1.4 預簽 URL 模式
Vấn đề: User upload file 100MB qua API server → bottleneck
Giải pháp: Presigned URL - upload trực tiếp lên S3
Client → API: "Tôi muốn upload avatar.jpg"
API → S3: GeneratePresignedURL(PUT, bucket, key, 15min)
API → Client: "Upload tại URL này (hết hạn 15 phút)"
Client → S3: PUT trực tiếp (không qua API server)
S3 → SNS/Lambda: Trigger post-processing
# Python - Generate presigned URL
import boto3
s3 = boto3.client('s3')
url = s3.generate_presigned_url(
'put_object',
Params={'Bucket': 'my-bucket', 'Key': 'uploads/avatar.jpg'},
ExpiresIn=900 # 15 minutes
)
2. 資料湖、資料倉儲、Lakehouse
2.1 比較
Data Warehouse: Data Lake: Lakehouse:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Structured only │ │ Raw everything │ │ Best of both │
│ Schema-on-WRITE │ │ Schema-on-READ │ │ Schema evolution │
│ SQL queries │ │ Any processing │ │ SQL + ML + Stream│
│ Expensive │ │ Cheap storage │ │ Open formats │
│ │ │ │ │ │
│ Redshift, BQ, │ │ S3 + Spark, │ │ Delta Lake, │
│ Snowflake │ │ HDFS │ │ Apache Iceberg │
└──────────────────┘ └──────────────────┘ └──────────────────┘
2.2 資料湖架構
Data Sources Ingestion Storage Layers
┌──────────┐ ┌─────────┐ ┌─────────────────┐
│ APIs │────────────►│ │───────►│ Raw Zone │
│ DBs │────────────►│ Kafka/ │───────►│ (landing) │
│ Logs │────────────►│ Spark │ ├─────────────────┤
│ IoT │────────────►│ Airflow │───────►│ Cleaned Zone │
│ Files │────────────►│ │ │ (validated) │
└──────────┘ └─────────┘ ├─────────────────┤
│ Curated Zone │
│ (analytics-ready│
└────────┬────────┘
│
┌────────▼────────┐
│ Consumption │
│ BI, ML, Reports │
└─────────────────┘
3. 時間序列資料庫
3.1 時間序列資料特徵
Đặc điểm:
- Append-mostly (ít update, delete)
- Time-ordered
- High write throughput
- Recent data truy vấn nhiều hơn
- Aggregations: avg, sum, percentile theo time window
Ví dụ:
Metrics: CPU usage mỗi 10s, 100 servers → 864K points/ngày
IoT: 10K sensors, mỗi giây 1 reading → 864M points/ngày
3.2 最佳化
1. Time-based partitioning:
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Jan 2024 │ │ Feb 2024 │ │ Mar 2024 │
└──────────┘ └──────────┘ └──────────┘
→ Drop old partitions thay vì DELETE
2. Columnar storage:
Row: [time, cpu, mem, disk] [time, cpu, mem, disk] ...
Column: [time, time, time...] [cpu, cpu, cpu...] [mem, mem, mem...]
→ Compression tốt hơn (cùng type data)
→ Aggregation nhanh hơn
3. Downsampling:
Raw: 1 point/giây (86400/ngày)
1h: 1 point/giờ (24/ngày)
1d: 1 point/ngày
→ Giữ raw 7 ngày, 1h 30 ngày, 1d mãi mãi
3.3 流行的TSDB
| 資料庫 | 建築 | 優點 |
|---|---|---|
| InfluxDB | 單機/叢集 | 設定簡單，InfluxQL |
| TimescaleDB | PostgreSQL 擴充 | 完整的 SQL、超表 |
| 普羅米修斯 | 基於拉動的指標 | K8s 原生、PromQL |
| 點擊屋 | 列式 OLAP | 極快聚合 |
| VictoriaMetrics | 普羅米修斯相容 | 存儲效率 |
3.4 PromQL 範例
# CPU usage trung bình 5 phút
avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)
# Request rate per second (QPS)
rate(http_requests_total[5m])
# 99th percentile latency
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# Alert: CPU > 80% trong 5 phút
avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) < 0.2
4. 搜尋引擎
4.1 Elasticsearch 架構
Cluster
├── Node 1 (Master + Data)
│ ├── Index: products
│ │ ├── Shard 0 (Primary)
│ │ └── Shard 2 (Replica)
│ └── Index: logs
│ └── Shard 1 (Primary)
│
├── Node 2 (Data)
│ ├── Index: products
│ │ ├── Shard 1 (Primary)
│ │ └── Shard 0 (Replica)
│ └── Index: logs
│ └── Shard 0 (Primary)
│
└── Node 3 (Data)
├── Index: products
│ └── Shard 2 (Primary)
└── Index: logs
└── Shard 1 (Replica)
4.2 倒排索引
Documents:
Doc 1: "Kiến trúc hệ thống phân tán"
Doc 2: "Thiết kế hệ thống chat"
Doc 3: "Kiến trúc microservices"
Inverted Index:
"kiến trúc" → [Doc 1, Doc 3]
"hệ thống" → [Doc 1, Doc 2]
"phân tán" → [Doc 1]
"thiết kế" → [Doc 2]
"chat" → [Doc 2]
"microservices" → [Doc 3]
Query: "kiến trúc hệ thống"
→ "kiến trúc" ∩ "hệ thống" = [Doc 1]
→ Score: Doc 1 (match cả 2) > Doc 2, Doc 3
5. 多語言持久性
5.1 電子商務範例
┌─────────────────────────────────────────────────┐
│ E-Commerce App │
├─────────┬──────────┬──────────┬────────┬────────┤
│ Users │ Products │ Orders │ Search │ Cache │
│ │ Catalog │ │ │ │
│PostgreSQL│ MongoDB │PostgreSQL│Elastic │ Redis │
│ │ │ │Search │ │
│Relational│Document │ACID txns │Full-text│Session│
│Schema │Flexible │Consistent│Scoring │Cart │
│Joins │Nested │Foreign │Facets │Rate │
│ │attrs │keys │ │Limit │
└─────────┴──────────┴──────────┴────────┴────────┘
│ │
┌────▼────┐ ┌──────▼──────┐
│ S3 │ │ InfluxDB │
│ Images │ │ Metrics │
│ Files │ │ Monitoring │
└─────────┘ └─────────────┘
總結
| 儲存類型 | 最適合 | 範例 |
|---|---|---|
| 關係型資料庫管理系統結構化、酸性 | 使用者、訂單、帳單 | |
| 文檔資料庫 | 靈活的架構 | 產品目錄，CMS |
| 鍵值 | 簡單、快速 | 快取、會話 |
| 物件儲存 | 檔案、blob | 映像、視訊、備份 |
| 時間序列 | 指標、物聯網 | 監控、感測器資料 |
| 搜尋引擎 | 全文檢索 | 產品搜尋、日誌 |
| 圖資料庫 | 關係 | 社群網路、詐欺 |
| 資料湖 | 原始分析 | 機器學習、商業智慧、報告 |
練習
-
儲存設計： 設計醫療保健系統的儲存架構：病患記錄（符合 HIPAA 標準）、醫學影像（DICOM）、生命徵象監測、處方搜尋。為每個用例選擇哪個資料庫？
-
時間序列： IoT 系統有 50K 個感測器，每個感測器每 5 秒發送一次資料。計算一年所需的儲存量。設計保留政策。
-
搜尋架構： 電子商務有1000萬種產品。搜尋系統設計支援：全文搜尋、篩選器（價格、品牌、類別）、分面導航、自動建議。