OLTP&OLAP
|
|
OLTP |
OLAP |
| 概念 |
OLTP即聯機事務處理，就是我們經常說的關係資料庫，增刪查改就是我們經常應用的東西，這是資料庫的基礎；TPCC(Transaction Processing Performance Council)屬於此類。 強調資料庫記憶體效率，強調記憶體各種指標的命令率，強調併發操作。 |
OLAP即聯機分析處理，是資料倉庫的核心部心，所謂資料倉庫是對於大量已經由OLTP形成的資料的一種分析型的資料庫，用於處理商業智慧、決策支援等重要的決策資訊；資料倉庫是在資料庫應用到一定程式之後而對歷史資料的加工與分析，讀取較多，更新較少，TPCH屬於此類。 隨著大資料時代的到來，對於OLAP，列儲存模式或者說nosql模式比傳統意義的行儲存模式可能更具優勢。 強調資料分析，強調SQL執行市場，強調磁碟I/O，強調分割槽等。 |
| 功能 |
日常操作處理 |
分析決策 |
| DB設計 |
面向應用 採用實體-聯絡ER模型和麵嚮應用的資料庫設計 |
面向主題 採用星型或雪花模型和麵向主題的資料庫設計 |
| 資料 |
當前的，最新的細節的，二維的分立的 |
歷史的，聚集的，多維的整合的，統一的 |
| 存取 |
讀/寫數十條記錄 |
讀上百萬條記錄 |
| 工作單位 |
簡單事物 |
複雜查詢 |
| 使用者數 |
上千個 |
上百萬個 |
| DB大小 |
100MB-GB |
100GB-TB |
| 時間要求 |
實時性 |
對時間要求不嚴格 |
| 主要應用 |
資料庫 |
資料倉庫 |
| 吞吐量 |
小 |
大 |
| 併發訪問量 |
非常高 |
不高 |
| 單筆事物的資源消耗 |
小 |
大 |
| SQL語句型別 |
主要是插入和修改操作（DML） |
主要是大量的查詢操作或是批量DML操作 |
| 並行技術 |
使用不多 |
大量使用 |
| 物化檢視 |
少量使用 |
大量使用 |
| 特點 |
1.實時性要求高。 2.資料量不是很大，生產庫上的資料量一般不會太大，而且會及時做相應的資料處理與轉移。 3.交易一般是確定的，比如銀行存取款的金額肯定是確定的，所以OLTP是對確定性的資料進行存取。 4.高併發，並且要求滿足ACID原則。比如兩人同時操作一個銀行卡賬戶，比如大型的購物網站秒殺活動時上萬的QPS請求。 |
1.實時性要求不是很高，比如最常見的應用就是天級更新資料，然後出對應的資料報表。 2.資料量大，因為OLAP支援的是動態查詢，所以使用者也許要通過將很多資料的統計後才能得到想要知道的資訊，例如時間序列分析等等，所以處理的資料量很大。 3.OLAP系統的重點是通過資料提供決策支援，所以查詢一般都是動態，自定義的。所以在OLAP中，維度的概念特別重要。一般會將使用者所有關心的維度資料，存入對應資料平臺。 |
| 能力評估標準 |
一般都是高可用的線上系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量。 |
在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的資料也非常多。所以，在這樣的系統中，考核的標準往往是磁碟子系統的吞吐量（頻寬），如能達到多少MB/s的流量。 |
| 瓶頸點 |
OLTP系統最容易出現瓶頸的地方就是CPU與磁碟子系統。 |
磁碟子系統的吞吐量則往往取決於磁碟的個數，這個時候，Cache基本是沒有效果的，資料庫的讀寫型別基本上是db file scattered read與direct path read/write。應儘量採用個數比較多的磁碟以及比較大的頻寬，如4Gb的光纖介面。 |
| 優化思路 |
Cache 和索引。儘量減少表關聯，減少分散式事務，OLTP 系統是一個數據塊變化非常頻繁，SQL 語句提交非常頻繁的系統。 對於資料塊來說，應儘可能讓資料塊儲存在記憶體當中。 在設計上要特別注意，如在高可用的OLTP環境中，不要盲目地把OLAP的技術拿過來用。 |
對於OLAP系統，在記憶體上可優化的餘地很小，增加CPU 處理速度和磁碟I/O 速度是最直接的提高資料庫效能的方法，當然這也意味著系統成本的增加。 |
關係
參考文獻：
https://www.cnblogs.com/hhandbibi/p/7118740.html
https://www.cnblogs.com/andy6/p/6011959.html
https://blog.csdn.net/zhongguomao/article/details/53769948
https://blog.csdn.net/qq_33414271/article/details/81149966