MySQL分庫分表之MyCat實現(五)


一 .分庫分表

  1. 什么是分庫分表?

       分庫分表就是為了解決由於數據量過大而導致數據庫性能降低的問題,將原來獨立的數據庫拆分成若干數據庫組成,將數據大表分成若干數據表組成,使得單一數據庫、單一數據表的數據量變小,從而達到提升數據庫性能的目的。

2.分庫分表的方式

2.1分庫:

     1.垂直分庫:是指按照業務將表進行分類,分布到不同的數據庫上面,每個庫可以放不同的服務器上,它的核心理念是專庫專用。

     2水平分庫:把同一個表的數據按一定規則拆分到不同的數據庫中,每個庫可以放不同的服務器上

2.2分表:

    1.垂直分表:將一個表按照字段分成多表,每個表存儲其中一部分字段

    2.水平分:在同一個數據庫內,把同一個表的數據按一定規則拆到多個表中。

   

 

 

二. MyCat實現

2.1 什么是MyCat?

          MyCat 是目前最流行的基於 java 語言編寫的數據庫中間件,是一個實現了 MySQL 協議的服務器,前端用戶可以把它看作是一個數據庫代理,用 MySQL 客戶端工具和命令行訪問,而其后端可以用 MySQL 原生協議與多個 MySQL 服務器通信,也可以用 JDBC 協議與大多數主流數據庫服務器通信,其核心功能是分庫分表。配合數據庫的主從模式還可實現讀寫分離。

         MyCat 是基於阿里開源的 Cobar 產品而研發,Cobar 的穩定性、可靠性、優秀的架構和性能以及眾多成熟的使用案例使得 MyCat 變得非常的強大.MyCat 發展到目前的版本,已經不是一個單純的 MySQL 代理了,它的后端可以支持MySQLSQL ServerOracleDB2PostgreSQL 等主流數據庫,也支持 MongoDB 這種新型NoSQL 方式的存儲,未來還會支持更多類型的存儲。而在最終用戶看來,無論是那種存儲方式,在 MyCat 里,都是一個傳統的數據庫表,支持標准的 SQL 語句進行數據的操作,這樣一來,對前端業務系統來說,可以大幅降低開發難度,提升開發速度。

2.2 MyCat構架

      

2.3.MyCat關鍵特性

支持SQL92標准

遵守Mysql原生協議,跨語言,跨平台,跨數據庫的通用中間件代理。

基於心跳的自動故障切換,支持讀寫分離,支持MySQL主從,以及galera cluster集群。

支持Galera for MySQL集群,Percona Cluster或者MariaDB cluster

基於Nio實現,有效管理線程,高並發問題。

支持數據的多片自動路由與聚合,支持sum,count,max等常用的聚合函數,支持跨庫分頁。

支持單庫內部任意join,支持跨庫2join,甚至基於caltlet的多表join

支持通過全局表,ER關系的分片策略,實現了高效的多表join查詢。

支持多租戶方案。

支持分布式事務(弱xa)。

支持全局序列號,解決分布式下的主鍵生成問題。

分片規則豐富,插件化開發,易於擴展。

強大的web,命令行監控。

支持前端作為mysq通用代理,后端JDBC方式支持OracleDB2SQL Server mongodb 、巨杉。

支持密碼加密

支持服務降級

支持IP白名單

支持SQL黑名單、sql注入攻擊攔截

支持分表(1.6

集群基於ZooKeeper管理,在線升級,擴容,智能優化,大數據處理(2.0開發版)。

2.4Mycat解決了哪些問題

連接過多導致應用競爭問題,mycat統一管理所有數據源,后端數據庫對前端應用透明;

ER關系分片,解決ER分片難處理問題,提高誇節點join的效率;

采用全局分片技術,每個節點同時並發讀取、插入和更新數據;

支持基於MySQL主從復制狀態的高級讀寫分離控制機制;

全局表 

HBTHuman Brain Tech)人工智能catlet

2.5 MyCAT技術原理

  mycat攔截用戶發送的SQL語句,對SQL做特定的分析如分片分析,路由分析,讀寫分離分析,緩存分析等,然后將SQL發往后端的真是數據庫,並將返回結果做適當處理,最終返回給用戶。

2.6.MyCAT的問題:

非分片字段查詢

MyCAT中的路由結果是通過分片字段和分片方法來確定的,如果查詢條件是分片字段,查詢將路由到某個具體的分片上;如果查詢條件沒有分片字段,MyCAT無法計算路由,便發送到所有節點,隨着節點的增多,會消耗更多的數據庫資源;

分頁排序問題:消耗大量的計算資源;

無法實現任意表join,必須確保相關聯的表的關聯字段具有相同的分布;

MyCat無法實現事務強一直性;

趨勢:數據庫應用已經普遍建立於計算機網絡之上了

集中式數據庫的不足

集中式處理勢必造成存儲和性能瓶頸

無法高可用;

系統的規模和配置都不夠靈活,系統的可擴展性差

Amoeba專注於分布式數據庫前端代理層,具有負載均衡,高可用,SQL過濾,讀寫分離,SQL路由,結果合並等功能,穩定性,性能和功能支持不夠好,核心人員的離開

Cobar 基於Amoeba開發,穩定,可靠,優秀的架構設計2013年后沒在更新

MyCat 基於Cobar開發,

解決數據存儲和業務規模迅速增長的情況下的數據瓶頸問題;

單主機模式:LAMP服務都在一台主機上;

獨立主機模式:將web服務器和MySQL服務器分開,分別部署獨立主機模式;

讀寫分離:考慮業務實時性要求,寫庫不方便橫向擴展;

業務垂直拆分:解決高並發下單庫寫入壓力無法分擔的問題,單庫的壓力還沒有明顯的緩解;

單業務庫水平垂直切分:水平拆分橫向擴展比較好,對查詢挑戰比較大;

業務垂直切分,業務無關的關鍵字水平拆分,不能無限擴展,確定好分庫個數后基本不可添加

 

 

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM