大家好，我是韓鋒，一個數(shù)據(jù)庫領域資深從業(yè)者（好吧，我是個70后）。近些年來，主要從事數(shù)據(jù)庫產(chǎn)品、架構等工作。本文我將以個人感受，談談在新時期下數(shù)據(jù)庫架構優(yōu)化工作的一些問題，供大家參考。

下面的分享，我將從外部環(huán)境對數(shù)據(jù)庫架構的影響、當前架構中若干熱門的技術問題、之前的架構實踐經(jīng)歷，以及個人如何成長等方面談談我的感受。

首先談下外部因素對架構工作的影響。有些同學可能會感到疑惑，架構問題不是技術問題嘛，為什么還要考慮外部因素？這里是有個誤區(qū)的，架構的本質是為了解決企業(yè)的業(yè)務問題，針對某一問題可能有很多種解法，選擇最為合適的（而非最優(yōu)的）是考驗一個架構師的核心能力。

正如上圖中，右下角的描述“脫離企業(yè)環(huán)境的架構，都是耍流氓”。那么影響架構的外部因素有哪些呢？

下面將以一個較為傳統(tǒng)的企業(yè)客戶視角，看看其內(nèi)外部的需求是什么？這些因素都將對后續(xù)的架構設計，帶來很大的影響。

對于外在需求部分，可分為如下幾個方面（有優(yōu)先級順序）：

對于內(nèi)在需求部分，可分為如下幾個方面（有優(yōu)先級順序）：

企業(yè)、部門、團隊的情況，也會對架構選擇有所影響。

如之前環(huán)境篇開篇談到的問題，公司所處行業(yè)、性質及發(fā)展階段對架構選擇存在不同影響，這里就不贅述了。

下面的技術篇中，我將談到企業(yè)使用數(shù)據(jù)庫的方式及對當前一些技術選擇的個人觀點。

這是較為傳統(tǒng)的一種方式。企業(yè)購買大型商業(yè)數(shù)據(jù)庫軟件，并對應購買服務支持工作。在過去三、四十年里，這是主流方式?？梢哉f也很好地滿足了各類企業(yè)的快速發(fā)展。只是隨著近二十年來，互聯(lián)網(wǎng)化的變革，對此種方式產(chǎn)生了不小的沖擊。

這種方式適合傳統(tǒng)企業(yè)，對數(shù)據(jù)庫要求較高，自有技術能力有限，未來發(fā)展相對固定的情況。未來發(fā)展隨著商業(yè)數(shù)據(jù)庫的發(fā)展而變化，從總體來看，未來云化的需求對其沖擊較大。此外，在國產(chǎn)化、自主可控化等要求下，也會對這個模式影響較大。

風險分析：

這一方式也較為常見。在前一方式中，隨著企業(yè)使用商業(yè)軟件的深入，自有服務需求就變得迫切起來。通過建立自有服務體系，可以更好地滿足企業(yè)自身需求。這種方式，適合有一定技術積累的傳統(tǒng)企業(yè)。未來發(fā)展隨著商業(yè)數(shù)據(jù)庫的發(fā)展而變化，總體相對穩(wěn)定。

風險分析：

在風險方面，與前者類似。其中技術風險上，自有人員對商業(yè)產(chǎn)品的把控，較原廠還是有所差距。當然對應人員風險就降低，通過自有人員對產(chǎn)品把控力更大。

隨著開源數(shù)據(jù)庫的日益成熟，越來越多的企業(yè)開始使用開源數(shù)據(jù)庫。但相較于商業(yè)數(shù)據(jù)庫，開源方案對企業(yè)自有技術能力要求較高。因此，很多考慮搭上開源浪潮的企業(yè)，采用這種方式。適用于轉型中的企業(yè)，從商業(yè)走向開源，這種方式可以在一定程度上規(guī)避風險。但一般為過渡階段，長期來看還是要培養(yǎng)企業(yè)自有的服務能力。

風險分析：

這是典型的“互聯(lián)網(wǎng)”玩法，也是較為常見的一種方式。適用于規(guī)模較大，企業(yè)定制化要求較高的場景。發(fā)展成熟可考慮向企業(yè)內(nèi)部私有云或數(shù)據(jù)庫產(chǎn)品、方案方向發(fā)展，甚至對外賦能。

風險分析：

