1. 程式人生 > >記錄一次經歷的資料庫從單庫到分庫分表的過程

記錄一次經歷的資料庫從單庫到分庫分表的過程

前言

   目前所在的的專案組,由於專案正在處於一個業務爆發期,每天資料的增長量已經給我們資料庫乃至系統造成了很多不確定的因數,前期依靠優化業務和SQL等方式暫時還能夠支撐住。但是最近發現某些表資料達到500W+以後查詢統計效能嚴重下降,高峰時段出現了很多SQL阻塞的情況例如:


這種阻塞帶來的災難是滾雪球的,由於越堆越多基本上把資料庫已經拖死,所以我們就面臨資料庫切分的問題。

技術選型

   既然要分庫分表那資料庫叢集是少不了的,那我們的專案怎樣和這些叢集打交道呢?我調研了大概分為以下幾種來完成這個功能(僅僅針對java專案)

中介軟體

例如淘寶開源的cobar,以及後來開源社群根據cobar做二次開發的Mycat(個人建議如果使用中介軟體的話可以考慮Mycat)

Jar形式的開源工具

例如淘寶的TDDL,以及噹噹開源出來的,Sharding-JDBC等

動態資料來源

根據自己的業務來指定資料來源來完成不同庫和表的操作

   給予上面三個我最後選擇了估計看起來最LOW的第三種方式:我說一下我自己選擇的依據:

   上述開元產品中淘寶系的cobar沒有維護,TDDL開源出來的和內部版本也不一樣有不少BUG我們這邊人力緊缺,估計沒時間來爬坑。Sharding-JDBC呢,剛推出來沒有專案實戰經驗。Mycat其實是我發現目前比較好的一個解決方案,但是mycat是給予代理模式的需要人維護,如果維護不得力,效能也不會太高,基於我們組人員的能力和我還是最終放棄了。

   之所以選擇動態資料來源:主要是因為技術相對簡單,對於業務程式碼修改也比較少,可控性較高,減少了加入中介軟體或者第三方工具所帶來的風險。(申明一下我們專案完全沒有使用JPA事物的,對於事物是採用的補償機制這裡就不贅述)

  主鍵生成策略

  既然要分庫分表那麼全域性唯一主鍵也是我們需要考慮的問題,我所知道的和有使用經驗的有如下幾種技術:

問題

可行性

基於redis

單點問題,redis重啟問題等

較高,公司有專案使用

給予DB(每次生成多個使用時去取出來)

單點問題,併發量問題

低併發,資料量較小的可以使用

UUID

暫用儲存空間比較大,非可排序的,體現不出增長的趨勢

較高

Xx年以後可能存在重複問題,需要配置生產引數

高,分散式的沒單點故障問題,時間上是遞增的。推薦

基於DB步長的方式

不是所有資料庫都支援

  我選擇的是snowflake。

實現細節  

   因為分庫分表所以查詢和新增都需要帶上分配策略主鍵。

新增流程

查詢邏輯


分庫分表後能解決我們的效能問題,但是也帶來了很多其他的問題:我總結了一下分庫分表後的坑

1.分完之後只能直接按分片鍵查詢,為了避免掃所有分片,如果按非分片鍵查詢,在OLTP環境中得走搜尋引擎。資料庫和搜尋引擎同步資料靠binlog2.按不同維度查詢,比如買家維度和賣家維度查訂單。除了走搜尋引擎之外,還可以在不同的系統中各寫一條訂單資料。3.ID得通過ID生成器。4.有熱點資料問題,比如一個超級買家,買了好多種商品,然而還有不怎麼熱的買家,沒什麼訂單。解決方法兩種,熱點資料拿出來放到單獨的系統。或者按資料塊分片,比如十種商品算一個塊,但這種方法具體細節我忘了,只是聽人分享過。5.跨庫事務問題,NPC一般不用,補償是一種方法,TCC是一種方法,TCC的變種,比如SAGA比如XTS,努力送達是一種方法6.資料擴充套件問題,可以看看阿里的愚公。我個人覺得還半夜停機維護比較靠譜。7.分頁的坑,前期可以用中介軟體Limit,中期得走搜尋引擎,後期OLAP8.可用性問題,依賴資料庫高可用方案。據說會出現 sharding 演算法 會因為網路抖動 造成部分分割槽錯誤 導致片出問題9.配置中心問題。儘量使用配置中心,不要用zookeeper10.非代理模式,就是JDBC路由模式 每個client都會對 db開啟pool ,資料庫可能會死在資料庫連線上,一種方法是定製Mysql,設定高低水位,讓超過資料庫處理能力的資料庫連線排隊。第二種方法是在JDBC路由模式之上做Mysql的Proxy

