從商用到開源:DB2遷移至MySQL的最佳實踐

NO IMAGE
技術小能手 2017-11-27 14:01:03 瀏覽128 評論0 發表於: 數據和雲

架構 服務器 mysql Oracle SQL 日誌 線程 高可用 數據庫 互聯網 查詢優化 磁盤 傳統企業存儲

摘要:

身處數據驅動快速變革的時代,數據庫系統的選型和架構設計對於整個IT基礎架構,甚至企業的發展都起到至關重要的作用。那麼今天,如果您的企業需要搭建一套新的應用系統,你會選擇什麼數據庫類型?如果當前的系統不能滿足業務需求,面臨系統遷移,你又會如何選擇? 在2017年初,我們分享過一份國外的報告“開發人員是如何使用數據庫的 ”,並且進行了一次調查『中國數據庫愛好者的選擇和背離』,其中的一些數據展示了用戶對於數據庫的選擇,非常具有參考價值,鏈接可以直接參考分析報告。

身處數據驅動快速變革的時代,數據庫系統的選型和架構設計對於整個IT基礎架構,甚至企業的發展都起到至關重要的作用。那麼今天,如果您的企業需要搭建一套新的應用系統,你會選擇什麼數據庫類型?如果當前的系統不能滿足業務需求,面臨系統遷移,你又會如何選擇?

在2017年初,我們分享過一份國外的報告“
開發人員是如何使用數據庫的 ”,並且進行了一次調查『中國數據庫愛好者的選擇和背離』,其中的一些數據展示了用戶對於數據庫的選擇,非常具有參考價值,鏈接可以直接參考分析報告


從商用到開源:DB2遷移至MySQL的最佳實踐

隨著互聯網+時代的到來,企業的業務發展對IT架構提出了更高的要求,傳統的架構往往運維複雜、成本高、不易擴展,在很大程度上制約了企業的快速發展。隨著領先互聯網企業的開源架構嘗試和探索,人們開始逐漸接受並嘗試『非IOE』架構和組件,尤其是一些勇於創新的傳統行業企業,如金融、保險、證券等,他們正在快速跟上極速變革的技術新時代。

而在數據庫領域加速這一過程的,便是以MySQL為代表的開源數據庫的應用。MySQL在近幾年發展迅速,以其體積小、速度快、成本低,尤其是開放源碼等優勢受到廣大用戶的喜愛。

同時,在 DB-Engines 的排名上,Oracle 和 MySQL 兩個產品長期霸佔了前兩名的位置。但根據近幾年的增長趨勢,MySQL 在這個榜單上超越Oracle數據庫是遲早的事,而且這一時點可能很快到來。

從商用到開源:DB2遷移至MySQL的最佳實踐

近期,雲和恩墨為某證券公司進行了從DB2到MySQL數據庫系統的遷移論證、驗證,對兩類數據庫展開全方位多角度的對比分析,並根據用戶的業務現狀進行了相關架構、性能、備份恢復及高可用驗證。

在以下的系列文章中,我們將把來自於實踐的分析、論證、驗證數據分享給大家,從商用到開源,從DB2到MySQL,從傳統業務到互聯網架構,一切正在發生。

為什麼是MySQL不是DB2?

我們知道,IT架構通常由業務架構、數據架構、IT基礎架構和應用架構構成,而數據架構則是整個IT架構的中心,企業最核心的資產就是數據。

從商用到開源:DB2遷移至MySQL的最佳實踐

很多傳統的企業比如金融證券等行業的IT軟硬件架構都是IBM系列產品,比如IBM小型機/DB2數據庫/DS8000高端存儲等產品,這種IT架構被業界稱為“IOE”架構,其特點是基於向上擴展(Scale Up)技術的高端設備以及圍繞它們開發的專有硬件、大型商業數據庫和中間件組合。

有人說,DB2在金融證券保險行業有絕對不可替代的優勢!

的確,DB2擁有悠久的歷史並且被很多人認為是最早使用SQL的數據庫產品。主要應用於大型應用系統,具有較好的可伸縮性,可支持從大型機到單用戶環境,應用於所有常見的服務器操作系統平臺下。然而隨著時代的進步,開源產品和技術也已經被證明具備支撐企業核心業務的能力。


時代導向

在移動互聯網時代,各組織都在試圖構建面向互聯網+的安全可控的技術架構,在互聯網轉型升級壓力下,需要對IT系統重構、而數據架構是IT重構的基礎和核心。因此上述傳統的IOE架構正在逐漸演化為新一代以X86架構、開源應用平臺、數據平臺等為技術基礎的新一代技術架構。

MySQL數據庫作為互聯網行業IT架構的標配,在長期的實踐中積累了大量的高可用、分佈式架構和災備經驗。

