資料架構之我見

  https://mp.weixin.qq.com/s/SXmnkpRKlhQxRp8oxueZ5A

公眾號原文

可能有些朋友聽過系統架構但是未必聽過資料架構。其實架構是圍繞著資料庫而展開的。我們 舉幾個例子：

1、如果一個系統就一個資料庫（沒有資料庫的系統幾乎沒見過，至少有要一個吧），那麼這個架構複雜不到哪裡去。

2、如果一個系統有多個資料庫（這裡 指的是同構的資料庫），那麼這些資料庫如果全部都是獨立的，那麼就是煙囪架構。

3、如果一個系統有多個資料庫（這裡還是同構資料庫），這些資料庫之間有相互關係的，那麼這就是微服務架構或者中臺架構。

4、如果一個系統有多個資料庫（這裡是異構資料庫），那麼就是複雜多了。涉及到了異構資料庫之間的資料同步、涉及到了關係型和非關聯式資料庫之間的互動、涉及到了NoSQL的快取、分片、節點、分散式這些聽起來可以唬人的，其實大同小異的概念。

5、如果又覺這麼多同構異構資料庫分的太多了，要統籌查詢，這裡就要把這些資料進行集中到一個平臺上來進行查詢和分析。這就是大資料。

      以前套用三國演義的一句話分久必合合久必分。

     分是因為資料量多了加上最佳化到極致硬體還是處理不了，就分。20年前的硬體處理TB級別的資料就差不多了。PB級別的處理不了。

     合是因為分的實在太開了，使用起來非常不方便，必須合在一起，分的代價比合在一起還要大。現在的PC伺服器和20年前的小型機比起來，屬於一個級別的。

      有一次幫別人參加一個會議，主題是架構評審。當時問題是用了MySQL的主從架構，設計的是一個事務寫的操作在主庫，讀的操作在從庫。遇到了較大的問題，說白了這樣做幾乎不可能達到他們想要的效果。別說MySQL，其他的資料庫也沒有這樣做的。其他資料庫的架構上都沒有說一個節點上的寫和其他節點上的讀有一致性的。當然強一致的可以，比如Oracle的RAC和MySQL的MGR等等吧，我就不一一列舉了。

     我們別說現在主庫上執行的SQL有好幾秒，就是主庫上執行10ms，從庫接收和執行也要幾個ms，不能做到實時。真正應該做的讀寫分離是，事務內的讀寫都在主庫，而報表、運維之類的讀在從庫。而不是事務跨主從讀寫。

     不少人還是擔心全部在主庫壓力承受不了。其實大可不必擔心，我拿一個資料2005年財付通一天10萬筆交易，用的是MySQL4的單機。今天我估計大部分企業的交易沒有達到一天10萬筆。如果有這個擔心，我們就把表設計好、SQL寫好、實現邏輯寫好。那麼絕大部分問題都解決了。

    天龍八部掃地僧說：少林絕技每一項都可以致人於死地，所以每一項都要相應的佛法來化解。只有佛法越高深、慈悲之心越高的高僧才能練習這些絕技，否則內在修為達不到，強行運功，早晚有一天會走火入魔。最後傷及五臟六腑，性命不保。而佛法達到一定程度的人，反而不屑於學習更多的絕技。

    其實經歷過強壓和高併發的人知道，真正的絕殺一定是簡單、簡單再簡單。越複雜的越難以高併發。每次遇到不停的擴充套件機器、分庫分表、以及引入各種快取、中介軟體、訊息佇列、流式計算、大資料等等就發現其實根本沒發現問題的本質。即使這樣以後發現實時性和一致性都不能保證。