第六章節： 關於 partition 的 join - Jay

[at7211]

這一章節感覺是比較 high level 的大致探討 partition 會遇到的 issue，先分享這篇，更實務的探討 partition 在 RDBMS 的狀況以及解決方案。

裡面有提到我蠻有興趣知道的一點，若是應用層想針對跨資料庫做 join 會如何

問題 2 : Join 如何處理呢 ?
在分庫以後，基本上有以下幾種方法解決 :

不要用 : 自行在應用層抓一抓你要的資料，然後拼裝超來。
一點點的反正規化 : 也就是說在設計表時，會多加一些欄位，例如訂單與用戶這樣的組合，有可能會在訂單這個分庫的資訊上，多儲放一些用戶的資訊，這樣就不需要使用到 join。
統一透過中間件處理 : 有一些中間件軟體會提供多庫 join 的操作，以 mycat 來看它有提供，不過只提供兩層的 join，這個地方在之後 mycat 的文章中會提。
這裡是比較建議分庫後儘量不要用 join，因為坑會有點大，而且你儘然分庫了，你還很常需要 join，那是不是要想想，分庫的規則有問題了呢 ?

想知道大家有實際碰到應用層下需要跨資料庫做 join 的問題嗎？

[kylemocode]

未點先猜馬克大

[Parkerhiphop]

資料量過大，就會直接不 Join，有效能問題就加機器，不要把效能壓在 DB 上。 Query 時直接一個個拉 Table 然後在 Application Layer 組。 （資料量太小，效能就會很差）

Foreign Key 太多寫入很慢。

但如果都是 Application Layer 做的話， RDBMS 的意義？

• 懸而未解
• 業界很多這樣做
• （也可能是單純 MongoDB 不好用之類的）

跨 DB Join 也挺常用幻讀的

[at7211]

@Parkerhiphop 這邊筆記應該更正一下， 幻讀算是跨 DB join 會遇到的 issue