以鐵路的售票系統來說明分庫分表對架構的影響。
一、問題：鐵路的售票系統的數據量是海量嗎？
不是。因為數據量不大，真不大。
每一個車次與車次間是獨立的，每車次不超過2000張票，一天發車不超過50萬車次；
以預售期15天來講，15*0.1億張不超過1.5億筆的熱線數據，稱不上海量數據的。
再加上可以按線路分庫，更是不到千萬級的單表容量。已經發車完成的進入歸檔分析。
即數據庫按路線使用不同的服務器，不同的車次放在不同的表中。並發量鎖真不大。
當然，如果不分庫分表，再加上不歸檔處理，鐵路的售票系統的數據量看起來是海量的；
關鍵是這海量的數據沒有意義。
二、如何分庫分表？
2.1 分庫，考慮數據間沒有直接關系和服務器如何部署
鐵路的售票系統為例來說，按路線分庫，再按車次分表是合理的。
設路線有1萬條，按每1000條需要兩台服務器(一台熱機沉余)，不到20台服務器
如果使用SAN存儲，則使用SAN作為存儲，本機作為熱機沉余，只需要10台。
當然使用mySQL這種經濟型數據庫，服務器需要更多來防災；
即可以采用雙寫或多寫的方式來保證數據的絕對安全。
2.2分表，考慮數據間不存在重疊，即數據滿足二分原則
鐵路的售票系統的任意兩個車次是沒有關系的，所以可以分表。
電信的某個用戶的通話和其它用戶的通話記錄，也是沒有關系，所以可以分表處理
（實際上電信的系統，分庫分表后也是不大的，難在后台的計費、結算等規則）
三、數據庫訪問接口
1. 元數據：如何識別到當前要處理的數量在哪張表？
鐵路的售票系統會有一個車次管理系統，例2012年2月12日 D3206 車次，
按預先設計的在哪台服務器的哪個庫，建哪個表。
2.建立元數據的規則：即具體如何分庫分表的規則
這個就是數據庫的訪問接口。
3.數據庫訪問接口的透明程度
即哪個層知道哪些元數據信息。
例，是否讓窗口售票的客戶端來解析元數據的規則然后緩存，還是通過中間件來解析緩存的
具體各層使用怎樣透明程度，和業務性質、節點和數據中心的拓撲等有關。
四、歷史數據歸檔與分析
1.使用分庫分表后，數據需要歸檔，分析處理的程序變得復雜，但使聯機交易變得簡單
2.分析：要注意是針對熱線數據分析、歸檔數據分析、混合分析有關，
通過分庫分表和歸檔，更方便使用分布式的統計方案。
具體可以參考，淘寶的開放平台架構師寫的文章：
Beatles小記-分布式數據流分析框架(一) http://www.blogjava.net/cenwenchu/archive/2011/12/07/365776.html
結論：分庫分表跟不分庫分表，整個架構是完全不一樣的。
像鐵票的售票系統、淘寶、電信、銀行等，絕對要采用分庫分表的數據存儲方案，
來解決數據量的增長而不影響性能的問題。
像淘寶等互聯網應用還要解決帶寬即CDN問題。
供大家一起討論、分享經驗。