我把我現在的專案抽出來了一個簡單的模型放出來:原始碼我將放在git上面

https://github.com/bingzhilanmo-bowen/spring-multi-datasource

                                                                                                                                                                                          如有問題可聯絡我:

                                                                                                                                                                                           mail: [email protected]

                                                                                                                                                                                           歡迎加入java高階群:329019348

轉載:https://blog.csdn.net/wangfanbb/article/details/50887108

相關推薦

記錄經歷的數據分庫過程

人力 per 靠譜 img center 沒有 tdd 推出 數據 前言 目前所在的的項目組,由於項目正在處於一個業務爆發期,每天數據的增長量已經給我們數據庫乃至系統造成了很多不確定的因數,前期依靠優化業務和SQL等方式暫時還能夠支撐住。但是最近發現某些表數據達到50

記錄經歷資料庫分庫過程

前言   目前所在的的專案組,由於專案正在處於一個業務爆發期,每天資料的增長量已經給我們資料庫乃至系統造成了很多不確定的因數,前期依靠優化業務和SQL等方式暫時還能夠支撐住。但是最近發現某些表資料達到500W+以後查詢統計效能嚴重下降,高峰時段出現了很多SQL阻塞的情況例如:

記錄誤刪數據指定數據---------->血的教訓

img http 查詢 復制粘貼 跟蹤 type 變更 image 圖表 本來要進行select的查詢,結果不小心誤執行了delete的命令,導致unitID=100004的數據全部被刪除 這下尷尬了 這可是線上的數據庫啊 , 趕緊去查看binlog日誌 期望能恢復

記錄利用pn532進行學校水卡改餘額過程

僅為個人學習分享,切勿利用破壞違法,本人對其內容不負任何法律責任 一、準備過程 1.PN532 2.PL2303串列埠模組USB轉TTL              &

記錄艱辛的Python包持續整合與釋出過程

緣由 為了保證程式碼質量,編寫單元測試是非常必要的,特別是在團隊開發的過程中,編寫有效的單元測試保證每人編寫的模組能夠正常工作,以免專案後期出現各種不可預知的bug,因此,在提交程式碼前執行單元測試,可以有效保證程式碼的健壯性。這種工作當然是要自動化完成,因此

Mysql叢集和主多之後如何分庫的方案實現(三)

4-3、使用MyCat配置橫向拆分 之前文章中我們介紹瞭如何使用MyCat進行讀寫分離,類似的關係型資料庫的讀寫分離儲存方案可以在保持上層業務系統透明度的基礎上滿足70%業務系統的資料承載規模要求和效能要求。比起單純使用LVS + Replicaion的讀寫分離方案而言最大的優勢在於更能增加對上層業務系

16、MySQL數據分庫備份腳本

mysql數據庫分庫分表備份腳本MySQL數據庫分庫分表備份腳本===================學員分享分庫分表==========================腳本單雙引號的區別:單引號是強引用,強制輸出是所見即所得。雙引號是解析變量 和 多個字符串、數字等連接一個字符串條件1 || 條件2

MyBatis實現Mysql數據分庫操作和總結

用戶表 設計 行數 百萬 出現問題 網絡 自增 .html tro 閱讀目錄 前言 MyBatis實現分表最簡單步驟 分離的方式 分離的策略 分離的問題 分離的原則 實現分離的方式 總結 前言 作為一個數據庫,作為數據庫中的一張表,隨著用戶的增多隨著時間的推移,總有一

數據分庫

事務管理 mys cal 為什麽 分配 slaver 資源問題 時間流 1.7 1. 數據庫分庫分表 1.1. 前言 1.1.1. 名詞解釋 1.2. 數據庫架構演變 1.3. 分庫分表前的問題 1.3.1. 用戶請求量太大 1.3.2. 單庫太大 1.3.3

