企業使用資料庫的12種姿勢
資料庫,作為IT系統的基礎類軟體,發揮著非常巨大的作用。那麼企業在使用資料庫時,有什麼樣的方式可以選擇?不同方式又各有其什麼特點呢?本文將從使用方式、適用場景、未來發展、成本因素(人力、財務、時間)及風險點等多角度分析十二種情況(前六種為本地方式,後六種為雲端方式)。
方式1:商業資料庫 + 商業服務
這是比較傳統的一種方式。企業購買大型商業資料庫軟體,並對應購買服務支援工作。在過去三、四十年裡,這是主流的一種使用方式。可以說也很好地滿足了各類企業的快速發展。只是隨著近二十年來,網際網路化的變革,對此種方式產生了不小的衝擊。
這種方式適合傳統企業,對資料庫要求較高,自有技術能力有限,未來發展相對固定的情況,未來發展隨著商業資料庫的發展而變化,從總體來看,未來雲化的需求對其衝擊較大。此外,在國產化、自主可控化等要求下,也會對這個模式影響較大。
成本因素
從人力成本角度來看,整體投入不大,主要是由廠商提供。自有人員主要是完成稽核、評估等工作。從財務成本分析,是幾個方案中,相對最高的一種。經常見到“某國有銀行,年度資料庫採購xxxx萬元的新聞”見諸報端。
正因為財力投入較大,這種方式也一般僅限於大中型企業或某些特殊行業要求。對時間成本而言,是相對較少的。選擇商業資料庫+服務,也就是看重其多年產品研發技術積累和成熟的商業交付能力。無論是產品成熟度、穩定性;還是服務支援方面等,一般都是可在較短時間內交付的。
風險分析
- 技術風險:技術封閉、不開放;不符合自主可控要求。
- 政治風險:如是外商產品,還易受到政治環境的影響。
- 財務風險:容易受到廠商綁架,經濟投入上不太可控。
- 人員風險:受廠商技術人員技術能力水平影響很大,自有人員無法承擔,長期得不到成長。
- 功能風險:成熟商業產品,很難定製化滿足客戶個性需求;且存在與其他元件整合風險。
- 轉型風險:採用某商業產品後,想轉型其他產品較為困難。
其他說明
- 商業產品,包含國產資料庫及新興資料庫廠商。作為商業產品很好的補充,這兩類方案在綜合成本上是有優勢的,但還需要在產品功能及服務能力上進一步加強。畢竟類似國外的商業產品服務,已經有四、五十年的積累。
- 商業服務,除了原廠服務外,還包括第三方服務支援公司。在後者的選擇上,針對國外和國內廠商服務,差異還是比較大的。近期看到國產包括新興資料庫廠商與第三方服務公司之間的合作,動作很多(包括培訓、認證、交付等)。
方式2:商業資料庫 + 自主服務
這一方式也較為常見。在前一方式中,隨著企業使用商業軟體的深入,自有服務需求就變得迫切起來。通過建立自有服務體系,可以更好地滿足企業自身需求。這種方式,適合有一定技術積累的傳統企業。未來發展隨著商業資料庫的發展而變化,總體相對穩定。
成本因素
從人力成本來看,相較於前者有更多的投入。商業資料庫產品推廣多年,相關人才保有量很大,因此一般很容易招聘到需要的人才,且往往價格也不太高。這與後面的開源軟體,形成鮮明的對比。財務成本投入仍然相對較大,商業軟體的採購費用佔整體的大頭。
從時間成本看,較前者有所增加,但整體仍然偏少。這主要是因為商業資料庫成熟的生態,很容易搭建出運維體系;且人才方面,也較容易去補充。
風險分析
在風險方面,與前者類似。其中技術風險上,自有人員對商業產品的把控,較原廠還是有所差距。當然對應人員風險就降低,通過自有人員對產品把控力更大。
其他說明
在某些關鍵核心領域,仍然建議採用原廠支援,減低技術風險。
方式3:開源資料庫 + 商業服務
隨著開源資料庫的日益成熟,越來越多的企業開始使用開源資料庫。但相較於商業資料庫,開源方案對企業自有技術能力要求較高。因此,很多考慮搭上開源浪潮的企業,採用這種方式。適用於轉型中的企業,從商業走向開源,這種方式可以在一定程度上規避風險。但一般為過渡階段,長期來看還是要培養企業自有的服務能力。
成本因素
人力成本來看,處於中等水平,相較於商業服務,其綜合人力成本有所降低的。財務成本投入大體中等左右,但服務廠商不同差異較大。時間成本投入較少,但相較於商業方案,需要企業對商業服務做更多的技術考察。因此在初始的評測階段,往往需要投入較多的時間。
風險分析
- 技術風險:開源資料庫自身技術風險、企業技術選型風險及商業服務能力風險。
- 人員風險:受廠商技術人員技術能力水平影響很大,需要認真評估。
- 功能風險:一般而言,開源資料庫在功能上相較於商業資料庫,還是有所欠缺。因此這部分要仔細評估。
其他說明
與商業服務不同,目前在開源服務方面,各廠商能力參差不齊,也沒有較為統一的標準。有些開源資料庫,是有所謂“原廠”類商業支援,但在國內聲小勢微。
方式4:開源資料庫 + 自主服務
這是典型的“網際網路”玩法,也是較為常見的一種方式。適用於規模較大,企業定製化要求較高的場景。發展成熟可考慮向企業內部私有云或資料庫產品、方案方向發展,甚至對外賦能。
成本因素
這種方式的人力成本相對較高,但根據企業的使用規模、難度差異較大。開源資料庫的發展也經歷了一段時間,市場上人才保有量也逐步提升。但對於高階人才,仍然相對稀缺,人才成本也較高。財務方面,主要也表現在人力成本上。
此外,對於基礎設施上也需要有一定投入,甚至可能比商業方案投入更大。時間成本較高,企業要建立成熟的開源資料庫運維體系,是需要一定時間積累。
風險分析
風險分析與上者類似,突出人員風險,需長期培養投入。
方式5:開源定製資料庫 + 商業服務
這是方案3的一種特殊情況。企業不是使用原生開源產品,而是使用第三方公司定製開源方案,可能是純軟體,也可能是軟硬一體式。這類方式,會針對開源軟體的不足,做定製化改進,滿足企業級軟體的需求。
但這種方式一般企業無法自己獨立運維,需要藉助第三方公司的商業支援。對資料庫的企業級特性有較高要求,但原生開源資料庫又無法滿足的情況。對於短期內有去除商業資料庫的需求場景,非常適合。隨著國內對開源資料庫使用水平不斷深入,有越來越多的此類初創型企業出現。非常看好這種模式的未來發展。
成本因素
人力成本,主要來自於第三方服務,總體不高。財務成本,主要看方案情況,差異較大。時間成本,可視同純商業方案。
風險分析
- 技術風險:定製化部分不開放,企業不可把控;此外,原生開源的版本變化,可能短期無法適用到方案中
- 人員風險:受廠商技術人員技術能力水平影響很大,需要認真評估。
- 轉型風險:受限於方案,存在一定轉型的風險。
方式6:私有云 + 雲化服務
最後一種企業私有化部署方案,是一種雲化折中方案。受限於一些特殊國情,有些企業無法直接使用公有云,但又急需類似公有云的平臺能力。因此,某些雲廠商或資料庫廠商提供了一種私有云化部署方案。可簡單理解為將雲搬回家。
過去有種說法,說私有云會逐步萎縮,公有云會一統天下。但從近兩年的國內雲市場發展來看,私有云的發展速度某些指標甚至超過公有云。當我們現在大談”toB”市場成為下一個藍海時,這種模式也是toB服務市場的一個重要組成部分。這種方式,適合於大型企業,長期看好。
成本因素
從成本角度來看,人力成本投入不大,主要取決於廠商人員投入。財力方面,雖然相較於大型商業解決方案,有一定的成本優勢,但優勢不甚明顯。時間成本上,也要長於傳統方案,畢竟這不是單一技術平臺的更換,而是涉及到Iaas、Paas等諸多層面。
風險分析
其風險點除了在財力方面,更多是考慮在對廠商的技術依賴性。相較於傳統方案,這種方式的依賴性甚至更高。廠商一般提供很好的私有云,及對應其自有公有云的打通方案;但對其他公有云或企業自有平臺,則較難打通。
方式7:裸雲 + 開源資料庫 + 自主服務
這是一種上雲使用的初級階段,企業僅使用雲的Iaas部分,其餘均自建。這種方式可充分利用公有云帶來的彈性優勢,將企業原有的技術積累延續到雲端。對於企業來說,這種方式也是最為“平滑”的,甚至應用可以不做更多感知,仍然像使用企業內部IT資源一樣,使用公有云資源。很適合於有多雲、跨雲需求的場合。但缺點是無法利用雲廠商技術能力帶來的附加值。
成本因素
從成本角度來看,企業可做到”最優”。僅使用裸機的情況下,完全可以按”價低者得”的策略,優化選擇。在一定規模情況下,公有云還是有其價格優勢,何況還可以充分利用彈效能力,動態縮減,根據企業發展隨時調整IT投入。人員方面,與企業自主運維變化不大。時間方面,因為底層交付速度的提升,還是有一定的提高。
風險分析
風險不大,僅僅是依賴公有云底層,很容易遷移到其他雲廠商或遷回自有。
方式8:裸雲 + 商業資料庫 + 第三方服務/自主服務
這是一種較為特殊的情況。企業選擇將商業資料庫,構建在公有云上。但其沒有選擇雲廠商提供的,而是自主構建或選擇第三方廠商協助完成。這往往是一些中小型的企業,其規模不足以支援私有化部署,而應用又依賴於商業資料庫產品。企業想要充分利用雲的彈性,因此組合出這種使用方式。
成本因素
財務成本來說,主要是針對基礎設施層面,會較自建有所節省。人力、時間方面,差異不大。
風險分析
風險在於,某些商業資料庫針對雲場景的不予支援,企業有一定技術風險。要麼有比較強大的自主技術能力,要麼依賴於第三方服務廠商。
方式9:雲資料庫(開源) + 雲平臺服務
這是雲廠商推出的最為“傳統”的資料庫服務,也是目前最多的一種選擇。雲廠商基於開源的資料庫版本+自有的平臺服務,構建其資料庫產品。其核心的資料庫與開源的版本,是完全一致的,各家比拼的更多是平臺服務能力。這種方式對於企業的運維要求很低,基本可以依賴於雲廠商提供的能力(除了個別高可用、容災需求外)。這一方案比較適合於初期上雲企業,可逐步摸索雲與原有方式的區別。
成本因素
財務成本來說,與商業方案比較無疑是有優勢的,但與自主開源對比,幾乎沒有優勢。其更多的是在快速交付、擴縮容等方面產品特點。此外,對於人力成本來說,因運維類工作大幅度降低,因此是可以節約一定人力,壓縮自有人員規模。時間成本方面,也有所提升。
風險分析
資料庫自身風險不大,畢竟其使用的與開源同一版本,技術上可遷移至其他雲廠商。當資料庫版本升級後,也可以享受到對應的技術紅利。但對平臺服務,是存在一定依賴的,各家能力不同,需要有適應過程。此外,運維依賴雲廠商,也存在一定技術風險。自主的技術能力,會逐步喪失。
方式10:雲資料庫(開源定製) + 雲平臺服務
雲廠商除了提供與開源一致版本外,一般還提供私有定製版本。它往往是基於某開源資料庫某一版本的深度定製,針對某些特性做了加強。當然有些以反饋社群的方式,回饋給開源(可能未來會merge入新版),但很多僅存在在”雲私有DB”。如企業有針對某一特殊場景(如秒殺)或其他方面(如金融級資料同步)的強需求,可考慮使用此方案。當
然使用也意味著與雲廠商深度繫結。此外,在平臺服務方面,與上面情況類似。這種方案比較適合於對資料庫有一定要求,而原生開源版本又不支援的情況。
成本因素
與上一種方式類似。
風險分析
風險在於繫結單一廠商,一般很難下來。這與使用大型商業資料庫的情況類似。當然可以在應用端做個設計,儘量減少對特性的依賴。此外,因為是定製版本,未來開源版本的升級可能不會短時間內支援,甚至可能不會考慮支援,完全走向獨立分支的道路。針對這點,企業也是需要關注的。
方式11:雲原生資料庫(自研) + 雲平臺服務
某些大的雲廠商,除了上述兩種外,可通過自研資料庫方式,增加未來的產品競爭力。從最新的Gather報告來看,更多的雲廠商加入進來,這也給資料庫整體市場帶來了活力。從預測來看,均一致看好雲原生資料庫的未來發展。相較於前兩種方式,這類資料庫更是誕生於雲,從設計之初就更多考慮了雲化環境特點,因此極具競爭力。
當然,從目前來看,現有云原生還處於”初級”階段,未來在解決了更大規模擴充套件性、多讀多寫能力等後,其將真正進入井噴式發展。現有各大廠,在這一領域紛紛重點佈局,加大投入。對企業而言,無疑又多了一種選擇,特別是某些場景(如海量資料等),原生開源、擴充套件開源產品均無法滿足。
成本因素
目前各廠商都在不遺餘力地推廣,因此從成本上企業還是可以受益的;但從長期來看,還需要進一步觀察。從人員來說,企業也是需要一定投入,畢竟這是一種全新的資料庫,雖然雲廠商提供了很好的互動平臺,但還是需要企業做一定的技術儲備,因此人員上還需要些投入。時間上來看,對於這個比較新的產品,還需要做更多的測試評估工作,因此也是需要多些投入。
風險分析
風險類似上面,甚至有過之。企業應用將完全依賴於廠商產品。儘管很多是宣傳相容開源或商業資料庫,但畢竟不是同一產品。這點還需要企業仔細評估。此外,針對相容性、備份恢復、高可用、資料同步、跨雲容災等,都是值得投入研究的。
方式12:雲資料庫(自研) + 雲服務 + 雲託管平臺
這是一類小眾的方案,其背景是緣起於資料庫廠商與雲廠商的蛋糕劃分問題。有些資料庫廠商(如MongoDB)不希望將雲資料庫市場由雲廠商主導,而是希望可由自身主導,構建不依賴於雲廠商的獨立生態。目前這種方式國內見得不多,此處暫不評論了。
作者:韓鋒
首發於作者個人公號《韓鋒頻道》,歡迎關注。
來源:宜信技術學院
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69918724/viewspace-2654335/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Guava Cache使用的三種姿勢Guava
- 在react中使用svg的各種騷姿勢ReactSVG
- 前端樹形Tree資料結構使用-🤸🏻♂️各種姿勢總結前端資料結構
- PTH的幾種食用姿勢
- BeautifulSoup的使用姿勢
- npm換源的幾種姿勢NPM
- Python爬蟲的N種姿勢Python爬蟲
- 程式碼除錯的N種姿勢除錯
- PHP 檔案操作的各種姿勢PHP
- 解鎖跨域的九種姿勢跨域
- 建立 React 元件三種“姿勢”React元件
- TiDB 的正確使用姿勢TiDB
- Redis的正確使用姿勢Redis
- 聊聊javascript事件的使用姿勢JavaScript事件
- Vue-router的使用姿勢Vue
- 探索Bitmap使用姿勢
- 使用NineData定製企業級資料庫規範資料庫
- 原來,企業網盤還能以這2種姿勢做內外網的檔案交換
- 【吐血整理】Git的各種撤銷姿勢Git
- Powershell惡意程式碼的N種姿勢
- Windwos密碼匯出的幾種姿勢密碼
- 論二級域名收集的各種姿勢
- 雙 11 技術攻略:企業雲架構的正確姿勢架構
- laravel 使用 es 的正確姿勢Laravel
- 使用列舉的正確姿勢
- 使用快取的正確姿勢快取
- ArcGIs建立企業級資料庫資料庫
- ElasticSearch基本使用姿勢二Elasticsearch
- Postman 正確使用姿勢Postman
- Flutter 知識梳理 (狀態管理) - Provider 之各種 XXProvider 的使用姿勢FlutterIDE
- Spring Boot 郵件傳送的 5 種姿勢!Spring Boot
- 論JVM爆炸的幾種姿勢及自救方法JVM
- 入門快應用的另一種姿勢
- Spring Boot使用AOP的正確姿勢Spring Boot
- npm run dev 的正確使用姿勢NPMdev
- 原始碼|使用FutureTask的正確姿勢原始碼
- 使用 react Context API 的正確姿勢ReactContextAPI
- Spring之RequestBody的使用姿勢小結Spring