對於很多程式設計師來說，公司選擇什麼樣的資料庫，基本不需要你來決定。當你加入乙個公司的時候，公司的大部分技術選型已經確認，特別是資料庫選型，因為資料庫一旦選擇，後期遷移的代價還是很大的。
隨著大資料時代的來臨，湧現出了很多新型資料庫，在公司遇到資料效能瓶頸，喊去ioe口號或者是想嘗鮮時，都會慢慢的使用新型資料庫。但是無論是技術選型還是轉型，你都不能忽略乙個因素：你選的資料庫技術你能駕馭嗎？
我們知道，現在有很多開源資料庫可以讓我們選擇，但是我們有相關的技術人員精通這些資料庫嗎？比如greenplum這款資料，有開源版本，也有商業公司在運作，我們看到官方宣傳的案例很好，查詢效率很高。在一些大資料量查詢聚合也比oracle快一點。但是作為生產資料庫使用，隨著資料量的增加，你會發現各種你之前沒有了解到的問題，對於開發人員來說，比之前的oracle難用多了。這時候你可能會尋求商業公司的幫助，r派來高階工程師對資料庫進行巡檢後，提出了很多優化方案、使用規範和管理策略，這些都是你之前不曾了解的。
很多人看到了bat用的很好，自己就去嘗試，並很快用於生產。你可以看看bat有多少研究員，可能你的公司乙個都沒有。很多人會問，postgresql宣傳的很好，我們替換掉mysql吧。乙個公司的資料庫如果從來不出現問題，那一定是沒有業務量，一旦業務量上來，就會遇到各種問題，這時候什麼最重要？救火！所以在資料庫出現問題時，公司是否有足夠專業的工程師去解決問題是很重要的。所以，對很多想要去o的公司來說，你要想好如何選型新技術。看著開源的免費，貿然使用會付出更多代價。
技術更新很快，還是希望大家在測試開發時候使用新技術，逐步精通的過程中，緩慢過度生產，如果公司有預算，可以請商業公司進行指導半年到一年，自己人學到精髓後再開展獨立運維。
再好的資料庫，如果使用姿勢不對也是枉然，更何況很多程式設計師並不怎麼懂資料庫。在資料庫使用中，我們常會碰到很多問題。
人為失誤一般分兩類，一種是dba操作失誤，一種是程式設計師開人員程式裡使用不當。dba一般我們認為是資料庫管理的專家了，出錯的概率比較小，但是一旦出錯，危險是做大的。比如我們經常調侃的「刪庫跑路」，雖然是依據調侃，但是我是真真的見到過兩次，生產環境出現一次，就會在你的工作生涯上記上「光輝」一筆，所以說dba算是乙個高危工作了吧。另一種是開發人員使用不當。常見的比如在使用大表時候，不考慮是否有索引，進行了全表掃瞄，導致整個資料庫被拖垮。
只要是資料庫，就會有併發量的限制。以前使用mysql，我們經常看到網際網路公司併發上萬的壓測。但是對於很多新型的mpp資料庫，他們的併發並不是你想的那樣，mpp一般由集群cpu物理核數有關。比如以前開發程式查詢的mysql，遷移到gp，那麼你的資料庫連線池要改一改了。特別是對於一些面向網際網路的**，資料庫管理層也要做訪問策略，不然，乙個外掛程式可能就會把你的庫搞死。
我們都知道索引在傳統的關係型資料庫中使用的很多，效果也很明顯。但是你要知道索引是拿儲存換時間的操作。曾遇到過開發人員動不動就讓建索引，搞的好像不要錢一樣。還有像vertica（適用olap場景）這個資料庫就比較友好了，不需要建立索引，只需要在建表時候預排序分布即可提高查詢效率，同時列儲存的資料還是壓縮的，降低了儲存，還提高了查詢效率。
資料庫作為儲存查詢引擎的同時，支撐著大型**的後台服務，一定要考慮高可用。對於一些天然不支援高可用或者高可用不友好的選型一定要小心。再來安利一下vertica，無master mpp架構，集群中只要不超過一半機器宕機（物理位置不相鄰），集群就處於可用狀態。
sql就是針對資料庫查詢產生的語言。隨著新型資料庫的出現，很多資料庫不支援標準sql或者支援很弱。比如hbase。這對於很多以前的開發人員還是有一定學習門檻的，還有就是後期如果出現業務遷移還是很困難的。
oracle支援標準sql，但是儲存過程並不是每個資料庫都有的，這也是阿里為何禁用儲存過程的吧，你無法想象乙個上萬行儲存過程的遷移要耗費多少資源。對標準sql的支援，降低了開發人員的使用門檻，也降低了以後業務遷移的風險。
我們會發現傳統的mysql資料庫對於併發聯機事務處理支援很好，但是隨著網際網路和物聯網發展，很多場景下無法單獨使用mysql做支撐，我們通常選引入大資料技術比如hbase輔助，或者搜尋引擎。在分析領域我們選擇hadoop和mpp資料庫作為支撐，效果也很好，但是越多的技術棧意味著越多的學習成本和風險。
聽過pingcap提出的htap架構。資料是系統架構的中心，但過去的系統通常都只能解決一部分場景的問題，在 oltp，olap，資料倉儲方面各有側重，現在終於走向更全能的 htap 架構，在一致性、可用性、可擴充套件性上取得平衡，充分利用雲的彈性供給能力和動態排程能力，並且降低運維成本和系統複雜性。
如果出現了一款資料庫能夠兩者兼顧，那必然是美好的。也許還會其他更好的方案，不管怎樣，我們會逐步看到更多以資料為中心的架構，更好應對業務和環境的複雜性，響應需求的變化，資料庫領域的未來還有許多探索空間~
那些關於程式設計師的段子
一 程式猿問科比 你為什麼這麼成功？科比 你知道洛杉磯凌晨四點是什麼樣子嗎？程式猿 知道，一般那個時候我還在寫 怎麼了？科比 額 二 女神 你能讓這個論壇的人都吵起來，我今晚就跟你走。程式猿 php語言是最好的語言！論壇炸鍋了，各種吵架。女神 服了你了，我們走吧，你想幹啥都行。程式猿 今天不行，我一...
作為PHP程式設計師應該了解MongoDB的五件事
2010年應該被人們記住，因為sql將在這一年死去。這一年關聯式資料庫行將就木，這一年開發者發現他們再不需要長時間辛苦的構造列或者 來存放資料。2010年將是文件型資料庫的起始年。儘管這樣的勢頭已經持續多年，現在才是乙個更多，更廣泛的文件型資料庫出現的年代。從基於雲計算的amazon到google，...
程式設計師面試 資料庫
1 有個表tableqq，有整型的id項和字元型別的nickname項，這兩個項都不允許為空 1 寫出建立該錶的sql語句 2 找出nickname為qq的使用者，按id降序排列的sql語句 3 寫出刪除id為1234使用者記錄的sql語句 4 寫出新增id為5555，nickname為 1234 ...