從上世紀80年代到今天,達夢資料庫技術架構演進與應用全記錄
導語: 本文根據黃海明老師在2018年5月10日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。
達夢技術總監黃海明
資深資料庫專家,ITPUB論壇版主,具有13年以上資料庫研發、測試、推廣經驗。帶領團隊將達夢資料庫在國家電網、中國神華、中國鐵建、中國民航、社保等重大行業的核心生產系統中的取得廣泛應用。目前致力於達夢資料庫核心技術研究及達夢資料庫的推廣工作。
摘要: 傳統關聯式資料庫經過幾十年的發展,架構是否已經到了演進盡頭?MPP、讀寫分離、共享儲存、分庫分表……琳琅滿目的架構從何處來向何處去?未來關聯式資料庫架構可能會如何發展?本主題以達夢資料庫架構演進與創新為例,向大家分享我們的看法。
達夢資料庫架構演進
達夢資料庫從上世紀80年代開始一直走自研的道路,既非基於開源,也並非源自第三方授權。
像Oracle資料庫一樣,達夢資料庫開局也是一個單機資料庫,這個單機資料庫是1988年馮玉才教授研究出來的我國第一代有自主智慧財產權的資料庫管理系統。隨著達夢資料庫在一些重要行業的廣泛應用,為了解決高可用性的需求,達夢推出了主備架構。隨著“稜鏡門”事件的發展,國家對資訊保安的重視程度進一步提升,國家希望能夠推行晶片級的國產化,為了在晶片級國產化的場景裡面真正應用起來,達夢推出了讀寫分離架構。2012年後大資料蓬勃發展,面對大資料分析的需求,達夢推出了大規模平行計算的架構。
達夢推出這麼多的架構,都是基於匠人之心在做。比如主備架構,我們的備機設計之初就可以做只讀的,Oracle 11G才支援只讀,Oracle 10G的時候備機只能以mount狀態啟動,不能用於做查詢。另外,系統在做讀寫分離的時候,很多報表程式想在備機上執行,這個報表程式大部分是隻讀的,但是很多的報表程式需要用臨時表存一下中間資料,臨時表上一些增刪改的操作無法在備機上完成。在碰到這個需求之後,達夢對備機做了創新,就是達夢的備機可以支援對臨時表的增刪改,這樣報表業務就可以執行在備機上面。我們的備機可以支援實時的備機和非同步備機,實時的備機主要做故障切換用的,如果報表程式要單獨使用一個備機的話,我們可以在實時備機的基礎上在加一個非同步備機。
實際上,在X86的伺服器上達夢單機的處理能力已經很強悍了,我們一般一個一主一備的主備架構就足以應對很多核心的生產系統。到了晶片級的國產化環節就需要讀寫分離的架構,因為它的單機處理能力要稍微的弱一些。我們的讀寫分離和傳統的開源的讀寫分離架構是不太一樣的,我們的讀寫分離不需要應用也不需要中介軟體去做分發,它是在我們的驅動程式和伺服器端做的分發,這樣對於應用是透明的。另外,我們的讀寫分離可以同時兼顧效能和可靠性的問題,主備機之間可以做負載均衡,當主機出現故障的時候,它可以選擇一臺備機切換成主機對外響應業務。
在做大規模並行叢集(MPP)的時候,我們也做了很多的創新,我們的MPP叢集同時支援行儲存和列儲存。它不只是簡單的做一個行儲存引擎和列儲存引擎,它會做很多的融合。
作為一個企業級的資料庫,我們的MPP叢集支援單機所有的SQL特性,包括單機支援的一些介面。對於共享儲存的叢集,我們也實現了跟Oracle架構完全一樣的真正的資料共享叢集。
主備架構
我們之所以做主備叢集,主要源自於國家電網的國產化專案。
在2008年,國家電網在新一代智慧排程系統裡開始全面做國產化,這裡選用的資料庫就是達夢資料庫。國家電網新一代智慧排程系統可用性要求是99.99%,也就是說一年的停機時間不能超過兩個小時。我們以前的單機架構是無法滿足這種需求的,比如升級的時候,你沒有辦法做滾動升級,於是我們推出了主備架構,這個主備架構也是基於REDO日誌來做複製的,實現原理跟Oracle是完全一樣的。
在中國鐵建的財務共享平臺專案中,我們針對財務系統的特點做了一個讀寫分離的解決方案。大家都知道財務系統的SQL語句是非常複雜的,中國鐵建有十幾個局,以前每一個局都有一套財務系統,隨著國家對央企管理越來越嚴,鐵建要做一個財務共享服務平臺,把每個局的財務系統全部集中到一起,專門成立一個財務公司來統一管理。這樣就面臨著系統如何去實現國產化的問題,於是我們做了一個讀寫分離的架構,把日常的一些費用控制類的寫操作較多的業務,放在主機上面,然後把那些SQL比較複雜的核算類的業務放在備機上去執行,這樣便做了一些有效的讀寫分離。但是我們也遇到了一個問題,就比如每個月末和季度末要出報表了,由於備機不支援對臨時表的增刪改,報表程式只能放在主機上跑,這種情況下備機不是很忙,但主機很忙。這個時候我們就希望把報表程式放在備機上面,進一步提高備機的利用率。於是我們便做了一個創新,就是在備機上面支援對臨時表的插入、刪除和更新的操作,這樣我們的報表程式就可以非常方便的切換到我們的備機上面去執行,有效的提高了資源的利用率。
讀寫分離
達夢的主備架構在很多的央企和政府裡面獲得了廣泛的應用,當然大部分都是基於X86平臺。眾所周知,美國商務部對中興公司進行了封鎖,完全暴露出我國在國產晶片上的短板。但實際上我們的國產晶片目前的處理能力其實還是可以的,目前市面上可以買到的CPU主頻可以達到1.5G以上,核心數大概在16核以上,支援的記憶體容量可以到64~128GB,這是目前國產CPU的整體水平,當然這和X86平臺還是有一定差距的,因為它不只是晶片的問題,是一個生態問題,CPU也需要很多的外設和作業系統、資料庫之間的配合,所以它在單機處理能力以及整體可用性上就跟X86系統稍微有一些差距。為了實現全國產的目的,我們研發出一個讀寫分離的架構。
目前全國產的系統大多數的業務場景符合讀多寫少的特徵,這樣就可以把一些寫的操作放在主機上,讀的操作放在備機上。整個讀寫分離的過程對使用者來說是透明的,它透過我們的驅動程式和服務端自動做分發,也就是說單機的程式不需要做任何的修改,可以方便的移植到我們的讀寫分離系統上面來。比如說我們一主三備組成的叢集,這四臺機器任何三臺出現問題整個系統都是可用的,主機出現問題的話可以選用一臺備機切換到主機,這個切換可以是手動的也可以是自動的;備機出現問題可以自動將壞掉的備機剔除出叢集,主備之間始終保持著嚴格的一致性。
那麼我們是怎麼去做讀寫分離的呢?首先我們主備機之間的複製我們稱之為及時歸檔,就是說我們主機產生的REDO傳送給備機,備機應用了之後,主機才會提交,這樣可以保證主機和備機之間的強一致性。有了這個的保障之後就可以做事務級的讀寫分離。
第一個事務是讀和寫的混合事務,它的第一個SQL語句是一個查詢語句,我們的驅動會自動的把它分配到備機上去執行。第二條語句是一個插入語句,我們把它分配到主機上去執行,並且在整個過程中,它下面的操作都是在主機上執行的。第一個事務是一個純的查詢類的業務直接分配到備機上去執行。主機和備機承擔多少業務都是可以設定的。
上圖是我們做的一個測試,是在某國產CPU平臺環境下面做了一個對OA典型應用效能的測試。
系統的效能要求在500併發下所有操作的響應時間不超過5s,
透過測試我們可以看出在200Vuser上,單機效能就顯得非常勉強。於是我們做了一個一主五備的叢集,它可以滿足500併發的需求。
我們這個方案有效的支撐了國家安全可控事業的發展,目前,我們在10多個部委,30多個省市和10多個央企獲得了應用。
平行計算
在2008年的時候,我們做了一個分析型的專案,資料量大概在5TB左右,當時是一個單機的架構。過程中我們做了很多的最佳化:建索引、改寫SQL等,但是發現這些最佳化手段還是不能夠滿足效能的需求,因為它是一個即時查詢,它的每一個列都有可能成為一個過濾條件。所以在2011年的時候,我們推出了一個大規模並行叢集的架構,它的儲存和計算是在一起的,資料可以均衡的分佈在叢集的各個節點上,一條SQL過來的時候,每個節點同時運算,這樣在一些表連線不多的場景,隨著節點數的增多,效能可以得到一個線性的提升。
這種架構可以滿足100TB以內分析型的需求,但是如果是100TB以上,這種架構就會表現出很大的侷限性。因為它的儲存和計算是一起的,要想滿足需求我們就要將計算和儲存做分離。達夢公司的下一代產品DM8就是一種彈性計算的架構,也就是儲存和計算分離的架構。
我們將這種分析型的場景分了兩類,一類是MPP加列儲存,也就是統計分析型的業務。但是面對很多客戶應用,它不僅僅是一個純粹的統計分析型的業務,它還有很多的精確查詢或條件查詢。例如社保,它需要建一個分析型叢集,那麼它就需要根據一些人的資訊做一些精確查詢,這種精確查詢的併發量是非常大的,所以我們重點要解決的問題就是混合負載的問題,於是我們推出了行儲存和列儲存做融合的解決方案。
達夢在行列融合方面做了一些創新,首先就是在同一個MPP叢集裡面可以同時支援行儲存和列儲存。傳統的列存資料庫要把資料插入到列存的表裡,前端需要設定一套ETL來做資料的入庫,但是我們就不需要做這些,我們的行儲存可以直接的轉換成列儲存,簡單說就是一個查詢插入的操作。
其次,另一個創新是源自於什麼樣的場景呢?比如做大資料分析,首先資料必須從生產系統同步到分析系統,傳統的列存資料庫可能需要用ETL做一些批次抽取,但它會有延時,而很多客戶的應用場景又要求資料是實時的。並且從事務型的資料庫到分析型的資料庫裡面,列儲存還面臨一個問題,我們用一種類似Oracle OGG的工具去分析原庫的資料庫日誌,在把它同步到列儲存的目的庫,但是這個列存庫它不適合做高頻次的單條插入,只適合批次操作。怎麼去解決這個問題呢?實際上我們每一個列存表都有一個隱藏的δ表,這個δ表是一個行存表,主要是做輔助的,這樣對於單條的高頻次插入操作來說,我們會先插入到行存表裡面,然後到了一定的時機,它會把這些單條的操作變成一個批次的操作,然後寫入我們列存的庫裡,使用者去查詢的時候,我們的最佳化器會自動去查詢這個行存表和列存表,把它的結果做一個Merge後提供給使用者,這整個過程對使用者都是透明的。
有了這個行列融合的解決方案後,我們的MPP就不需要單獨建一個查詢庫、一個分析庫。對於高頻次插入併發量比較大的精確查詢業務,我們可以用行存表來支撐,對於大資料集上的一些統計分析業務我們可以用列存表來支撐。
這個MPP叢集在很多大資料分析的場景裡面獲得了應用,比如河北省的公安雲、吉林的公安雲、湖北的公安雲以及國家公商總局的企業資訊公示系統等。工商總局的系統就是一個典型的網際網路應用,每天查詢的次數都在幾千萬次以上,後臺都是用我們MPP叢集來支撐的。
資料共享
我們在做國產資料庫售前交流的時候,我被客戶問的最多的就是你們支援RAC嗎?這是一個無法迴避的問題,從現在來講RAC不是唯一的選擇,但是2018年我們回頭再去看這個問題,我們發現在做密集交易型的場景裡面這種共享儲存的叢集仍然是一個非常好的選擇。
Oracle的RAC叫真正應用叢集,以前對“真正”這兩個字沒有什麼體會,但是我們在做共享儲存叢集的時候就深刻的體會到了這兩個字。因為實現共享儲存叢集要克服很多難題。首先它必須要實現快取交換技術,這項技術Oracle叫快取融合,也就是把每個節點上的記憶體當成一塊公共的記憶體來使用。其次要實現一套自動儲存管理系統,每個節點都要做負載均衡,當節點出現故障的時候,要有整套故障處理的流程,包括故障恢復之後重加入的流程,整個過程對客戶要是友好的、透明的。另外,各個叢集、元件之間的狀態要實現同步管理,我們叫叢集同步管理軟體。而且 RAC是非常依賴於網路的,有很頻繁的記憶體交換的動作,所以我們還要構建一套高速的私有網路。
在解決了這些棘手問題之後還要做廣泛的相容性,我們不僅要在X86平臺上支援,還要在國產的飛騰、龍芯等平臺上支援。2016年,我們推出了共享儲存叢集,它可以滿足三種特性,一個是高可用性,實現了兩個節點的可讀可寫,當節點出現故障的時候,它可以自動處理,然後做重加入。另一個是高吞吐量,對於Oracle為什麼叫真正應用叢集,因為它的每個節點都是可讀可寫的,實際上很多其他的資料庫實現的所謂共享儲存叢集只有一個節點是可讀寫的,其他節點是隻讀的,並不是真正的共享儲存叢集。還有一個特點就是要實現負載均衡,我們的驅動程式會自動的把連線均勻的分配到每一個節點上來,從而實現負載均衡。
目前,我們共享儲存的叢集在公安行業和檢察行業獲得了廣泛的應用。
未來會是什麼?
達夢資料庫是一個通用型的商用資料庫,我們的方案要對使用者和合作夥伴負責。我們的使用者和合作夥伴很多用了一些比較傳統的技術,比如Pro*C、Hibernate等架構,我們都需要去一一兼顧。
所以對於未來的資料庫架構來說,要對傳統企業應用架構友好,最好能直接移植。這裡提煉了幾點,第一個是要能橫向擴充套件儲存,應對越來越大的資料規模;第二個是要靈活的運用資源,提升資源的利用率;第三個是要保證服務的可用性,能夠做故障的檢測和切換;第四個是要具備資料副本能力,保證資料可靠性;最後一個是我們非常看重的,就是希望這一套架構要同時的滿足事務型和分析型的業務。
彈性計算
達夢公司的下一代產品DM8裡提出了一種彈性計算的架構。
首先在網路裡面有一個註冊的伺服器,可以把這些MPP、單機、共享儲存、讀寫分離等叢集管理起來。然後選一個主資料庫,其他資料庫做輔助,當一個客戶請求過來的時候,主資料庫就會判斷目前的計算能力是否能夠滿足需求,如果滿足不了就會生成一個彈性計算的子計劃,然後從註冊伺服器裡面獲取我們可用的計算資源的列表,然後我們把彈性計算的子計劃和它的資料傳送給我們輔助計算的節點,多個輔助計算的節點同時運算把計算結果反饋給主節點,主節點再做一些整合的計算,生成最終的結果。
對於儲存層我們開發自己的分散式檔案系統,它分三層。最底下是儲存層,在這一層我們提出了容災域的概念。我們認為一個容災域裡所有的副本和儲存同時失效的可能性很大,所以我們容災域裡儲存層的副本是在另外一個容災域裡面,它的副本可以是多個的。另外我們還有一個目錄伺服器,主要做一些後設資料的管理。中間我們提供了一個分散式檔案訪問介面,供上層計算節點呼叫。
其他
除此之外,DM8還做了很多高階特性。在行列融合方面,我們做了行列的深度融合,DM8可能是沒有列存表的,我們需要的行存表會自動的維護一個影子的列存表,它的資料可以自動的同步,執行計劃可以根據場景自己選擇使用行存表還是列存表。目前的共享儲存的叢集只支援2個節點,但是我們DM8會支援到4節點或者8節點。
以後隨著CPU計算能力的增強以及IO能力的廣泛應用,網路會面臨一個瓶頸,所以我們會全面支援RDMA。另外,之前DM7有很多查詢最佳化的引數,很多的引數需要手動干預,但是DM8做了很多的智慧化,可以根據不同的使用場景使用不同的最佳化引數。
在運維管理方面,我們的業務規模越來越大,需要管理的資料庫也越來越多,所以我們會推出一個運維管理平臺來做集中管理。
技術以外的話題
借用歡樂喜劇人的一句話:搞國產資料庫,我們是認真的!
網上有幾個觀點,有的人認為資料庫有開源的資料庫可以用,有商業的資料庫可以用,為什麼要去做國產的資料庫?為什麼要重複的發明輪子?造不如買,買不如租!
目前,實踐證明這種觀點是站不住腳的。從美國商務部對中興的封鎖可以得出結論:我們的核心技術必須掌握在自己的手上。大家現在才認識到這個問題,但是我們達夢人在30年前就已經認識到這個問題了,從那時候我們就開始自主研發我們自己的資料庫。
目前,國產的氛圍很好,國產資料庫也算是遇到了一個風口,很多廠商也開始做資料庫,有開源的、有基於第三方商業授權的。從國家層面來說,到底什麼樣的資料庫是安全可控的,於是在2017年年底,國家組建了一個豪華陣容的專家團隊做了一個稽核。其中,稽核中有很重要的一項,用黑鴨子軟體對原始碼進行比對,這個黑鴨子軟體有2TB的開原始碼,在比對的時候,達夢99.9%以上的程式碼是自主研發的。
當然除了以上情懷和自研,還有什麼原因值得你選擇達夢資料庫呢?
總結一下,是有三個方面的需求。一方面是國家安全可控的需求,對於IOE去O很難的問題,達夢有更好的解決方法。達夢有和Oracle並行執行的逐步替代的科學方法來實現去O,達夢有一個資料同步的軟體可以把 Oracle的資料實時同步到達夢資料庫,然後達夢具備很強的Oracle相容性,同一套應用既可以執行在達夢上面也可以執行在Oracle上面,這樣就可以並行執行一段時間,建立信任後,把達夢切換成主機,Oracle切換成備機,再之後把Oracle去掉。透過這樣的方法我們去掉了很多央企的核心生產系統的Oracle資料庫。當然,僅僅在X86平臺上面做國產化替代是不夠的,在國產的CPU平臺上面也要能夠去替換國外的系統,達夢的讀寫分離的架構能夠有效的推動國產晶片的實用化程式。
另外,中興事件是一個警鐘,央企選擇達夢資料庫也是基於這個考慮的,他們的選擇基於兩點,一個是技術上必須可行,經濟上必須合理,這兩個要求達夢都可以滿足。達夢在技術上可以根據使用者需求不斷創新,在服務上,給使用者提供本地化的原廠服務,但是對於 Oracle來說,這種原廠服務費用很高。達夢還可以提供更進一步的原始碼級的服務,Oracle的服務層次只能到區域的服務中心,達夢的服務層次可以到達總部的研發中心。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31542119/viewspace-2199574/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 技術架構演進的思考架構
- 從資料庫到全棧資料解決方案,達夢不走捷徑資料庫全棧
- 從MVC到DDD的架構演進MVC架構
- 前端技術演進(四):前端三層結構與應用前端
- MySQL資料庫架構——高可用演進MySql資料庫架構
- 2017雙11技術揭祕—阿里巴巴資料庫技術架構演進阿里資料庫架構
- Apache SeaTunnel技術架構演進及其在AI領域的應用Apache架構AI
- 達夢資料庫基礎知識(三)達夢資料庫記憶體結構資料庫記憶體
- 餘額寶技術架構及演進架構
- 大型網站技術架構的演進網站架構
- 雲端計算-從基礎到應用架構系列-雲端計算的演進應用架構
- 配置ORACLE資料庫到達夢資料庫的異構DBLINKOracle資料庫
- 高德客戶端及引擎技術架構演進與思考客戶端架構
- 從 ClickHouse 到 Apache Doris,騰訊音樂內容庫資料平臺架構演進實踐Apache架構
- 【IT技術】阿里RDS首席產品架構師何雲飛:阿里雲資料庫的架構演進之路阿里架構資料庫
- 技術架構分享:美團配送系統架構演進實踐架構
- dubbo應用架構演進路線圖應用架構
- 服務架構學習與思考(12):從單體架構到微服務架構的演進歷程架構微服務
- 從SOL到NoSQL,資料庫還要向何處演進?SQL資料庫
- 資料治理:資料整合架構的演進架構
- DataX將Oracle資料庫資料同步到達夢資料庫Oracle資料庫
- 大型網站的技術架構演進過程網站架構
- 達夢資料庫初體驗-單機環境部署記錄資料庫
- 從“智慧湖倉”架構的技術演進,看現代化資料平臺的發展方向架構
- 百分點大資料技術團隊:輿情平臺架構實踐與演進大資料架構
- 達夢資料庫學習筆記資料庫筆記
- 雲原生時代,應用架構將如何演進?應用架構
- 達夢資料庫索引結構詳解資料庫索引
- 配置達夢資料庫同構DBLINK資料庫
- Ceph儲存後端ObjectStore架構和技術演進後端Object架構
- 彩虹橋架構演進之路-效能篇|得物技術架構
- 達夢資料庫DM8共享叢集測試記錄資料庫
- 技術進階:Kubernetes高階架構與應用狀態部署架構
- 日均處理萬億資料!Flink在快手的應用實踐與技術演進之路
- 架構師日記-從資料庫發展歷程到資料結構設計探析架構資料庫資料結構
- DTCC演講 | PolarDB-X技術架構:雲原生分散式資料庫架構分散式資料庫
- 餓了麼交易系統應用架構演進應用架構
- Tungsten Fabric架構和最新技術進展丨TF成立大會演講實錄架構