資料庫的選型

對於很多程式設計師來說，公司選擇什麼樣的資料庫，基本不需要你來決定。當你加入一個公司的時候，公司的大部分技術選型已經確認，特別是資料庫選型，因為資料庫一旦選擇，後期遷移的代價還是很大的。

​

隨著大資料時代的來臨，湧現出了很多新型資料庫，在公司遇到資料效能瓶頸，喊去IOE口號或者是想嚐鮮時，都會慢慢的使用新型資料庫。但是無論是技術選型還是轉型，你都不能忽略一個因素：你選的資料庫技術你能駕馭嗎？

我們知道，現在有很多開源資料庫可以讓我們選擇，但是我們有相關的技術人員精通這些資料庫嗎？比如GreenPlum這款資料，有開源版本，也有商業公司在運作，我們看到官方宣傳的案例很好，查詢效率很高。在一些大資料量查詢聚合也比Oracle快一點。但是作為生產資料庫使用，隨著資料量的增加，你會發現各種你之前沒有了解到的問題，對於開發人員來說，比之前的Oracle難用多了。這時候你可能會尋求商業公司的幫助，r派來高階工程師對資料庫進行巡檢後，提出了很多優化方案、使用規範和管理策略，這些都是你之前不曾瞭解的。

很多人看到了BAT用的很好，自己就去嘗試，並很快用於生產。你可以看看BAT有多少研究員，可能你的公司一個都沒有。很多人會問，postgreSQL宣傳的很好，我們替換掉MySQL吧。一個公司的資料庫如果從來不出現問題，那一定是沒有業務量，一旦業務量上來，就會遇到各種問題，這時候什麼最重要？救火！所以在資料庫出現問題時，公司是否有足夠專業的工程師去解決問題是很重要的。所以，對很多想要去O的公司來說，你要想好如何選型新技術。看著開源的免費，貿然使用會付出更多代價。

技術更新很快，還是希望大家在測試開發時候使用新技術，逐步精通的過程中，緩慢過度生產，如果公司有預算，可以請商業公司進行指導半年到一年，自己人學到精髓後再開展獨立運維。

資料庫如何避坑

再好的資料庫，如果使用姿勢不對也是枉然，更何況很多程式設計師並不怎麼懂資料庫。在資料庫使用中，我們常會碰到很多問題。

• 人為失誤

​

人為失誤一般分兩類，一種是DBA操作失誤，一種是程式設計師開人員程式裡使用不當。DBA一般我們認為是資料庫管理的專家了，出錯的概率比較小，但是一旦出錯，危險是做大的。比如我們經常調侃的“刪庫跑路”，雖然是依據調侃，但是我是真真的見到過兩次，生產環境出現一次，就會在你的工作生涯上記上“光輝”一筆，所以說DBA算是一個高危工作了吧。另一種是開發人員使用不當。常見的比如在使用大表時候，不考慮是否有索引，進行了全表掃描，導致整個資料庫被拖垮。

• 資料庫的訪問瓶頸

只要是資料庫，就會有併發量的限制。以前使用MySQL，我們經常看到網際網路公司併發上萬的壓測。但是對於很多新型的MPP資料庫，他們的併發並不是你想的那樣，MPP一般由叢集CPU物理核數有關。比如以前開發程式查詢的MySQL，遷移到GP，那麼你的資料庫連線池要改一改了。特別是對於一些面向網際網路的網站，資料庫管理層也要做訪問策略，不然，一個外掛可能就會把你的庫搞死。

• 索引

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

• HA（高可用）

​

資料庫作為儲存查詢引擎的同時，支撐著大型網站的後臺服務，一定要考慮高可用。對於一些天然不支援高可用或者高可用不友好的選型一定要小心。再來安利一下Vertica，無Master MPP架構，叢集中只要不超過一半機器宕機（物理位置不相鄰），叢集就處於可用狀態。

• 標準SQL

​

SQL就是針對資料庫查詢產生的語言。隨著新型資料庫的出現，很多資料庫不支援標準SQL或者支援很弱。比如HBase。這對於很多以前的開發人員還是有一定學習門檻的，還有就是後期如果出現業務遷移還是很困難的。

Oracle支援標準SQL，但是儲存過程並不是每個資料庫都有的，這也是阿里為何禁用儲存過程的吧，你無法想象一個上萬行儲存過程的遷移要耗費多少資源。對標準SQL的支援，降低了開發人員的使用門檻，也降低了以後業務遷移的風險。

資料庫發展期望

​

我們會發現傳統的MySQL資料庫對於併發聯機事務處理支援很好，但是隨著網際網路和物聯網發展，很多場景下無法單獨使用MySQL做支撐，我們通常選引入大資料技術比如HBase輔助，或者搜尋引擎。在分析領域我們選擇Hadoop和MPP資料庫作為支撐，效果也很好，但是越多的技術棧意味著越多的學習成本和風險。

聽過PingCAP提出的HTAP架構。資料是系統架構的中心，但過去的系統通常都只能解決一部分場景的問題，在 OLTP，OLAP，資料倉庫方面各有側重，現在終於走向更全能的 HTAP 架構，在一致性、可用性、可擴充套件性上取得平衡，充分利用雲的彈性供給能力和動態排程能力，並且降低運維成本和系統複雜性。

如果出現了一款資料庫能夠兩者兼顧，那必然是美好的。也許還會其他更好的方案，不管怎樣，我們會逐步看到更多以資料為中心的架構，更好應對業務和環境的複雜性，響應需求的變化，資料庫領域的未來還有許多探索空間~