一、问题：铁路的售票系统的数据量是海量吗？
不是。因为数据量不大，真不大。
每一个车次与车次间是独立的，每车次不超过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问题。