網絡應用持續擴張的過程當中,爲了處理海量數據每每首先遇到的挑戰就是數據存儲的擴展前端
數據存儲的擴展通常以切分來實現,切分的技術實現又可分爲垂直切分和水平切分:mysql
以表(或Schema)爲切分粒度的是垂直切分web
以表內行爲切分粒度的是水平切分sql
初期擴展使用垂直切分就能夠基本解決問題,垂直切分也相對簡單,但隨着數據行成量級的持續增加,針對這張表的各層面操做性能都會顯著下降,此時就不得不進行水平切分了,水平切分就要複雜不少mongodb
爲了應對此類挑戰,就產生了一類新的數據庫 NoSQL (Not Only SQL) ,此類的表明有 MongoDB、Redis、Memcached、Elasticsearch ,這類數據庫能夠輕鬆應對數據庫的擴展(不管是水平仍是垂直切分都很是高效),在海量數據的狀況下,也能有着極佳的讀寫性能,NoSQL的根本優點就在於大數據時代易於進行大規模分佈式擴展數據庫
可是因爲NoSQL固有的分佈式架構,目前對事務的支持很是弱,存儲也是弱結構的,join等複雜操做能力不好,應用場景比較侷限後端
數據庫弱了,就意味着,若是要實現同樣的特性,應用層面的設計得更復雜才能彌補,這也無形地引入了架構風險緩存
爲了使用到關係模型的一些特性(交易或支付的場景,前幾年很是火熱的去IOE),仍是繞不過關係型數據庫,可是關係型數據庫先天就對分佈式支持很弱安全
簡單點能夠這麼理解:服務器
事務性就是序列化,高併發就是分佈式,序列化與並行相背離,因此事務性和分佈式很難和諧共處
在事務性和高併發中得有取捨,因此市面上又出現了不少用來進行協調的中間件
支持SQL92標準
遵照Mysql原生協議,跨語言,跨平臺,跨數據庫的通用中間件代理。
基於心跳的自動故障切換,支持讀寫分離,支持MySQL主從,以及galera cluster集羣。
支持Galera for MySQL集羣,Percona Cluster或者MariaDB cluster
基於Nio實現,有效管理線程,高併發問題。
支持數據的多片自動路由與聚合,支持sum,count,max等經常使用的聚合函數,支持跨庫分頁。
支持單庫內部任意join,支持跨庫2表join,甚至基於caltlet的多表join。
支持經過全局表,ER關係的分片策略,實現了高效的多表join查詢。
支持多租戶方案。
支持分佈式事務(弱xa)。
支持全局序列號,解決分佈式下的主鍵生成問題。
分片規則豐富,插件化開發,易於擴展。
強大的web,命令行監控。
支持前端做爲mysq通用代理,後端JDBC方式支持Oracle、DB二、SQL Server 、 mongodb 、巨杉。
支持密碼加密
支持服務降級
支持IP白名單
支持SQL黑名單、sql注入攻擊攔截
支持分表(1.6)
集羣基於ZooKeeper管理,在線升級,擴容,智能優化,大數據處理(2.0開發版)。
一個完全開源的,面向企業應用開發的大數據庫集羣
支持事務、ACID、能夠替代MySQL的增強版數據庫
一個能夠視爲MySQL集羣的企業級數據庫,用來替代昂貴的Oracle集羣
一個融合內存緩存技術、NoSQL技術、HDFS大數據的新型SQL Server
結合傳統數據庫和新型分佈式數據倉庫的新一代企業級數據庫產品
一個新穎的數據庫中間件產品
四、MyCat配置
MyCAT 是做爲通用代理設計的,後端是以 Mysql協議 和 JDBC 的方式鏈接數據庫,能夠支持 Oracle、DB二、SQL Server 、 mongodb、mysql
4.一、數據庫中間件
因此Mycat沒有存儲引擎,自己並不存儲數據,只是起到了請求分析,拆解,路由與結果聚合的做用,爲前端應用提供統一接口,Mycat 與後端的數據庫集羣有機組合才一塊兒構成一個分佈式數據庫系統。
4.二、邏輯庫(schema)
相似於LVM中VG的概念(VG由一個或多個PV構成),邏輯庫是由一個或多個後端數據庫構成的,展現給應用的是一個單一視圖,是分佈式數據庫在邏輯上的一個抽象
4.三、邏輯表(table)
4.3.一、邏輯表
與數據庫中表相對應的,分佈式數據表在邏輯上的一個抽象
4.3.二、分片表
數據表切分後的一個部分(原表的一個真子集)
4.3.三、非分片表
沒有分片的表,就是非分片表
4.3.四、ER表
保留了實體關係特性的表,就是ER表
關係型數據庫是基於實體關係模型的相關理論來構建的數據庫,表與表間有依賴關係,經過表分組(Table Group) 讓有依賴的表在同一實例庫中從而避免了數據Join不會跨庫操做
4.3.五、全局表
全局表是全部分片上都有一份完整拷貝的表
字典表或符合字典特性的表能夠被設置爲全局表
有如下特色的表,被稱做字典表:
變更不頻繁
數據量整體變化不大
數據規模不大(不多超過十萬條記錄)
會與其它表發生關聯
這類表能夠經過冗餘來解決join問題,也就是全部的分片都放上一份數據的拷貝來避免跨分片聯查
4.四、分片節點(dataNode)
每一個表分片所在的數據庫就是分片節點
4.五、節點主機(dataHost)
分片節點所在的服務器就是節點主機,儘可能將讀寫壓力高的分片節點均衡放在不一樣的節點主機上,以免單節點主機併發數限制
4.六、分片規則(rule)
分片規則就是切分數據的規則
4.七、全局序列號(sequence)
保證數據全局惟一性標識的外部機制就是全局序列號
4.八、多租戶
多租戶技術也叫多重租憑技術,就是在確保用戶間數據隔離的前提下實如今多用戶環境中共用相同系統或程序等軟硬件資源的一種軟件架構技術
獨立數據庫
共享數據庫,隔離數據架構
共享數據庫,共享數據架構
隔離級別愈來愈低,共享程度愈來愈高,均攤成本愈來愈低
五、MyCat配置
Mycat 的大部分配置都是以 XML 的格式設定的。
Conf |
Comment |
conf/wrapper.conf |
JVM運行環境配置 |
conf/server.xml |
用來定義系統相關變量 |
conf/schema.xml |
用來定義邏輯庫,表,分片節點 |
conf/rule.xml |
用來定義分片規則 |
5.一、schema.xml配置
Attribute |
Comment |
maxCon |
一個讀寫實例連接池的最大鏈接數 |
minCon |
一個讀寫實例連接池的最小鏈接數,初始化鏈接池的大小 |
balance |
負載均衡類型:0 表明不開啓讀寫分離機制,只使用writeHost; 1 表明readHost與writeHost分擔讀請求; 2 表明隨機分配讀請求和1相似; 3 表明只由readHost來承擔讀請求 |
writeType |
負載均衡類型:0 表明發到第一個writeHost,掛了後切到還生存的第二個writeHost,從新啓動後以切換後的爲準,也就是不漂回;1 表明寫操做隨機發送到writeHost,這樣不安全; |
dbType |
後端數據庫類型 |
dbDriver |
mysql系可使用native,其它系列得使用JDBC |
switchType |
切換類型:-1 表明不切換,1 表明自動切換, 2 表明基於主從同步狀態決定是否切換 |
slaveThreshold |
slave讀的安全邊界,若是Seconds_Behind_Master 大於這個值,這臺slave會被臨時剔除,以避免被讀 |
writeHost/readHost
Attribute |
Comment |
host |
一個主機標識,便於區分,沒必要和真實主機名一致 |
url |
後端實例鏈接地址 |
user |
鏈接帳戶 |
password |
鏈接密碼 |
爲何須要mycat
應對大數據量的存儲與操做,傳統單機單庫的數據庫沒法很好的擴展性切分,架構規模和性能缺陷被放大。
Mycat的目標
解決數據存儲和業務規模迅速增加狀況下的數據瓶頸問題。2014年上海《中華架構師》大會上對外宣講,截止2015年4月約估計有60多項目在使用,主要包括電信,互聯網,交易管理等領域項目。
Mycat是什麼
是一個開源的分佈式數據庫系統
是一個實現了MySQL協議的服務器,前端能夠看作是一個數據庫代理,能夠經過MySQL的客戶端工具訪問,後端用MySQL的原生協議與多個MySQL服務器通訊,也能夠經過JDBC協議與大多數主流數據庫服務器通訊,其核心是分表分庫,即將一個大表水平分割爲N個小表,存儲在後端MySQL服務器或者其餘數據庫服務器裏。
後端目前支持oracle,sqlserver,db2,postgresql,mysql,也支持mongodb的nosql方式存儲,對前端支持標準的SQL語句進行數據操做,能夠大幅度的下降前端開發難度,提高開發速度。
Mycat解決了哪些問題
鏈接過多致使應用競爭問題,mycat統一管理全部數據源,後端數據庫對前端應用透明;
ER關係分片,解決ER分片難處理問題,提升誇節點join的效率;
採用全局分片技術,每一個節點同時併發讀取、插入和更新數據;
支持基於MySQL主從複製狀態的高級讀寫分離控制機制;
全局表
HBT(Human Brain Tech)人工智能catlet
MyCAT技術原理
攔截,mycat攔截用戶發送的SQL語句,對SQL作特定的分析如分片分析,路由分析,讀寫分離分析,緩存分析等,而後將SQL發日後端的真是數據庫,並將返回結果作適當處理,最終返回給用戶。
MyCAT的問題:
非分片字段查詢
MyCAT中的路由結果是經過分片字段和分片方法來肯定的,若是查詢條件是分片字段,查詢將路由到某個具體的分片上;若是查詢條件沒有分片字段,MyCAT沒法計算路由,便發送到全部節點,隨着節點的增多,會消耗更多的數據庫資源;
分頁排序問題:消耗大量的計算資源;
沒法實現任意表join,必須確保相關聯的表的關聯字段具備相同的分佈;
MyCat沒法實現事務強一直性;
趨勢:數據庫應用已經廣泛創建於計算機網絡之上了
集中式數據庫的不足
集中式處理勢必形成存儲和性能瓶頸
沒法高可用;
系統的規模和配置都不夠靈活,系統的可擴展性差
Amoeba專一於分佈式數據庫前端代理層,具備負載均衡,高可用,SQL過濾,讀寫分離,SQL路由,結果合併等功能,穩定性,性能和功能支持不夠好,核心人員的離開
Cobar 基於Amoeba開發,穩定,可靠,優秀的架構設計2013年後沒在更新
MyCat 基於Cobar開發,
解決數據存儲和業務規模迅速增加的狀況下的數據瓶頸問題;
單主機模式:LAMP服務都在一臺主機上;
獨立主機模式:將web服務器和MySQL服務器分開,分別部署獨立主機模式;
讀寫分離:考慮業務實時性要求,寫庫不方便橫向擴展;
業務垂直拆分:解決高併發下單庫寫入壓力沒法分擔的問題,單庫的壓力尚未明顯的緩解;
單業務庫水平垂直切分:水平拆分橫向擴展比較好,對查詢挑戰比較大;
業務垂直切分,業務無關的關鍵字水平拆分,不能無限擴展,肯定好分庫個數後基本不可添加