關(guān)于數(shù)據(jù)庫，程序員應(yīng)該了解的那些事

數(shù)據(jù)庫的選型

對于很多程序員來說，公司選擇什么樣的數(shù)據(jù)庫，基本不需要你來決定。當(dāng)你加入一個公司的時候，公司的大部分技術(shù)選型已經(jīng)確認(rèn)，特別是數(shù)據(jù)庫選型，因為數(shù)據(jù)庫一旦選擇，后期遷移的代價還是很大的。

隨著大數(shù)據(jù)時代的來臨，涌現(xiàn)出了很多新型數(shù)據(jù)庫，在公司遇到數(shù)據(jù)性能瓶頸，喊去IOE口號或者是想嘗鮮時，都會慢慢的使用新型數(shù)據(jù)庫。但是無論是技術(shù)選型還是轉(zhuǎn)型，你都不能忽略一個因素：你選的數(shù)據(jù)庫技術(shù)你能駕馭嗎？

我們知道，現(xiàn)在有很多開源數(shù)據(jù)庫可以讓我們選擇，但是我們有相關(guān)的技術(shù)人員精通這些數(shù)據(jù)庫嗎？比如GreenPlum這款數(shù)據(jù)，有開源版本，也有商業(yè)公司在運(yùn)作，我們看到官方宣傳的案例很好，查詢效率很高。在一些大數(shù)據(jù)量查詢聚合也比Oracle快一點。但是作為生產(chǎn)數(shù)據(jù)庫使用，隨著數(shù)據(jù)量的增加，你會發(fā)現(xiàn)各種你之前沒有了解到的問題，對于開發(fā)人員來說，比之前的Oracle難用多了。這時候你可能會尋求商業(yè)公司的幫助，r派來高級工程師對數(shù)據(jù)庫進(jìn)行巡檢后，提出了很多優(yōu)化方案、使用規(guī)范和管理策略，這些都是你之前不曾了解的。

很多人看到了BAT用的很好，自己就去嘗試，并很快用于生產(chǎn)。你可以看看BAT有多少研究員，可能你的公司一個都沒有。很多人會問，postgreSQL宣傳的很好，我們替換掉MySQL吧。一個公司的數(shù)據(jù)庫如果從來不出現(xiàn)問題，那一定是沒有業(yè)務(wù)量，一旦業(yè)務(wù)量上來，就會遇到各種問題，這時候什么最重要？救火！所以在數(shù)據(jù)庫出現(xiàn)問題時，公司是否有足夠?qū)I(yè)的工程師去解決問題是很重要的。所以，對很多想要去O的公司來說，你要想好如何選型新技術(shù)?？粗_源的免費(fèi)，貿(mào)然使用會付出更多代價。

技術(shù)更新很快，還是希望大家在測試開發(fā)時候使用新技術(shù)，逐步精通的過程中，緩慢過度生產(chǎn)，如果公司有預(yù)算，可以請商業(yè)公司進(jìn)行指導(dǎo)半年到一年，自己人學(xué)到精髓后再開展獨(dú)立運(yùn)維。

數(shù)據(jù)庫如何避坑

再好的數(shù)據(jù)庫，如果使用姿勢不對也是枉然，更何況很多程序員并不怎么懂?dāng)?shù)據(jù)庫。在數(shù)據(jù)庫使用中，我們常會碰到很多問題。

• 人為失誤

人為失誤一般分兩類，一種是DBA操作失誤，一種是程序員開人員程序里使用不當(dāng)。DBA一般我們認(rèn)為是數(shù)據(jù)庫管理的專家了，出錯的概率比較小，但是一旦出錯，危險是做大的。比如我們經(jīng)常調(diào)侃的“刪庫跑路”，雖然是依據(jù)調(diào)侃，但是我是真真的見到過兩次，生產(chǎn)環(huán)境出現(xiàn)一次，就會在你的工作生涯上記上“光輝”一筆，所以說DBA算是一個高危工作了吧。另一種是開發(fā)人員使用不當(dāng)。常見的比如在使用大表時候，不考慮是否有索引，進(jìn)行了全表掃描，導(dǎo)致整個數(shù)據(jù)庫被拖垮。

• 數(shù)據(jù)庫的訪問瓶頸

