關於資料庫切分的一些基礎概念總結--垂直切分+水平切分

人員切分什麼意思

概述

抽空整理了一下目前資料庫切分的一些概念，偏基礎，僅供參考。

OLTP/OLAP-->關係型和NOSQL-->資料切分-->垂直切分+水平切分

1、 OLTP 和 OLAP

在網際網路時代，海量資料的儲存與訪問成為系統設計與使用的瓶頸問題，對於海量資料處理，按照使用場景，主要分為兩種型別：聯機事務處理（OLTP）和聯機分析處理（OLAP）。

聯機事務處理（OLTP）也稱為面向交易的處理系統，其基本特徵是原始資料可以立即傳送到計算中心進行處理，並在很短的時間內給出處理結果。

聯機分析處理（OLAP）是指透過多維的方式對資料進行分析、查詢和報表，可以同資料探勘工具、統計分析工具配合使用，增強決策分析功能。

對於兩者的主要區別可以用下表來說明：

2、關係型資料庫和 NoSQL 資料庫

針對上面兩類系統有多種技術實現方案，儲存部分的資料庫主要分為兩大類：關係型資料庫與 NoSQL 資料庫。

關係型資料庫，是建立在關係模型基礎上的資料庫，其藉助於集合代數等數學概念和方法來處理資料庫中的資料。主流的 oracle、DB2、MS SQL Server 和 mysql 都屬於這類傳統資料庫。

NoSQL 資料庫，全稱為 Not Only SQL，意思就是適用關係型資料庫的時候就使用關係型資料庫，不適用的時候也沒有必要非使用關係型資料庫不可，可以考慮使用更加合適的資料儲存。主要分為臨時性鍵值儲存（memcached、Redis）、永久性鍵值儲存（ROMA、Redis）、面向文件的資料庫（MongoDB、CouchDB）、面向列的資料庫（Cassandra、HBase），每種 NoSQL 都有其特有的使用場景及優點。

Oracle，mysql 等傳統的關係資料庫非常成熟並且已大規模商用，為什麼還要用 NoSQL 資料庫呢？主要是由於隨著網際網路發展，資料量越來越大，對效能要求越來越高，傳統資料庫存在著先天性的缺陷，即單機（單庫）效能瓶頸，並且擴充套件困難。這樣既有單機單庫瓶頸，卻又擴充套件困難，自然無法滿足日益增長的海量資料儲存及其效能要求，所以才會出現了各種不同的 NoSQL 產品，NoSQL 根本性的優勢在於在雲計算時代，簡單、易於大規模分散式擴充套件，並且讀寫效能非常高。

下面分析下兩者的特點，及優缺點：

雖然在雲計算時代，傳統資料庫存在著先天性的弊端，但是 NoSQL 資料庫又無法將其替代，NoSQL 只能作為傳統資料的補充而不能將其替代，由於目前開源或者商用的傳統資料庫基本不支援大規模自動擴充套件，所以就需要藉助第三方來做處理，也就是資料切分。

3、資料切分？

簡單來說，就是指透過某種特定的條件，將我們存放在同一個資料庫中的資料分散存放到多個數據庫（主機）上面，以達到分散單臺裝置負載的效果。

資料的切分（Sharding）根據其切分規則的型別，可以分為兩種切分模式。

一種是按照不同的表（或者Schema）來切分到不同的資料庫（主機）之上，這種切可以稱之為資料的垂直（縱向）切分；另外一種則是根據表中的資料的邏輯關係，將同一個表中的資料按照某種條件拆分到多臺資料庫（主機）上面，這種切分稱之為資料的水平（橫向）切分。

垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模組所使用的表分拆到不同的資料庫中。根據不同的表來進行拆分，對應用程式的影響也更小，拆分規則也會比較簡單清晰。

水平切分於垂直切分相比，相對來說稍微複雜一些。因為要將同一個表中的不同資料拆分到不同的資料庫中，對於應用程式來說，拆分規則本身就較根據表名來拆分更為複雜，後期的資料維護也會更為複雜一些。

4、 垂直切分

一個數據庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分佈到不同的資料庫上面，這樣也就將資料或者說壓力分擔到不同的庫上面，如下圖：

系統被切分成了使用者，訂單交易，支付幾個模組

一個架構設計較好的應用系統，其總體功能肯定是由很多個功能模組所組成的，而每一個功能模組所需要的資料對應到資料庫中就是一個或者多個表。而在架構設計中，各個功能模組相互之間的互動點越統一越少，系統的耦合度就越低，系統各個模組的維護性以及擴充套件性也就越好。這樣的系統，實現資料的垂直切分也就越容易。

但是往往系統之有些表難以做到完全的獨立，存在這擴庫 join 的情況，對於這類的表，就需要去做平衡，是資料庫讓步業務，共用一個數據源，還是分成多個庫，業務之間透過介面來做呼叫。在系統初期，資料量比較少，或者資源有限的情況下，會選擇共用資料來源，但是當資料發展到了一定的規模，負載很大的情況，就需要必須去做分割。

一般來講業務存在著複雜 join 的場景是難以切分的，往往業務獨立的易於切分。如何切分，切分到何種程度是考驗技術架構的一個難題。

下面來分析下垂直切分的優缺點：

優點：

• 拆分後業務清晰，拆分規則明確；

• 系統之間整合或擴充套件容易；

• 資料維護簡單。

缺點：

• 部分業務表無法 join，只能透過介面方式解決，提高了系統複雜度；

• 受每種業務不同的限制存在單庫效能瓶頸，不易資料擴充套件跟效能提高；

• 事務處理複雜。

由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與儲存瓶頸，所以就需要水平拆分來做解決。

5、 水平切分

相對於垂直拆分，水平拆分不是將表做分類，而是按照某個欄位的某種規則來分散到多個庫之中，每個表中包含一部分資料。簡單來說，我們可以將資料的水平切分理解為是按照資料行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的資料庫中，如圖：

拆分資料就需要定義分片規則。關係型資料庫是行列的二維模型，拆分的第一原則是找到拆分維度。比如：從會員的角度來分析，商戶訂單交易類系統中查詢會員某天某月某個訂單，那麼就需要按照會員結合日期來拆分，不同的資料按照會員 ID 做分組，這樣所有的資料查詢 join 都會在單庫內解決；如果從商戶的角度來講，要查詢某個商家某天所有的訂單數，就需要按照商戶 ID 做拆分；但是如果系統既想按會員拆分，又想按商家資料，則會有一定的困難。如何找到合適的分片規則需要綜合考慮衡量。

幾種典型的分片規則包括：

• 按照使用者 ID 求模，將資料分散到不同的資料庫，具有相同資料使用者的資料都被分散到一個庫中；

• 按照日期，將不同月甚至日的資料分散到不同的庫中；

• 按照某個特定的欄位求摸，或者根據特定範圍段分散到不同的庫中。

如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面用使用者 ID 求模舉例：

既然資料做了拆分有優點也就優缺點。

優點：

• 拆分規則抽象好，join 操作基本可以資料庫做；

• 不存在單庫大資料，高併發的效能瓶頸；

• 應用端改造較少；

• 提高了系統的穩定性跟負載能力。

缺點：

• 拆分規則難以抽象；

• 分片事務一致性難以解決；

• 資料多次擴充套件難度跟維護量極大；

• 跨庫 join 效能較差。

覺得有用的朋友多幫忙轉發哦！後面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~