數據庫跨庫查詢

因爲微服務技術發展迅猛，在咱們的架構中，每一個微服務都會相應的對接一個數據庫，各個數據庫之間有關聯的表(好比用戶表、業務表等)會互相同步數據，其餘的數據操做各自獨立(如日誌表、操做表等)，這麼設計是基於性能考慮下降數據庫容量及盡最大努力避免性能遭遇瓶頸。這麼設計對於container來講確實是極友好的，在平常運維中，好比每個月/季度的數據彙總就難受了，身爲DBA，處理跨表查詢應該是小case，然而在hibernate跨表查詢中，雖然麻煩但仍是啃一下仍是能夠解決的。然而最近接到的需求倒是要，跨！庫！聯！查！
我在想微服務的背景下，跨庫查詢應該是新常態

單庫時，系統中不少列表和詳情頁所需數據能夠簡單經過SQL join關聯表查詢；然而多庫狀況下，數據可能分佈在不一樣的節點/實例上，不能跨庫使用join，此時join帶來的問題就很棘手了。

咱們在開發過程當中，鏈接數據庫一個鏈接也是隻能連一個數據庫這個是常規操做，例如

db1 = pymysql.connect("11.22.33.44", "yerik", "mimajiubiekanla", "shujukuming1", port=3306)

若是咱們要查詢另外一個數據庫呢？不就要，再創建一個鏈接嘛

db2 = pymysql.connect("55.66.77.88", "yerik", "mimajiubiekanla", "shujukuming2", port=3306)

這個怎麼可能用join操做，可能有讀者想要槓一下，說，能夠經過xx操做在代碼層面進行開發，可是，這樣的代碼可讀性有多強？另外就代碼審查來講，也不會讓你這麼寫，萬一某一天你甩鍋離職了，這天花亂墜的代碼，誰受得了？
不過嘛，辦法總比困難多的——視圖。利用視圖，咱們能夠很是簡單的實現這樣的跨庫查詢的需求。咱們知道所謂視圖，其實就是存儲的查詢語句，當調用的時候，產生結果集，視圖充當的是虛擬表的角色。所以：

• 若是要對一張表或者多張表進行查詢,能夠經過寫複雜的SQL語句來實現
• 若是要這些SQL語句存儲爲視圖,那麼查詢的時候,就直接查詢這個視圖就能夠了

一開始我也是被我這個想法驚訝到了，總以爲跨庫建視圖太過於驚悚了，畢竟實踐是檢驗真理的惟一標準嘛，隨手就在navicat上面創建一個視圖，以後運行

很是神奇~~那問題這樣就解決啦，仍是一條SQL語句就能夠解決問題了

經過這個思路，其實能夠繼續推廣：跨表聯查，建個視圖，跨庫聯查，建個視圖。建就完事了。另外這個操做其實還須要考慮數據同步的問題，由於是多庫聯查，若是數據不一致會是災難的，這個具體問題要具體分析，加鎖或者配置同步策略這些都是常規方案，因爲我沒有這個需求，就不展開討論啦。

這個案例對我來講頗有感觸

1. 所謂運維開發，就是在運維過程當中提供開發思路，原先一味的代碼開發，遇到這樣的多庫查詢簡直想要與原地爆炸，藉助這個思路，多庫查詢就變成了單表查詢
2. 咱們的架構基於jhipster進行開發，要對數據庫操做須要經過jpa調用hibernate。這個是常規思路，可是爲了敏捷開發，一個web服務，我使用django進行開發，直接一條sql就完事了，查詢結果經過整理在一份csv文件中，經過郵件發送給用戶
3. 敏捷開發也不過如此吧，這個小插件的開發，從需求確認到服務上線也就4個鐘，可是因爲簡潔，一直服務着，也沒發生啥故障，也給運維省了工做量