風險分析與上者類似，突出人員風險，需長期培養(yǎng)投入。

這是方案3的一種特殊情況。企業(yè)不是使用原生開源產(chǎn)品，而是使用第三方公司定制開源方案，可能是純軟件，也可能是軟硬一體式。這類方式，會針對開源軟件的不足，做定制化改進，滿足企業(yè)級軟件的需求。但這種方式一般企業(yè)無法自己獨立運維，需要借助第三方公司的商業(yè)支持。對數(shù)據(jù)庫的企業(yè)級特性有較高要求，但原生開源數(shù)據(jù)庫又無法滿足的情況。對于短期內(nèi)有去除商業(yè)數(shù)據(jù)庫的需求場景，非常適合。隨著國內(nèi)對開源數(shù)據(jù)庫使用水平不斷深入，有越來越多的此類初創(chuàng)型企業(yè)出現(xiàn)。非常看好這種模式的未來發(fā)展。

風險分析：

企業(yè)私有化部署方案，是一種云化折中方案。受限于一些特殊國情，有些企業(yè)無法直接使用公有云，但又急需類似公有云的平臺能力。因此，某些云廠商或數(shù)據(jù)庫廠商提供了一種私有云化部署方案，可簡單理解為將云搬回家。

過去有種說法，說私有云會逐步萎縮，公有云會一統(tǒng)天下。但從近兩年的國內(nèi)云市場發(fā)展來看，私有云的發(fā)展速度某些指標甚至超過公有云。當我們現(xiàn)在大談“toB”市場成為下一個藍海時，這種模式也是toB服務市場的一個重要組成部分。這種方式，適合于大型企業(yè)，長期看好。

風險分析：

其風險點除了在財力方面，更多是考慮在對廠商的技術依賴性。相較于傳統(tǒng)方案，這種方式的依賴性甚至更高。廠商一般提供很好的私有云，及對應其自有公有云的打通方案；但對其他公有云或企業(yè)自有平臺，則較難打通。

這是一種上云使用的初級階段，企業(yè)僅使用云的IaaS部分，其余均自建。這種方式可充分利用公有云帶來的彈性優(yōu)勢，將企業(yè)原有的技術積累延續(xù)到云端。對于企業(yè)來說，這種方式也是最為“平滑”的，甚至應用可以不做更多感知，仍然像使用企業(yè)內(nèi)部IT資源一樣，使用公有云資源。很適合于有多云、跨云需求的場合。但缺點是無法利用云廠商技術能力帶來的附加值。

風險分析：

風險不大，僅僅是依賴公有云底層，很容易遷移到其他云廠商或遷回自有。

這是一種較為特殊的情況。企業(yè)選擇將商業(yè)數(shù)據(jù)庫，構建在公有云上。但其沒有選擇云廠商提供的，而是自主構建或選擇第三方廠商協(xié)助完成。這往往是一些中小型的企業(yè)，其規(guī)模不足以支持私有化部署，而應用又依賴于商業(yè)數(shù)據(jù)庫產(chǎn)品。企業(yè)想要充分利用云的彈性，因此組合出這種使用方式。

風險分析：

風險在于，某些商業(yè)數(shù)據(jù)庫針對云場景的不予支持，企業(yè)有一定技術風險。要么有比較強大的自主技術能力，要么依賴于第三方服務廠商。

這是云廠商推出的最為“傳統(tǒng)”的數(shù)據(jù)庫服務，也是目前最多的一種選擇。云廠商基于開源的數(shù)據(jù)庫版本+自有的平臺服務，構建其數(shù)據(jù)庫產(chǎn)品。其核心的數(shù)據(jù)庫與開源的版本，是完全一致的，各家比拼的更多是平臺服務能力。這種方式對于企業(yè)的運維要求很低，基本可以依賴于云廠商提供的能力（除了個別高可用、容災需求外）。這一方案比較適合于初期上云企業(yè)，可逐步摸索云與原有方式的區(qū)別。

風險分析：

數(shù)據(jù)庫自身風險不大，畢竟其使用的與開源同一版本，技術上可遷移至其他云廠商。當數(shù)據(jù)庫版本升級后，也可以享受到對應的技術紅利。但對平臺服務，是存在一定依賴的，各家能力不同，需要有適應過程。此外，運維依賴云廠商，也存在一定技術風險。自主的技術能力，會逐步喪失。

