小明是一家初創(chuàng)電商平臺的開發(fā)人員，他負責賣家模塊的功能開發(fā)，其中涉及了店鋪、商品的相關(guān)業(yè)務，設(shè)計如下數(shù)據(jù)庫 ：
SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽] FROM [商品信息] p LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪] WHERE p.id = ?
形成類似以下列表展示 ：
分庫分表包括分庫和分表兩個部分，在生產(chǎn)中通常包括 ：垂直分庫、水平分庫、垂直分表、水平分表四種方式。
下邊通過一個商品查詢的案例來垂直分表 ：
通常在商品列表中是不是顯示商品詳情信息的，如下圖 ：
SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽] FROM [商品信息] p LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪] WHERE...ORDER BY...LIMIT...
需要獲取商品描述時，再通過以下sql獲取 ：
SELECT * FROM [商品描述] WHERE [商品ID] = ?
小明進行的這一步優(yōu)化，就叫垂直分表。
垂直分表定義 ：將一個表按照字段分成多表，每個表存儲其中一部分字段。
它帶來的提升是 ：
1.為了避免IO爭搶并減少鎖表的幾率，查看詳情的用戶與商品信息瀏覽互不影響。
2.充分發(fā)揮熱門數(shù)據(jù)的操作效率，商品信息的操作的高效率不會被商品描述的低效率所拖累。
注意 ：
為什么大字段IO效率低 ：
第一是由于數(shù)據(jù)量本身大，需要更長的讀取時間；
第二是跨頁，頁是數(shù)據(jù)庫存儲單位，很多查找及定位操作都是以頁為單位，單頁內(nèi)的數(shù)據(jù)行越多數(shù)據(jù)庫整體性能越好，而大字段占用空間大，單頁內(nèi)存儲行數(shù)少，因此IO效率較低。
第三，數(shù)據(jù)庫以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣表中字段長度較短且訪問頻率較高，內(nèi)存能加載更多的數(shù)據(jù)，命中率更高，減少來磁盤IO，從而提升來數(shù)據(jù)庫性能。
一般來說，某業(yè)務實體中的各個數(shù)據(jù)項的訪問頻次是不一樣的，部分數(shù)據(jù)項可能是占用存儲空間比較大的BLOB或是TEXT。例如上例中的商品描述。所以，當表數(shù)據(jù)量很大時，可以將表按字段切開，將熱門字段、冷門字段分開放置在不同庫中，這些庫可以放在不同的存儲設(shè)置上，避免IO爭搶。垂直切分帶來的性能提升主要集中在熱門數(shù)據(jù)的操作效率上，而且磁盤爭用情況減少。
通常我們按以下原則進行垂直拆分 ：
1、把不常用的字段單獨放在一張表；
2、把text，blob等大字段拆分出來放在附表中；
3、經(jīng)常組合查詢的列放在一張表中；
通過垂直分表能得到來一定程度的提升，但是還沒有達到要求，并且磁盤空間也快不夠來，因為數(shù)據(jù)還是始終限制在一臺服務器，庫內(nèi)垂直分表只解決來單一表數(shù)據(jù)量過大的問題，但沒有將表分布到不同的服務器上，因此每個表還是競爭同一個物理機的CPU、內(nèi)存、網(wǎng)絡IO
、磁盤。
經(jīng)過思考，他把原來的SELLER_DB（賣家?guī)欤譃閬鞵RODUCT_DB (商品庫)和STORE_DB（店鋪庫），并把這兩個庫分散到不同服務器，如下圖 ：
解決業(yè)務層面的耦合，業(yè)務清晰
能對不同業(yè)務的數(shù)據(jù)進行分級管理、維護、監(jiān)控、擴展等
高并發(fā)場景下，垂直分庫一定程度的提升IO、數(shù)據(jù)庫連接數(shù)、降低單機硬件資源的瓶頸
垂直分庫通過將表按業(yè)務分類，然后分庫在不同數(shù)據(jù)庫，并且可以將這些數(shù)據(jù)庫部署在不同服務器上，從而達到多個服務器共同分攤壓力的效果，但是依然沒有解決單表數(shù)據(jù)量過大的問題。
經(jīng)過垂直分庫后，數(shù)據(jù)庫性能問題得到一定程度的解決，但是隨著業(yè)務量的增長，PRODUCT_DB（商品庫）單庫存儲數(shù)據(jù)已經(jīng)超出預估。粗糧統(tǒng)計，目前有8W店鋪，每個店鋪平均150個不同規(guī)格的商品，再算增長，那商品數(shù)量的往1500w+上預估，并且PRODUCT_DB（商品庫）屬于訪問非常頻繁的資源，單臺服務器已經(jīng)無法支撐。此時該如何優(yōu)化？
再次分庫？但是從業(yè)務角度分析，目前情況已經(jīng)無法再次垂直分庫?？梢試L試水平分庫，將店鋪ID為單數(shù)的和店鋪ID為雙數(shù)的商品信息分別放在兩個庫中。
解決來單庫大數(shù)據(jù)，高并發(fā)的性能瓶頸。
提高來系統(tǒng)的穩(wěn)定性及可用性。
穩(wěn)定性體現(xiàn)在IO沖突減少，鎖定減少，可用性指某個庫出問題，部分可用。
當一個應用難以再細粒度的垂直切分，或切分后數(shù)據(jù)量行巨大，存在單庫讀寫、存儲性能瓶頸，這時候就需要進行水平分庫了，經(jīng)過水平切分的優(yōu)化，往往能解決單庫存儲量及性能瓶頸。但由于同一個表被分配在不同的數(shù)據(jù)庫，需要額外進行數(shù)據(jù)操作的路由工作，因此大大提升了系統(tǒng)復雜度。
按照水平分庫的思路對他把PRODUCT_DB_X（商品庫）內(nèi)的表也可以進行水平拆分，其目的也是為解決單表數(shù)據(jù)量大的問題，如下圖 ：
優(yōu)化單一表數(shù)據(jù)量過大而產(chǎn)生的性能問題
避免IO爭搶并減少鎖表的幾率
庫內(nèi)的水平分表，解決來單一表數(shù)據(jù)量過大的問題，分出來的小表中只包含一部分數(shù)據(jù)，從而使得單個表的數(shù)據(jù)量變小，提高檢索性能。
介紹來分庫分表的幾種方式，它們分別是垂直分表、垂直分庫、水平分庫和水平分表 ：
垂直分表 ：可以把一個寬表的字段按訪問頻次，是否是大字段的原則拆分為多個表，這樣既能使業(yè)務清晰，還能提升部分性能。拆分后，盡量從業(yè)務角度避免聯(lián)查，否則性能方面將得不償失。
垂直分庫 ：可以把多個表按業(yè)務耦合松緊歸類，分別存放在不同的庫，這些庫可以分布在不同服務器，從而使訪問壓力被能服務器負載，大大提升性能，同時能提高整體架構(gòu)的業(yè)務清晰度，不同的業(yè)務庫可根據(jù)自身情況定制優(yōu)化方案。但是它需要解決跨庫帶來的所有復雜問題。
水平分庫 ：可以把一個表的數(shù)據(jù)（按數(shù)據(jù)行）分到多個不同的庫，每個庫只有這個表的部分數(shù)據(jù)，這些庫可以分布在不同服務器，從而使訪問壓力被多服務器負載，大大提升性能。它不僅需要解決跨庫帶來的所有復雜問題，還要解決數(shù)據(jù)路由的問題（數(shù)據(jù)路由問題后邊介紹）。
水平分表 ：可以把一個表的數(shù)據(jù)（按數(shù)據(jù)行）分到多個同一個數(shù)據(jù)庫的多張表中，每個表只有這個表的部分數(shù)據(jù)，這樣做能小幅提升性能，它僅僅作為水平分庫的一個補充優(yōu)化。
一般來說，在系統(tǒng)設(shè)計階段就應該根據(jù)業(yè)務耦合松緊來確定垂直分庫，垂直分表方案，在數(shù)據(jù)量及訪問壓力不是特別大的情況，首先考慮緩沖、讀寫分離、索引技術(shù)等方案。若數(shù)據(jù)量極大，且持續(xù)增長，再考慮水平分庫水平分表方案。
分庫分表能有效的緩解來單機和單庫帶來的性能瓶頸和壓力，突破網(wǎng)絡IO、硬件資源、連接數(shù)的瓶頸，同時也帶來了一些問題。
由于分庫分表把數(shù)據(jù)分布在不同庫甚至不同服務器，不可避免會帶來分布式事務問題。
在沒有分庫前，我們檢索商品時可以通過以下SQL對店鋪信息進行關(guān)聯(lián)查詢 ：
SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽] FROM [商品信息] p LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪] WHERE...ORDER BY...LIMIT...
但垂直分庫后【商品信息】和【店鋪信息】不在一個數(shù)據(jù)庫，甚至不在一臺服務器，無法進行關(guān)聯(lián)查詢。
可將原關(guān)聯(lián)查詢分為兩次查詢，第一次查詢的結(jié)果集中找出關(guān)聯(lián)數(shù)據(jù)id，然后根據(jù)id發(fā)起第二次請求得到關(guān)聯(lián)數(shù)據(jù)，最后將獲得到的數(shù)據(jù)進行拼裝。
跨節(jié)點多庫進行查詢時，limit分頁、order by排序等問題，就變得比較復雜了。需要先在不同的分片節(jié)點中將數(shù)據(jù)進行排序并返回，然后將不同分片返回的結(jié)果集進行匯總和再次排序。
如，進行水平分庫后的商品庫，按ID倒序排序分頁，取第一頁 ：
在分庫分表環(huán)境中，由于表中數(shù)據(jù)同時存在不同數(shù)據(jù)庫中，主鍵值平時使用的自增長將無用武之地，某個分區(qū)數(shù)據(jù)庫生成的ID無法保證全局唯一。因此需要單獨設(shè)計全局主鍵，比避免跨庫主鍵重復問題。
實際的應用場景中，參數(shù)表、數(shù)據(jù)字典表等都是數(shù)據(jù)量較小，變動少，而且屬于高頻聯(lián)合查詢的依賴表。例子中地理區(qū)域表也屬于此類型。
可以將這類表在每個數(shù)據(jù)庫都保存一份，所有對公共表的更新操作都同時發(fā)送到分庫執(zhí)行。
由于分庫分表之后，數(shù)據(jù)被分散在不同的數(shù)據(jù)庫、服務器。因此，對數(shù)據(jù)的操作也就無法通過常規(guī)方式完成，并且它還帶來了一系列的問題。好在，這些問題不是所有都需要我們在應用層面上解決，其中Sharding-JDBC中間件可供選擇。
Sharding-JDBC是當當網(wǎng)研發(fā)的開源分布式數(shù)據(jù)庫中間件，從 3.0 開始Sharding-JDBC被包含在 Sharding-Sphere 中，之后該項目進入進入Apache孵化器，4.0版本之后的版本為Apache版本。
ShardingSphere是一套開源的分布式數(shù)據(jù)庫中間件解決方案組成的生態(tài)圈，它由Sharding-JDBC、Sharding- Proxy和Sharding-Sidecar(計劃中)這3款相互獨立的產(chǎn)品組成。 他們均提供標準化的數(shù)據(jù)分片、分布式事務和 數(shù)據(jù)庫治理功能，可適用于如Java同構(gòu)、異構(gòu)語言、容器、云原生等各種多樣化的應用場景。
官方地址:https://shardingsphere.apache.org/document/current/cn/overview/
咱們目前只需關(guān)注Sharding-JDBC，它定位為輕量級Java框架，在Java的JDBC層提供的額外服務。 它使用客戶端 直連數(shù)據(jù)庫，以jar包形式提供服務，無需額外部署和依賴，可理解為增強版的JDBC驅(qū)動，完全兼容JDBC和各種 ORM框架。
Sharding-JDBC的核心功能為數(shù)據(jù)分片和讀寫分離，通過Sharding-JDBC，應用可以透明的使用jdbc訪問已經(jīng)分庫 分表、讀寫分離的多個數(shù)據(jù)源，而不用關(guān)心數(shù)據(jù)源的數(shù)量以及數(shù)據(jù)如何分布。
適用于任何基于Java的ORM框架，如: Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
基于任何第三方的數(shù)據(jù)庫連接池，如:DBCP, C3P0, BoneCP, Druid, HikariCP等。
支持任意實現(xiàn)JDBC規(guī)范的數(shù)據(jù)庫。目前支持MySQL，Oracle，SQLServer和PostgreSQL。
性能損耗測試 ：服務器資源充足、并發(fā)數(shù)相同，比較JDBC和Sharding-JDBC性能損耗，Sharding-JDBC相對JDBC損耗不超過7%。
基準測試性能對比
性能對比測試:服務器資源使用到極限，相同的場景JDBC與Sharding-JDBC的吞吐量相當。
性能對比測試:服務器資源使用到極限，Sharding-JDBC采用分庫分表后，Sharding-JDBC吞吐量較JDBC不分表有接近2倍的提升。
