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

xuexiaogang發表於2021-12-11

自己原文公眾號: 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,還是叢集。還遠沒有到這個業務量。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/637517/viewspace-2847147/,如需轉載,請註明出處,否則將追究法律責任。

相關文章