講講OLTP和OLAP資料庫領域中大家經常會看到兩個詞：OLTP及OLAP。舉例說明，比如進行一次交易，資金從A帳戶轉帳到B帳戶，這整個過程就是一次交易事務。如果過程中有任何系統錯誤，交易會回滾A帳戶中的金額都回恢到操作前的狀態，這就是On-Line Transaction Processing聯機事務處理過程(OLTP)的操作。在OLTP場景中使用者併發操作量會很大，要求系統實時進行資料操作的響應，在查詢時往往也是隻會檢索一條或幾條明確的目標資料，以實現使用者的業務互動。OLAP意思是On-Line Analytical Processing聯機分析處理，顧名思義就是主要針對於資料的分析彙總操作。如我們的業務系統中每天都需要出銷售日報，這個操作需要對當天所有資料進行彙總，並需要進行計算，以得到全天收入、產品銷售排名、分時段的銷售量，甚至與過去30天及去年當天進行對比，這樣的操作都屬於OLAP。業界早期使用資料時，尤其是OLTP場景下，通常選擇非分散式的關係型資料庫，如MySQL、SQLServer、Oracle、PostgreSQL即可滿足大部份的需求。OLAP中主流資料庫遭遇瓶頸從技術角度而言，OLAP場景，不僅涉及的資料量大而且要求分析的結果實時返回，對應的SQL查詢十分複雜。如何做到技術性能和業務功能權衡，對於資料庫而言是一個重大考驗。已有的兩個主流開源資料庫，MySQL和PostgreSQL都是針對OLTP環境的，在OLAP線上分析需求下它們的效能明顯不足。特別是MySQL在大規模分析操作時多表Join的效能是當前網際網路使用者的一大痛點。在OLAP發展的早期，其操作並沒有專門的資料庫支撐，直接就與OLTP業務放在同一個資料庫中完成。但隨著業務量的增加，OLAP每次要分析的資料量越來越大，這樣的分析操作執行時就會導致資料庫的業務交易下降。因此業界開始將OLTP、OLAP拆分成兩套不同的資料庫進行處理，OLTP資料庫中的資料通過ETL軟體持續或定期抽取到OLAP資料庫，讓業務交易與報表分析進行分離。