數據庫的選型
對于很多程序員來說，公司選擇什么樣的數據庫，基本不需要你來決定。當你加入一個公司的時候，公司的大部分技術選型已經確認，特別是數據庫選型，因為數據庫一旦選擇，后期遷移的代價還是很大的。
隨著大數據時代的來臨，涌現出了很多新型數據庫，在公司遇到數據性能瓶頸，喊去IOE口號或者是想嘗鮮時，都會慢慢的使用新型數據庫。但是無論是技術選型還是轉型，你都不能忽略一個因素：你選的數據庫技術你能駕馭嗎？
我們知道，現在有很多開源數據庫可以讓我們選擇，但是我們有相關的技術人員精通這些數據庫嗎？比如這款數據，有開源版本，也有商業公司在運作，我們看到官方宣傳的案例很好，查詢效率很高。在一些大數據量查詢聚合也比快一點。但是作為生產數據庫使用，隨著數據量的增加，你會發現各種你之前沒有了解到的問題，對于開發人員來說，比之前的難用多了。這時候你可能會尋求商業公司的幫助，r派來高級工程師對數據庫進行巡檢后，提出了很多優化方案、使用規范和管理策略，這些都是你之前不曾了解的。
很多人看到了BAT用的很好，自己就去嘗試，并很快用于生產。你可以看看BAT有多少研究員，可能你的公司一個都沒有。很多人會問，宣傳的很好，我們替換掉MySQL吧。一個公司的數據庫如果從來不出現問題，那一定是沒有業務量，一旦業務量上來，就會遇到各種問題，這時候什么最重要？救火！所以在數據庫出現問題時，公司是否有足夠專業的工程師去解決問題是很重要的。所以網站數據庫連接出錯，對很多想要去O的公司來說，你要想好如何選型新技術?？粗_源的免費，貿然使用會付出更多代價。
技術更新很快，還是希望大家在測試開發時候使用新技術，逐步精通的過程中，緩慢過度生產，如果公司有預算，可以請商業公司進行指導半年到一年，自己人學到精髓后再開展獨立運維。
數據庫如何避坑
再好的數據庫，如果使用姿勢不對也是枉然，更何況很多程序員并不怎么懂數據庫。在數據庫使用中，我們常會碰到很多問題。
人為失誤一般分兩類，一種是DBA操作失誤，一種是程序員開人員程序里使用不當。DBA一般我們認為是數據庫管理的專家了，出錯的概率比較小，但是一旦出錯，危險是做大的。比如我們經常調侃的“刪庫跑路”，雖然是依據調侃，但是我是真真的見到過兩次，生產環境出現一次，就會在你的工作生涯上記上“光輝”一筆，所以說DBA算是一個高危工作了吧。另一種是開發人員使用不當。常見的比如在使用大表時候，不考慮是否有索引，進行了全表掃描，導致整個數據庫被拖垮。
只要是數據庫，就會有并發量的限制。以前使用MySQL，我們經常看到互聯網公司并發上萬的壓測。但是對于很多新型的MPP數據庫，他們的并發并不是你想的那樣，MPP一般由集群CPU物理核數有關。比如以前開發程序查詢的MySQL，遷移到GP，那么你的數據庫連接池要改一改了。特別是對于一些面向互聯網的網站，數據庫管理層也要做訪問策略，不然，一個外掛可能就會把你的庫搞死。
我們都知道索引在傳統的關系型數據庫中使用的很多，效果也很明顯。但是你要知道索引是拿存儲換時間的操作。曾遇到過開發人員動不動就讓建索引，搞的好像不要錢一樣。還有像（適用OLAP場景）這個數據庫就比較友好了，不需要建立索引網站數據庫連接出錯，只需要在建表時候預排序分布即可提高查詢效率，同時列存儲的數據還是壓縮的，降低了存儲，還提高了查詢效率。
數據庫作為存儲查詢引擎的同時，支撐著大型網站的后臺服務，一定要考慮高可用。對于一些天然不支持高可用或者高可用不友好的選型一定要小心。再來安利一下，無 MPP架構，集群中只要不超過一半機器宕機（物理位置不相鄰），集群就處于可用狀態。
SQL就是針對數據庫查詢產生的語言。隨著新型數據庫的出現，很多數據庫不支持標準SQL或者支持很弱。比如HBase。這對于很多以前的開發人員還是有一定學習門檻的，還有就是后期如果出現業務遷移還是很困難的。
支持標準SQL，但是存儲過程并不是每個數據庫都有的，這也是阿里為何禁用存儲過程的吧，你無法想象一個上萬行存儲過程的遷移要耗費多少資源。對標準SQL的支持，降低了開發人員的使用門檻，也降低了以后業務遷移的風險。
數據庫發展期望
我們會發現傳統的MySQL數據庫對于并發聯機事務處理支持很好，但是隨著互聯網和物聯網發展，很多場景下無法單獨使用MySQL做支撐，我們通常選引入大數據技術比如HBase輔助，或者搜索引擎。在分析領域我們選擇和MPP數據庫作為支撐，效果也很好，但是越多的技術棧意味著越多的學習成本和風險。聽過提出的HTAP架構。數據是系統架構的中心，但過去的系統通常都只能解決一部分場景的問題，在 OLTP，OLAP，數據倉庫方面各有側重，現在終于走向更全能的 HTAP 架構，在一致性、可用性、可擴展性上取得平衡，充分利用云的彈性供給能力和動態調度能力，并且降低運維成本和系統復雜性。如果出現了一款數據庫能夠兩者兼顧，那必然是美好的。也許還會其他更好的方案，不管怎樣，我們會逐步看到更多以數據為中心的架構，更好應對業務和環境的復雜性，響應需求的變化，數據庫領域的未來還有許多探索空間~歷史好文推薦
你點的每個在看，我都認真當成了喜歡