首页 > 数据库 > MySQL > 正文
基于MySQL分库分表方案简介
2012-03-05       个评论      
收藏    我要投稿
一、    背景介绍

1.大数据量的存储需要大量的数据库资源;

2.数据量的不断增长要求数据库存储具有可扩展性;

3.在保证大数据量的情况下,要保证性能、高可用性等质量要求;

4.现有框架中没有彻底解决大数据量的存储问题;

5.Oracle等海量存储方案价格不菲,采用MySQL进行分库分表节约IT成本。

二、    可行性分析

1.     风险评估

1)       DBA数据库管理的资源和规范要求;

2.    业务数据量规模和变化的影响

1)       对于事先可规划的中等以上数据规模,采用单库分表(一个数据库实例,分多张表)、读写分离、或者多库多表(多个数据库实例,多张表)可以满足业务需求,且相应设计和实现相对简单,不易出错。

2)       对于初期数据规模不可准确预知,但随着业务发展数据规模不断增长的系统,要求数据存储具有可扩展性。这种可扩展性通过分库分表解决,要求分库分表在路由上具有极强的伸缩性,这也是分库分表的难点,本方案提出一个循序渐进的实现路线逐步解决这个问题。

3.    技术积累

1)       公司已有简单的分库分表方案

2)       这个方案缺乏扩展性

3)       本方案将提出短期实现一定扩展性、中长期高可扩展性的方案

4.    开源或产品

1)       商业版数据库Sharding:MySQL Proxy,提供MySQL协议接口(非JDBC),主从结构,可以负载平衡,读写分离,failover等,lua语法复杂,不支持大数据量的分库分表;

2)       Amoeba,支持分数据库实例,每个数据相同的表,不支持事务;类似MySQL Proxy,设计上抛弃lua,更简单;

3)       阿里集团研究院开源的CobarClient,主要面向小规模的数据库sharding集群访问,基于ibatis,需要规划数据规模,缺乏扩展性;另外有Cobar,阿里集团内部的一个完整DAL层,实现完整JDBC代理;

4)       HibernateShards,Hibernate提供的sharding,支持分数据库实例,比较复杂,事先规划数据规模,和框架不符;

5)       guzz,多库(虚拟的数据库,实际数据库的路由规则仍然自定义)、表分切、读写分离,以及多台数据库之间透明的分布式事务支持,设计目标是支持大型在线生产应用;需完全替换ibatis;完全和框架不符。

6)       TDDL,淘宝的DAL,很强的分库分表能力,仍然需要数据量实现规划,动态扩展有限。

7)       以上某些产品在一定程度上可以满足我们的需求,但不能彻底解决我们大数据量可扩展的问题。

三、    性能指标

1.       和没有引入分库分表时相比,每次操作最大延迟<1ms;

四、    特性列表和RoadMap

1.     垂直分库,不同业务数据使用不同数据库实例存储

2.     数据切分:

a)       根据切分字段Hash取模;

b)       确定需要切分的数据,尽量将可能进行关联的分片数据放在一个数据库实例中,例如同一用户的基本信息、好友信息或者文件信息等;

3.     短期:分库分表

a)       数据库实例编号递增

b)       每个数据库内分表序号从1递增,不全局编号

c)       基于数据源(ibatis基础上)拦截建立访问层,应用感知

d)       应用需在底层进行数据源、分布式事务考虑和管理等

e)       可扩展性:只支持向上扩展,不支持收缩

4.     长期:数据库访问层

a)       建立灵活的数据切分和路由规则

b)       支持MySQL集群

c)       读写分离和负载均衡

d)       可用性探测

e)       分布式事务

f)        对应用透明

 

附录:

\

\


摘自 doliu6的专栏

点击复制链接 与好友分享!回本站首页
上一篇:mysql 发生系统错误1067的解决方法
下一篇:关于mysql出现大量locked进程
相关文章
图文推荐
文章
推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训
版权所有: 红黑联盟--致力于做实用的IT技术学习网站