因此,潮流的改變IT傳統架構的演變。越來越多的DB2數據庫客戶轉向開源數據庫,而 MySQL 作為當前最火的開源數據庫,也常常是受到老DB2用戶關注最多的。

政策驅動

將DB2遷移到MySQL並不是一件容易的事,更不可能受單一的時代潮流影響而一蹴而就,對於傳統企業來說是一個逐步試水嘗試的過程;數據是企業IT架構的核心資產,數據的任何丟失都是難以接受的。而受國家信息安全“自主可控”政策的號召,更加堅定了傳統企業作將DB2遷移到MySQL的嘗試。比如著名的銀監會39號文要求各銀行業金融機構對安全可控信息技術的應用以不低於15%的比例逐年增加,直至2019年達到不低於75%的總體佔比。

成本驅動

為了穩定運行,很多客戶的 DB2 數據庫都是運行在全套 IBM 平臺中,成本高昂;那麼將DB2遷移到以X86架構為主的MySQL數據庫當中,數據庫運行的底層基礎架構的要求大大降低,每年需要給原廠商的商業 License 費用也會隨之減少。

隨著大數據和雲時代的到來,企業的新業務和應用變更非常快,此時,以低成本的方式進行系統擴展和維護便是首要考慮的問題。

自主可控

由於互聯網行業的薪資和職業前景吸引了大量技術人才湧入互聯網公司從事開發運維等工作,使得原廠技術支持團隊人才流失嚴重,而且服務體制僵化,服務響應流程慢等弊端,導致了服務質量的下降,從而拉低了客戶滿意度。

將DB2數據庫遷移到MySQL,那麼可以很大程度降低對原廠服務的依賴性;轉而使用“最受歡迎的開源數據庫”——MySQL,首先一點是國內MySQL從業人員多,而且深入代碼研究的MySQL DBA也不少,第三方服務運維水平也比較高,是現在傳統企業擁抱互聯網時備受青睞的選擇。

社區生態

整個行業DB2技術從業人員相對較少,圈子也在不斷縮小,存在人才斷崖風險。一方面很多10多年前培養起來的經驗豐富的DB2 DBA,或者去了大型甲方單位像大型銀行、券商等IT建設投入相對比較大的企業,另一方面很多人才轉行到開源領域,或者轉行到大數據雲計算等行業,社區生態持續收縮。

因此,由於DB2數據庫技術人才儲備的嚴重不足以及業內人才梯隊斷層,導致很多企業招人難,特別是很多中小型企業,社區和產品是相互促進、相互推動,人才必然影響到產品的應用。

推薦使用MySQL的原因


從商用到開源:DB2遷移至MySQL的最佳實踐

全球數據庫熱度排名中,MySQL穩居第二名直逼第一名。參考鏈接:https://db-engines.com/en/ranking

要注意的事項


當然,在考慮將DB2遷移到MySQL之前,也應該充分認識到MySQL在功能上的一些缺陷。

比如在多表查詢方面,MySQL只支持NL JOIN,不支持表的全外連接,也不支持HS JOIN和MG JOIN;MySQL的存儲過程和觸發器的功能比較弱,甚至不建議在MySQL數據庫中對存儲過程的使用等。

總之,從功能上,MySQL適合拿來存放數據、不適合做運算場景,實際中大部分互聯網公司也只是把它當做數據存儲器來使用,把需要的數據取出來然後在應用程序中進行運算,這一點和DB2/Oracle那種商業數據庫儘量什麼都放到數據庫裡面的使用風格很不一樣。

因此,將DB2遷移到MySQL的話,需要認清MySQL適用於OLTP場景,不建議在OLAP場景中運用;而且必須考慮將原先放在DB2中的某些業務邏輯在遷移到MySQL後,從數據庫中剝離出來放到應用中去實現;需要加強對應用架構的管控。

如何實現DB2遷移至MySQL的最佳實踐


基於上述的遷移驅動力,你是不是也決定要把你的DB2系統遷移至MySQL了呢?那麼如何才能規避遷移中的系列問題呢?這需要我們完全把握兩個數據庫的特點,各自的優勢和不足,在遷移中做合理規劃設計。

為此,本系列接下來會包含(但不限於)以下內容,帶領大家全面認識DB2遷移至MySQL的實踐。

遷移準備

1、DB2與MySQL數據庫對比分析。包含:數據庫架構對比,數據類型對比,數據庫對象對比,SQL對比等。

2、測試。包含DB2與MySQL兼容性測試,MySQL性能測試,MySQL基於OLPT的測試等等。

遷移過程

1、應用設計與改造。

2、MySQL高可用設計與部署

