一、問題：鐵路的售票系統的數據量是海量嗎？
不是。因為數據量不大，真不大。
每一個車次與車次間是獨立的，每車次不超過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.分析：要注意是針對熱線數據分析、歸檔數據分析、混合分析有關，
通過分庫分表和歸檔，更方便使用分布式的統計方案。
具體可以參考，淘寶的開放平臺架構師寫的文章：
結論：分庫分表跟不分庫分表，整個架構是完全不一樣的。
像鐵票的售票系統、淘寶、電信、銀行等，絕對要采用分庫分表的數據存儲方案，
來解決數據量的增長而不影響性能的問題。
像淘寶等互聯網應用還要解決帶寬即CDN問題。