云廠商除了提供與開源一致版本外，一般還提供私有定制版本。它往往是基于某開源數(shù)據(jù)庫某一版本的深度定制，針對某些特性做了加強。當然有些以反饋社區(qū)的方式，回饋給開源（可能未來會merge入新版），但很多僅存在“云私有DB”。如企業(yè)有針對某一特殊場景（如秒殺）或其他方面（如金融級數(shù)據(jù)同步）的強需求，可考慮使用此方案。當然使用也意味著與云廠商深度綁定。此外，在平臺服務方面，與上面情況類似。這種方案比較適合于對數(shù)據(jù)庫有一定要求，而原生開源版本又不支持的情況。

風險分析：

風險在于綁定單一廠商，一般很難下來。這與使用大型商業(yè)數(shù)據(jù)庫的情況類似。當然可以在應用端做個設計，盡量減少對特性的依賴。此外，因為是定制版本，未來開源版本的升級可能不會短時間內(nèi)支持，甚至可能不會考慮支持，完全走向獨立分支的道路。針對這點，企業(yè)也是需要關注的。

某些大的云廠商，除了上述兩種外，可通過自研數(shù)據(jù)庫方式，增加未來的產(chǎn)品競爭力。從最新的Gatner報告來看，更多的云廠商加入進來，這也給數(shù)據(jù)庫整體市場帶來了活力。從預測來看，均一致看好云原生數(shù)據(jù)庫的未來發(fā)展。相較于前兩種方式，這類數(shù)據(jù)庫更是誕生于云，從設計之初就更多考慮了云化環(huán)境特點，因此極具競爭力。

當然，從目前來看，現(xiàn)有云原生還處于“初級”階段，未來在解決了更大規(guī)模擴展性、多讀多寫能力等后，其將真正進入井噴式發(fā)展?，F(xiàn)有各大廠，在這一領域紛紛重點布局，加大投入。對企業(yè)而言，無疑又多了一種選擇，特別是某些場景（如海量數(shù)據(jù)等），原生開源、擴展開源產(chǎn)品均無法滿足。

風險分析：

風險類似上面，甚至有過之。企業(yè)應用將完全依賴于廠商產(chǎn)品。盡管很多是宣傳兼容開源或商業(yè)數(shù)據(jù)庫，但畢竟不是同一產(chǎn)品。這點還需要企業(yè)仔細評估。此外，針對兼容性、備份恢復、高可用、數(shù)據(jù)同步、跨云容災等，都是值得投入研究的。

這是一類小眾的方案，其背景是緣起于數(shù)據(jù)庫廠商與云廠商的蛋糕劃分問題。有些數(shù)據(jù)庫廠商（如MongoDB）不希望將云數(shù)據(jù)庫市場由云廠商主導，而是希望可由自身主導，構建不依賴于云廠商的獨立生態(tài)。目前這種方式國內(nèi)見得不多。

受到眾多互聯(lián)網(wǎng)公司的影響，很多傳統(tǒng)企業(yè)對于開源方案也是躍躍欲試。但在選擇之前，也要看到，開源方案并不是免費的“蛋糕”。讓我們來看看，開源方案的利與弊。

對于托管類數(shù)據(jù)庫產(chǎn)品而言，其核心功能還是要跟官方產(chǎn)品走。當然，各個大廠都有著自己多年豐富的實踐經(jīng)驗，并具備一定的內(nèi)核研發(fā)能力。于是，往往針對原生產(chǎn)品做一些定制化的改造，進而提供與原生產(chǎn)品差異化的能力。改造方向上，往往傾向于下面幾類：

針對上述定制化后產(chǎn)品，有時就成為某種“銀彈”，對于企業(yè)客戶很具吸引力；但事情也具有兩面性，對于這些特殊之處的依賴，也會導致客戶對產(chǎn)品的依賴。這也是某些客戶猶豫之處。在我看來，這個問題的要點在于企業(yè)處于的發(fā)展階段。不同階段的企業(yè)，核心訴求不同，在此處的考慮角度也會不同。

 ② 外圍功能

