在什麼情況下你需要考慮換個資料庫了？

資料庫對公司業務至關重要，如果因業務發展需要更換資料庫需要考慮哪些方面？

業務系統為了獲得的良好水平擴展能力，都傾向於將業務服務無狀態化，將狀態存儲到資料庫中，這樣資料庫很多時候都是業務系統最核心的部分，所以換資料庫是一件需要謹慎決策事情。

但是，產生換資料庫這個念頭，是不需要做一個謹慎的決定，這還只是一個想法，可以先調研，小範圍試用，我覺得在下面兩個情況下，可以動動換資料庫的這個念頭：

1、資料庫技術上出現重大的變革

一般來說，都是業務推動技術變革，那其實也就說明瞭在出現技術變革的公司，一定是出現了新的業務場景用現在的技術不能很好解決，這個新的業務場景可能目前公司還沒有碰到，但是很可能在不久的將來會遇到。一個很好的例子，Google 在 2000 年前後碰到大數據的問題，然後推出了GFS、MapReduce 和 Bigtable 技術創新（其實也不是嚴格意義上的技術創新）來解決這一問題，在 Google 遇到大數據問題的時候，大部分公司應該還感知不強烈，但是在今天看來，大數據的浪潮又放過了誰？

所以，在技術出現重大變革的時候，我們需要去思考推動技術變革的業務需求是什麼，我們公司的業務以後會有出現這個業務需求嗎？

如果答案是肯定的，那麼可以動一動這個念頭，先調研，小範圍試用。這其實就是重要不緊急的事情，如果我們把它變成了重要緊急的事情，這其實就是技術方向把控上的錯誤。

對於資料庫來說，更是如此，它的業務差別比較小，一般都是比較共性的業務需求，所以如果資料庫技術出現重大的變革的時候，先調研，小範圍試用，是開放的技術思維，避免將重要不緊急的事情變成重要緊急的事情。

2、業務場景上出現重大的變化

業務場景上出現重大的變化的情況有很多，比如是公司的業務轉型，開拓出新的業務場景，用戶量快速增長，或者數據量快速增長等，一般對資料庫來說，如果業務場景對資料庫的 TPS 和數據量的要求提高，那麼這個時候需要考慮當前的資料庫能否滿足要求，或者考慮對於新的業務場景是否有更符合要求的資料庫。

其實，如果業務場景上已經出現重大變化的時候，才考慮這個問題，其實已經有點晚了，更好的方式應該是不斷對業務場景做趨勢預判，然後對適合將來業務場景的技術進行調研，小範圍試用，確保避免將重要不緊急的事情變成重要緊急的事情。

所以，上面兩個情況，本質上都是業務場景未來可能出現重大的變化，所以提前做技術積累，提前思考技術轉型，確保避免將重要不緊急的事情變成重要緊急的事情（重要的事情已經說了三遍）。

前面的部分，回答了什麼時候應該動換資料庫的念頭，然後進行調研和小範圍試用，這其實是比較輕鬆的部分，畢竟調研和小範圍的試用成本和風險都是很低的，如果要決策換一個資料庫，那將是一個艱難的決定，我們接下來來討論這一個問題。

不論是什麼技術選型，本質上還是在公司當前的業務場景、研發資源下，對新老技術方案在成本、效率和穩定性三方面進行評估和trade-off後決定的，資料庫是業務系統最關鍵的部分，同時還是業務是最底層的部分，並且是有狀態服務，不像無狀態服務可用很方便進行替換和回滾，所以，決策要不要換資料庫更是應該慎重。

技術選型，成本是非常關鍵的因素，比如阿里去 IOE 最關鍵的因素就是它。對於成本方面，我覺得需要考慮下面幾個方面的成本：

替換成本：

即替換資料庫的成本，包括資料庫替換過程中 DBA、基礎架構團隊和業務團隊投入的所有成本，包括：數據層面遷移的成本，業務層面遷移的成本，對新資料庫完全掌控的成本，對業務迭代影響的成本，相關配套工具的改造成本等等，這一部分是一次性的成本；

機器成本：

