日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
數(shù)據(jù)庫中間件為何不支持join

有網(wǎng)友對《假如讓你來設(shè)計數(shù)據(jù)庫中間件》一文中，數(shù)據(jù)庫中間件僅僅支持四類SQL存有疑問：

  • partition key普通查詢
  • partition key上的IN查詢
  • 非partition key上的查詢
  • 有限功能的排序+分頁查詢

這四類SQL就能滿足公司業(yè)務(wù)的需求么，這個結(jié)論是怎么來的?

看來《假如讓你來設(shè)計數(shù)據(jù)庫中間件》的架構(gòu)結(jié)論并不能讓刨根究底的網(wǎng)友們滿意，于是把13年底，需求調(diào)研的過程細節(jié)也說一說，作為一個一線架構(gòu)師，治學(xué)還是得嚴謹。

一、業(yè)務(wù)側(cè)的分庫后SQL需求

先說結(jié)論，通過初步的調(diào)研，發(fā)現(xiàn)58各業(yè)務(wù)線對有分庫需求的應(yīng)用場景為：

  • 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

大部分需求集中在前三條，排序+分頁的需求由于分布式實現(xiàn)困難，各業(yè)務(wù)線往往也采用了一些限制或者變通手段實現(xiàn)，例如：

  • 建立索引表以避免遍歷庫再內(nèi)部排序
  • 使用額外的id查詢條件來避免大數(shù)據(jù)量的查詢

調(diào)研結(jié)果顯示，各業(yè)務(wù)線暫沒有下列需求：

  • 夸庫join
  • 夸庫事務(wù)
  • 夸庫子查詢
  • 其他奇形怪狀的SQL

二、搜索研發(fā)部調(diào)研

從搜索研發(fā)部高級架構(gòu)師@longc 處了解到，暫時沒有數(shù)據(jù)庫分庫需求。

畫外音：@龍神 做搜索內(nèi)核，壓根瞧不起我這個用MySQL搞業(yè)務(wù)的人呀。

三、即時通訊部調(diào)研

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

對于58幫幫的“用戶登陸表”，數(shù)據(jù)量較大，目前分為32個表，以uid作為partition key，所有的查詢都會帶上partition key，故可以直接定位到數(shù)據(jù)所屬的partition。

如上例，假設(shè)58幫幫對某數(shù)據(jù)量較大的表以id為partition key分了3個表，上游的所有查詢都會帶上id=xxx這個查詢條件(當然，亦可以同時帶上其他查詢條件)。

畫外音：@玄姐 設(shè)計的系統(tǒng)，架構(gòu)考慮得極其完善。

四、移動研發(fā)部調(diào)研

從@liunz 了解到，無線分庫使用場景和幫幫技術(shù)部類似，都是“partition key 上的普通查詢”。

五、架構(gòu)部調(diào)研

從@liuzw 了解到，架構(gòu)部在imc，umc等服務(wù)使用水平分庫，業(yè)務(wù)需求為常見需求中的“patition key 上的普通查詢”，“partition key上的IN查詢”，“非partition key上的查詢”。

對于“partition key上的IN查詢”，架構(gòu)部采用的是將各個partition key定位到相關(guān)的庫，***將查詢結(jié)果集匯總，再返回上游的方式來實現(xiàn)。注意，如上圖所示，帶partition key的IN查詢并不一定會遍歷所有的庫。

對于“非partition key上的查詢”，根據(jù)不同的業(yè)務(wù)，架構(gòu)部有兩種處理方式：

1. 方式一

業(yè)務(wù)方不需要精確數(shù)據(jù)，隨機取一個庫的數(shù)據(jù)，即可滿足業(yè)務(wù)方要求，例如“查詢10個有頭像的用戶”

當業(yè)務(wù)方不需要關(guān)注結(jié)果集的精確性時，可以隨機取一個庫查詢。

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

2. 方式二

業(yè)務(wù)方需要精確數(shù)據(jù)，就必須遍歷所有的庫，例如“查詢用戶名為shenjian的用戶”。

畫外音：uid的生成沒有采用“基因法”，非常遺憾。關(guān)于“基因法”的方案詳見《單KEY業(yè)務(wù)，數(shù)據(jù)庫水平切分架構(gòu)實踐 | 架構(gòu)師之路》。

六、會員技術(shù)部調(diào)研

從@wangzt 了解到，會員技術(shù)部使用水平分庫，調(diào)研結(jié)論里對分庫的四種SQL需求在業(yè)務(wù)中都有用到。

對“非partition key上的查詢”，除了使用架構(gòu)部使用的全庫查詢方案，會員技術(shù)部還是用了冗余數(shù)據(jù)法來解決這個問題：

這種查詢方式使用冗余數(shù)據(jù)來避免全庫查詢，缺點是可能存在數(shù)據(jù)一致性問題。

“夸庫分頁查詢”，會員技術(shù)部的處理方式是索引表：

使用訂單分庫，買家的查詢查詢索引表，索引表的本質(zhì)也是冗余。

畫外音：關(guān)于“帖子業(yè)務(wù)的水平切分”的方案詳見《1對多業(yè)務(wù)，數(shù)據(jù)庫水平切分架構(gòu)一次搞定 | 架構(gòu)師之路》。

七、支付平臺部調(diào)研

從@hudp 了解到，分庫的數(shù)據(jù)訪問，貨幣系統(tǒng)部所有的線上實時業(yè)務(wù)都必須攜帶partition key，故其訪問模式和即時通訊的數(shù)據(jù)訪問模式相同。

但對于支撐系統(tǒng)/統(tǒng)計需求，在分庫數(shù)據(jù)上，他們計劃引入cobar來解決他們的問題。

八、前端業(yè)務(wù)部調(diào)研

從@wangjk 了解到，前端業(yè)務(wù)部這邊，四種分庫SQL都有，對于夸庫分頁，前端業(yè)務(wù)部這邊的業(yè)務(wù)上要求必須帶上一個特殊的id作為where字段，以避免拉取大量的數(shù)據(jù)重新排序。

九、結(jié)論

58如果要做數(shù)據(jù)庫中間件，一期支持四類SQL：

  • partition key普通查詢
  • partition key上的IN查詢
  • 非partition key上的查詢
  • 有限功能的排序+分頁查詢

能夠滿足業(yè)務(wù)線絕大部分分庫的需求。

【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】


網(wǎng)頁標題：數(shù)據(jù)庫中間件為何不支持join
網(wǎng)址分享：http://www.dlmjj.cn/article/dpshcde.html