大數據架構下的資料庫設計與工程
在學習資料工程的過程中，雖然沒有特別區分，但從講師的敘述和某些技術中，隱隱可以察覺「大數據」和一般的資料工程是有區隔的，不單單只是「資料變多」而已。所以雖然不在課程內，但我另外又搜尋了一些與大數據有關的資料，包括大數據下的資料庫設計、大數據下的資料工程等。除了分享也作為筆記，讓自己可以重複複習關於大數據的相關知識。
目錄
簡介
在軟體工程的世界裡，資料庫往往是系統的瓶頸所在。當資料規模從 GB 成長至 TB 甚至 PB 等級，我們面臨的不僅是儲存空間的挑戰，更是計算能力的典範轉移 (Paradigm Shift)。
1. 大數據的特殊性 (Volume, Velocity, Variety)
傳統單機資料庫（RDBMS）依賴 Vertical Scaling (Scale-up)，透過升級 CPU 和記憶體來提升效能。然而，硬體升級有其物理極限。大數據架構的核心在於 Horizontal Scaling (Scale-out)，利用數百甚至數千台商用伺服器組成叢集，共同處理龐大的資料集。
2. 分散式架構的本質
在大數據領域（如 Hadoop 生態系、Spark、Cloud Data Warehouses），我們遵循 「分而治之 (Divide and Conquer)」 的哲學：
- 儲存與計算分離 (Storage-Compute Separation)：現代架構傾向將資料存在物件儲存（如 S3, GCS, HDFS），計算資源（如 Spark Executors）則是動態調配的。
- 移動計算而非移動數據：由於網路 I/O 是最大的效能瓶頸，我們盡可能將程式碼派發到存放資料的節點上執行，而非將資料拉回中心節點處理。
資料庫設計模型
理解資料模型的適用場景，是架構師進行技術選型（Tech Stack Selection）的第一步。
1. 一般資料庫模型 (General Purpose / OLTP)
這些模型通常應用於應用程式後端，強調交易的即時性與一致性。
- Relational Model (RDBMS)
- 代表：MySQL, PostgreSQL, Oracle。
- 特性：嚴格 Schema、ACID 交易保證、使用 SQL。
- 適用：核心業務系統（Core Banking, ERP），資料一致性要求極高的場景。
- Document Model
- 代表：MongoDB。
- 特性：Schema-less (BSON/JSON)、支援巢狀結構、開發迭代快。
- 適用：內容管理系統 (CMS)、產品目錄 (Catalog)、屬性高度動態的資料。
- Key-Value Model
- 代表：Redis, DynamoDB。
- 特性：Hash Table 結構、O(1) 讀寫延遲。
- 適用：快取 (Cache)、Session Store、高併發計數器。
- Graph Model
- 代表：Neo4j。
- 特性：以節點 (Node) 與邊 (Edge) 儲存關係，解決遞迴查詢效能問題。
- 適用：社交網絡分析、推薦引擎、路徑演算法。
2. 大數據與資料倉儲模型 (Analytical / OLAP)
當場景轉向數據分析時，寫入效能不再是首要考量，查詢吞吐量 (Throughput) 與 歷史資料整合 才是重點。