效能問題往往出現在開發人員可控範圍之外

關於資料庫的應用，總有兩派觀點，一派是資料庫要那麼強的能力幹嘛，資料庫的問題都可以透過應用來解決，系統效能不行，肯定是應用沒開發好。而另外一派則是資料庫太垃圾，應用跑起來就太費勁，一定要選一款強大的資料庫來支撐應用，資料庫不行，所以系統就慢。實際上從各自的角度來說，這兩者都沒錯，二者不能相互理解，那是因為二者面臨的實際情況不同。今天一早就在高鐵上，就簡單聊幾句這個問題吧。

我對上面這個問題的看法是，應用的效能問題往往出在應用開發團隊能力可控制的範圍之外，當系統的複雜性對於研發團隊來說是可控的情況下，系統效能問題也是可控的;而當系統的複雜性超出了研發團隊的可控範圍的時候，效能問題必然會變得複雜。也就是說開發團隊的能力與特點決定了資料庫應用的基本面。因此不同的人有不同的觀點就十分正常了，這是各自認知的世界以及對這個世界的立場和觀點不同決定的。

用這個觀點來分析全面的二者的時候，可以如此解釋，前者的能力能夠把控應用當前的複雜度，因此他們不需要藉助資料庫的能力就能解決應用中的複雜性問題。而當系統複雜度，負載等持續增加，有一天超出團隊能力的時候，他們也會發現他們可能需要選擇能力更強的資料庫來支撐他們了。這一點最近在一些做實時數倉應用的團隊中經常遇到。在選型的時候覺得hudi不錯，而用了一段時間發現，某些hudi不太強的地方Drois其實也不錯。實際上大多數開源專案都不一定能夠完美的契合我們的應用，這時候我們必須透過自己的應用來適配這些開源產品。商用產品則在這方面好一些，因為商業利益驅動了廠家不斷地去滿足多樣化的使用者的需求。

前些年有個使用者和我說，自從他們把資料庫從 Oracle 遷移到雲上的 RDS MYSQL，他發現他們的研發團隊水平太差了，因此這些年他重點抓研發團隊的能力提升，也用重金聘請了一些在MySQL開發上水平較高的架構師加入他們。隨著開發團隊能力的提升，現在他們已經能夠應對雲上RDS出現的各種問題了。

另外一個例子也是從ORACLE向RDS MYSQL遷移，使用者以前的核心繫統都在ORACLE上，經常出問題，經常需要對應用與資料庫進行最佳化，即使如此，系統故障，當機等現象還是無法杜絕。這些年企業推進系統上雲，很多新建系統都用了雲上的RDS。RDS使用起來很方便，系統上線後運維也挺方便的，因為RDS上跑的系統都不大，所以也沒有遇到什麼執行上的問題。於是企業的IT部門領導認為RDS是比ORACLE更好的資料庫解決方案，推進把一些較為複雜的關鍵系統也向RDS MYSQL遷移。不幸的是，他們的研發隊伍還是當年把ORACLE都用得經常出問題的那幫人，對業務很熟悉，但是SQL寫得很隨意。當一些稍微複雜一點的系統被遷移到雲上後，他們發現原來使用Oracle的時候系統存在的問題依然存在，甚至系統的效能問題更嚴重。這下子麻煩大了，以前使用傳統架構的時候，最佳化SQL、最佳化資料庫還是有套路的，上雲後，以前的最佳化套路也失效了。他們被一個新的，更難解決的問題完全困住了。

能不能把應用搞好，研發團隊的技術水平十分關鍵，研發能否把控系統的複雜度，是否瞭解底層基礎設施，很好的掌握與利用資料庫等的特性，也十分關鍵。今天我要表達的觀點是，比起研發隊伍的能力來說，IT主管部門領導對自己研發團隊的能力邊界的認知更為重要。如果不瞭解自己的能力邊界，盲目的推行某些技術路線，選型資料庫產品，對於一個組織來說是十分危險的。