分库分表的设计思路让大系统变简单

 一、问题：铁路的售票系统的数据量是海量吗？
 
  不是。因为数据量不大，真不大。

  每一个车次与车次间是独立的，每车次不超过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问题。

供大家一起讨论、分享经验。