開始思考的背景

剛開始到公司的時候，我們只有 MySQL 系統使用的資料庫，撈資料也是直接用 R 連線到 Production Database，憑藉著大學和碩士班把 MySQL 查詢優化摸得很透徹，這樣查沒有影響系統效能的話，倒也不是什麼大問題，直到開始遇到需要查過去半年的答題數據，下的條件沒有建立 index ，按下去居然要 30分鐘 ，而主管表示針對巨大的 log 表加上新的 index 是個很大的成本，而且查詢的條件組合多元，會因此建立超級多 index。

因為這樣的背景我便回想起研究所時，指導教授提過 OLTP 與 OLAP 這兩種不同的資料系統，也開始深入研究這兩種系統的差異，我們需要的是在 MySQL 建立 index，還是真的需要一個新的 OLAP 資料系統來幫助分析？

OLTP 與 OLAP

資料儲存後的主要有兩種處理目的：『處理系統運作交易需求』與『分析彙總資料』

因此在資料處理系統產生了兩種分類：

OLTP (Online Transaction Processing)

為了支援軟體系統日常運作而設計的，SQL查詢類型通常是針對『某個特定用戶的指定功能內容』，例如：A用戶目前購物車的商品有哪些。

技術重點在於快速、高效的資料CRUD （建立、讀取、更新、刪除），並且要求嚴格的ACID （原子性、一致性、隔離性、持久性），以能夠處理大量的concurrent requests，並確保每次用戶操作得到的行為或是資訊是一致的。

特點：

• 高吞吐量：能夠處理大量小型的交易請求。

• 低延遲：對回應時間要求很高，確保用戶的體驗

• 高一致性：利用ACID 特性來確保資料的完整性與一致性

OLAP (Online Analytical Processing)

這類型的資料庫設計是為了支援複雜的查詢和資料分析，幫助公司進行多維度的數據分析，作為決策的依據，常見查詢是針對『一群用戶在指定時間區段的統計』，例如：過去三個月都有登入，且結帳次數超過5次的用戶數量』。

對於技術的需求重點在於資料庫內用區塊式的查詢、有效率的統計計算。

特點：

• 批量處理：一次性處理大量數據，用於分析趨勢和模式。

• 延遲容忍度高：相對於OLTP，OLAP系統對即時性要求不高，重點是正確性和深度分析。

• 多維度數據模型：通常以多維度資訊能快速被取得來設計，能夠進行複雜的查詢分析，如Slicing、Chunk、Roll Up 或Drill Down 等操作。

OLTP 與 OLAP 的比較

OLAP 的計算實現

OLAP 其實並不一定是一個資料庫，有許多不同的實踐方式，像是最經典的 Hadoop (HDFS + MapReduce)，也是近代資料工程最關注的重點。
比較常見可以分成 In-memory computing 和 In-database computing ，這兩種計算理論同樣是出自 UC Berkeley 的兩個實驗室，In-memory computing 就是大家日常處理資料的方式，有一天另一個實驗室就想說，『為什麼我需要把一大堆資料從資料庫拿出來做計算，不能先在裡面算好呢？』於是產生了 In-database computing 這樣的概念，後續的文章也會跟大家進一步聊聊。

小結

OLTP 系統適用於需要頻繁處理大量小型交易查詢的情境，而 OLAP 系統則專注於資料分析，幫助企業進行用戶行為的研究、長期戰略規劃。兩者在資料處理的焦點上有所不同：OLTP 重視速度與資料一致性，OLAP 則專注於提供高效且深入的資料分析。

也因為OLTP 和 OLAP 有如此不同的技術要求，衍生不同的資料庫底層邏輯的設計，像是

• In-memory computing 與 In-database computing
• Row-base Database 與 Columnar Database

而 MySQL 是最常見也使用最廣泛的一個 OLTP 資料庫系統，屬於關聯式的資料庫設計，後續的文章會針對兩種資料庫結構差異 與 MySQL關聯式資料庫的設計模式 進行深入說明。