這個是最好計算的，通過性能參數和小範圍試用的情況就可以推斷出新老資料庫維持公司的業務正常運轉所需要的機器成本，所以也是最好比較的一部分，這一部分是長期成本；

效率評估同樣技術選型非常關鍵的部分，並且效率和成本很多情況下是可以相互轉換的，效率高一般來說人力成本會低，但是這一塊很容易被忽視，因為通過提供效率減低的人力成本很難被估計；另一個方面，有一些情況下的效率的提高是不能通過增加成本來完成的，這個「人月神話」闡述的很清楚了，特別是一些在關鍵點的情況下。所以，雖然效率和成本很多情況下是可以相互轉換，但是在效率和成本之間，應該優先考慮的是效率，因為一般來說，代表未來趨勢的技術，大多都是通過解決一些關鍵問題，極大提高了效率來完成技術更替的。

研發效率：

如果新的資料庫能更好地解決一些問題，能提高研發效率，那麼這個資料庫是非常值得考慮的，因為提高效率必然會減低成本，並且能提高產品的迭代速度，這是一個非常非常大的價值，特別是在一些競爭激烈的產品場景下，能提高產品的迭代速度，這將是一個巨大的優勢；

運維效率：

對於資料庫來說，運維效率的高低很大程度上取決於水平擴展能力，水平擴展能力越強的資料庫的運維效率越高，畢竟增加機器是簡單高效的事情，增加了機器還要去做資料庫遷移甚至重新做數據分佈是非常複雜和低效的事情，有時候甚至會影響產品的迭代速度，這個是無法接受的；

生態效率：

新老資料庫如果生態不同的話，這一部分也需要考慮，生態效率不僅需要考慮現在，也要考慮生態長期的發展，生態長期向好的資料庫，一般來說長期優勢是比較好的，並且可能很多需要的東西生態都提供了，這個是非常高效的事情，這個就是生態的紅利；

對於資料庫選型來說，穩定性是非常關鍵的部分，對於互聯網公司來說，數據纔是核心價值，不論因為資料庫導致的故障和資料庫丟失都是非常嚴重的問題，而且它的恢復時間和擴展時間比業務服務要長，更容易導致嚴重的故障。對於資料庫選型的穩定性方面的考慮，主要是下面兩個方面：

技術的成熟度：

一項技術的成熟度，要看當前的成熟度，這個代表它目前的水平，另外，我們也要看它的趨勢，比如進化速度，是否是代表未來技術的方向等等，比如目前同樣穩定的兩項技術，進化速度越快的技術，在未來很可能變得更穩定。

技術的掌控度：

對於一項技術來說，團隊的掌控程度越高，穩定性就越高，能否掌控這項技術，除了和團隊的技術水平相關外，還和社區的開放度、成熟度相關，這個需要綜合來考慮。

所以，「在什麼情況下你需要考慮換個資料庫了？」這個問題需要根據公司的業務場景、研發資源，對新老資料庫在成本、效率和穩定性三方面進行 trade-off 後決定的，需要具體問題具體分析，不過一定要注意的是，千萬要避免將重要不緊急的事情變成重要緊急的事情。

另外，提供一個參考，伴魚資料庫選型過程：https://zhuanlan.zhihu.com/p/164706527

當新任大boss說要換，

那纔是真正要換的時候。

先潑個冷水，換資料庫是傷筋動骨的，成本不大能夠升級硬體或者提高軟體性能能夠維持得了生活的話，還是不建議更換。

這裡面，永遠是成本和收益的問題。

要知道目前你遇到的問題是什麼、不更換的解決成本是多少，更換的解決成本是多少：

1、業務發展需要是業務邏輯複雜了？

哪些業務場景變的更加複雜了？把它一一列出來，這些場景是必須要更換資料庫才能解決麼？在現有條件下改造的成本是多少？更換資料庫業務代碼上的改造成本又是多少？

2、業務發展需要是業務量增加了？

未來幾年業務量估計會怎麼增長？按照現有資料庫提升硬體性能需要多少硬體成本？更換資料庫能夠減少多少硬體投資？

