建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
數(shù)據(jù)庫(kù)切分概述
為企業(yè)提供成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、網(wǎng)站優(yōu)化、網(wǎng)絡(luò)營(yíng)銷(xiāo)推廣、競(jìng)價(jià)托管、品牌運(yùn)營(yíng)等營(yíng)銷(xiāo)獲客服務(wù)。成都創(chuàng)新互聯(lián)公司擁有網(wǎng)絡(luò)營(yíng)銷(xiāo)運(yùn)營(yíng)團(tuán)隊(duì)，以豐富的互聯(lián)網(wǎng)營(yíng)銷(xiāo)經(jīng)驗(yàn)助力企業(yè)精準(zhǔn)獲客，真正落地解決中小企業(yè)營(yíng)銷(xiāo)獲客難題，做到“讓獲客更簡(jiǎn)單”。自創(chuàng)立至今，成功用技術(shù)實(shí)力解決了企業(yè)“網(wǎng)站建設(shè)、網(wǎng)絡(luò)品牌塑造、網(wǎng)絡(luò)營(yíng)銷(xiāo)”三大難題，同時(shí)降低了營(yíng)銷(xiāo)成本，提高了有效客戶(hù)轉(zhuǎn)化率，獲得了眾多企業(yè)客戶(hù)的高度認(rèn)可！
OLTP和OLAP
在互聯(lián)網(wǎng)時(shí)代，海量數(shù)據(jù)的存儲(chǔ)與訪問(wèn)成為系統(tǒng)設(shè)計(jì)與使用的瓶頸問(wèn)題，對(duì)于海量數(shù)據(jù)處理，按照使用場(chǎng)景，主要分為兩種類(lèi)型：聯(lián)機(jī)事務(wù)處理（OLTP）和聯(lián)機(jī)分析處理（OLAP）。
聯(lián)機(jī)事務(wù)處理（OLTP）也稱(chēng)為面向交易的處理系統(tǒng)，其基本特征是原始數(shù)據(jù)可以立即傳送到計(jì)算中心進(jìn)行處理，并在很短的時(shí)間內(nèi)給出處理結(jié)果。
聯(lián)機(jī)分析處理（OLAP）是指通過(guò)多維的方式對(duì)數(shù)據(jù)進(jìn)行分析、查詢(xún)和報(bào)表，可以同數(shù)據(jù)挖掘工具、統(tǒng)計(jì)分析工具配合使用，增強(qiáng)決策分析功能。
對(duì)于兩者的主要區(qū)別可以用下表來(lái)說(shuō)明：
| OLTP | OLAP | |
系統(tǒng)功能 | 日常交易處理 | 統(tǒng)計(jì)、分析、報(bào)表 |
DB 設(shè)計(jì) | 面向?qū)崟r(shí)交易類(lèi)應(yīng)用 | 面向統(tǒng)計(jì)分析類(lèi)應(yīng)用 |
數(shù)據(jù)處理 | 當(dāng)前的, 最新的細(xì)節(jié)的, 二維的分立的 | 歷史的, 聚集的, 多維的集成的, 統(tǒng)一的 |
實(shí)時(shí)性 | 實(shí)時(shí)讀寫(xiě)要求高 | 實(shí)時(shí)讀寫(xiě)要求低 |
事務(wù) | 強(qiáng)一致性 | 弱事務(wù) |
分析要求 | 低、簡(jiǎn)單 | 高、復(fù)雜 |
關(guān)系型數(shù)據(jù)庫(kù)和NoSql數(shù)據(jù)庫(kù)
針對(duì)上面兩類(lèi)系統(tǒng)有多種技術(shù)實(shí)現(xiàn)方案，存儲(chǔ)部分的數(shù)據(jù)庫(kù)主要分為兩大類(lèi)：關(guān)系型數(shù)據(jù)庫(kù)與NOSQL數(shù)據(jù)庫(kù)。
關(guān)系型數(shù)據(jù)庫(kù)，是建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫(kù)，其借助于集合代數(shù)等數(shù)學(xué)概念和方法來(lái)處理數(shù)據(jù)庫(kù)中的數(shù)據(jù)。主流的oracle、DB2、MS SQL Server和MySQL都屬于這類(lèi)傳統(tǒng)數(shù)據(jù)庫(kù)。
NoSQL數(shù)據(jù)庫(kù)，全稱(chēng)為Not Only SQL，意思就是適用關(guān)系型數(shù)據(jù)庫(kù)的時(shí)候就使用關(guān)系型數(shù)據(jù)庫(kù)，不適用的時(shí)候也沒(méi)有必要非使用關(guān)系型數(shù)據(jù)庫(kù)不可，可以考慮使用更加合適的數(shù)據(jù)存儲(chǔ)。主要分為臨時(shí)性鍵值存儲(chǔ)（memcached、redis）、永久性鍵值存儲(chǔ)（ROMA、Redis）、面向文檔的數(shù)據(jù)庫(kù)（MongoDB、CouchDB）、面向列的數(shù)據(jù)庫(kù)（Cassandra、HBase），每種NoSQL都有其特有的使用場(chǎng)景及優(yōu)點(diǎn)。
Oracle，mysql等傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)非常成熟并且已大規(guī)模商用，為什么還要用NoSQL數(shù)據(jù)庫(kù)呢？主要是由于隨著互聯(lián)網(wǎng)發(fā)展，數(shù)據(jù)量越來(lái)越大，對(duì)性能要求越來(lái)越高，傳統(tǒng)數(shù)據(jù)庫(kù)存在著先天性的缺陷，即單機(jī)（單庫(kù)）性能瓶頸，并且擴(kuò)展困難。這樣既有單機(jī)單庫(kù)瓶頸，卻又?jǐn)U展困難，自然無(wú)法滿(mǎn)足日益增長(zhǎng)的海量數(shù)據(jù)存儲(chǔ)及其性能要求，所以才會(huì)出現(xiàn)了各種不同的NoSQL產(chǎn)品，NoSQL根本性的優(yōu)勢(shì)在于在云計(jì)算時(shí)代，簡(jiǎn)單、易于大規(guī)模分布式擴(kuò)展，并且讀寫(xiě)性能非常高。
下面分析下兩者的特點(diǎn)，及優(yōu)缺點(diǎn)：
關(guān)系型數(shù)據(jù)庫(kù)
1) 關(guān)系數(shù)據(jù)庫(kù)的特點(diǎn)是：
- 數(shù)據(jù)關(guān)系模型基于關(guān)系模型，結(jié)構(gòu)化存儲(chǔ)，完整性約束。
- 基于二維表及其之間的聯(lián)系，需要連接、并、交、差、除等數(shù)據(jù)操作。
- 采用結(jié)構(gòu)化的查詢(xún)語(yǔ)言（SQL）做數(shù)據(jù)讀寫(xiě)。
- 操作需要數(shù)據(jù)的一致性，需要事務(wù)甚至是強(qiáng)一致性。
2) 優(yōu)點(diǎn)：
- 保持?jǐn)?shù)據(jù)的一致性（事務(wù)處理）
- 可以進(jìn)行join等復(fù)雜查詢(xún)。
- 通用化，技術(shù)成熟。
3) 缺點(diǎn):
- 數(shù)據(jù)讀寫(xiě)必須經(jīng)過(guò)sql解析，大量數(shù)據(jù)、高并發(fā)下讀寫(xiě)性能不足。
- 對(duì)數(shù)據(jù)做讀寫(xiě)，或修改數(shù)據(jù)結(jié)構(gòu)時(shí)需要加鎖，影響并發(fā)操作。
- 無(wú)法適應(yīng)非結(jié)構(gòu)化存儲(chǔ)。
- 擴(kuò)展困難。
- 昂貴、復(fù)雜。
NoSQL數(shù)據(jù)庫(kù)
1) NoSQL數(shù)據(jù)庫(kù)的特點(diǎn)是：
- 非結(jié)構(gòu)化的存儲(chǔ)。
- 基于多維關(guān)系模型。
- 具有特有的使用場(chǎng)景。
2) 優(yōu)點(diǎn)：
- 高并發(fā)，大數(shù)據(jù)下讀寫(xiě)能力較強(qiáng)。
- 基本支持分布式，易于擴(kuò)展，可伸縮。
- 簡(jiǎn)單，弱結(jié)構(gòu)化存儲(chǔ)。
3) 缺點(diǎn):
- join等復(fù)雜操作能力較弱。
- 事務(wù)支持較弱。
- 通用性差。
- 無(wú)完整約束復(fù)雜業(yè)務(wù)場(chǎng)景支持較差。
雖然在云計(jì)算時(shí)代，傳統(tǒng)數(shù)據(jù)庫(kù)存在著先天性的弊端，但是NoSQL數(shù)據(jù)庫(kù)又無(wú)法將其替代，NoSQL只能作為傳統(tǒng)數(shù)據(jù)的補(bǔ)充而不能將其替代，所以規(guī)避傳統(tǒng)數(shù)據(jù)庫(kù)的缺點(diǎn)是目前大數(shù)據(jù)時(shí)代必須要解決的問(wèn)題。如果傳統(tǒng)數(shù)據(jù)易于擴(kuò)展，可切分，就可以避免單機(jī)（單庫(kù)）的性能缺陷，但是由于目前開(kāi)源或者商用的傳統(tǒng)數(shù)據(jù)庫(kù)基本不支持大規(guī)模自動(dòng)擴(kuò)展，所以就需要借助第三方來(lái)做處理，那就是本書(shū)要講的數(shù)據(jù)切分，下面就來(lái)分析一下如何進(jìn)行數(shù)據(jù)切分。
何為數(shù)據(jù)切分？
簡(jiǎn)單來(lái)說(shuō)，就是指通過(guò)某種特定的條件，將我們存放在同一個(gè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)分散存放到多個(gè)數(shù)據(jù)庫(kù)（主機(jī)）上面，以達(dá)到分散單臺(tái)設(shè)備負(fù)載的效果。
數(shù)據(jù)的切分（Sharding）根據(jù)其切分規(guī)則的類(lèi)型，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來(lái)切分到不同的數(shù)據(jù)庫(kù)（主機(jī)）之上，這種切可以稱(chēng)之為數(shù)據(jù)的垂直（縱向）切分；另外一種則是根據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個(gè)表中的數(shù)據(jù)按照某種條件拆分到多臺(tái)數(shù)據(jù)庫(kù)（主機(jī)）上面，這種切分稱(chēng)之為數(shù)據(jù)的水平（橫向）切分。
垂直切分的最大特點(diǎn)就是規(guī)則簡(jiǎn)單，實(shí)施也更為方便，尤其適合各業(yè)務(wù)之間的耦合度非常低，相互影響很小，業(yè)務(wù)邏輯非常清晰的系統(tǒng)。在這種系統(tǒng)中，可以很容易做到將不同業(yè)務(wù)模塊所使用的表分拆到不同的數(shù)據(jù)庫(kù)中。根據(jù)不同的表來(lái)進(jìn)行拆分，對(duì)應(yīng)用程序的影響也更小，拆分規(guī)則也會(huì)比較簡(jiǎn)單清晰。
水平切分于垂直切分相比，相對(duì)來(lái)說(shuō)稍微復(fù)雜一些。因?yàn)橐獙⑼粋€(gè)表中的不同數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)中，對(duì)于應(yīng)用程序來(lái)說(shuō)，拆分規(guī)則本身就較根據(jù)表名來(lái)拆分更為復(fù)雜，后期的數(shù)據(jù)維護(hù)也會(huì)更為復(fù)雜一些。
垂直切分
一個(gè)數(shù)據(jù)庫(kù)由很多表的構(gòu)成，每個(gè)表對(duì)應(yīng)著不同的業(yè)務(wù)，垂直切分是指按照業(yè)務(wù)將表進(jìn)行分類(lèi)，分布到不同的數(shù)據(jù)庫(kù)上面，這樣也就將數(shù)據(jù)或者說(shuō)壓力分擔(dān)到不同的庫(kù)上面，如下圖：
系統(tǒng)被切分成了，用戶(hù)，訂單交易，支付幾個(gè)模塊。
一個(gè)架構(gòu)設(shè)計(jì)較好的應(yīng)用系統(tǒng)，其總體功能肯定是由很多個(gè)功能模塊所組成的，而每一個(gè)功能模塊所需要的數(shù)據(jù)對(duì)應(yīng)到數(shù)據(jù)庫(kù)中就是一個(gè)或者多個(gè)表。而在架構(gòu)設(shè)計(jì)中，各個(gè)功能模塊相互之間的交互點(diǎn)越統(tǒng)一越少，系統(tǒng)的耦合度就越低，系統(tǒng)各個(gè)模塊的維護(hù)性以及擴(kuò)展性也就越好。這樣的系統(tǒng)，實(shí)現(xiàn)數(shù)據(jù)的垂直切分也就越容易。
但是往往系統(tǒng)之有些表難以做到完全的獨(dú)立，存在這擴(kuò)庫(kù)join的情況，對(duì)于這類(lèi)的表，就需要去做平衡，是數(shù)據(jù)庫(kù)讓步業(yè)務(wù)，共用一個(gè)數(shù)據(jù)源，還是分成多個(gè)庫(kù)，業(yè)務(wù)之間通過(guò)接口來(lái)做調(diào)用。在系統(tǒng)初期，數(shù)據(jù)量比較少，或者資源有限的情況下，會(huì)選擇共用數(shù)據(jù)源，但是當(dāng)數(shù)據(jù)發(fā)展到了一定的規(guī)模，負(fù)載很大的情況，就需要必須去做分割。
一般來(lái)講業(yè)務(wù)存在著復(fù)雜join的場(chǎng)景是難以切分的，往往業(yè)務(wù)獨(dú)立的易于切分。如何切分，切分到何種程度是考驗(yàn)技術(shù)架構(gòu)的一個(gè)難題。
下面來(lái)分析下垂直切分的優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)：
· 拆分后業(yè)務(wù)清晰，拆分規(guī)則明確。
· 系統(tǒng)之間整合或擴(kuò)展容易。
· 數(shù)據(jù)維護(hù)簡(jiǎn)單。
缺點(diǎn)：
· 部分業(yè)務(wù)表無(wú)法join，只能通過(guò)接口方式解決，提高了系統(tǒng)復(fù)雜度。
· 受每種業(yè)務(wù)不同的限制存在單庫(kù)性能瓶頸，不易數(shù)據(jù)擴(kuò)展跟性能提高。
· 事務(wù)處理復(fù)雜。
由于垂直切分是按照業(yè)務(wù)的分類(lèi)將表分散到不同的庫(kù)，所以有些業(yè)務(wù)表會(huì)過(guò)于龐大，存在單庫(kù)讀寫(xiě)與存儲(chǔ)瓶頸，所以就需要水平拆分來(lái)做解決。
水平切分
相對(duì)于垂直拆分，水平拆分不是將表做分類(lèi)，而是按照某個(gè)字段的某種規(guī)則來(lái)分散到多個(gè)庫(kù)之中，每個(gè)表中包含一部分?jǐn)?shù)據(jù)。簡(jiǎn)單來(lái)說(shuō)，我們可以將數(shù)據(jù)的水平切分理解為是按照數(shù)據(jù)行的切分，就是將表中的某些行切分到一個(gè)數(shù)據(jù)庫(kù)，而另外的某些行又切分到其他的數(shù)據(jù)庫(kù)中，如圖：
拆分?jǐn)?shù)據(jù)就需要定義分片規(guī)則。關(guān)系型數(shù)據(jù)庫(kù)是行列的二維模型，拆分的第一原則是找到拆分維度。比如：從會(huì)員的角度來(lái)分析，商戶(hù)訂單交易類(lèi)系統(tǒng)中查詢(xún)會(huì)員某天某月某個(gè)訂單，那么就需要按照會(huì)員結(jié)合日期來(lái)拆分，不同的數(shù)據(jù)按照會(huì)員ID做分組，這樣所有的數(shù)據(jù)查詢(xún)join都會(huì)在單庫(kù)內(nèi)解決；如果從商戶(hù)的角度來(lái)講，要查詢(xún)某個(gè)商家某天所有的訂單數(shù)，就需要按照商戶(hù)ID做拆分；但是如果系統(tǒng)既想按會(huì)員拆分，又想按商家數(shù)據(jù)，則會(huì)有一定的困難。如何找到合適的分片規(guī)則需要綜合考慮衡量。
幾種典型的分片規(guī)則包括：
· 按照用戶(hù)ID求模，將數(shù)據(jù)分散到不同的數(shù)據(jù)庫(kù)，具有相同數(shù)據(jù)用戶(hù)的數(shù)據(jù)都被分散到一個(gè)庫(kù)中。
· 按照日期，將不同月甚至日的數(shù)據(jù)分散到不同的庫(kù)中。
· 按照某個(gè)特定的字段求摸，或者根據(jù)特定范圍段分散到不同的庫(kù)中。
如圖，切分原則都是根據(jù)業(yè)務(wù)找到適合的切分規(guī)則分散到不同的庫(kù)，下面用用戶(hù)ID求模舉例：
既然數(shù)據(jù)做了拆分有優(yōu)點(diǎn)也就優(yōu)缺點(diǎn)。
優(yōu)點(diǎn)：
· 拆分規(guī)則抽象好，join操作基本可以數(shù)據(jù)庫(kù)做。
· 不存在單庫(kù)大數(shù)據(jù)，高并發(fā)的性能瓶頸。
· 應(yīng)用端改造較少。
· 提高了系統(tǒng)的穩(wěn)定性跟負(fù)載能力。
缺點(diǎn)：
· 拆分規(guī)則難以抽象。
· 分片事務(wù)一致性難以解決。
· 數(shù)據(jù)多次擴(kuò)展難度跟維護(hù)量極大。
· 跨庫(kù)join性能較差。
前面講了垂直切分跟水平切分的不同跟優(yōu)缺點(diǎn)，會(huì)發(fā)現(xiàn)每種切分方式都有缺點(diǎn)，但共同的特點(diǎn)缺點(diǎn)有：
· 引入分布式事務(wù)的問(wèn)題。
· 跨節(jié)點(diǎn)Join的問(wèn)題。
· 跨節(jié)點(diǎn)合并排序分頁(yè)問(wèn)題。
· 多數(shù)據(jù)源管理問(wèn)題。
針對(duì)數(shù)據(jù)源管理，目前主要有兩種思路：
A. 客戶(hù)端模式，在每個(gè)應(yīng)用程序模塊中配置管理自己需要的一個(gè)（或者多個(gè)）數(shù)據(jù)源，直接訪問(wèn)各個(gè)數(shù)據(jù)庫(kù)，在模塊內(nèi)完成數(shù)據(jù)的整合；
B. 通過(guò)中間代理層來(lái)統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫(kù)集群對(duì)前端應(yīng)用程序透明；
可能90%以上的人在面對(duì)上面這兩種解決思路的時(shí)候都會(huì)傾向于選擇第二種，尤其是系統(tǒng)不斷變得龐大復(fù)雜的時(shí)候。確實(shí)，這是一個(gè)非常正確的選擇，雖然短期內(nèi)需要付出的成本可能會(huì)相對(duì)更大一些，但是對(duì)整個(gè)系統(tǒng)的擴(kuò)展性來(lái)說(shuō)，是非常有幫助的。
Mycat 通過(guò)數(shù)據(jù)切分解決傳統(tǒng)數(shù)據(jù)庫(kù)的缺陷，又有了NoSQL易于擴(kuò)展的優(yōu)點(diǎn)。通過(guò)中間代理層規(guī)避了多數(shù)據(jù)源的處理問(wèn)題，對(duì)應(yīng)用完全透明，同時(shí)對(duì)數(shù)據(jù)切分后存在的問(wèn)題，也做了解決方案。下面章節(jié)就分析，mycat的由來(lái)及如何進(jìn)行數(shù)據(jù)切分問(wèn)題。
由于數(shù)據(jù)切分后數(shù)據(jù)Join的難度在此也分享一下數(shù)據(jù)切分的經(jīng)驗(yàn)：
第一原則：能不切分盡量不要切分。
第二原則：如果要切分一定要選擇合適的切分規(guī)則，提前規(guī)劃好。
第三原則：數(shù)據(jù)切分盡量通過(guò)數(shù)據(jù)冗余或表分組（Table Group）來(lái)降低跨庫(kù)Join的可能。
第四原則：由于數(shù)據(jù)庫(kù)中間件對(duì)數(shù)據(jù)Join實(shí)現(xiàn)的優(yōu)劣難以把握，而且實(shí)現(xiàn)高性能難度極大，業(yè)務(wù)讀取盡量少使用多表Join。
什么是mycat，maycat從哪里來(lái)，又是如何解決這些問(wèn)題的，下一章讓我們來(lái)作分析。
更多內(nèi)容關(guān)注微信公眾號(hào)：it_haha
網(wǎng)站名稱(chēng)：mycat系列-概述
網(wǎng)站地址：http://www.dlmjj.cn/article/ppohsd.html
