數據庫中間件MyCat的介紹

今天小編就爲大家分享一篇關於數據庫中間件MyCat的介紹,小編覺得內容挺不錯的,現在分享給大家,具有很好的參考價值,需要的朋友一起跟隨小編來看看吧

1、Mycat 應用場景

Mycat 發展到現在,適用的場景已經很豐富,而且不斷有新用戶給出新的創新性的方案,以下是幾個典型的應用場景:

  • 1. 單純的讀寫分離,此時配置最爲簡單,支持讀寫分離,主從切換
  • 2. 分表分庫,對於超過 1000 萬的表進行分片,最大支持 1000 億的單表分片
  • 3. 多租戶應用,每個應用一個庫,但應用程序只連接 Mycat,從而不改造程序本身,實現多租戶化
  • 4. 報表系統,藉助於 Mycat 的分表能力,處理大規模報表的統計
  • 5. 替代 Hbase,分析大數據
  • 6. 作爲海量數據實時查詢的一種簡單有效方案,比如 100 億條頻繁查詢的記錄需要在 3 秒內查詢出來結果,除了基於主鍵的查詢,還可能存在範圍查詢或其他屬性查詢,此時 Mycat 可能是最簡單有效的選擇。

MYCAT可以實現讀寫分離下的讀操作負,mycat載均衡,將大量的讀操作均衡到不同的從庫上,主要出現在一主多從情形下。

MYCAT可實現數據庫的高可用,在數據庫主節點可用的情況下,配置一臺可寫從節點,這兩個節點都配置在MYCAT中,當主節點宕機時,MyCAT會自動將寫操作路由到備用節點上,但並不支持在切換之後的繼續主從同步。

當讀寫分離已經不能滿足持續增加的訪問量時,MYCAT可實現數據庫的垂直拆分,將所有的數據庫表按照模塊劃分,不同類型的表拆分到不同的數據庫服務器。

隨着業務量的增長,垂直拆分之後如果又出現了數據庫性能問題,則需要進行水平切分,這就是俗稱的分庫分表。將數據量很大的表數據切分到不同的服務器庫中,表結構是一樣的,而使用MYCAT實現水平切分,對前端應用是完全透明的,不用調整前臺邏輯。

從定義和分類來看,它是一個開源的分佈式數據庫系統,是一個實現了MySQL協議的服務器,前端用戶可以把它看作是一個數據庫代理,用MySQL客戶端工具和命令行訪問,而其後端可以用MySQL原生協議與多個MySQL服務器通信,也可以用JDBC協議與大多數主流數據庫服務器通信,其核心功能是分表分庫,即將一個大表水平分割爲N個小表,存儲在後端MySQL服務器裏或者其他數據庫裏。

MyCat發展到目前的版本,已經不是一個單純的MySQL代理了,它的後端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流數據庫,也支持MongoDB這種新型NoSQL方式的存儲,未來還會支持更多類型的存儲。而在最終用戶看來,無論是那種存儲方式,在MyCat裏,都是一個傳統的數據庫表,支持標準的SQL語句進行數據的操作,這樣一來,對前端業務系統來說,可以大幅降低開發難度,提升開發速度

2.傳統關係型數據庫侷限性

傳統關係型數據庫由於缺乏擴展性在面對大數據時存在巨大的缺陷,但是關係模型、事務機制對於大部分系統又不必不可少,目前業界主流的做法就是將傳統數據庫進行切分(包括垂直切分、水平切分等),提高數據庫的可擴展性。但是切分之後又帶來了新的問題,比如多數據源管理問題、跨節點join問題、分佈式事務問題等。下面探討Mycat如何解決這些問題。

多數據源管理問題

針對多數據源管理問題,主要有兩種解決思路,第一:客戶端模式,在每個應用程序模塊中配置管理自己需要的一個(或者多個)數據源,直接訪問各個數據庫,在模塊內完成數據的整合。第二:通過中間代理層來統一管理所有的數據源,後端數據庫集羣對前端應用程序透明。第一種方式不具備通用性,每個應用程序都需要自行開發數據整合功能,且對於已經建設完成的系統需要進行代碼重構,不適宜推廣。目前主要使用的是第二種方式,Mycat 的原理如下: Mycat 的原理中最重要的一個動詞是“攔截”,它攔截了用戶發送過來的SQL語句,首先對SQL語句做了一些特定的分析:如分片分析、路由分析、讀寫分離分析、緩存分等,然後將此SQL發往後端的真實數據庫,並將返回的結果做適當的處理,最終再返回給用戶。

Mycat的原理與其他分佈式數據庫中間件很類似,但是在架構上還是有區別,Mycat來源於Cobar,但在其基礎上進行了很大改進,Mycat的架構如下:

目前主流的分佈式數據庫中間件還有TDDL、 Amoeba、 Coba等,TDDL不同於其它幾款產品,並非獨立的中間件,只能算作中間層,是以Jar包方式提供給應用調用。屬於JDBC Shard 的思想,網上也有很多其它類似產品。Amoeba是作爲一個真正的獨立中間件提供服務,即應用去連接Amoeba操作MySQL集羣,就像操作單MySQL一樣,從架構中可以看來,Amoeba算中間件中的早期產品,後端還在使用JDBC Driver. Cobar 是Amoeba基礎上進化的版本,一個顯著變化是把後端JDBC Driver改爲原生的MySQL通信協議層,這就意味着不能支持Oracle、ProstgreSQL 等主流數據庫。MyCat 又是在Cobar基礎上發展的版本,後端由BI0改爲NIO,併發量有大幅提高,增加了對Order By、GroupBy、limit 等聚合功能的支持,支持目前主流的大部分數據庫。

跨節點join問題

Mycat支持inner join、leaf/right join、cross join、 Full join等方式跨節點join,主要是通過全局表,ER分片,Share Join 和catlet(人工智能)四種方式實現:

1、全局表

一個真實的業務系統中,往往存在大量的類似字典表的表格,它們與業務表之間可能有關係,這種關係,可以理解爲“標籤”,而不應理解爲通常的“主從關係”,這些表基本上很少變動,可以根據主鍵ID進行緩存,下面這張圖說明了一個典型的“標籤關係”圖:

在分片的情況下,當業務表因爲規模而進行分片以後,業務表與這些附屬的字典表之間的關聯,就成了比較棘手的問題,考慮到字典表具有以下幾個特性:

  • 1.變動不頻繁
  • 2.數據量總體變化不大
  • 3.數據規模不大,很少有超過數十萬條記錄。

鑑於此,MyCAT定義了一種特殊的表,稱之爲“全局表”,全局表具有以下特性:

  • 1.全局表的插入、更新操作會實時在所有節點上執行,保持各個分片的數據一致性
  • 2.全局表的查詢操作,只從一個節點獲取
  • 3.全局表可以跟任何一個表進行J0IN操作

將字典表或者符合字典表特性的一些表定義爲全局表,則從另外一個方面,很好的解決了數據J0IN的難題。通過全局表+基於ER關係的分片策略,MyCAT可以滿足80%以上的企業應用開發。

全局表配置方式如下(全局表會存儲於所以節點) :

總結

以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對神馬文庫的支持。如果你想了解更多相關內容請查看下面相關鏈接

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章