以電商領(lǐng)域為例，訂單庫將訂單相關(guān)的數(shù)據(jù)（訂單銷售，訂單售后，訂單任務(wù)處理等數(shù)據(jù)）都放在一個數(shù)據(jù)庫
中。對于訂單的銷售數(shù)據(jù)，性能第一，需要能夠承受促銷期間每分鐘幾萬到幾十萬的訂單壓力；而售后數(shù)據(jù)，在訂
單生成后，用于訂單物流及訂單克服等，性能壓力不明顯，但是需要保證及時性。將訂單的銷售數(shù)據(jù)與售后數(shù)據(jù)放
在同一個庫中會導(dǎo)致促銷期間數(shù)據(jù)庫壓力增大，影響到售后業(yè)務(wù)的進(jìn)行。這個時候我們需要考慮拆分?jǐn)?shù)據(jù)庫。
垂直分庫在“微服務(wù)”盛行的今天已經(jīng)非常普及了?；舅悸肪褪前凑諛I(yè)務(wù)模塊來劃分出不同的數(shù)據(jù)庫。而
不是將所有的數(shù)據(jù)表都放在同一個數(shù)據(jù)庫中。數(shù)據(jù)庫層面的拆分能夠使不同業(yè)務(wù)類型的數(shù)據(jù)進(jìn)行獨立的管理、維
護(hù)，監(jiān)控和擴(kuò)展。當(dāng)然錯誤的業(yè)務(wù)拆分也會帶來很多問題（跨庫join，分布式事務(wù)）。
垂直分庫可以按照業(yè)務(wù)模塊來劃分出不同的數(shù)據(jù)庫。將不同業(yè)務(wù)的數(shù)據(jù)表劃分到不同數(shù)據(jù)中，從而解決了不同
業(yè)務(wù)系統(tǒng)間的熱點問題。但是仍然無法解決單一業(yè)務(wù)數(shù)據(jù)庫及數(shù)據(jù)表數(shù)據(jù)量過于龐大的問題。例如對于訂單銷售數(shù)
據(jù)，如果遇到大型的促銷（如雙11,618等），數(shù)據(jù)庫TPS和QPS達(dá)到上限，單個銷售訂單庫無法滿足業(yè)務(wù)的需求。
當(dāng)訂單表相關(guān)數(shù)據(jù)量過大時也會造成單臺數(shù)據(jù)庫服務(wù)器硬盤容量飽和，不能滿足業(yè)務(wù)需求。因此還需要進(jìn)行進(jìn)一步
的拆分。
當(dāng)單表的數(shù)據(jù)量越來越大時，需要對數(shù)據(jù)庫進(jìn)行水平拆分。水平拆分就是將表中的數(shù)據(jù)行按照一定規(guī)律分布到
不同的數(shù)據(jù)表中。這樣來降低單表數(shù)據(jù)量，優(yōu)化查詢性能。但是本質(zhì)上這些表還是保存在同一個數(shù)據(jù)庫中，所以
庫級別上仍然會有IO和磁盤瓶頸。由于數(shù)據(jù)庫TPS有限，所以需要考慮分庫，把分表放在分庫里面。減輕單庫的壓
力，增加總的TPS。
常見的水平切分算法有：范圍法和哈希法。
垂直水平拆分，是綜合了垂直和水平拆分方式的一種混合方式，垂直拆分把不同類型的數(shù)據(jù)存儲到不同庫中，再結(jié)合水平拆分，使單表數(shù)據(jù)量保持在合理范圍內(nèi)，提升總TPS，提升性能。
當(dāng)伴隨著某一個表的數(shù)據(jù)量越來越大，以至于不能承受的時候，就需要對它進(jìn)行進(jìn)一步的切分。范圍法是按照時間區(qū)間和ID區(qū)間來切分。如：ID為1-10000的放到A表中，ID為10000~20000的放到B表中。這樣的擴(kuò)展就是可預(yù)見的。
范圍法的優(yōu)點：
1.單表大小可控，天然水平擴(kuò)展，擴(kuò)容非常簡單。
2.切分策略簡單，根據(jù)主鍵或時間戳很容易定位到數(shù)據(jù)在哪個上
范圍法的缺點：
1.表中必須有滿足自增特性的屬性，例如主鍵必須滿足遞增特性或使用時間戳
2.數(shù)據(jù)量不均衡，新擴(kuò)展出的表初期數(shù)據(jù)會比較少
3.請求量不均衡，一般來說新產(chǎn)生的數(shù)據(jù)往往比歷史數(shù)據(jù)有更高的活躍度，更容易被訪問。因此新的數(shù)據(jù)表
的負(fù)載往往比歷史表要高，導(dǎo)致服務(wù)器利用率不均衡。
哈希法一般采用mod來切分，一開始就要確定要切分的數(shù)據(jù)庫的個數(shù)，通過關(guān)鍵字hash取模來決定存儲到哪個數(shù)據(jù)表中。這種方法能夠平均的分配數(shù)據(jù)，但是伴隨著數(shù)據(jù)量的增大，需要進(jìn)行擴(kuò)展的時候無法做到無線擴(kuò)容。每增加節(jié)點的時候，就要對hash算法重新運算，調(diào)整數(shù)據(jù)表中的數(shù)據(jù)。
哈希法的優(yōu)點：
1.切分策略簡單，根據(jù)關(guān)鍵字，按照hash可以很容易定位到數(shù)據(jù)在哪個數(shù)據(jù)庫上。
2.數(shù)據(jù)量均衡，只要關(guān)鍵字是均衡的，數(shù)據(jù)在各個庫上的分布就是均勻的
3.請求量均衡，只要關(guān)鍵字是均衡的，數(shù)據(jù)在各個庫上的分布就是均勻的
哈希法的缺點：
1.擴(kuò)容麻煩，如果容量不夠，要增加一個庫，重新hash可能會導(dǎo)致數(shù)據(jù)遷移，如何平滑的進(jìn)行數(shù)據(jù)遷移，是
一個需要解決的問題。
數(shù)據(jù)庫進(jìn)行分表分庫后，大表中的數(shù)據(jù)分散存儲在各個數(shù)據(jù)庫中。在進(jìn)行查詢時往往需要通過范圍法或者哈希法找到對應(yīng)的數(shù)據(jù)庫進(jìn)行查詢。但這只能滿足按照關(guān)鍵字來進(jìn)行的查詢。當(dāng)業(yè)務(wù)中存在按照其他屬性進(jìn)行查詢的需求時就無法滿足了，此時需要遍歷全部數(shù)據(jù)庫，顯然不可接受。
路由表的策略是它單獨維護(hù)一張路由表，根據(jù)用戶的某一屬性來查找路由表決定使用哪個數(shù)據(jù)庫，這種方式是一種更加通用的方案。查詢請求先通過屬性查找路由表，找到該條數(shù)據(jù)所在的數(shù)據(jù)庫，再進(jìn)行查詢。
數(shù)據(jù)庫進(jìn)行分表分庫后，大表中的數(shù)據(jù)分散存儲在各個數(shù)據(jù)庫中。在進(jìn)行查詢時往往需要通過范圍法或者哈希法找到對應(yīng)的數(shù)據(jù)庫進(jìn)行查詢。但這只能滿足按照關(guān)鍵字來進(jìn)行的查詢。當(dāng)業(yè)務(wù)中存在按照其他屬性進(jìn)行查詢的需求時就無法滿足了，此時需要遍歷全部數(shù)據(jù)庫，顯然不可接受。
索引表是用來維護(hù)其他屬性與關(guān)鍵字的對應(yīng)關(guān)系，當(dāng)通過其他屬性訪問數(shù)據(jù)表時，先通過索引表找到該屬性對應(yīng)的關(guān)鍵字，在通過關(guān)鍵字按照范圍法或者哈希法找到對應(yīng)的數(shù)據(jù)庫進(jìn)行取數(shù)。
更優(yōu)化的一種方案是將映射的結(jié)果存儲在緩存中，屬性與關(guān)鍵字的映射關(guān)系很少會發(fā)生變化，一旦放入緩存無需淘汰，緩存命中率超高。如果數(shù)據(jù)量過大，可以根據(jù)屬性自動進(jìn)行cache的水平切分。
數(shù)據(jù)庫拆分的目的是將單一數(shù)據(jù)庫的大表數(shù)據(jù)拆分到不同的數(shù)據(jù)庫的數(shù)據(jù)表中，從而達(dá)到消除對單一服務(wù)器磁盤容量和TPS的限制，做到可擴(kuò)展。除此之外，我們在進(jìn)行數(shù)據(jù)表拆分時還需要考慮業(yè)務(wù)上的應(yīng)用場景，采用合理的分庫分表策略，否則會產(chǎn)生跨庫join及分布式事務(wù)等問題。
那么，合理的分表分庫策略需要如何確定呢？
1.合理分析業(yè)務(wù)場景，梳理出不同參與者對數(shù)據(jù)的需求場景以及對一致性和實時性的要求。
2.根據(jù)第一步的梳理結(jié)果，確定數(shù)據(jù)表需要支持查詢的屬性范圍。并據(jù)此確定分庫分表策略，思路是
同一維度條件的查詢結(jié)果保證數(shù)據(jù)存儲在同一個數(shù)據(jù)庫表中，避免跨庫join。
3.針對非uid屬性的查詢，可以采用“建立非uid屬性到uid的映射關(guān)系”的架構(gòu)方案。
4.對訪問量低，可用性要求不高，一致性要求沒這么嚴(yán)格的查詢業(yè)務(wù)系統(tǒng)，可以采用“前臺與后臺分離”的
架構(gòu)方案，避免少數(shù)批量請求耗盡資源，導(dǎo)致數(shù)據(jù)庫cpu瞬間占滿，影響其他應(yīng)用的訪問。
5.針對“多key”類業(yè)務(wù)，需要采用“基因法”，“數(shù)據(jù)冗余法”，“前臺與后臺分離”等架構(gòu)設(shè)計方法。
UID做為數(shù)據(jù)表的主鍵，需要保證全局唯一。以保證分庫分表后，同一業(yè)務(wù)的不同庫表的數(shù)據(jù)的uid不能重復(fù)。
唯一UID的方案有很多，主流的有如下幾種：
Sequence ID是數(shù)據(jù)庫自增長序列或字段，最常見的方式。由數(shù)據(jù)庫維護(hù)，數(shù)據(jù)庫唯一。
優(yōu)點：
缺點：
優(yōu)化方案：
UUID是一個32位16進(jìn)制的序列。可以利用數(shù)據(jù)庫也可以利用程序生成，一般來說全球唯一。GUID是微軟對UUID標(biāo)準(zhǔn)的實現(xiàn)，UUID還有很多其他實現(xiàn)。
優(yōu)點：
簡單，代碼方便。
全球唯一，在遇見數(shù)據(jù)遷移，系統(tǒng)數(shù)據(jù)合并，或者數(shù)據(jù)庫變更等情況下，可以從容應(yīng)對。
缺點：
沒有排序，無法保證趨勢遞增。
UUID往往是使用字符串存儲，查詢的效率比較低。
存儲空間比較大，如果是海量數(shù)據(jù)庫，就需要考慮存儲量的問題。
傳輸數(shù)據(jù)量大
不可讀。
優(yōu)化方案：
為了解決UUID不可讀，可以使用UUID to Int64的方法。
Snowflake是Twitter開源的分布式ID生成算法，結(jié)果是一個long型的ID。其核心思想是：使用41bit作為毫秒數(shù)，10bit作為機(jī)器的ID（5個bit是數(shù)據(jù)中心，5個bit的機(jī)器ID，可以支持1024個節(jié)點），12bit作為毫秒內(nèi)的流水號（意味著每個節(jié)點在每毫秒可以產(chǎn)生4096個ID），最后還有一個符號位，永遠(yuǎn)是0。snowflake算法可以根據(jù)自身項目的需要進(jìn)行一定的修改。比如估算未來的數(shù)據(jù)中心個數(shù)，每個數(shù)據(jù)中心的機(jī)器數(shù)以及統(tǒng)一毫秒可以能的并發(fā)數(shù)來調(diào)整在算法中所需要的bit數(shù)。
優(yōu)點：
不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。
ID按照時間在單機(jī)上是遞增的。
缺點：
在單機(jī)上是遞增的，但是由于涉及到分布式環(huán)境，每臺機(jī)器上的時鐘不可能完全同步，也許有時候也會出現(xiàn)不是全局遞增的情況。
舉例，假設(shè)某公司ID生成器服務(wù)的需求如下：
單機(jī)高峰并發(fā)量小于1W，預(yù)計未來5年單機(jī)高峰并發(fā)量小于10W
有2個機(jī)房，預(yù)計未來5年機(jī)房數(shù)量小于4個
每個機(jī)房機(jī)器數(shù)小于100臺
目前有5個業(yè)務(wù)線有ID生成需求，預(yù)計未來業(yè)務(wù)線數(shù)量小于10個
…
分析過程如下：
高位取從2017年1月1日到現(xiàn)在的毫秒數(shù)（假設(shè)系統(tǒng)ID生成器服務(wù)在這個時間之后上線），假設(shè)系統(tǒng)至少運行10年，那至少需要10年*365天*24小時*3600秒*1000毫秒=320*10^9，差不多預(yù)留39bit給毫秒數(shù)
每秒的單機(jī)高峰并發(fā)量小于10W，即平均每毫秒的單機(jī)高峰并發(fā)量小于100，差不多預(yù)留7bit給每毫秒內(nèi)序列號
5年內(nèi)機(jī)房數(shù)小于4個，預(yù)留2bit給機(jī)房標(biāo)識
每個機(jī)房小于100臺機(jī)器，預(yù)留7bit給每個機(jī)房內(nèi)的服務(wù)器標(biāo)識
業(yè)務(wù)線小于10個，預(yù)留4bit給業(yè)務(wù)線標(biāo)識
這樣設(shè)計的64bit標(biāo)識，可以保證：
每個業(yè)務(wù)線、每個機(jī)房、每個機(jī)器生成的ID都是不同的
同一個機(jī)器，每個毫秒內(nèi)生成的ID都是不同的
同一個機(jī)器，同一個毫秒內(nèi)，以序列號區(qū)區(qū)分保證生成的ID是不同的
將毫秒數(shù)放在最高位，保證生成的ID是趨勢遞增的
flickr開發(fā)團(tuán)隊在2010年撰文介紹了flickr使用的一種主鍵生成測策略，同時表示該方案在flickr上的實際運行效果也非常令人滿意。它與一般Sequence表方案有些類似，但卻很好地解決了性能瓶頸和單點問題，是一種非?？煽慷咝У娜种麈I生成方案。整體思想是：建立兩臺以上的數(shù)據(jù)庫ID生成服務(wù)器，每個服務(wù)器都有一張記錄各表當(dāng)前ID的Sequence表，但是Sequence中ID增長的步長是服務(wù)器的數(shù)量，起始值依次錯開，這樣相當(dāng)于把ID的生成散列到了每個服務(wù)器節(jié)點上。例如：如果我們設(shè)置兩臺數(shù)據(jù)庫ID生成服務(wù)器，那么就讓一臺的Sequence表的ID起始值為1,每次增長步長為2,另一臺的Sequence表的ID起始值為2,每次增長步長也為2，那么結(jié)果就是奇數(shù)的ID都將從第一臺服務(wù)器上生成，偶數(shù)的ID都從第二臺服務(wù)器上生成，這樣就將生成ID的壓力均勻分散到兩臺服務(wù)器上，同時配合應(yīng)用程序的控制，當(dāng)一個服務(wù)器失效后，系統(tǒng)能自動切換到另一個服務(wù)器上獲取ID，從而保證了系統(tǒng)的容錯。
優(yōu)點：高可用、ID較簡潔
缺點：需要單獨的數(shù)據(jù)庫集群
組合UID，是一種帶有業(yè)務(wù)屬性的UID方案，取UID的前N位，再通過業(yè)務(wù)屬性（其他主鍵）的二級制后N位來生成UID。例如：訂單UID=60位全局唯一id+userid二進(jìn)制末4位（如userid=666，其二級制為：0000 0010 10011010 ，取1010），此時省的訂單id具有了用戶的基因，在制定分表分庫規(guī)則時，可以據(jù)此規(guī)則將同一用戶的訂單都放到同一張庫表中。
優(yōu)點：
1.解決UUID無序的問題
2.可以滿足滿足業(yè)務(wù)屬性條件的數(shù)據(jù)都存儲在同一個庫表中，避免查詢時的“跨庫join”的情況。如分庫分表時滿足同一用戶生成的訂單都在同一個庫表中。