只要是數(shù)據(jù)庫，就會有并發(fā)量的限制。以前使用MySQL，我們經(jīng)常看到互聯(lián)網(wǎng)公司并發(fā)上萬的壓測。但是對于很多新型的MPP數(shù)據(jù)庫，他們的并發(fā)并不是你想的那樣，MPP一般由集群CPU物理核數(shù)有關(guān)。比如以前開發(fā)程序查詢的MySQL，遷移到GP，那么你的數(shù)據(jù)庫連接池要改一改了。特別是對于一些面向互聯(lián)網(wǎng)的網(wǎng)站，數(shù)據(jù)庫管理層也要做訪問策略，不然，一個外掛可能就會把你的庫搞死。

• 索引

我們都知道索引在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中使用的很多，效果也很明顯。但是你要知道索引是拿存儲換時間的操作。曾遇到過開發(fā)人員動不動就讓建索引，搞的好像不要錢一樣。還有像Vertica（適用OLAP場景）這個數(shù)據(jù)庫就比較友好了，不需要建立索引，只需要在建表時候預(yù)排序分布即可提高查詢效率，同時列存儲的數(shù)據(jù)還是壓縮的，降低了存儲，還提高了查詢效率。

• HA（高可用）

數(shù)據(jù)庫作為存儲查詢引擎的同時，支撐著大型網(wǎng)站的后臺服務(wù)，一定要考慮高可用。對于一些天然不支持高可用或者高可用不友好的選型一定要小心。再來安利一下Vertica，無Master MPP架構(gòu)，集群中只要不超過一半機(jī)器宕機(jī)（物理位置不相鄰），集群就處于可用狀態(tài)。

• 標(biāo)準(zhǔn)SQL

SQL就是針對數(shù)據(jù)庫查詢產(chǎn)生的語言。隨著新型數(shù)據(jù)庫的出現(xiàn)，很多數(shù)據(jù)庫不支持標(biāo)準(zhǔn)SQL或者支持很弱。比如HBase。這對于很多以前的開發(fā)人員還是有一定學(xué)習(xí)門檻的，還有就是后期如果出現(xiàn)業(yè)務(wù)遷移還是很困難的。

Oracle支持標(biāo)準(zhǔn)SQL，但是存儲過程并不是每個數(shù)據(jù)庫都有的，這也是阿里為何禁用存儲過程的吧，你無法想象一個上萬行存儲過程的遷移要耗費(fèi)多少資源。對標(biāo)準(zhǔn)SQL的支持，降低了開發(fā)人員的使用門檻，也降低了以后業(yè)務(wù)遷移的風(fēng)險。

數(shù)據(jù)庫發(fā)展期望

我們會發(fā)現(xiàn)傳統(tǒng)的MySQL數(shù)據(jù)庫對于并發(fā)聯(lián)機(jī)事務(wù)處理支持很好，但是隨著互聯(lián)網(wǎng)和物聯(lián)網(wǎng)發(fā)展，很多場景下無法單獨(dú)使用MySQL做支撐，我們通常選引入大數(shù)據(jù)技術(shù)比如HBase輔助，或者搜索引擎。在分析領(lǐng)域我們選擇Hadoop和MPP數(shù)據(jù)庫作為支撐，效果也很好，但是越多的技術(shù)棧意味著越多的學(xué)習(xí)成本和風(fēng)險。

聽過PingCAP提出的HTAP架構(gòu)。數(shù)據(jù)是系統(tǒng)架構(gòu)的中心，但過去的系統(tǒng)通常都只能解決一部分場景的問題，在 OLTP，OLAP，數(shù)據(jù)倉庫方面各有側(cè)重，現(xiàn)在終于走向更全能的 HTAP 架構(gòu)，在一致性、可用性、可擴(kuò)展性上取得平衡，充分利用云的彈性供給能力和動態(tài)調(diào)度能力，并且降低運(yùn)維成本和系統(tǒng)復(fù)雜性。

如果出現(xiàn)了一款數(shù)據(jù)庫能夠兩者兼顧，那必然是美好的。也許還會其他更好的方案，不管怎樣，我們會逐步看到更多以數(shù)據(jù)為中心的架構(gòu)，更好應(yīng)對業(yè)務(wù)和環(huán)境的復(fù)雜性，響應(yīng)需求的變化，數(shù)據(jù)庫領(lǐng)域的未來還有許多探索空間~

歷史好文推薦

1. 聊聊數(shù)據(jù)庫
   

2. 數(shù)據(jù)湖vs數(shù)據(jù)倉庫vs數(shù)據(jù)集市
   

3. 淺談數(shù)據(jù)中臺
   

4. 數(shù)據(jù)中臺設(shè)計方法論
   

你點的每個在看，我都認(rèn)真當(dāng)成了喜歡