系統分析：OLAP or OLTP?

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

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

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

OLTP和OLAP的比較。OLTP面向實時交易類，實時要求性高，查詢分析功能偏弱。OLAP面向統計分析類，實時性要求一般，涉及到大範圍掃描，JOIN，聚合查詢等，要求有比較高的查詢分析能力。

MySQL適合OLTP型別的系統，因為MySQL的分析支援比較弱，適合高併發的小的查詢操作。在進行資料庫技術選型及選擇解決方案之前，必須對系統是OLTP還是OLAP做出準確的判斷。

技術選型：關係型資料庫 or NoSQL資料庫 ?

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

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

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

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

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

雖然在雲端計算時代，傳統資料庫存在著先天性的弊端，但是 NoSQL 資料庫又無法將其替代，NoSQL 只能作為傳統資料的補充而不能將其替代，所以規避傳統資料庫的缺點是目前大資料時代必須要解決的問題。如果傳統資料易於擴充套件，可切分，就可以避免單機(單庫)的效能缺陷，但是由於目前開源或者商用的傳統資料庫基本不支援大規模自動擴充套件，所以就需要藉助第三方來做處理，那就是下面要講的資料切分，下面就來分析一下如何進行資料切分。

資料切分：解決單庫瓶頸

在同一個資料庫中的資料分散存放到多個數據庫(主 機)上面，以達到分散單臺裝置負載的效果。資料的切分(Sharding)根據其切分規則的型別，可以分為兩種切分模式。

 垂直切分

按照不同的表(或者Schema)來切分到不同的資料庫(主機)之上，這種切可以稱之為資料的垂直(縱向)切分。

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

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

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

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

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

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

    優點:

• 拆分後業務清晰，拆分規則明確;
• 系統之間整合或擴充套件容易;
• 資料維護簡單。

    缺點:

• 部分業務表無法 join，只能通過介面方式解決，提高了系統複雜度;
• 受每種業務不同的限制存在單庫效能瓶頸，不易資料擴充套件跟效能提高;
• 事務處理複雜。

水平切分

另外一種則是根據 表中的資料的邏輯關係，將同一個表中的資料按照某種條件拆分到多臺資料庫(主機)上面，這種切分稱之為資料的水平(橫向)切分。

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

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

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

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

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

• 按照某個特定的欄位求摸，或者根據特定範圍段分散到不同的庫中。 如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面用使用者ID求模舉例:

   優點:

• 拆分規則抽象好，join 操作基本可以資料庫做;
• 不存在單庫大資料，高併發的效能瓶頸;
• 應用端改造較少;
• 提高了系統的穩定性跟負載能力。

    缺點：

• 拆分規則難以抽象；
• 分片事務一致性難以解決；
• 資料多次擴充套件難度及維護量大；
• 跨庫join效能較差；

    前面講了垂直切分跟水平切分的不同跟優缺點，會發現每種切分方式都有缺點，但共同的特點缺點有:

•  引入分散式事務的問題;
• 跨節點 Join 的問題;
• 跨節點合併排序分頁問題;
• 多資料來源管理問題。

    針對這些問題的討論和解決方案會在下一篇說到。

    資料切分解決傳統資料庫的缺陷，又有了 NoSQL 易於擴充套件的優點。

MySQL：做分散式資料庫的優勢

關於Oracle和MySQL的對比。

關於這兩資料庫的全方位的多維度的優劣對比，比較有經驗的資料庫開發人員應該能列舉出很多來，我身為一名普通的應用開發人員，寫不出什麼硬核的分析對比，只能大概表達一些我的理解。

Oracle簡單概括：功能，效能，穩定，人才；MySQL簡單概括：靈活，簡單，便宜，開源。

Oracle的發展歷史是MySQL的兩倍以上，現在已經是很成熟的商業資料庫系統。Oracle為使用者提供了非常豐富強大的功能，可程式設計和分析函式的支援都做到非常完善，還有無限的行級鎖，最高級別的隔離級別，完全的事務支援，成熟的熱備工具，穩定可靠但複雜的高可用配置，還有大批有經驗的DBA人才，總之，如果你想要一個穩定可靠並且效能強大的資料庫單叢集，那Oracle是完美的。But，如果使用分散式解決方案，昂貴的Oracle也會給你帶來驚人的license費用，Oracle的功能看上去豐富而全面，但是那都是要錢的，有時候我們並不需要其中的很多東西，Oracle缺少可定製化的靈活性。

MySQL有開源和靈活的優勢，輕便的MySQL雖然功能性沒有Oracle強大，但是作為資料庫，最重要和核心的功能都做的很好。MySQL非常靈活，針對每個表都能指定不同的儲存引擎，InnoDB引擎支援依賴於索引的行級鎖；同時MySQL提供了簡單高速的主從複製配置，能提供快速冗餘的專業叢集伺服器；MySQL的開源特性，讓網際網路團隊可以自研支援MySQL協議的代理中介軟體來支援實現MySQL的分散式叢集，同時可以靈活定製修改MySQL細節功能，目前基於MySQL的分散式資料庫基本都是採用這一方式。

下一篇將分享一些MySQL分片的問題討論。

本文參考：