1. 什么是分庫分表
1.1 數據庫瓶頸
1.1.1 IO瓶頸
- 磁盤讀IO瓶頸，熱點數據太多，數據庫緩存放不下，每次查詢時會產生大量的IO，降低查詢速度 -> 分庫和垂直分表
- 網絡IO瓶頸，請求的數據太多，網絡帶寬不夠 -> 分庫
1.1.2 CPU瓶頸
- SQL問題，如SQL中包含join，group by，order by，非索引字段條件查詢等，增加CPU運算的操作 -> SQL優化，建立合適的索引，在業務Service層進行業務計算
- 單表數據量太大，查詢時掃描的行太多，SQL效率低，CPU率先出現瓶頸 -> 水平分表
1.2 分庫分表
分庫分表有兩種方式：垂直切分和水平切分。其中垂直切分包含垂直分表和垂直分庫；水平切分包含水平分表和水平分庫。
1.2.1 水平分庫
1.2.2 水平分表
1.2.3 垂直分庫
1.2.4 垂直分表
1.3 分庫分表的應用和問題
隨着數據庫數據量的增加，開發者不應該馬上考慮做水平切分，應該首先考慮使用緩存、讀寫分離、索引優化等手段（原因在於分庫分表后會引入一些問題，如：跨節點連接查詢[join]、排序[order by]、計數[count]、分組[group by]、分頁等操作的復雜度提高；以及多數據源的管理問題），如果這些方式不能根本性解決問題，再考慮分庫分表。同時在數據庫設計的時候就要考慮到垂直分庫和垂直分表。
2. Apache ShardingSphere是什么
關於ShardingSphere ，可以參考其官網介紹：
2.1 ShardingSphere-JDBC
定位為輕量級 Java 框架，在 Java 的 JDBC 層提供的額外服務。 它使用客戶端直連數據庫，以 jar 包形式提供服務，無需額外部署和依賴，可理解為增強版的 JDBC 驅動，完全兼容 JDBC 和各種 ORM 框架。
- 適用於任何基於 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
- 支持任何第三方的數據庫連接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
- 支持任意實現 JDBC 規范的數據庫，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 標准的數據庫。
2.2 ShardingSphere-Proxy
定位為透明化的數據庫代理端，提供封裝了數據庫二進制協議的服務端版本，用於完成對異構語言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 協議的訪問客戶端(如：MySQL Command Client, MySQL Workbench, Navicat 等)操作數據，對 DBA 更加友好。
- 向應用程序完全透明，可直接當做 MySQL/PostgreSQL 使用。
- 適用於任何兼容 MySQL/PostgreSQL 協議的的客戶端。
2.3 ShardingSphere-Sidecar(TODO)
該模塊目前還在開發中，這里不予探究。
2.4 混合架構
上面是三者之間的對比，結合之前的介紹，不難看出，ShardingSphere-JDBC 采用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；ShardingSphere-Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片數據庫進行管理和運維的場景。
Apache ShardingSphere 是多接入端共同組成的生態圈。 通過混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，並采用同一注冊中心統一配置分片策略，能夠靈活的搭建適用於各種場景的應用系統，使得架構師更加自由地調整適合與當前業務的最佳系統架構。
