確定了這個小節的主題之後，我們回顧一下，一個互聯網應用從小變大的過程中遇到的一些問題，通過遇到的問題來引出我們拆分RDBMS的重要性。
系統剛開始的時候，因爲系統剛上線，用戶不多，那個時候，所有的數據都放在了同一個數據庫中，這個時候因爲用戶少壓力小，一個數據庫完全可以應付的了，但是隨着運營那些哥們辛苦的吶喊和拼命的推廣以後，突然有一天發現，oh,god,用戶數量突然變多了起來，隨之而來的就是數據庫這哥們受不了，它終於在某一天大家都和愜意的時候掛掉啦。此時，咱們搞技術的哥們，就去看看究竟是啥原因，我們查了查以後，發現原來是數據庫讀取壓力太大了，此時咱們都清楚是到了讀寫分離的時候，這個時候我們會配置一個server爲master節點，然後配幾個salve節點，這樣以來通過讀寫分離，使得讀取數據的壓力分攤到了不同的salve節點上面，系統終於又恢復了正常，開始正常運行了。但是好景還是不長，有一天我們發現master這哥們撐不住了，它負載老高了，汗流浹背，隨時都有翹掉的風險，這個時候就需要咱們垂直分區啦（也就是所謂的分庫），比如將商品信息，用戶信息，交易信息分別存儲到不同的數據庫中，同時還可以針對商品信息的庫採用master，salve模式，OK，通過分庫以後，各個按照功能拆分的數據庫寫壓力被分擔到了不同的server上面，這樣數據庫的壓力終於有恢復到正常狀態。但是是不是這樣，我們就可以高枕無憂了呢？NO,這個NO，不是我說的，是前輩們通過經驗總結出來的，隨着用戶量的不斷增加，你會發現系統中的某些表會變的異常龐大，比如好友關係表，店鋪的參數配置表等，這個時候無論是寫入還是讀取這些表的數據，對數據庫來說都是一個很耗費精力的事情，因此此時就需要我們進行“水平分區”了（這就是俗話說的分表，或者說sharding）。
上面說了很多，無非就是告訴大家一個事實“數據庫是系統中最不容易scale out的一層”，一個大型的互聯網應用必然會經過一個從單一DB server,到Master/salve,再到垂直分區（分庫），然後再到水平分區（分表，sharding）的過程，而在這個過程中，Master/salve 以及垂直分區相對比較容易，對應用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個分區join查詢數據，如何平衡各個shards的負載等等，這個時候就需要一個通用的DAL框架來屏蔽底層數據存儲對應用邏輯的影響，使得底層數據的訪問對應用透明化。