雖然很不情願說，還是要說一下不要被所謂的新技術洗腦，我認為大部分的公司，目前的主流資料庫，不管你用的是啥，基本上都能滿足業務需要。如果滿足不了需要，公司的研發能力、運維能力都要重新評估一下，有那個換資料庫的成本，不如多請幾個牛人。

好問題。

雖然廣告嫌疑很深，不過還是可以扯扯的……

等我去做個發布回來更新。

更新開始。

加錢好不好啊？

首先，一般情況下我建議先加錢。

加錢能解決的問題，請先加錢解決。

1C1G跑不動的，上1C2G；

2C4G跑不動的，上4C8G；

.....

反正，加錢就是。

扼殺一切在搖籃中

先從加錢的怪圈出來的話，

第一個考慮換一個資料庫的場景是：

寫下第一行代碼之前。

最美的開始永遠是還沒出發，

路上的泥濘也不會和你有什麼關係，

風大雨大也不會影響你的心情。

所以，在這個時間，

請隨便換，

想怎麼換就怎麼換。

莽上線是個好事情

然鵝再做一百次重新開始，

大部選擇我們還是一樣的：MySQL先莽上線再說。

要什麼SQL優化，

要什麼神奇的邏輯視圖，

要什麼牛逼的IOPS,

我們上線就一把梭....

黎明契機

一把梭完了之後，

居然我們的應用還活下來了，

居然用戶數和數據量還真漲起來了，

居然資料庫容量好像也有點大了。

這個時間點是不是可以開始搞事了？

是不是可以搞掂KPI項目玩玩了？

是不是追求極致的XX體驗啦？

要不？

yaobu?

Or Yes?

換個資料庫？

抱歉，我想做個好人

先容我提個問題：

究竟遇到了什麼樣的問題是當前資料庫方案解決不了的？

期待新方案解決哪些問題？真的可以解決嗎？

新方案是否會引入新的問題？是否完全有資源能把控新方案？

當我去嘗試回答這些問題的時候，

一切的思路是豁然開朗的。

叨叨叨叨到現在，

好像也沒聊到什麼時候需要換資料庫了。

最後結合最近的項目來聊聊吧。

某租房信息網，數據落地一直都在MySQL，

不斷在不同場景使用不同的資料庫來滿足需求。

從1C1G自建服務，爬蟲寫入同時實時查詢跑滿CPU導致不可用；

到後來定期寫入，查詢結構加Redis緩存完全支撐起訪問量。

從MySQL Like搜索「慢查詢」拖慢性能，

到犧牲實時性使用ES 搜索引擎支持搜索需求，支持起早期關鍵字查詢。

從資料庫業務分表分散數據支撐起幾百萬房源信息，

到直接根據城市劃分MongoDB 集合表，離散化存儲後支持更舒服的性能要求。

到了今天，

大部分情況直接走Redis緩存，

實時查詢落到MongoDB，

落地數據在MySQL中，

基本就是當前我的資料庫選擇方案。

至於其他的，

暫時還是要什麼自行車的。

目前的庫不合適，而且新換的庫有理論和實踐支撐，不要盲目的換。

1、硬體+資料庫擴容無法解決，或者者硬體+資料庫擴容成本奇高的場景

2、原資料庫+分散式緩存仍然解決不了

3、原資料庫+新增資料庫共存仍然無法解決問題的時候

一般是資料庫技術出現關鍵技術的重大更新，某些功能通過新的資料庫實現可以減少很多開發量，例如分散式事務這樣的，會考慮在新的微服務系統或者新的項目使用這個新資料庫先試試，如果穩定奔放，則大面積切換使用

當前資料庫已到達瓶頸或者雖然滿足當前及未來的需要，但成本過高時會考慮更換

更換資料庫會考慮投入的硬體成本，時間成本，人力成本以及運維成本，現有團隊是否熟悉新的資料庫，相關dba是否好招聘，是否主流資料庫，資料庫是否有穩定的維護團隊

1. 功能是否滿足業務需求

2. 性能是否達到預期

3. 穩定性

4. 社區活躍度，生態

5. 易用性

6. 成本

7. 技術積累

持久化存儲的話主要考慮數據量