paulwong

铁路的售票系统来说明分库分表对架构的影响

一、问题:铁路的售票系统的数据量是海量吗?

不是。因为数据量不大,真不大。

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

posted on 2012-01-17 13:24 paulwong 阅读(513) 评论(0)  编辑  收藏 所属分类: 性能优化火车站售票系统


只有注册用户登录后才能发表评论。


网站导航: