建站
咨詢
售后
建站咨詢
新聞中心
?熙熙攘攘的春節(jié)假期完完全全的結(jié)束了，因為兒子今年高考，所以春節(jié)只是窩在深圳。春節(jié)期間應兒子的要求去看了一場電影-《流浪地球》，電視也沒啥可看的，只有一個更新速度像便秘的《三體》還值得一看。兩部片子看著看著就看岔了情節(jié)了，地球人駕駛著地球，跨越2500年時空去三體人的老家蹭太陽，而宇宙的那一端，三體人跨過茫茫宇宙要來搶劫地球，不知道那撥人出現(xiàn)了技術(shù)誤判。
創(chuàng)新互聯(lián)公司是專業(yè)的昌江黎族網(wǎng)站建設公司，昌江黎族接單;提供成都網(wǎng)站建設、網(wǎng)站建設,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行昌江黎族網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
我每天寫點東西，都是最近在思考的東西，春節(jié)假期放空自己，思考的問題不多，可寫的題材也不多。正好春節(jié)假期的最后幾天在編寫一篇調(diào)研報告的提綱，還算思考了一些技術(shù)問題，實際上在春節(jié)前我也寫過這方面的題材，那就是國產(chǎn)商用數(shù)據(jù)庫上云的問題，今天就從另外一個角度聊聊這個話題吧。
數(shù)據(jù)庫上云的方式一般數(shù)據(jù)庫服務器云納管、云主機部署、RDS服務、容器云這四種方式。云納管僅僅是一種最低程度的云管，實際上數(shù)據(jù)庫和云還是完全分離的。今天我們先來看看其他三種方式。
云主機部署數(shù)據(jù)庫是最早出現(xiàn)的數(shù)據(jù)庫上云的方式，利用云平臺的ECS與云主機模板，以及云平臺的資源編排能力，可以實現(xiàn)數(shù)據(jù)庫在云上的快速部署與快速變更。數(shù)據(jù)庫的部署可以做成云主機模板，以小時級的速度交付使用。這對于以往以周為單位的交付效率來說，已經(jīng)是革命性提高了。不過這種部署模式存在很多問題，首先是交付與運維還是脫離的，數(shù)據(jù)庫運維的模式還是傳統(tǒng)的模式，自動化程度不高；其次是部署在云主機上的數(shù)據(jù)庫性能還是有些問題的，大型數(shù)據(jù)庫往往還需要外接集中式存儲來解決IO性能的問題；第三是稍微關鍵一些的數(shù)據(jù)庫往往會受到云資源超配的干擾，需要通過獨立的安置組來做資源隔離，避免其他云組件對數(shù)據(jù)庫的性能影響；最后一點是交付效率還存在提升的需求。
RDS是數(shù)據(jù)庫上云目前最主要的方式之一，也是針對云主機部署的一種改良。RDS一般以裸金屬的方式部署，在一臺服務器上部署多個數(shù)據(jù)庫實例，通過資源管理的模式來限制其資源使用。RDS部署的數(shù)據(jù)庫以服務器的本地盤為存儲介質(zhì)，可以使用SATA HDD、SAS HDD、SATA SSD、NVME SSD等多種形式的存儲介質(zhì)，有些云廠商還提供高性能云存儲作為存儲介質(zhì)。這種采用裸金屬部署的模式，數(shù)據(jù)庫在性能方面損耗較少，因此在同樣的數(shù)據(jù)庫上，RDS的性能往往優(yōu)于云主機部署的數(shù)據(jù)庫。不過受限于單機容量，RDS的規(guī)模是受到PC服務器的物理限制的，CPU，內(nèi)存，存儲容量的擴展都存在一定的限制，CPU、內(nèi)存的限制在其他模式的部署中也是如此，不過數(shù)據(jù)庫的容量受限是個比較麻煩的事情。不過裸金屬云也有一些突破容量限制的解決方案，比如通過INTEL的RSD可以動態(tài)分配磁盤等資源給某臺服務器，實現(xiàn)分鐘級的資源調(diào)度，阿里的神龍就是一個類似的裸金屬云解決方案。RDS除了存儲容量的限制外，資源隔離方面也不是完美的，多個數(shù)據(jù)庫服務使用同一個OS，相互之間還是會有一定的干擾，因此有時候會出現(xiàn)一些莫名其妙的性能問題。
RDS數(shù)據(jù)庫的高可用、備份等可以使用數(shù)據(jù)庫原生的模式，比如通過MHA、MGR等構(gòu)建主從環(huán)境，或者利用云平臺的底層存儲快照、副本復制等技術(shù)來實現(xiàn)數(shù)據(jù)庫復制，也可以通過云平臺底層的CDP/CDM技術(shù)實現(xiàn)可持續(xù)的數(shù)據(jù)保護，不過這些方式的實現(xiàn)成本都比較高，大多數(shù)用戶還是通過傳統(tǒng)的數(shù)據(jù)庫主從復制來獲得高可用能力。
第四種上云模式是近些年比較流行的容器云，在容器中跑數(shù)據(jù)庫目前已經(jīng)挺普遍了，一些企業(yè)已經(jīng)構(gòu)建起了DEVOPS的工具鏈，不僅僅可以快速交付數(shù)據(jù)庫，還可以快速交付整個應用。數(shù)據(jù)庫的容器云一般來說部署的數(shù)據(jù)庫規(guī)模都較小，支撐一個不太復雜的業(yè)務。如果一個企業(yè)有數(shù)百個規(guī)模類似，業(yè)務負載也差不多的數(shù)據(jù)庫，或者一些大型業(yè)務可以拆分為數(shù)十個這樣類似的數(shù)據(jù)庫，那么容器云可以節(jié)約大量的部署、運維的成本。
大家要注意的是，里面我提到了一個“規(guī)模類似”，為什么要提這個詞呢，因為如果多個數(shù)據(jù)庫可以使用相同的容器鏡像來部署，那么容器云的成本是最低的，如果庫都要構(gòu)建數(shù)十個獨立的鏡像，那么其成本就不低了。另外一個要注意的問題是要有高水平的operator來支撐容器云，如果一個應用拆分為數(shù)十個數(shù)據(jù)庫，每個數(shù)據(jù)庫都還需要DBA來做精細的運維，那么還不如把這幾十個數(shù)據(jù)庫合并為一個大型數(shù)據(jù)庫，每個小庫作為這個數(shù)據(jù)庫的一個庫或者一個SCHEMA。容器云的大量小型數(shù)據(jù)庫應該是90%以上甚至99%以上的運維是通過過operator自動化運維的，這樣才能真正的節(jié)約運維成本。我以前幫助用戶優(yōu)化過容器中的數(shù)據(jù)庫，因為他們的鏡像是從網(wǎng)上下載的，根本沒有根據(jù)他們的應用的要求重新構(gòu)建，因此當數(shù)據(jù)庫出問題的時候，很多指標都采集不到，分析問題十分不便，這樣的容器中運行的大型數(shù)據(jù)庫，一旦出現(xiàn)一些問題，那么定位起來就好似大海撈針一樣。
今天時間關系，就先寫了這個問題的上半部分吧，今天實際上只是討論了數(shù)據(jù)庫上云的幾種方式。關于商用數(shù)據(jù)庫上云的方式以及存在的問題的討論本來是本文要討論的重點，我們放在明天的下集里在討論吧。最后給廣大讀者拜個晚年。?
網(wǎng)站標題：商用數(shù)據(jù)庫上云的方式與存在的問題
地址分享：http://www.5511xx.com/article/djgppdj.html
