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