除了核心功能外，還有些非數(shù)據(jù)庫核心能力，但對于企業(yè)使用必不可少的功能。例如：監(jiān)控、備份恢復、優(yōu)化、容災等等。如果沒有云的話，這些能力往往是需要企業(yè)花費精力去自建的。哪怕企業(yè)數(shù)據(jù)庫規(guī)模不大、使用復雜度不高，使用開源數(shù)據(jù)庫也能滿足需求，但上述需求還是要滿足的。于是，前兩年平臺很火，很多企業(yè)都自建了自己的內(nèi)部運維平臺，構建上述能力。當然這種方式有利有弊。利之處在于，企業(yè)可以根據(jù)自身需求度身定制，滿足個性化需求；弊之處在于，構建能力及花費資源長期維護。

如果說，上述功能企業(yè)還是可以較容易具備的，那么云功能則相對門檻有些高了。這里所說的“云功能”，是指例如彈性擴縮容等類。這類能力，往往需要依托于強大的底座能力，是需要較大的研發(fā)投入和長期積累才能具備。在某些特定的場合下，這一能力對企業(yè)很具吸引力，例如業(yè)務形態(tài)、幅度變化很大的企業(yè)客戶。

企業(yè)選擇上云，往往不是僅依靠一兩款產(chǎn)品，而更多是看中云端生態(tài)功能。對于企業(yè)來講，如何通過云端打通技術瓶頸，快速具備業(yè)務能力成為核心。例如從數(shù)據(jù)埋點、數(shù)據(jù)捕捉、數(shù)據(jù)存儲、數(shù)據(jù)計算到分析展示，如果全流程都可以在云端無縫集成，對于企業(yè)來說，是很具有吸引力的。

無疑，這是云數(shù)據(jù)庫頗具優(yōu)勢的方案。企業(yè)如果想通過自建方式解決類似問題，沒有高素質的人才是不行的。然而，一方面此類人才稀缺且價格不菲；另一方面即使已有人才，也要面臨如何留住等問題。畢竟對于大多數(shù)企業(yè)來說，專業(yè)技術人員更多是輔助性崗位，對高級專業(yè)人員來說也面臨長期發(fā)展等問題。而云數(shù)據(jù)庫方案，則不存在此問題，你大可以在很短時間內(nèi)享受到大廠的“腦力”資源，而且不必擔心出現(xiàn)斷檔等問題。

針對這點，是需要企業(yè)充分衡量的。如果通過自建方式，是初期投入大，中長期投入較少，存在一個明顯的波動性。如果通過外購云服務方式，則相對較為平均。兩者的財力分配方式不同。當然，云有一個明顯的優(yōu)勢，就是彈性。企業(yè)可根據(jù)自身情況，靈活選擇，隨時調整。

這是企業(yè)往往容易忽略的問題，時間投入也是一種成本。當你的企業(yè)快速發(fā)展，需要短時間具備某種能力；當你面臨新業(yè)務上線，而后臺IT就遲遲跟不上節(jié)奏。隱形的時間成本，有時對企業(yè)頗為重要；對稍縱即逝的業(yè)務機會來說，穩(wěn)健、敏捷的IT支撐能力很重要。

很多企業(yè)是需要一個“兜底”的服務，即盡量降低企業(yè)的IT風險，保證企業(yè)的正常運營。自建的方式可以解決，但需要構建起整套的能力，投入不?。灰部梢酝ㄟ^購買外部服務的方式，這種就需要考察對方的技術實力、并解決互相扯皮等問題。云廠商，則不存在此問題，基本可做到風險可控。

作為三大核心基礎軟件之一，數(shù)據(jù)庫在整個IT技術中占據(jù)重要的位置。隨著近些年來中國經(jīng)濟的快速發(fā)展，特別是龐大的人口基數(shù)帶來的紅利效應，互聯(lián)網(wǎng)技術在中國蓬勃發(fā)展。甚至在某些技術場景下，相較于國外有著更高的要求。這也促進國內(nèi)企業(yè)在IT基礎技術（包括數(shù)據(jù)庫）上取得了長足的進步。國內(nèi)企業(yè)對數(shù)據(jù)庫的使用大致走過了“商業(yè)->開源->開源+定制->自研”逐步演進的道路。近些年來，隨著技術、資本、人才的積累，國內(nèi)的數(shù)據(jù)庫領域取得很大的突破。

