一、數據處理分類
1. 海量數據處理，按照使用場景主要分為兩種類型：
聯機事務處理（OLTP）
面向交易的處理系統，其基本特征是原始數據可以立即傳送到計算機中心進行處理，並在很短的時間內給出處理結果。簡單地說，主要是對數據的插入、修改、刪除，所以對事物和實時性要求比較高。
聯機分析處理（OLAP）
通過多維的方式對數據進行分析、查詢和報表，可以同數據挖掘工具、統計分析工具配合使用，增強決策分析功能。簡單地說，主要是對海量數據的查詢統計分析
2. OLTP和OLAP的比較
| OLTP | OLAP | |
| 系統功能 | 日常交易處理 | 統計、分析、報表 |
| DB設計 | 面向實時交易類應用 | 面向統計分析類應用 |
| 數據處理 | 當前的、最新細節的、二維的分立的 | 歷史的、聚集的、多維集成的、統一的 |
| 實時性 | 實時讀寫要求高 | 實時讀寫要求低 |
| 事物 | 強一致性 | 弱事物 |
| 分析要求 | 低、簡單 | 高、復雜 |
二、常用數據庫分類
傳統數據庫：
Oracle、Mysql、SQLserver、DB2
NoSQL數據庫：
臨時性鍵值存儲——Redis、Memcached
永久性鍵值存儲——Redis、ROMA
面向文檔存儲——MongoDB、CouchDB
面向列存儲——Cassandra、HBase
傳統數據庫與NoSQL數據庫對比：
| 傳統數據庫 | NoSQL數據庫 | |
| 特點 | 數據關系模型基於關系模型、結構化存儲、完整性約束。 基於二維表及其之間的聯系，需要連接、並、交、差、除等數據操作。 采用結構化的查詢語言（SQL）做數據讀寫。 操作需要數據的一致性，需要事物甚至是強一致性。 |
非結構化的存儲。 基於多維關系模型。 具有特定的使用場景。 |
| 優點 | 保持數據的一致性（事物處理）。 可以進行join等復雜查詢。 通用化，技術成熟。 |
高並發，大數據下讀寫分離能力較強。 基本支持分布式，易於擴展，可伸縮。 簡單，弱結構化存儲。 |
| 缺點 | 數據讀寫需要經過sql解析，大量數據、高並發下讀寫性能不足。 對數據做讀寫，或修改數據結構時需要加鎖，影響並發操作。 無法適應非結構化存儲。 擴展困難。昂貴、復雜。 |
Join等復雜操作能力較弱。 事物支持較弱。 通用性差。 無法完整約束復雜業務場景支持較差。 |
三、分庫分表
1. 常規未進行分庫分表的情況
2. 解決上面的這種情況的方法——分庫分表
把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲於多個表上
分庫分表的目的：分散單台設備的負載
3. 數據切分
分庫分表的基本思想：數據切分
數據切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式：
垂直（縱向）切分：
將不同的表（或者Schema）拆分到不同的數據庫（主機）上。
說明：這種切分方式是根據業務來切分的，比如我有2個系統，分別是訂單支付系統和用戶信息系統，在之前所有的表都是在一個庫里面，現在做業務拆分，就把訂單支付相關的表都放在訂單支付的庫里面，用戶信息相關的表都放在用戶信息的庫里面
水平（橫向）切分：
根據表中數據的邏輯關系，將同一張表中的數據安裝某種條件拆分到多台數據庫（主機）的同一表結構的表中。
說明：這種拆分方式是拆表的，簡單的說，就是根據表中的某個字段對表進行拆分，比如我有一個訂單表，隨着年份的變化數據量越來越大，這個時候就需要根據年份來把表中的數據拆分到不同數據庫（主機）的訂單表里面去了
垂直（縱向）切分與水平（橫向）切分的比較：
| 垂直切分 | 水平切分 | |
| 特點 | 規則簡單，實施方便。 業務之間耦合度非常低，相互影響很小。 根據不同的表來進行拆分，對應用程序的影響也更小。 |
將同一個表中的不同數據拆分到不同的數據庫。 對應用程序來說，表的命名比垂直拆分更復雜。 后期的數據維護也會復雜。 |
| 優點 | 系統之間的整合或擴展容易。 拆分后業務清晰，拆分規則明確。 數據維護簡單。 |
拆分規則抽象好，Join操作基本可以數據庫做。 不存在單庫大數據和高並發性能瓶頸。 應用端改造較少。 提高了系統的穩定性跟負載能力。 |
| 缺點 | 部分業務無法join，只能通過接口方式解決，提高了系統復雜度。 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。 事務處理復雜。 |
拆分規則難以抽象。 分片事物一致性難以解決。 數據多次擴展跟維護量極大。 跨庫Join性能較差。 |
4. 分庫分表需要應對的技術難題
4.1 分布式全局唯一id
解決方法：
1）數據庫自增：針對同一張表，在每個數據庫建表的時候設置步長（step）
2）UUID/GUID
3）Redis Increment
4）MongoDB ObjectId（類似UUID的方式）
5）Zookeeper分布式鎖
6）Twitter的Snowflake（又叫雪花算法）
7）Ticket Server（數據庫生存方式，Flickr采用的就是這種方式）
4.2 分片規則和策略
1）分片字段的選擇
2）分片規則
3）數據遷移，容量規划，擴容等
4.3 跨分片技術問題
1）跨分片的排序分頁 limit 1 5
2）跨分片函數處理
3）跨分片join
4.4 跨分片事物問題
1）強一致性問題
2）弱一致性問題/最終一致性
5. 分庫分表中間件有哪些
1）Cobar
Cobar是來自阿里的mysql中間件,但是現在已經很久沒有更新了，它可以在分布式的環境下看上去像傳統數據庫一樣為您提供海量數據服務
2）Sharding JDBC
當當應用框架ddframe中，從關系型數據庫模塊dd-rdb中分離出來的數據庫水平分片框架，實現透明化數據庫分庫分表訪問
3）TDDL
淘寶根據自身業務需求研發了TDDL（Taobao Distributed Data Layer 外號頭都大了）框架，主要用於解決分庫分表場景下的訪問路由（持久層與數據訪問層的配合）以及異構數據庫之間的數據同步，它是一個基於集中式配置的JDBC DataSource實現，具有分庫分表、讀寫分離（Master/Salve）、動態數據源配置等功能。
4）Mycat
一個開源的分布式數據庫系統，實現了mysql協議的服務器。前端用戶可以把它看作是一個數據庫代理，用mysql客戶端工具和命令行訪問，而其后端可以用mysql原生協議與多個mysql服務器通信，也可以用jdbc協議與大多數主流數據庫服務器通信
這幾種中間件的對比：
6. mycat分庫分表中間件解決分庫分表過程中面對的各種技術問題
6.1 分布式全局唯一id
多種分布式全局唯一id的實現方式
6.2 分片規則和策略
多種分片規則和策略，甚至可以自定義
6.3 跨分片技術問題
多種分片規則和策略，甚至可以自定義
6.4 跨分片事物問題
單庫內保證事物的完整性，跨庫事物弱XA（最終一致性）
mycat其他特點：
1）可以通過mycat統一管理所有數據源，后端數據庫集群對前端應用程序透明
2）獨創的ER關系分片，解決ER分片難處理問題
3）采用全局分片技術，每個節點同時並發插入和更新數據，每個節點都可以讀取數據
4）通過人工智能的Catlet支持分片復雜SQL實現以及存儲過程支持等