少即是多--資料架構之我見

自己原文公眾號： https://mp.weixin.qq.com/s/2uMMrT5RO0vabXWtkDsxGw

1870年9月6日，英國皇家海軍鐵甲艦“船長”號，在第一次航行中就遇到風暴而沉沒，船上473人喪命。

這艘軍艦為什麼這麼弱不禁風呢？

事故調查發現：首先，“船長”號以蒸汽機作為動力，又畫蛇添足地安裝了風帆桅杆;其次，工人們在造艦時唯恐用料不足，大多數零件的重量超出設計標準，導致完工的軍艦整體重量比設計重量多出了747噸;最後，兩門旋轉炮塔導致軍艦上部過重，重心上移，穩定性欠佳。遇到風暴，這艘號稱當時最先進的鐵甲艦就這麼沉沒了。

從此以後，炮塔鐵甲艦都取消了風帆裝置，只保留一根軍用桅杆用來發訊號、打旗語。每一個零件的重量都必須符合設計要求，安裝的每一步都必須符合圖紙的規定。因為血的教訓告訴我們：複雜和多並不意味著完美，反而是隱患。

     有一句話說得好：“如無必要，勿增實體。”意思是說：“切勿浪費較多東西去做，用較少的東西，同樣可以做好的事情。”

    我見過一個廠家設計了一套系統有三臺機器ABC。

   A上安裝clickhouse、B上安裝clickhouse、C上安裝clickhouse其實就是clickhouse的叢集。

    同時A上安裝kafka、B上安裝kafka、C上安裝kafka，其實也就是kafka的叢集。

     同時A上安裝mongodb、B上安裝mongodb、C上安裝mongodb。其實也就是mongodb的叢集。

     以上操作看明白了嗎？就是3套資料庫和中介軟體都是分散式的安裝在3臺機器上。每個上面都有3樣，我當時看不明白了。就問為什麼要這樣設計？答案是說寫入資料要寫入mongodb，然後要寫入分析的列式資料庫clickhouse。那為什麼要加個訊息佇列呢？說是怕寫入來不及。其實我對此是大跌眼鏡的。一般來說資料庫的寫入瓶頸在IO。我們先不說有沒有那麼大的量。一般來說99.99%的系統寫入都不是問題。問題主要是讀。那麼假設他真的出現來不及寫（恭喜你業務已經是全國第一梯隊的了），那麼這個時候每臺機器上都是mongodb、kafka和clickhouse在競爭，這好的了嗎？

    而且還要考慮一下，寫入訊息佇列一次消耗，在讀取一次，有一次消耗，最後還是要寫到資料庫（clickhouse），比起直接寫還多了兩次操作，和多了一個環節。（很多訊息佇列是一次寫多次讀也就算了，還算是用在正道上）。每個都是好東西，放在一起，怎麼就覺得那麼彆扭呢？

    以上如果是我的話直接寫入clickhouse就行了。我見過太多的都是為了用而用，浪費不說，還增加了複雜度。花架子太多，華而不實。據我所知，財付通2005年單機MySQL4.1 每天10萬筆交易。現如今有多少公司用的是MySQL8、Oracle19C、PostgreSQL13，還是叢集。還遠沒有到這個業務量。