從數(shù)據(jù)庫技術本身而言，隨著分布式、云原生、軟硬一體化、人工智能等技術的出現(xiàn)，為自研數(shù)據(jù)庫代替大型傳統(tǒng)商業(yè)數(shù)據(jù)庫，實現(xiàn)彎道超車提供了可能。同時這些技術的出現(xiàn)，也解決了很多傳統(tǒng)數(shù)據(jù)庫固有的問題，突破了舊有架構的缺陷，更好地滿足客戶對海量、彈性、安全、性能等方面的要求。沒有傳統(tǒng)數(shù)據(jù)庫廠商的歷史包袱，新興廠商站在更高的起點上，實現(xiàn)對傳統(tǒng)廠商的超越。

雖然有些企業(yè)在去除大型商業(yè)數(shù)據(jù)庫實踐上，已經(jīng)有十余年的時間；但大多數(shù)都是限于企業(yè)內(nèi)部。受限于其內(nèi)部場景，很多實踐經(jīng)驗是很難復用到外部企業(yè)。且也沒有一個完整、成熟的商業(yè)化產(chǎn)品提供此類服務。但是近些年來，已可以明顯看到一些變化，以云廠商為代表，正在將企業(yè)內(nèi)部多年的經(jīng)驗積累以產(chǎn)品的化的方式輸出，幫助廣大客戶完成這一過程。

針對這樣一個基礎軟件的替換，我們需要清醒地認識到，不是簡單的“蘋果換成桔子”的過程。這需要從架構設計、程序開發(fā)、運維安全等多個角度去看待。之前很多企業(yè)在拋棄傳統(tǒng)商業(yè)數(shù)據(jù)庫上舉步維艱，正是因為缺乏必要的經(jīng)驗指導，無法將好的技術快速落地并穩(wěn)定運行。在這里需要重點強調的是，很多企業(yè)認為選擇一個功能非常強大的數(shù)據(jù)庫，就可以幫著自己擺脫傳統(tǒng)商業(yè)數(shù)據(jù)庫。其實，這是一個大大的誤區(qū)。功能強大的產(chǎn)品，不一定是適合你，要想完成這一過程，云數(shù)據(jù)庫廠商的實施經(jīng)驗不可或缺。只有“好的產(chǎn)品+豐富經(jīng)驗+良好服務”，才能最終達成這一目標。

企業(yè)（特別是傳統(tǒng)企業(yè)）在數(shù)據(jù)庫使用上，按需求的優(yōu)先級排序，可分為服務、生態(tài)、自主、成本等多個因素。這里最被企業(yè)看中的，正是“服務”一環(huán)。很多企業(yè)使用大型商業(yè)數(shù)據(jù)庫多年，已經(jīng)習慣于傳統(tǒng)數(shù)據(jù)庫廠商的“交鑰匙”工程，非?？粗仄渫陚涞姆漳芰?，使得企業(yè)可以安心于業(yè)務。即使每年付出昂貴的服務費，企業(yè)仍然可以接受。這點也是國內(nèi)廠商的短板，要在短時間內(nèi)建立其等同于國外數(shù)十年積累的企業(yè)服務能力，不是一朝一夕的功夫。這是需要國內(nèi)廠商靜下心來，苦練內(nèi)功，加大投入。經(jīng)過幾年來的積累，國內(nèi)的云廠商已具備了較為成熟交付服務提醒，形成了規(guī)范化的服務能力。

傳統(tǒng)大型商業(yè)數(shù)據(jù)庫，頗令人詬病的一點就是“貴”。究其根本原因，一方面是其商業(yè)策略有關，此外也有人力成本、服務方式等因素有關。此外，還有很容易忽略的一點，就是舊有架構的問題。隨著新架構的演進、技術的突破，特別是“數(shù)據(jù)庫+云”的結合，為客戶提供更靈活、更具性價比的數(shù)據(jù)庫方案成為可能。

隨著數(shù)字經(jīng)濟的到來，各類企業(yè)都在做著數(shù)字化轉型，新的業(yè)態(tài)也不斷涌現(xiàn)。這對于支撐企業(yè)數(shù)字化轉型的重要基礎設施—數(shù)據(jù)庫，提出了更高的要求。如何滿足快速多變的業(yè)務模式創(chuàng)新？如何滿足快速發(fā)展的業(yè)務規(guī)模需求？等等諸如此類的問題，都是數(shù)據(jù)庫產(chǎn)品需要考慮的。國產(chǎn)數(shù)據(jù)庫正是站在這一高點，從國內(nèi)情況出發(fā)，有針對性地推出很多功能，滿足這種創(chuàng)新。

