本次分享主要有三個大的方向，一是從職業規劃的角度看爲什麼我會認爲數據庫選型很重要，第二個方向會根據這些經驗說說選型的基本原則是什麼，最後總結一下這些年數據庫選型的路線圖，希望能對大家以後做數據庫選型時有幫助，可以根據你們公司的場景進行套用，當然這不一定適合所有場景，主要還是提供思路以方便大家借鑑。
一、從職業發展看選型
DBA這個行業有很多年了，隨着時間的變化職業規劃也有着不同的變化。我放了一張DB-Engine的圖，這是DB的排名，前三的就不說了，老三位沒什麼可聊的。但是看下面的排名，除了常見的數據庫，還有ES、HBase、Neo4j這些我們之前不太認爲是DBA管理範疇內的DB。
我經常跟團隊小夥伴說咱們DBA的思維不要光侷限於前面的老三位或者TOP5，我們是不是可以考慮到更多的數據庫也是DBA可以從事的行業。比如你可不可以做HBase？你可不可以管理ES？這些東西都體現在這張表裏，我們可以擴展自己職業的領域，這也是職業發展方向的一種橫向擴展方式。
這張圖是我對比去年和今年變化的展示圖，去年關係型數據庫（藍色部分）佔了半壁江山，今年關係型數據庫仍然是第一，但是已經有很多份額被多用途的數據庫佔去了。
多用途數據庫是廠商選擇的趨勢，他們研發了越來越多支持多用途的數據庫。廠商爲什麼會這麼做？供給側的改變來源於需求側，因爲有很多需求已經不是單一的數據庫能解決的了。
在這種場景下，廠商迫於這種需求開發了很多能適應更多場景的數據庫。這種趨勢對DBA來說意味着什麼？這提醒我們，對多種數據庫的掌握是現在這個時代對DBA的要求。
這是一個必然的發展趨勢，因爲你要解決的場景會越來越多，你需要掌握的數據庫領域也越來越廣，這就意味着之前「一招鮮」的玩法已經落伍了。
我們再看現在崗位的設置，往前其實是純自建時代，現在的時代是雲時代，這兩個時代有着本質的區別。
自建時代的DBA更多意義上是運維領域區分出來的一個更專業、門檻更高的職業領域，再往前都沒有DBA，都是Ops管理的。後來出現DBA，再慢慢演化到DBA做一些細分，出現了開發DBA、內核DBA，還有部分同學轉去專門做大數據，這就是在自建時代的整個狀態。
但是雲時代會有一些什麼樣的變化呢？其實自建時代的傳統DBA現在還存在，因爲有混合雲的存在。那麼變化是什麼？是無論如何都不可能完全不談雲，一旦上雲，自有的運維體系受到衝擊是其次，主要還是業務可以選擇的服務就多起來了。之前由於基礎設施導致需要業務適配數據庫的情況就會變成需要DBA掌握更多的數據庫類型來滿足業務了。
更有甚者是有的公司已經全部上雲了，之前賴以生存的工作都變成了雲服務，這時候的DBA要做什麼轉變？最後還有一種變化是雲內DBA，作爲雲公司的DBA，孵化一個產品和提供對內服務又完全不是一回事。未來基本上我認爲DBA就是這三個領域裏面打轉了（混合雲DBA、雲上DBA和雲內DBA），但是無論哪種都需要掌握更多的數據庫，這個是不變的。
綜上，這個時代對DBA的要求就是需要掌握的數據庫領域越來越多的，甭管你是在哪個線上的，都需要懂很多領域，至少精通一種，掌握N多種，這是我這次演講想傳遞給大家的一個概念。
二、選型原則一二三
原則1：不講場景的選型都是耍流氓
在座做過數據庫選型相關工作的都知道場景很重要，但不是所有人都能把這個概念深入到骨子裏。比如這個場景，我相信大家應該都有實際經歷過。
你的用戶對數據庫的瞭解是沒有DBA熟的，他的出發點跟你的出發點是不一樣的，你想要的是長治久安，他想要的是把功能搞定。
如果你要做業務選型一定要對場景進行劃分，如日誌類、搜索類、離線需求等等，這些全部要跟線上分別開。業務模型是怎麼樣的？活動型還是規律型的，你是多讀還是寫多的？然後數據增長方式是怎樣的，不能光滿足上線一剎那的需求，業務增長是日期型的還是用戶型的、位置型的？這些都需要跟你和業務聊清楚了，如果問不清楚，後期就面臨一個最嚴重的問題：數據遷移。而數據遷移本身就可以成爲一個主題，這就意味着這個事情會花費巨大的成本，如果能從初期就避免掉儘量從初期避免。
原則2：沒有數據就沒得聊
沒法度量的東西就沒法管，放在數據領域一樣，沒有數據就沒法談。
這是一個場景，你找業務聊天的時候一問三不知，經常會遇到，業務也確實沒有辦法。但我想說的是我們一定要讓業務方拍出來的一個數據，因爲我們所有的決策都是基於這些數據的，沒有數據就沒法決策。
另外也期望可以讓整個業務鏈條的同學養成有數據的習慣，評估多了自然就能積攢下來一些方法論來解決「拍數」的問題。這其中關鍵的幾個點，也是最後選型圖上關鍵的點，一個是size，第二個是qps，還有一個是rt。
另外我們還需要提供一些基準數據。什麼叫基準數據，像剛纔那個場景，你問業務，他一問三不知，還有一種情況是業務問你MySQL能扛多久，你說我也不知道，咱們先跑再說，這肯定是不行的。
你如果管理一個類型的數據庫一定要對自己的東西有一個非常基準的認知，這個場景來了，我是給他做一主兩從還是分佈式，要不要上來就千庫萬表，還是用分區表等等，這些都一定要門清的。
最後有一個tips，評估是可以類比，只要邏輯說得通就行。來了一個需求你也說不清楚到底是多大量，你就看之前這個部門做沒做過類似的活動，是在什麼時間點做的，它跟你這個是什麼樣的邏輯，是否是近似的邏輯，如果是近似的邏輯我們就往上套。比如上次熱點事件的峯值是多少，如果這個產品功能也可能和熱點頁面相關聯，那麼就按照上次熱點事件的峯值進行對應的預估也算是符合邏輯的。
這裏給大家展示一下基準測試，這是我們在做混合雲運維解決方案時做的測試，因爲我們需要用多家廠商的數據，需要門兒清，我把這個服務部署到那家雲上性能到底有什麼樣的波動，也方便業務方對業務有更直觀的理解和認知。
原則3：不考慮可運維性的都應該槍斃
最後一個原則跟前兩個區別比較大，前兩個原則基本都是知道的，但是難在落地。第三個原則其實很多DBA也不太關注，但真的是很重要的一個原則，那就是可運維性。
我開始說了，DBA跟業務方評估不一樣，你的KPI也不一樣，需求的點也不一樣，業務要求上線，你要求可運維性，這關係到你的幸福度，關係到你的起夜率。如圖的這個例子就很經典，業務和DBA雙方根本沒有在一個頻道上溝通，最後只可能是不歡而散。
我認爲的可運維性是什麼？有四個方面：
一個是社區活躍度，社區活躍度決定着你獲取信息的難易程度。獲得信息的難易程度決定了什麼？關係到你出現了故障的定位速度甚至是能不能定位出來，如果社區很活躍，自然就能得到更多的幫助。
第二個是有沒有USER CASE，最好是自己認識的人，因爲眼見爲實，耳聽爲虛，認識的人往往能告訴你一些真實的「坑」，而不是宣傳用的「功能」。
第三個是自身團隊的情況、上手成本。你這個團隊有多大，團隊具備了什麼樣技術儲備？畢竟你開闢一個新的戰場，每一種數據庫都不是這麼簡單的，可能三四個人都不見的搞得定，但是實際業務到底使用多少卻說不清楚，這就很麻煩了。
最後一個是很隱性的事情，所謂的市場人才情況，這是可持續的成本。你如果選擇了一種數據庫，但如果市場對應的人才很少，那麼一旦出現人員流失，就會讓這種數據庫處於無人維護的情況，這對於公司來說是絕對不允許發生的事情。
三、選型路線圖
最後給大家聊一下選型路線圖，如果你沒有一個專門的DBA團隊，雲就是最好的選型，沒有了。至於這幾家之間他們到底誰好，我認爲根據投資關係選更合適一點，至於原因你懂的。
再講講這個技術選型路線圖，這是我根據這麼多年團隊經驗做的一個選型路線圖：
首先一定要做場景分析，到底是線上業務、離線業務還是統計類業務必須分出來，如果是離線的那麼走hadoop生態，如果是統計監控類的可以走專門的時序數據庫或者ES等，即使不走也要嚴格和線上的區分。
然後是線上，特殊需求走特殊的數據庫更合適，如果是一個純粹線上TOC端的產品需求，我們需要進行QPS的判斷。如果是中低的QS那往下面走，根據size來判斷擴展性，如果有高擴展需求那麼選目前比較火的分佈式數據庫是個好選擇，如果不高，那麼再往下看SQL複雜程度，一般簡單的互聯網應用MySQL足以，如果是用了很多存儲過程或者複雜大查詢的，那麼PG更適合一些。
返回剛纔的分叉，如果QPS高的話，那麼基本就是kv數據庫的天下了，我們需要先根據size來判斷，如果可控那麼純內存的kv數據庫是最佳選擇。接下來是基於RT的判斷，如果size也大、rt要求也高，那就只有分佈式內存kv數據庫（RedisCluster）選，如果對於rt要求不那麼高，那麼Pika/Aerospike都是比較好的節省成本的選擇。
最後說一下我們目前的最佳實踐，我們目前常規需求都使用MySQL+Cache的方案解決，特殊需求交給雲RDS去解決（比如PG、MongoDB等），並且選擇了一種HTAP的分佈式數據庫來解決擴展性問題。
Q & A
Q：現在所謂的雲原生DB比較流行，但是我們目前還沒有使用到。一些宣傳上說雲原生DB是可以擴展的，並且和傳統數據庫也是類似的，我想問一下對於傳統數據庫來說它的不足在哪裏？
A：這個不足點就是它要求升高了，分佈式數據庫的門檻變高了，對業務來說，在功能、擴展性上它現在是全面是超過了傳統的數據庫。但是對於DBA的要求來說，有非常高的門檻，這對我們之前的問題分析、調優、故障定位思路都會有很大的衝擊。
作者介紹：
肖鵬，前新浪微博研發中心技術副總監，主要負責微博數據庫（MySQL、Reids、HBase、Memcached）相關的業務保障、性能優化、架構設計，以及周邊的自動化系統建設。經歷了微博數據庫各個階段的架構改造，包括服務保障及SLA體系建設、微博多機房部署、微博平臺化改造等項目。10年互聯網數據庫架構和管理經驗，專注於數據庫的高性能和高可用技術保障方向。
本文由 dbaplus 社羣授權轉載。
原文鏈接：