資料庫中介軟體為何不支援join，中介軟體不支援join

資料庫中介軟體為何不支援join，中介軟體不支援join

有網友對《假如讓你來設計資料庫中介軟體》一文中，資料庫中介軟體僅僅支援四類SQL存有疑問：

• partition key普通查詢

• partition key上的IN查詢

• 非partition key上的查詢

• 有限功能的排序+分頁查詢

這四類SQL就能滿足公司業務的需求麼，這個結論是怎麼來的？

看來《假如讓你來設計資料庫中介軟體》的架構結論並不能讓刨根究底的網友們滿意，於是把13年底，需求調研的過程細節也說一說，作為一個一線架構師，治學還是得嚴謹。

 

一、業務側的分庫後SQL需求

先說結論，通過初步的調研，發現58各業務線對有分庫需求的應用情境為：

• partition key上的簡單查詢

  WHERE key=xxx AND xxx

• partition key上的IN查詢

  WHERE key IN(xxx, yyy) AND xxx

• 非partition key上的簡單查詢

  WHERE notkey=xxx AND xxx

• 排序+分頁的需求

  ORDER BY xxx OFFSET xxx LIMIT xxx

大部分需求集中在前三條，排序+分頁的需求由於分布式實現困難，各業務線往往也採用了一些限制或者變通手段實現，例如：

• 建立索引表以避免遍曆庫再內部排序

• 使用額外的id查詢條件來避免大資料量的查詢

 

調研結果顯示，各業務線暫沒有下列需求：

• 誇庫join

• 誇庫事務

• 誇庫子查詢

• 其他奇形怪狀的SQL

二、搜尋研發部調研

從搜尋研發部進階架構師@longc 處瞭解到，暫時沒有資料庫分庫需求。

畫外音：@龍神 做搜尋核心，壓根瞧不起我這個用MySQL搞業務的人呀。

 

三、即時通訊部調研

和@sunx 進行了溝通，幫幫技術部沒有水平分庫，只有水平分表，業務需求為常見需求中的“partition key上的普通查詢”。

對於58幫幫的“使用者登陸表”，資料量較大，目前分為32個表，以uid作為partition key，所有的查詢都會帶上partition key，故可以直接定位到資料所屬的partition。

如上例，假設58幫幫對某資料量較大的表以id為partition key分了3個表，上遊的所有查詢都會帶上id=xxx這個查詢條件（當然，亦可以同時帶上其他查詢條件）。

畫外音：@玄姐 設計的系統，架構考慮得極其完善。

 

四、移動研發部調研

從@liunz 瞭解到，無線分庫使用情境和幫幫技術部類似，都是“partition key 上的普通查詢”。

 

五、架構部調研

從@liuzw 瞭解到，架構部在imc，umc等服務使用水平分庫，業務需求為常見需求中的“patition key 上的普通查詢”，“partition key上的IN查詢”，“非partition key上的查詢”。

對於“partition key上的IN查詢”，架構部採用的是將各個partition key定位到相關的庫，最後將查詢結果集匯總，再返回上遊的方式來實現。注意，如所示，帶partition key的IN查詢並不一定會遍曆所有的庫。

 

對於“非partition key上的查詢”，根據不同的業務，架構部有兩種處理方式：

方式一

業務方不需要精確資料，隨機取一個庫的資料，即可滿足業務方要求，例如“查詢10個有頭像的使用者”

當業務方不需要關注結果集的精確性時，可以隨機取一個庫查詢。

畫外音：這是一個很好的設計，典型的“根據業務需求確定技術方案”的good case。

方式二

業務方需要精確資料，就必須遍曆所有的庫，例如“查詢使用者名稱為shenjian的使用者”。

畫外音：uid的產生沒有採用“基因法”，非常遺憾。關於“基因法”的方案詳見《單KEY業務，資料庫水平切分架構實踐 | 架構師之路》。

六、會員技術部調研

從@wangzt 瞭解到，會員技術部使用水平分庫，調研結論裡對分庫的四種SQL需求在業務中都有用到。

對“非partition key上的查詢”，除了使用架構部使用的全庫查詢方案，會員技術部還是用了冗餘資料法來解決這個問題：

這種查詢方式使用冗餘資料來避免全庫查詢，缺點是可能存在資料一致性問題。

 

“誇庫分頁查詢”，會員技術部的處理方式是索引表：

使用訂單分庫，買家的查詢查詢索引表，索引表的本質也是冗餘。

畫外音：關於“文章業務的水平切分”的方案詳見《1對多業務，資料庫水平切分架構一次搞定 | 架構師之路》。

七、支付平台部調研

從@hudp 瞭解到，分庫的資料訪問，貨幣系統部所有的線上即時業務都必須攜帶partition key，故其訪問模式和即時通訊的資料訪問模式相同。

 

但對於支撐系統/統計需求，在分庫資料上，他們計劃引入cobar來解決他們的問題。

 

八、前端業務部調研

從@wangjk 瞭解到，前端業務部這邊，四種分庫SQL都有，對於誇庫分頁，前端業務部這邊的業務上要求必須帶上一個特殊的id作為where欄位，以避免拉取大量的資料重新排序。

九、結論

58如果要做資料庫中介軟體，一期支援四類SQL：

• partition key普通查詢

• partition key上的IN查詢

• 非partition key上的查詢

• 有限功能的排序+分頁查詢

能夠滿足業務線絕大部分分庫的需求。

一切脫離業務的架構設計，都是耍流氓。

做技術要嚴謹，除了上述需求調研，也做了充分的技術調研：

《資料庫中介軟體TDDL調研筆記》

《資料庫中介軟體cobar調研筆記》

《資料庫中介軟體mysql-proxy調研筆記》

才有了後來的概要設計：

《假如讓你來設計資料庫中介軟體》

末了：看到調研文檔裡熟悉的名字，眼淚不知不覺的流下來，兄弟們，你們還好嗎？