下面以筆者之前在某公司的實踐過程，談談對架構實踐的理解。這里將從需求、資源、路徑、成長角度來談。

第一步，就是現(xiàn)狀分析。俗話說，磨刀不誤砍柴工，只有對現(xiàn)狀充分的了解，找出核心痛點，才能有助于問題的解決。無論是從架構調整還是其他工作都是如此，只有解決痛點才是對公司有價值的。

第二步，就是路徑演進。很多架構工作或其他技術工作，都不是一蹴而就的，而是有個逐步演進的過程。正如上面提到的，在之前公司的數(shù)據(jù)庫開發(fā)設計規(guī)范的落地，也是走過了文檔化->技術宣講->自研平臺的過程。

團隊的情況也很重要。只有統(tǒng)一思想、明確方向，才能有助于最終落地起效。

最后，我們談談對架構師作為個人成長方向的一些問題。相信很多做技術的同學都存在上述的問題：做技術還是做管理？年齡因素怎么看？技術革新太快，如何破？等等。

首先我們從企業(yè)內(nèi)部數(shù)據(jù)應用層次來看，從最為原始的滿足事務型處理需求，DBA更多是充當救火隊員的角色；到逐步規(guī)?；Ⅲw系化，DBA通過平臺處理運維工作甚至可做到預防性運維；再到運維工作已不是主要矛盾，企業(yè)開始關注數(shù)據(jù)庫設計、開發(fā)質量問題，DBA需要更多考慮架構側問題；最終到脫離具體變相的庫的形態(tài)，而從更為維的數(shù)據(jù)層面考慮企業(yè)內(nèi)的數(shù)據(jù)架構問題。

企業(yè)內(nèi)部對數(shù)據(jù)的應用層次的演進，其實也是DBA從運維、平臺、設計、優(yōu)化、架構的演進過程?？梢哉f，伴隨者企業(yè)發(fā)展，數(shù)據(jù)一線從業(yè)者都會慢慢具備一定的架構類職能。這也是技術人，比較理想的一個發(fā)展路線。

從一段時間來看，DBA職業(yè)正受到很大的沖擊，這里包括：

這是個老生常談的問題，做技術還是做管理？我的觀點是，選擇哪條路徑，取決于個人特質，不同的思維方式適合做不同的工作。不要勉強自己做不適合的職業(yè)選擇。

技術的路能走多長？這是很多人的疑問。難道每個人都能發(fā)展成為CTO嗎？顯然這是不現(xiàn)實的。無論是技術路線還是管理路線，其發(fā)展都是有階段性的。對于邁入到更高的臺階，都存在一定比例的選擇率。大部分人，是無法上升到更高的階段，要理性地看待這一問題。并在達到自己階段瓶頸后，找出后續(xù)的發(fā)展路線。說句時髦的話，就是所謂第二成長曲線。

承接上面，每個人發(fā)展都是存在一個階段性上限。當達到這一階段時，你會發(fā)現(xiàn)很難突破自己，此時可以考慮所謂T字性人才發(fā)展策略，即橫向發(fā)展。但這里需要注意的是，一定是在某一領域內(nèi)接近自己所能達到上限，因為這會決定你的“視野”問題。在橫向發(fā)展的選擇上，可以有很多。例如右面列出的技術上的其他領域、業(yè)務方向的沉淀或者參與人的工作（管理）之中。

Q1：如何看待列式數(shù)據(jù)庫的前景以及其在互聯(lián)網(wǎng)企業(yè)中應用場景？

A：列式數(shù)據(jù)庫，主要是說數(shù)據(jù)存儲方式采用列存方式?，F(xiàn)在很多數(shù)據(jù)庫都支持行、列混存的模式。其面對數(shù)據(jù)分析類場景時，列式存儲天然有其優(yōu)勢。企業(yè)中的分析場景，可以考慮使用列式存儲。

Q2：開源數(shù)據(jù)庫的安全隱患大嗎？安全性是否需要重點考慮？

