分类目录

链接

2012年九月
« 8月   10月 »
 12
3456789
10111213141516
17181920212223
24252627282930

近期文章

热门标签

博主推荐

现在位置:    首页 > MySQL, SQL Server > 正文
解决数据量的增长而不影响性能的问题(1)
MySQL, SQL Server 暂无评论 阅读(1,631)

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

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

 

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

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

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

本文版权归数据库之家所有,转载引用请完整注明以下信息:
本文作者:Bruce
本文地址:解决数据量的增长而不影响性能的问题(1) | 数据库之家