另一個常見資料庫分類是從「資料處理*」的應用角度來區分：

交易型Transaction: OLTP:
適合較多輸入(寫入與更新)的應用
記錄交易型資料(如銀行交易)
資料期間較短(3-6個月)
常見以Row-Based的資料庫儲存
資料體相對較小
使用者較多

分析型Analytical: OLAP:
適合較多輸出(讀取)的應用
儲存整合後資料
資料期間較長(2-5年)
較適用Columnar indexing 資料庫(如 Redshift)可以有更好存取效能
資料體相對較大
使用者較少

這兩類型的資料庫並不是對立，更像是前後處理階段之分，常見的應用場景像是銀行的資料庫：每天頻繁的交易產生出一筆筆的交易紀錄，各地分行的資料都存在各自的OLTP資料庫中。到了晚上，總行統一將分行資料更新至大型的OLAP資料庫，以利帳務記錄與交易統整；當每日資料累積到月底的時候，資料分析人員便可以利用OLAP資料庫幫使用者整理出他的交易行為與提出理財建議。

總結目前為止提到的資料儲存型態：
資料倉儲 Data warehouses：適合強結構化資料的集中儲存中心，適用有複雜查詢語句的應用場景
資料湖 Data lakes：適合當資料格式多樣的儲存中心，要查詢資料需較多程序
OLTP資料庫：適合結構化且頻繁寫入或更新的資料，不適合頻繁查詢
OLAP資料庫：適合結有已經過資料清洗的資料，適合快速查詢與分析的應用場景

除了目前為止介紹的DB服務外，AWS上還有許多專為其它資料類型而設計的資料庫，例如：更快速的記憶體資料庫Amazon ElastiCache；圖形化資料庫Amazon Neptune；為IOT串流應用的時間序列資料庫Amazon Timestream；具可靠加密驗證功能的總帳資料庫Amazon Quantum Ledger Database等。當然以上提到的AWS資料庫服務，有些目前還有限制使用區域，但從各種資料庫的類型可以看出資料的多樣性。

豐富的資料經過時間積累都可能會讓使用者面臨容量問題，解決資料流中數據「巨量」的問題，增加儲存容量是一種方法，而另一種方式就是加速處理。接下來會討論如何更快速的處理這些使用者辛苦累積下來的巨量資料。

*線上資料處裡(https://zh.wikipedia.org/wiki/%E7%B7%9A%E4%B8%8A%E5%88%86%E6%9E%90%E8%99%95%E7%90%86 )