數據庫中間件為何不支持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上的查詢”，根據不同的業務，架構部有兩種處理方式：
1. 方式一
業務方不需要精確數據，隨機取一個庫的數據，即可滿足業務方要求，例如“查詢10個有頭像的用戶”
當業務方不需要關注結果集的精確性時，可以隨機取一個庫查詢。
畫外音：這是一個很好的設計，典型的“根據業務需求確定技術方案”的good case。
2. 方式二
業務方需要精確數據，就必須遍歷所有的庫，例如“查詢用戶名為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上的查詢
- 有限功能的排序+分頁查詢
能夠滿足業務線絕大部分分庫的需求。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
