資料庫應有與之匹配的基礎環境

      前幾天在一個群裡看到大家討論硬體。大佬說：現在誰還共享池總出問題？（早期因為資源不足，SQL爛一點的話會造成爭用），現在隨隨便便都是1T的記憶體，哪裡會有共享池問題？其他人也說自己是128G記憶體起。有人也說之前看Oracle要那麼大記憶體，感覺太誇張，隨便上百G，現在看國產。這麼一筆下來，Oracle真節約。

    對於以上問題，我第一個說我有時候還遇到共享池問題。因為我好多年沒見過100G以上的機器了。早些年，我用64G的機器處理幾十億級別資料的時候也過來了。那時候是開發素質高，每個場景都是精心設計的。開發都是70後和80後。那時候入職面試還要考演算法，資料庫是必考。現在開發面試只有大廠才會考這些吧？因為一個無知的開發上去真的會把資料庫搞死，然後直接導致系統故障，進而影響該公司的股價。我以前公司有個開發，我對他說你這樣寫不行。開始他不以為然，後來估計出去面試了一些好的公司，別人問的都不是那種假大空的問題，而是切切實實的基礎問題。比如鎖、併發等等。如果透過現象看本質，其實開發還是基於資料庫開發，讀取資料，其他的佔比不大。所以他後來認識到了，開始轉變，不在務虛，而是實實在在的看問題的本質。不過有這種認識的人太少了。

    現在普遍一上來就是框架的，結果SQL奇差無比。在這種基因環境中，再配上較低的資料庫，那就是經常伴隨著這些問題。不同的資料庫機制不同，但是記憶體大的在記憶體競爭上總是會緩解的。就像一家人很富有，一個人一套房子（不是每人一間而是一套），這種代溝也好，矛盾衝突也好，都減弱。另外一家10個人，在20平米房間，上個廁所都排隊，能沒矛盾嗎？除非大家都是君子，素質很高。問題是這個前提條件不成立，因為本段開頭寫了都是奇差無比的。

   我從離開公安行業以後依稀見過一些用物理機的公司，有跑DB2的，有跑Oracle的，也有跑MySQL的。基本來說穩如泰山，到不是說他們開發寫的多好，而是物理機的大記憶體，裝載了更多資料，避免了磁碟讀。而物理機的處理能力抵消了爛SQL帶來的衝擊。反觀我也建立不少在虛擬機器上執行Oracle和MySQL、PG的。這些就時不時的和你解悶一下。究其原因就是基礎環境差配上爛程式碼。改造爛程式碼其實不容易，但是改造基礎環境相對容易一些。找高水平的開發的成本遠高於買好的硬體的成本。我想起我2017年看到的一款伺服器150T的NVme，這個來存放公司的資料，（可能有的公司說放不下，他們公司資料多）我覺得放得下的公司遠比放不下的公司多。我沒有這個伺服器配置的價格，我估計不會超過50萬吧？找個好點的開發每年不止50萬的成本吧？

      另外一個錯誤的認知，我發現很難改變，就是非資料庫領域的人已經被帶偏了。就是虛擬化鼓吹的漂移。首先漂移是好的，但是去飄無狀態的，比如tomcat等，這種甚至做到docker中我其實都沒意見。但是有狀態的資料庫沒必要，也不能飄。資料庫遇到問題重啟就好了，為了一致性重啟會做redo和undo這不是漂移去解決的也解決不了。我還被經常問到，那壞了怎麼辦？一般來說不會壞。萬一極端，這不是有高可用嗎？ Oracle RAC只有一個節點好就行。不用飄。  MySQL  MGR只有一個節點好就行，不用飄。PG的叢集沒做過，但是主從切換一下就好，不用飄。redis的cluster，es mongo這些分片的半數只有半數以上或者，不用飄。見過hadoop飄嗎？多副本就是幹這個用的，沒必要。而虛擬化上做資料庫不會給一個很高的配置，因為不利於漂移。也不利於虛擬化自身。

   所以當系統中發現幾個tomcat的總資源大於資料庫，或者說任意一個tomcat的資源等於資料庫，其實就意味著這個系統中資料庫的地位比較低下，那麼日後出於資料庫相關的問題就比較多。作為系統的中樞核心被輕視，後果比較嚴重。

    資料庫用物理機，最佳實踐。高可用用資料庫自身的，不推薦用虛擬化層來解決資料庫的容災，這樣是為了小機率容災，而限制了日常的使用。 仔細想想Oracle、阿里、騰訊、華為都出資料庫一體機是有道理的。