以铁路的售票系统来说明分库分表对架构的影响。
一、问题：铁路的售票系统的数据量是海量吗？
不是。因为数据量不大，真不大。
每一个车次与车次间是独立的，每车次不超过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问题。
供大家一起讨论、分享经验。
