建站
咨詢
售后
建站咨詢
新聞中心
節(jié)前寫過一篇關于分布式數(shù)據(jù)庫的文章，當時有幾個朋友和我討論集中式數(shù)據(jù)庫和分布式數(shù)據(jù)庫如何選擇的問題。實際上，數(shù)據(jù)庫產(chǎn)品都不是萬能的，對于不同的應用場景，不同的用戶群體，其對數(shù)據(jù)庫的選擇有所不同。對于一些用戶或者一些應用場景來說，可能選擇分布式數(shù)據(jù)庫是必然的選擇，另外一些用戶或者應用場景，選擇集中式數(shù)據(jù)庫更簡單一些。
創(chuàng)新互聯(lián)科技有限公司專業(yè)互聯(lián)網(wǎng)基礎服務商，為您提供中國電信成都樞紐中心，高防主機，成都IDC機房托管，成都主機托管等互聯(lián)網(wǎng)服務。
總體來說，集中式數(shù)據(jù)庫因為相對簡單，因此可能適用的場景更廣泛一些，特別是對于中小型非關鍵性系統(tǒng)或者沒有能力運行于維護大型分布式數(shù)據(jù)庫系統(tǒng)的用戶來說，選擇集中式數(shù)據(jù)庫可能更符合企業(yè)的需求。
實際上使用集中式數(shù)據(jù)庫的客戶也需要很多分布式數(shù)據(jù)庫具有的特性，比如高可用、多副本、故障自動隔離、橫向擴展等。
很多用戶都怕集中式數(shù)據(jù)庫的單機總體容量可能受限，實際上對于絕大多數(shù)系統(tǒng)來說，單機容量達到極限還是很困難的。無論是內(nèi)存，CPU，IO，網(wǎng)絡、存儲容量，現(xiàn)在的上限都相當高，對于一般的系統(tǒng)來說還是比較難達到極限的。
雖然如此，集中式數(shù)據(jù)庫支持某種意義上的橫向擴展還是很有必要的。比如ORACLE 的RAC，雖然不能像分布式數(shù)據(jù)庫一樣橫向擴展到幾十上百個節(jié)點，RAC的橫向擴展能力還是會讓人感到比較放心。對于國產(chǎn)集中式關系型數(shù)據(jù)庫來說，強一致性讀寫分離是很好的橫向擴展方式，其實現(xiàn)方式?jīng)]有Oracle RAC那么難，又能夠解決大量的讀操作消耗過多系統(tǒng)資源的問題。通過一個較好的方案實現(xiàn)強一致性讀寫分離，是國產(chǎn)集中式數(shù)據(jù)庫在同質(zhì)化競爭中脫穎而出的一個途徑。
可能有些朋友會說了，現(xiàn)在的國產(chǎn)數(shù)據(jù)庫，開源數(shù)據(jù)庫，基本上都有類似的功能，這個有什么難的。實際上目前開源、國產(chǎn)數(shù)據(jù)庫的集群計算都是外掛的，不是從數(shù)據(jù)庫的底層設計開始的，僅僅是集群計算框架與原有RDBMS內(nèi)核的整合。
要想把這個問題說清楚，首先我們需要分析一下客戶為什么需要找個功能。有些時候客戶需要強一致性的讀寫分離并不是為了橫向擴展，而是用一種最簡單的方式實現(xiàn)應用系統(tǒng)的高可用。
數(shù)據(jù)庫的無數(shù)據(jù)丟失強一致性同步一直是保證數(shù)據(jù)庫高可用的一種客戶的強需求，雖然大部分用戶可以接受部分的數(shù)據(jù)丟失，只要當主系統(tǒng)故障的時候，能夠快速恢復業(yè)務就可以達到他們的最基本的要求。不過正是因為故障切換是有損的，所以在真正做切換的時候還是會有些猶豫。因為每次切換后，都有一些臟數(shù)據(jù)要處理，對于運維部門，業(yè)務部門，開發(fā)商來說，都是留下了一些尾巴。如果切換后能夠?qū)崿F(xiàn)0數(shù)據(jù)丟失，不需要做收尾的工作，那么當主系統(tǒng)故障時，就會十分堅決的進行故障切換了。
強一致性同步的另外一個好處是，我們的MIS類的系統(tǒng)中，讀寫比例高達8:2甚至9:1，在應用的角度上講，把一些讀操作都轉(zhuǎn)移到只讀副本上去，可以大大減少主實例的負擔，也可以減少主實例故障的幾率。如果主備實例的數(shù)據(jù)不是隨時都是完全一致的，那么我們的應用需要做相應的修改，確保某些只讀操作是可以在只讀副本上運行，有些只讀操作需要強一致性，必須在主實例上運行。不過如果主從數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)隨時都能確保強一致，那么在一個集群環(huán)境中寫應用的難度就大大降低了。
除了強一致性的讀寫分離，客戶的另外一個重要需求就是透明應用故障切換，這個詞Oracle簡稱TAF，屬于RAC故障切換的一種早期方式，雖然十多年前這種切換方式就已經(jīng)被更為強大的快速連接故障切換（FCF）所替代，不過目前國內(nèi)的大多數(shù)應用軟件還在使用TAF。TAF的好處是當數(shù)據(jù)庫實例故障時，應用可以自動切換。
Oracle 12.1后支持的GDS服務就可以在一個集群計算環(huán)境中支持讀寫分離、負載均衡與故障切換，我們的國產(chǎn)數(shù)據(jù)庫廠商可以認真學習一下其功能與實現(xiàn)方式。
Oracle GDS可以構建一個統(tǒng)一而又復雜強大的統(tǒng)一計算環(huán)境，讓RAC\ADG\OGG等復制技術與計算框架有效地整合成一個整體。
我們需要數(shù)據(jù)庫集群計算環(huán)境的強一致性，強一致性讀寫分離的實現(xiàn)方式主要有以下幾種：
- 第一種模式：多實例共享存儲+緩沖區(qū)融合的讀寫分離：多個讀寫分離的數(shù)據(jù)庫實例共用一套存儲數(shù)據(jù)，只有主實例支持讀寫，其他實例均為只讀。對于未寫盤的臟塊，直接從主實例的緩沖區(qū)中獲得。這種實現(xiàn)方式比ORACLE RAC的多主模式實現(xiàn)起來要簡單一些；
- 第二種模式：多實例共享存儲+WAL APPLY：和第一種模式類似，采用一主多從模式，主實例可讀寫，其他實例只讀。不同的是，多實例之間是完全獨立的，不通過緩沖區(qū)融合來保證讀寫一致性，而是通過在備用實例上重演WAL數(shù)據(jù)來確保讀寫一致性。這種模式比第一種模式的優(yōu)點是主從實例之間完全是獨立的，互相的影響不大，只要底層存儲支撐得住，從節(jié)點的數(shù)量多一點也問題不大。缺點是如果主實例存在大量的寫操作，那么從實例的重演可能會產(chǎn)生一定的延時。Polardb-PG就是采用這種模式的一個例子；
- 第三種模式是多實例存儲復制+WAL APPLY：為了防止底層存儲的IO性能達到極限，從底層實現(xiàn)存儲的同步/半同步自動復制，確保多個存儲副本之間的數(shù)據(jù)一致性。不同的實例可以使用獨立的副本，或者某幾個有限的實例共享一個獨立的副本。其他的實現(xiàn)方式和第二種模式類似，這是第二種模式的變種方案。亞馬遜的AURORA DB CLUSTER就是這種模式的典型案例；
- 第四種模式是多實例非共享存儲0數(shù)據(jù)丟失復制：主從實例是完全獨立的數(shù)據(jù)庫，在存儲底層確保WAL數(shù)據(jù)自動實現(xiàn)無損復制，確保已經(jīng)提交的事務的WAL文件能夠復制到從庫。從庫通過日志重演確保與主庫的同步或者半同步。
實際上，以目前的數(shù)據(jù)庫與分布式數(shù)據(jù)庫技術，實現(xiàn)上述的四種模式，在技術上并沒有不可逾越的難關，最關鍵的是需要從數(shù)據(jù)庫SQL引擎、存儲引擎、緩沖區(qū)管理、DB WRITER、WAL WRITER等核心組件上到操作系統(tǒng)、存儲系統(tǒng)、網(wǎng)絡實現(xiàn)全棧貫通的設計和優(yōu)化，使之成為一體化的數(shù)據(jù)庫設計，而不是把一堆組件做簡單的集成。這種一體化的設計與實現(xiàn)，才能夠從整體上實現(xiàn)最優(yōu)處理，自動處置各種異常，并自動進行相關的容錯處理，從而確保數(shù)據(jù)庫提供的強一致性讀寫、故障切換、故障數(shù)據(jù)修復等都是能夠根據(jù)數(shù)據(jù)庫底層模塊自動完成的，而不是需要運維人員或者應用開發(fā)商去做相關的處理的。甚至今后在SQL執(zhí)行算子方面實現(xiàn)下推，實現(xiàn)某些計算場景跨數(shù)據(jù)庫實例的并行計算。
這種計算框架可以解決一些當前集中式數(shù)據(jù)庫中比較麻煩的問題。比如大型數(shù)據(jù)庫表分析時產(chǎn)生的大量IO導致的系統(tǒng)性能問題。在這種計算框架下，可以按照下面的方式實現(xiàn)集群計算。
當表分析任務發(fā)起后，主庫分解分布式計算的任務，通過消息隊列分發(fā)任務給各多個從庫，由從庫完成實際的計算任務，再把結(jié)果發(fā)送給主庫，由主庫統(tǒng)一入庫。再通過復制技術分發(fā)到各個從庫。
如果是十多年前，當硬件處理能力、分布式復制技術等還沒有發(fā)展到今天的時候，集中式數(shù)據(jù)庫的設計可能不會向這個方向去考慮，不過隨著這些年軟硬件與分布式計算框架的高速發(fā)展，我們的集中式數(shù)據(jù)庫的架構設計是不是也可以脫離開已經(jīng)使用了幾十年的老方案，嘗試一些適合現(xiàn)代軟硬件技術的新的方案呢？
實際上Oracle GDS也不是原生態(tài)的集群計算框架，是集成了ADG、OGG、ONS、FAN、ADG FAR SYNC等技術基礎上逐步發(fā)展起來的集成計算框架。不過從GDS我們也可以看出，集中式數(shù)據(jù)庫完全可以從單打獨斗模式過渡到了集群計算的新模式了。
實際上，集群計算模式在開源社區(qū)的發(fā)展也很迅速，MYSQL MGR就是一種典型的集群計算架構。只是目前的大多數(shù)集群計算架構大多數(shù)是以數(shù)據(jù)庫與服務組件集成的方式組建的，并不是基于數(shù)據(jù)庫原生態(tài)設計的，沒有形成硬件、操作系統(tǒng)、數(shù)據(jù)庫內(nèi)核、服務網(wǎng)關的一體化設計，因此在應用上還需要大量的工程化的實施工作，運行時也還需要對整個集群進行監(jiān)控和調(diào)整，無法像一個數(shù)據(jù)庫一樣一體化部署和一體化運行。
實際上我們完全可以從數(shù)據(jù)庫底層開始一體化設計一個支持集群計算框架的集中式數(shù)據(jù)庫系統(tǒng)，將現(xiàn)有集群計算的工程化工作變得十分簡化，這種基于集群計算架構的集中式數(shù)據(jù)庫在技術實現(xiàn)上會比分布式數(shù)據(jù)庫簡單不少，而其使用效果肯定也是相當不錯的。
分享題目：一篇了解集中式數(shù)據(jù)庫的集群計算
網(wǎng)址分享：http://www.5511xx.com/article/dphjppc.html
