您好,登錄后才能下訂單哦!
由于微服務技術發展迅猛,在我們的架構中,每個微服務都會相應的對接一個數據庫,各個數據庫之間有關聯的表(比如用戶表、業務表等)會互相同步數據,其他的數據操作各自獨立(如日志表、操作表等),這么設計是基于性能考慮降低數據庫容量及盡最大努力避免性能遭遇瓶頸。這么設計對于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操作在代碼層面進行開發,但是,這樣的代碼可讀性有多強?另外就代碼審查來說,也不會讓你這么寫,萬一某一天你甩鍋離職了,這天花亂墜的代碼,誰受得了?
不過嘛,辦法總比困難多的——視圖。利用視圖,我們可以非常簡單的實現這樣的跨庫查詢的需求。我們知道所謂視圖,其實就是存儲的查詢語句,當調用的時候,產生結果集,視圖充當的是虛擬表的角色。因此:
一開始我也是被我這個想法驚訝到了,總覺得跨庫建視圖太過于驚悚了,畢竟實踐是檢驗真理的唯一標準嘛,隨手就在navicat上面建立一個視圖,之后運行
非常神奇~~那問題這樣就解決啦,還是一條SQL語句就可以解決問題了
通過這個思路,其實可以繼續推廣:跨表聯查,建個視圖,跨庫聯查,建個視圖。建就完事了。另外這個操作其實還需要考慮數據同步的問題,因為是多庫聯查,如果數據不一致會是災難的,這個具體問題要具體分析,加鎖或者配置同步策略這些都是常規方案,由于我沒有這個需求,就不展開討論啦。
這個案例對我來說很有感觸
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。