資料庫中介軟體為何不支援join
轉自: http://mp.weixin.qq.com/s/q4DmWjhVmMMSzIP3K_n4Hw 架構師之路
有網友對《假如讓你來設計資料庫中介軟體》一文中，資料庫中介軟體僅僅支援四類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上的查詢”，除了使用架構部使用的全庫查詢方案，會員技術部還是用了冗餘資料法來解決這個問題：
這種查詢方式使用冗餘資料來避免全庫查詢，缺點是可能存在資料一致性問題。
“誇庫分頁查詢”，會員技術部的處理方式是索引表：
使用訂單分庫，買家的查詢查詢索引表，索引表的本質也是冗餘。
七、支付平臺部調研
從@hudp 瞭解到，分庫的資料訪問，貨幣系統部所有的線上實時業務都必須攜帶partition key，故其訪問模式和即時通訊的資料訪問模式相同。
但對於支撐系統/統計需求，在分庫資料上，他們計劃引入cobar來解決他們的問題。
八、前端業務部調研
從@wangjk 瞭解到，前端業務部這邊，四種分庫SQL都有，對於誇庫分頁，前端業務部這邊的業務上要求必須帶上一個特殊的id作為where欄位，以避免拉取大量的資料重新排序。
九、結論
58如果要做資料庫中介軟體，一期支援四類SQL：
-
partition key普通查詢
-
partition key上的IN查詢
-
非partition key上的查詢
-
有限功能的排序+分頁查詢
能夠滿足業務線絕大部分分庫的需求。
一切脫離業務的架構設計，都是耍流氓。
做技術要嚴謹，除了上述需求調研，也做了充分的技術調研：
才有了後來的概要設計：