3、MySQL備份與恢復設計

4、遷移中的重點問題和注意事項

遷移優化

1、性能測試

2、系統優化


一場從DB2遷移至MySQL的數據庫風暴即將襲來,你準備好了嗎?

MySQL vs DB2 Part 1: 體系架構

我們來對比一下DB2與MySQL體系架構有什麼不同。

MySQL體系架構

從商用到開源:DB2遷移至MySQL的最佳實踐

首先我們對圖中的組件進行說明。

由連接池組件、管理服務和⼯工具組件、SQL接口組件、查詢分析器組件、優化器組件、緩衝組件、插件式存儲引擎、物理⽂文件組成。MySQL是獨有的插件式體系結構,各個存儲引擎有自己的特點。

1、Connectors:指的是不同語言中與SQL的交互

2、ManagementServeices & Utilities: 系統管理和控制工具

3、Connection Pool:連接池:管理緩衝用戶連接,線程處理等需要緩存的需求

4、SQL Interface:SQL接口:接受用戶的SQL命令,並且返回用戶需要查詢的結果。比如select from就是調用SQL Interface

5、Parser: 解析器:SQL命令傳遞到解析器的時候會被解析器驗證和解析。解析器是由Lex和YACC實現的,是一個很長的腳本。



a . 將SQL語句分解成數據結構,並將這個結構傳遞到後續步驟,以後SQL語句的傳遞和處理就是基於這個結構的

b. 如果在分解構成中遇到錯誤,那麼就說明這個sql語句是不合理的。

6、Optimizer: 查詢優化器:SQL語句在查詢之前會使用查詢優化器對查詢進行優化。他使用的是“選取-投影-聯接”策略進行查詢。

舉例: selectuid,name from user where gender = 1;

這個select 查詢先根據where 語句進行選取,而不是先將表全部查詢出來以後再進行gender過濾,這個select查詢先根據uid和name進行屬性投影,而不是將屬性全部取出以後再進行過濾將這兩個查詢條件聯接起來生成最終查詢結果

7、Cache和Buffer: 查詢緩存。

如果查詢緩存有命中的查詢結果,查詢語句就可以直接去查詢緩存中取數據。

這個緩存機制是由一系列小緩存組成的。比如表緩存,記錄緩存,key緩存,權限緩存等

8、Engine :存儲引擎。存儲引擎是MySql中具體的與文件打交道的子系統。也是Mysql最具有特色的一個地方。

MySQL不是通過多進程來完成其功能的,MySQL只有一個進程,進程裡有多個線程。

MySQL的體系架構可劃分為以下三個邏輯層:

(1)應用層(ApplicationLayer)

從商用到開源:DB2遷移至MySQL的最佳實踐

主要是連接到MySQL服務器檢索、修改或增加數據,有以下常見MySQL管理工具或實用程序。

從商用到開源:DB2遷移至MySQL的最佳實踐

MySQL查詢接口主要指mysql腳本,使用mysql工具可以直接與MySQL服務器交互,是日常與MySQL服務器打交道最頻繁的工具。

客戶端應用接口主要是使用MySQL服務器對外公佈的一些API調用訪問數據庫,主要有CAPI、PythonAPI以及JavaAPI。

(2)邏輯層(LogicalLayer)

從商用到開源:DB2遷移至MySQL的最佳實踐

MySQL邏輯層主要是包括以下幾個功能:

SQL引擎編譯SQL語句

將客戶端發送的SQL語句請求通過SQL引擎將SQL語句編譯成MySQL服務器內部存取數據的指令的過程,編譯過程包括查詢解析(QueryParser)、查詢檢查(Query check),查詢優化(QueryOptimizer)以及查詢執行(Query Excution)四個階段。

事務控制

事務(Transaction)是由一組SQL語句組成的邏輯處理單元,這個邏輯處理單元被原子性地處理,即要麼其中的所有SQL語句全部執行成功,要麼全部失敗,沒有第三種可能。那麼MySQL是怎麼保證事務被原子性地處理呢?這就是Transactionmanagement組件的功能了。當事務全部處理完畢時,通過該組件完成決定commit還是rollback操作。

日誌管理

數據庫需要將所有對數據變更的操作記錄下來,以便當數據庫發生crash時做Redo或Undo操作,或者在分佈式結構中將操作通過從一個計算節點共享到其他計算節點,這些功能都是通過事務日誌來控制的。

MySQL的事務日誌管理系統是Recoverymanagement組件,主要功能是持久化事務日誌以及當數據庫crash時將數據庫恢復到crash之前的一致性狀態。

存儲管理