A：開源數(shù)據(jù)庫的安全問題，不能一概而論。只是一般意義上，開源產(chǎn)品在某些企業(yè)特性上較商業(yè)產(chǎn)品還是有所欠缺，安全性是其中之一。當然，隨著很多開源產(chǎn)品在企業(yè)中的到日益廣泛的應用，安全性問題也得到很多開源的重視，不斷補齊、增強這方面的能力。

Q3：如何選擇國產(chǎn)數(shù)據(jù)庫？

A：隨著近些年來國產(chǎn)數(shù)據(jù)庫的蓬勃發(fā)展，無論從產(chǎn)品數(shù)量、成熟度還是使用廣泛程度，都取得了長足的進步。在企業(yè)考慮選擇使用國產(chǎn)數(shù)據(jù)庫時，個人建議優(yōu)先考慮功能、服務、生態(tài)、性能的因素（有優(yōu)先級順序）。

Q4：如何看待國產(chǎn)數(shù)據(jù)庫，特別是分布式國產(chǎn)數(shù)據(jù)庫的前景？

A：無論從內(nèi)外部環(huán)境，還是IT本身發(fā)展規(guī)律，都很看好國產(chǎn)數(shù)據(jù)庫的發(fā)展。這也是我們必要需要經(jīng)歷的一個過程。比較欣喜的看到，近些年來國產(chǎn)數(shù)據(jù)庫發(fā)展很快，并逐步獲得很多關注。相信在不久的未來，必將得到更大的發(fā)展和普及。

分布式數(shù)據(jù)庫，是一個發(fā)展方向，其在解決容量、性能等核心問題上，有著天然的優(yōu)勢。隨著學術上的成熟，在工程領域已經(jīng)很多產(chǎn)品出現(xiàn)，并取得不錯的成績。

Q5：分庫分表清除歷史數(shù)據(jù)有什么需要注意的點？

A：分庫分表架構下，對于清理數(shù)據(jù)會帶來一定的復雜度。核心點在于有統(tǒng)一的清除標識，方便進行清理工作。

Q6：請問CK數(shù)據(jù)庫怎么解決并發(fā)支持不高的情況？

A：對CK了解不多，談寫粗淺認識。對于分析型數(shù)據(jù)庫而言，并發(fā)問題是個老大難問題。其核心問題是在于資源瓶頸。場景的解決方式：1.通過擴展資源，提高吞吐能力，變相提升并發(fā)支持能力；2.通過資源隔離方式，滿足部分高并發(fā)場景需求；3.通過拆分方式，分流并發(fā)需求等。

Q7：類似于TiDB這種整合的數(shù)據(jù)架構解決方案，前景您怎么看？

A：非?？春妙愃芓iDB的整合方案。整合方案的核心點在于，數(shù)據(jù)集中存儲、統(tǒng)一接口、統(tǒng)一管理，這對于用戶是很有吸引力的。解決了用戶對于管理、運維、人力、開發(fā)、成本等多方面的問題。當然，還是有小部分場景無法通過整合架構解決，但對于大多數(shù)客戶、大多數(shù)場景，整合架構還是適用的。

Q8：對于數(shù)據(jù)庫技能的積累上，是如何儲備的呢？SQL、NoSQL、NewSQL是否都有必涉足？

A：存儲哪些技能，核心還是取決于現(xiàn)實需求。這里不僅包括數(shù)據(jù)庫技能，也包括其他技能是同樣的道理。技術發(fā)展演進是很快的，需要人員具備快速學習的基本能力。只有適應這種變化，才能更好地適應未來發(fā)展。

Q9：請評估一下阿里的AnalyticDB這種實時分析型數(shù)據(jù)庫，并且還能支持高并發(fā)？

A：AnalyticDB是阿里云自研的云原生數(shù)據(jù)倉庫。在其初始設計中，就考慮了高并發(fā)的需求。在其前端接入節(jié)點部分，是支持擴展能力，可提供近似線性的擴展能力支持。

Q10：數(shù)據(jù)庫架構師的方向可以突破35歲的限制嗎？

A：架構方向，是技術人發(fā)展的一個方向。對于人員的知識結構、經(jīng)驗積累等，均有較高的要求。在年齡方面，限制度較其他崗位（如研發(fā)）要寬泛很多。我本人經(jīng)歷，也是在35+，才開始轉型到架構方向。

特別推薦一個分享架構+算法的優(yōu)質內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