數據分庫中間件 Sharding-JDBC 源碼分析 —— SQL 解析(六)之刪除SQL

java 後端 架構 數據庫 中間件關註微信公眾號:【芋道源碼】有福利:RocketMQ / MyCAT / Sharding-JDBC 所有源碼分析文章列表RocketMQ / MyCAT / Sharding-JDBC 中文註釋源碼 GitHub 地址您對於源碼的疑問每條留言都將得到認真回復。甚至不知道如

數據分庫中間件 Sharding-JDBC 源碼分析 —— 布式主鍵

java 後端 架構 數據庫 中間件關註**微信公眾號:【芋道源碼】**有福利:RocketMQ / MyCAT / Sharding-JDBC 所有源碼分析文章列表RocketMQ / MyCAT / Sharding-JDBC 中文註釋源碼 GitHub 地址您對於源碼的疑問每條留言都將得到認真回復。甚至

數據分庫思路

ace 連接數 定性 返回 讀寫性能 反範式 不存在 分配 -c 一. 數據切分 關系型數據庫本身比較容易成為系統瓶頸,單機存儲容量、連接數、處理能力都有限。當單表的數據量達到1000W或100G以後,由於查詢維度較多,即使添加從庫、優化索引,做很多操作時性能仍下降嚴重。此

數據 分庫

時報 mat bpa 了解 插入 5.6 切分 支持 sil 我們知道,如果我們使用mysql,當數據庫數據量達到一定數據量之後,會考慮對數據庫進行分庫分表等操作,但是在什麽情況下做怎麽的切分,下面分表介紹。 一、分庫 1 分庫原因 首先,在單臺數據庫服務器性能足夠的情況下

數據分庫思路 [轉]

id重復 奇數 水平切分 結構 是否 就是 space sele 拉取 一. 數據切分 關系型數據庫本身比較容易成為系統瓶頸,單機存儲容量、連接數、處理能力都有限。當單表的數據量達到1000W或100G以後,由於查詢維度較多,即使添加從庫、優化索引,做很多操作時性能仍下降嚴

數據分庫的應用場景及解決方案

margin 路由 單列 數據庫服務器 種類 要求 場景 fontsize 再次 數據庫分庫分表的應用場景及解決方案 現實業務場景中,為了保障客戶體驗並滿足業務的線性增長。會對數據量巨大,且業務會始終進行的產品進行分表分庫策略。但是如何合理的根據業務采取爭取

【幹貨】數據分庫基礎和實踐

ima 邏輯關系 部分 平分 range cto database 單個 ron 數據庫架構的演變在業務數據量比較少的時代,我們使用單機數據庫就能滿足業務使用,隨著業務請求量越來越多,數據庫中的數據量快速增加,這時單機數據庫已經不能滿足業務的性能要求,數據庫主從復制架構隨之

數據分庫(sharding)系列

使用 版權 支持 tar 策略 ofo sdn 數據源 鏈接 博客專欄http://blog.csdn.net/column/details/sharding.html 相關閱讀: 數據庫分庫分表(sharding)系列(五) 一種支持自由規劃無須數據遷移和修改路由代碼

為什麼選擇第三代分散式關係資料庫而不是分庫的二代方案

       “網際網路經濟”所帶來的巨大流量使得企業、機構面臨外部訪問負載以及資料量的大幅飆升,很多企業資訊系統目前所採用的傳統集中式關係型資料庫越來越不適應海量資料以及高併發環境下對資料處理能力的要求,在應對此類場景時資料庫逐漸成為整體系統的瓶頸,擴充套件

架構師必備技能:資料庫優化手術刀——實戰分庫

在最初,應用的資料量比較少,沒有任何壓力,一般會將所有的資料放在一個庫中。但是隨著業務的增長,資料量急劇增長,DB壓力增大,似乎隨時都會掛掉。此時,優化DB的使用已經是勢在必行,以下有幾個方案。 1 優化對DB的使用 讀寫分離(肯定一開始就做了……)、索引、使用合理的sql等等。一些簡單的優化可以先

數據分庫中間件:Mycat;布式數據;mysql的布式事務

版本 -s download ng- .html https pac apache tee 官網:http://mycat.io/,裏面有電子書籍可以下載:http://www.mycat.io/document/mycat-definitive-guide.pdf 舊版本