數據庫中操作數據的主要場所是bufferpools,怎麼控制數據頁和索引頁在bufferpool中的狀態就是通過storagemanagement完成的,該組件主要還是對Page層面的管理,包括將頁讀入內存、頁的清理等。

值得一提的是,MySQL的邏輯層的上述幾個組件功能並不是MySQL特有的,而是普遍適用於DB2/Oracle等常見關係型數據庫。

(3)物理層

數據庫的物理層主要關注的是數據怎麼落地存儲以及被有效訪問的問題,MySQL的物理層設計比較特殊,MySQL提供了多種存儲引擎供用戶選擇,而且這些存儲引擎是可插拔的(Pluggable),這是區別於業內其他關係型數據庫的一個很重要的特徵。MySQL數據庫為用戶提供了20多種可插拔的存儲引擎,比較常見的有如下列表所示幾種:

從商用到開源:DB2遷移至MySQL的最佳實踐

如上圖的存儲引擎中,從功能上比較接近商業數據庫功能的是InnoDB存儲引擎。從MySQL5.5開始,InnoDB成為MySQL服務器的默認存儲引擎;而早在SunMicroSystem被Oracle收購之前的2005年,InnoDB存儲引擎就被Oracle收購。

相比較於其他MySQL存儲引擎,MySQLInnoDB存儲引擎支持以下關鍵特性:

以下以InnoDB內部是怎麼和磁盤文件交互的詳細架構示意圖。

從商用到開源:DB2遷移至MySQL的最佳實踐

如下圖是支持訪問MySQL數據庫服務器的API接口類型,可以通過編寫程序調用四種API接口訪問MySQL數據庫:

通過Java程序訪問MySQL服務器

使用.NET程序訪問MySQL服務器

使用基於C語言庫的編程語言,比如C/C++語言、Python/PHP/Perl/Ruby語言等訪問MySQL數據庫。總之,MYSQL支持通過當前最流行的幾種主流語言訪問。

DB2體系架構

從商用到開源:DB2遷移至MySQL的最佳實踐

DB2 for LUW進程模型在DB2v9.5之前都是多進程模型,DB2v9.5之後體系架構變更為單進程多線程模型。

DB2是一個C/S結構,客戶端可以通過TCP/IP或IPC協議與服務器通信,每當客戶端與服務器建立連接之後,會在服務器端產生一個代理線程(db2agent)負責處理來自客戶端的所有請求,但是當某一時刻併發請求很多或者連接斷開時,重複地產生與銷燬代理線程會產生很大的系統開銷,所以DB2服務器在啟動時創建一個常連接池來避免重複地創建/銷燬代理線程,但是如果某一個處理的請求非常大時,如果單個線程去處理效率比較低下,為了提高單個請求的處理能力,與客戶端通信的那個代理線程(db2agent)可以從線程池中額外召集幾個線程(db2agentp)來共同處理某個請求。

DB2的線程主要分為以下幾大類:

DB2對數據的操縱主要在bufferpool中進行,當插入某些數據或對某些數據做了變更後形成髒頁(dirtypage)後,需要使用線程db2pclnr根據一定的機制定期清理bufferpool中的髒頁,一方面持久化數據,另一方面給bufferpool騰出更多可置換空間供使用。

日誌頁讀寫進程db2loggr/db2loggw:DB2採用的是讀日誌優先(Read logahead)的策略來持久化數據,即在將insert/delete/update的數據寫入磁盤前,必須先將對這些操作的日誌從日誌緩衝區持久化到磁盤當中,這個操作由db2loggw線程完成。

當需要使用持久化到磁盤的日誌恢復或撤銷某些操作時,需要從磁盤中將對應的日誌讀入到日誌緩衝區中,此時有db2loggr線程完成。

全局死鎖檢測線程db2dlock:該線程主要是檢測系統死鎖防止因為死鎖造成的應用不可用。

以下為部分常見DB2管理工具和實例:

從商用到開源:DB2遷移至MySQL的最佳實踐

該線程主要是檢測系統死鎖防止因為死鎖造成的應用不可用。

以下為部分常見DB2管理工具和實例:

DB2實例命令

從商用到開源:DB2遷移至MySQL的最佳實踐

原文發佈時間為:2017-11-27

本文作者:enmotech

本文來自雲棲社區合作伙伴“數據和雲”,瞭解相關信息可以關注“

數據和雲

”微信公眾號

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至:[email protected] 進行舉報,並提供相關證據,一經查實,本社區將立刻刪除涉嫌侵權內容。

原文鏈接

相關文章

如何快速部署Node.js項目

阿里雲容器服務新增支持Kubernetes編排系統,性能重大提升

【Linux】Linux服務器搭建JDK環境

【Linux】Linux下修改主機名簡單三步搞定